Bug#1072787: elpa-debian-el: support filing RFS bugs
Package: elpa-debian-el Version: 37.12 Severity: wishlist It would be useful to support filing RFS bugs through debian-bug. Nowadays people mostly use mentors.d.n to host packages waiting for sponsors, which also provide an RFS template for filing such bugs, therefore the most straightforward way to support it is to take advantage of the `mailto' link generated on that page instead of using a custom built template which may become out-of-sync with the RFS template. I am experimenting an implementation and will push to team repo once proven to be stable. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-5+b1 ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 ii emacsen-common 3.0.5 ii reportbug 12.0.0 ii xz-utils5.4.1-0.2 ii zstd1.5.4+dfsg2-5 Versions of packages elpa-debian-el recommends: ii emacs 1:29.3+1-3~bpo12+1 ii emacs-gtk [emacs] 1:29.3+1-3~bpo12+1 ii wget 1.21.3-1+b2 elpa-debian-el suggests no packages. -- no debconf information
Bug#1072556: RFS: elpa-rust-mode/1.0.5+git20240520.d00d83d-1 [ITA] [RC] -- Major Emacs mode for editing Rust source code
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "elpa-rust-mode": * Package name : elpa-rust-mode Version : 1.0.5+git20240520.d00d83d-1 Upstream contact : The Rust Project Developers * URL : https://github.com/rust-lang/rust-mode * License : Apache-2.0 or MIT * Vcs : https://salsa.debian.org/emacsen-team/rust-mode Section : editors The source builds the following binary packages: elpa-rust-mode - Major Emacs mode for editing Rust source code To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elpa-rust-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elpa-rust-mode/elpa-rust-mode_1.0.5+git20240520.d00d83d-1.dsc Changes since the last upload: elpa-rust-mode (1.0.5+git20240520.d00d83d-1) unstable; urgency=medium . [ Nicholas D Steeves ] * Drop emacs24 from Enhances (package does not exist in bullseye). * Matthew Kraai has moved to Emeritus status; remove him from Uploaders on his request. . [ Xiyue Deng ] * Sync to latest upstream snapshot (d00d83d) (Closes: #1072555) * Drop obsolete patches * Skip upstream Makefile which relies on eask * Drop obsolete override_dh_auto_test and refine override_dh_auto_clean * Include all source files in d/elpa * Migrate from compat to debhelper-compat version 13 * Drop unnecessary parameter "--parallel" with debhelper-compat 13 * Drop obsolete version requirements from dh-elpa and emacs * Declare Standards-Version 4.7.0; no change needed * Extend package description using upstream introduction * Drop Built-Using from "Architecture: all" package * Add myself as uploader (Closes: 1021460) * Modernize d/watch with special substitute strings * Rename license from Expat to MIT following upstream * Use https in Format URL * Update copyright years * Add copyright information for debian/* * Add Upstream-Contact * Add d/upstream/metadata * Add "Rules-Requires-Root: no" to source package * Add ${elpa:Depends} to Depends of binary package Regards, -- Xiyue Deng
Bug#1072555: elpa-rust-mode: This is an obsolete snapshot of the packaging
Package: elpa-rust-mode Version: 1.0.5+git20240301.6d86af4-1 Severity: serious Dear Maintainer, This is a placeholder bug for the current version in unstable, which is now being obsoleted by a newer snapshot prepared on mentors[1]. [1] https://mentors.debian.net/package/elpa-rust-mode/ -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-rust-mode depends on: ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 ii emacsen-common 3.0.5 Versions of packages elpa-rust-mode recommends: ii emacs 1:29.3+1-3~bpo12+1 ii emacs-gtk [emacs] 1:29.3+1-3~bpo12+1 elpa-rust-mode suggests no packages. -- no debconf information
Bug#1072554: RFS: emacs-dart-mode/1.0.7+git20240523.44beb62-2 -- Major mode for editing Dart files
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-dart-mode": * Package name : emacs-dart-mode Version : 1.0.7+git20240523.44beb62-2 Upstream contact : Jen-Chieh Shen * URL : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-dart-mode Section : editors The source builds the following binary packages: elpa-dart-mode - Major mode for editing Dart files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-dart-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-dart-mode/emacs-dart-mode_1.0.7+git20240523.44beb62-2.dsc Changes since the last upload: emacs-dart-mode (1.0.7+git20240523.44beb62-2) unstable; urgency=medium . * Source-only upload This is required for emacs-dart-mode to migrate to testing Regards, -- Xiyue Deng
Bug#1072553: RFS: emacs-corfu-terminal/0.7-2 -- Corfu popup on terminal
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-corfu-terminal": * Package name : emacs-corfu-terminal Version : 0.7-2 Upstream contact : Akib Azmain Turja * URL : https://codeberg.org/akib/emacs-corfu-terminal * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-corfu-terminal Section : editors The source builds the following binary packages: elpa-corfu-terminal - Corfu popup on terminal To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-corfu-terminal/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-corfu-terminal/emacs-corfu-terminal_0.7-2.dsc Changes since the last upload: emacs-corfu-terminal (0.7-2) unstable; urgency=medium . * Source-only upload This is required for it to migrate to testing. Regards, -- Xiyue Deng
Bug#1072552: RFS: clojure-mode/5.19.0-1 -- extra font-locking for clojure-mode
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "clojure-mode": * Package name : clojure-mode Version : 5.19.0-1 Upstream contact : Bozhidar Batsov * URL : https://github.com/clojure-emacs/clojure-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/clojure-mode Section : lisp The source builds the following binary packages: elpa-clojure-mode - Emacs major mode for Clojure code elpa-clojure-mode-extra-font-locking - extra font-locking for clojure-mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/clojure-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/clojure-mode/clojure-mode_5.19.0-1.dsc Changes since the last upload: clojure-mode (5.19.0-1) unstable; urgency=medium . * New upstream release * Add d/salsa-ci.yml with default settings * Stop using single-debian-patch to be compatible with dgit * Update Standards-Version to 4.7.0; no change needed * Keep testing files * Add patch to drop code for detecting clojure-mode source directory - This fixes autopkgtest stucking * Reinstate dh_elpa_test now that autopkgtest is fixed * Update debian copyright year in d/copyright * Add `Rules-Requires-Rules: no' in d/control Regards, -- Xiyue Deng
Bug#1072384: RFS: emacs-dart-mode/1.0.7+git20240523.44beb62-1 [ITP] -- Major mode for editing Dart files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-dart-mode": * Package name : emacs-dart-mode Version : 1.0.7+git20240523.44beb62-1 Upstream contact : Jen-Chieh Shen * URL : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-dart-mode Section : editors The source builds the following binary packages: elpa-dart-mode - Major mode for editing Dart files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-dart-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-dart-mode/emacs-dart-mode_1.0.7+git20240523.44beb62-1.dsc Changes for the initial release: emacs-dart-mode (1.0.7+git20240523.44beb62-1) unstable; urgency=medium . * Initial release (Closes: #1071708) Regards, -- Xiyue Deng
Bug#1072324: RFS: emacs-lsp-ui/9.0.0-1 -- UI modules for lsp-mode
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-lsp-ui": * Package name : emacs-lsp-ui Version : 9.0.0-1 Upstream contact : [fill in name and email of upstream] * URL : https://github.com/emacs-lsp/lsp-ui * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-lsp-ui Section : lisp The source builds the following binary packages: elpa-lsp-ui - UI modules for lsp-mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-lsp-ui/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-lsp-ui/emacs-lsp-ui_9.0.0-1.dsc Changes since the last upload: emacs-lsp-ui (9.0.0-1) unstable; urgency=medium . [ Debian Janitor ] * Remove constraints unnecessary since buster * Remove MIA uploaders. Thanks Thomas Koch for your maintenance (Closes: #1019024) * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.6.1, no changes needed * Set upstream metadata fields: Repository * Update standards version to 4.6.2, no changes needed . [ Xiyue Deng ] * New upstream version * Update Standards-Version to 4.7.0; no change needed * Disable pristine-tar in d/gbp.conf to match the current practice * Add myself to uploaders * Add elpa-lsp-mode and elpa-flycheck to build-depends in d/control as required by tests * Enable ERT tests * Keep testing files to fix autopkgtest * Add d/salsa-ci.yml with default settings * Refresh patches * Add patches to fix tests - Properly provide and require test-helper - Fix lsp-ui-doc--make-smaller-empty-lines - Disable tests using rustic * Update metadata for patches - Add upstream bug and forwarded status Regards, -- Xiyue Deng
Bug#1072279: RFS: treemacs/3.1-1 [Team] -- tree layout file explorer for Emacs - projectile support
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "treemacs": * Package name : treemacs Version : 3.1-1 Upstream contact : Alexander Miller * URL : https://github.com/Alexander-Miller/treemacs * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/treemacs Section : editors The source builds the following binary packages: elpa-treemacs - tree layout file explorer for Emacs elpa-treemacs-evil - tree layout file explorer for Emacs - evil support elpa-treemacs-magit - tree layout file explorer for Emacs - magit support elpa-treemacs-projectile - tree layout file explorer for Emacs - projectile support To access further information about this package, please visit the following URL: https://mentors.debian.net/package/treemacs/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/treemacs/treemacs_3.1-1.dsc Changes since the last upload: treemacs (3.1-1) unstable; urgency=medium . * Team upload * New upstream release * Update patches with new version and mark forwarded as not-needed * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.7.0; no changes needed * Update description of extensions to clarify which supports are added * Update debian copyright year in d/copyright * Add lintian-overrides for elpa-treemacs * Add d/salsa-ci.yml with default settings * Disable pristine-tar by default in d/gbp.conf Regards, -- Xiyue Deng
Bug#1072267: RFS: emacs-corfu-terminal/0.7-1 [ITP] -- Corfu popup on terminal
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-corfu-terminal": * Package name : emacs-corfu-terminal Version : 0.7-1 Upstream contact : Akib Azmain Turja * URL : https://codeberg.org/akib/emacs-corfu-terminal * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-corfu-terminal Section : editors The source builds the following binary packages: elpa-corfu-terminal - Corfu popup on terminal To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-corfu-terminal/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-corfu-terminal/emacs-corfu-terminal_0.7-1.dsc Changes for the initial release: emacs-corfu-terminal (0.7-1) unstable; urgency=medium . * Initial release (Closes: #1068440). Regards, -- Xiyue Deng
Bug#1072266: RFS: emacs-cfrs/1.6.0-2 -- Child-frame based read-string for Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-cfrs": * Package name : emacs-cfrs Version : 1.6.0-2 Upstream contact : Alexander Miller * URL : https://github.com/Alexander-Miller/cfrs * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-cfrs Section : editors The source builds the following binary packages: elpa-cfrs - Child-frame based read-string for Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-cfrs/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-cfrs/emacs-cfrs_1.6.0-2.dsc Changes since the last upload: emacs-cfrs (1.6.0-2) unstable; urgency=medium . * Add d/salsa-ci.yml with default settings This is also required as a source-only upload for migrating to testing. Regards, -- Xiyue Deng
Bug#1072265: RFS: emacs-popon/0.13-2 -- Pop floating text on an Emacs window
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-popon": * Package name : emacs-popon Version : 0.13-2 Upstream contact : Akib Azmain Turja * URL : https://codeberg.org/akib/emacs-popon * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-popon Section : editors The source builds the following binary packages: elpa-popon - Pop floating text on an Emacs window To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-popon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-popon/emacs-popon_0.13-2.dsc Changes since the last upload: emacs-popon (0.13-2) unstable; urgency=medium . * Add d/salsa-ci.yml with default settings This is also required as a source-only upload for migrating to testing. Regards, -- Xiyue Deng
Bug#1072263: RFS: activities-el/0.7-2 -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "activities-el": * Package name : activities-el Version : 0.7-2 Upstream contact : Adam Porter * URL : https://github.com/alphapapa/activities.el * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/activities-el Section : editors The source builds the following binary packages: elpa-activities - Save/restore sets of windows, tabs/frames, and their buffers in Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/activities-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/a/activities-el/activities-el_0.7-2.dsc Changes since the last upload: activities-el (0.7-2) unstable; urgency=medium . * Add d/salsa-ci.yml with default settings This is also required as a source-only upload for migrating to testing. Regards, -- Xiyue Deng
Bug#1072262: RFS: emacs-bazel-mode/0.0~git20230919.769b30d-2 -- Bazel support for GNU Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-bazel-mode": * Package name : emacs-bazel-mode Version : 0.0~git20230919.769b30d-2 Upstream contact : Google LLC * URL : https://github.com/bazelbuild/emacs-bazel-mode * License : Apache-2.0 * Vcs : https://salsa.debian.org/emacsen-team/emacs-bazel-mode Section : editors The source builds the following binary packages: elpa-bazel-mode - Bazel support for GNU Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-bazel-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-bazel-mode/emacs-bazel-mode_0.0~git20230919.769b30d-2.dsc Changes since the last upload: emacs-bazel-mode (0.0~git20230919.769b30d-2) unstable; urgency=medium . * Remove upstream-tag in d/gbp.conf for better detection * Add d/salsa-ci.yml using default settings * Add git to Build-Depends required by Salsa CI This is also required as a source-only upload so as to help migrating to testing. Regards, -- Xiyue Deng
Bug#1072223: RFS: rtags/2.38-11 [RC] -- C/C++ client/server indexer with integration for Emacs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "rtags": * Package name : rtags Version : 2.38-11 Upstream contact : Anders Bakken * URL : https://github.com/Andersbakken/rtags * License : BSD-4-Clause, Expat, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/rtags Section : devel The source builds the following binary packages: rtags - C/C++ client/server indexer with integration for Emacs elpa-rtags - emacs front-end for RTags elpa-company-rtags - company back-end for RTags elpa-flycheck-rtags - flycheck integration for RTags elpa-ac-rtags - auto-complete back-end for RTags elpa-ivy-rtags - ivy back-end for RTags elpa-helm-rtags - helm interface for RTags To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rtags/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rtags/rtags_2.38-11.dsc Changes since the last upload: rtags (2.38-11) unstable; urgency=medium . * Add missing dependency of emacs to d/tests/control (Closes: #1072201) * Add Upstream-Contact in d/copyright * Update debian copyright year in d/copyright Regards, -- Xiyue Deng
Bug#1072201: rtags: autopkgtest failure due to missing depends on emacs
Control: tags -1 patch pending Xiyue Deng writes: > Package: rtags > Version: 2.38-10 > Severity: serious > > Dear Maintainer, > > rtags is now failing autopkgtest due to missing dependency on emacs. > See the autopkgtest regression test from flycheck[1]. It used to work > because it pulls in emacs through the dependency of flycheck. The > recent upload of flycheck 34.1-1 has downgraded this dependency to > recommends (by me, actually) which triggered this failure. As this is > causing build failure on rebuild, I'm using the serious severity. > > I'll prepare a fix patch/MR soon. > > [1] https://ci.debian.net/packages/r/rtags/testing/amd64/47083927/ > > -- System Information: > Debian Release: 12.5 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled As I have team repo access, I have pushed the fix[1] and it has passed autopkgtest on Salsa CI[2]. [1] https://salsa.debian.org/emacsen-team/rtags/-/commit/af72d9a977846760ce7b21de36955e4083a34a68 [2] https://salsa.debian.org/emacsen-team/rtags/-/jobs/5789916 -- Xiyue Deng
Bug#1072201: rtags: autopkgtest failure due to missing depends on emacs
Package: rtags Version: 2.38-10 Severity: serious Dear Maintainer, rtags is now failing autopkgtest due to missing dependency on emacs. See the autopkgtest regression test from flycheck[1]. It used to work because it pulls in emacs through the dependency of flycheck. The recent upload of flycheck 34.1-1 has downgraded this dependency to recommends (by me, actually) which triggered this failure. As this is causing build failure on rebuild, I'm using the serious severity. I'll prepare a fix patch/MR soon. [1] https://ci.debian.net/packages/r/rtags/testing/amd64/47083927/ -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068186: mozc: FTBFS with abseil 20230802: ../../base/init_mozc.cc:90:29: error: ‘absl::debian5::flags_internal::ArgvListAction’ has not been declared
Hi, I have tested the patches from Hayashi-san to be working. It would be great to have this applied to fix mozc (which has since been removed from testing due to this bug.) As an attempt to help, I took the liberty to incorporate Hayashi-san's patches and provided the compiled packages on mentors[1], as well as created a merge request on salsa[2] (I have also attached the patch set in case people prefer these for reviewing.) I haven't filed an RFS bug for the packages on mentors yet, but let me know if that's a good idea. According the Salsa CI pipeline[3], the building went fine. There are 2 failed tests: blhc fails due to missing suggested building/linking flags, piuparts fails because the current version (-2.2) fails to install due to the fact that it is still depending on the previous version of abseil which is no longer available in testing. (Also, the crossbuild test has been marked as expected to fail.) So I hope the Salsa-CI pipeline results show that the NMU package in a good-enough shape. I am adding Gunnar who previously provided NMU of this package as well as the maintainer hoping them to review and sponsor my NMU attempt. (Also CCed Kentaro Hayashi as FYI.) [1] https://mentors.debian.net/package/mozc/ [2] https://salsa.debian.org/debian/mozc/-/merge_requests/10 [3] https://salsa.debian.org/manphiz/mozc/-/pipelines/683514 -- Xiyue Deng >From 7c83a80bb31420e76ae96746a8192673988f8a7e Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Tue, 28 May 2024 02:39:45 -0700 Subject: [PATCH 1/3] Apply patches by Kentaro HAYASHI to fix FTBFS with latest abseil (Closes: #1068186) --- ...-error-of-ParseCommandLineFlags-with.patch | 34 + ...Fix-missing-abseil-gyp-link-settings.patch | 38 +++ debian/patches/series | 2 + 3 files changed, 74 insertions(+) create mode 100644 debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch create mode 100644 debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch diff --git a/debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch b/debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch new file mode 100644 index 0..361fa959f --- /dev/null +++ b/debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch @@ -0,0 +1,34 @@ +From: Kentaro Hayashi +Date: Fri, 17 May 2024 18:21:29 +0900 +Subject: Fix the compile error of ParseCommandLineFlags with Abseil LTS + 20230802. + +Origin: https://github.com/google/mozc/commit/cad4064c8884eb711e0e19b4b79d2ff5610823dc +Description: Fix the compile error of ParseCommandLineFlags with Abseil LTS 20230802. + * Added the check of the Abseil version to the arguments of ParseCommandLineImpl. + * https://github.com/google/mozc/issues/790 + #codehealth + PiperOrigin-RevId: 561867167 +Author: Hiroyuki Komatsu + +Released in 2.29.5374.102 + +Signed-off-by: Kentaro Hayashi +--- + src/base/init_mozc.cc | 2 ++ + 1 file changed, 2 insertions(+) + +diff --git a/src/base/init_mozc.cc b/src/base/init_mozc.cc +index eee8b62..5e5b558 100644 +--- a/src/base/init_mozc.cc b/src/base/init_mozc.cc +@@ -87,7 +87,9 @@ std::string GetLogFilePathFromProgramName(const std::string _name) { + void ParseCommandLineFlags(int argc, char **argv) { + absl::flags_internal::ParseCommandLineImpl( + argc, argv, ++#if defined(ABSL_LTS_RELEASE_VERSION) && ABSL_LTS_RELEASE_VERSION < 20230802 + absl::flags_internal::ArgvListAction::kRemoveParsedArgs, ++#endif // ABSL_LTS_RELEASE_VERSION < 20230802 + // Suppress help messages invoked by --help and others. + // Use UsageFlagsAction::kHandleUsage to enable it. + absl::flags_internal::UsageFlagsAction::kIgnoreUsage, diff --git a/debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch b/debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch new file mode 100644 index 0..9eba7f14d --- /dev/null +++ b/debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch @@ -0,0 +1,38 @@ +From: Kentaro Hayashi +Date: Sat, 18 May 2024 17:05:16 +0900 +Subject: Fix missing abseil libraries + +It fixes the following error: + + /usr/bin/ld: obj/base/base_core.file_util.o: undefined reference to + symbol '_ZN4absl7debian5lsERSoNS0_11string_viewE' + /usr/bin/ld: + /lib/x86_64-linux-gnu/libabsl_string_view.so.20230802: error adding + symbols: DSO missing from command line + + /usr/bin/ld: obj/unix/emacs/mozc_emacs_helper_lib.client_pool.o: + undefined reference to symbol + '_ZN4absl7debian516raw_log_internal21internal_log_functionB5cxx11E' + /usr/bin/ld: + /lib/x86_64-linux-gnu/libabsl_raw_logging_internal.so.20230802: error + adding symbols: DSO missing from command line collect2: error: ld + returned 1 exit status + +Signed-off-by: Kentaro Hayashi +--- + src/base/absl.gyp | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/base/absl.gyp b/src/base/absl.g
Bug#1072044: RFS: emacs-libvterm/0.0.2+git20240520.df057b1-1 -- fully-fledged terminal emulator inside GNU Emacs based on libvterm - module
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-libvterm": * Package name : emacs-libvterm Version : 0.0.2+git20240520.df057b1-1 Upstream contact : Lukas Fürmetz * URL : https://github.com/akermu/emacs-libvterm * License : GPL-3, GPL-2+, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-libvterm Section : editors The source builds the following binary packages: emacs-libvterm - fully-fledged terminal emulator inside GNU Emacs based on libvterm - module elpa-vterm - fully-fledged terminal emulator inside GNU Emacs based on libvterm - elisp To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-libvterm/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-libvterm/emacs-libvterm_0.0.2+git20240520.df057b1-1.dsc Changes since the last upload: emacs-libvterm (0.0.2+git20240520.df057b1-1) unstable; urgency=medium . * New upstream snapshot * Add myself to Uploaders as permitted by Martin * Update Standards-Version to 4.7.0; no change needed * Use posix export in d/rules * Add Upstream-Name in d/copyright * Update copyright year for debian/* in d/copyright * Refresh patches using gbp pq Regards, -- Xiyue Deng
Bug#1068477: RFS: emacs-corfu/1.4-1 [Team] -- Completion Overlay Region FUnction in Emacs
Control: retitle -1 RFS: emacs-corfu/1.4-1 [Team] -- Completion Overlay Region FUnction in Emacs A new upstream release 1.4 is available. I have updated the packaging on team repo[1] and mentors[2]. PTAL. [1] https://salsa.debian.org/emacsen-team/emacs-corfu [2] https://mentors.debian.net/package/emacs-corfu/ -- Xiyue Deng
Bug#1071719: python3-sphinx: produces non-deterministic searchindex.js which breaks reproducibility tests
Package: python3-sphinx Version: 7.2.6-7 Severity: normal Dear Maintainer, The current latest python3-sphinx version () may still produce non-deterministic searchindex.js file which breaks reproducibility tests. See attached for a diffoscope result of the diff between two built flycheck-doc. This issue has been reported upstream[1] and has since been fixed[2]. Please consider packaging a newer version or backport the patch. TIA! [1] https://github.com/sphinx-doc/sphinx/issues/11622 [2] https://github.com/sphinx-doc/sphinx/pull/11665 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libjs-sphinxdoc depends on: ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-underscore 1.13.4~dfsg+~1.11.4-3 libjs-sphinxdoc recommends no packages. libjs-sphinxdoc suggests no packages. -- no debconf information ||0% ETA: --:--:-- ||0% control.tar.xz ETA: --:--:-- ||0% /control ETA: --:--:-- ||0% /md5sums ETA: --:--:-- ||0% ETA: --:--:-- ||0% ETA: --:--:-- ||0%data.tar.xz ETA: --:--:-- ||0% /usr/ ETA: --:--:-- ||0%/usr/share/ ETA: --:--:-- ||0%/usr/share/doc/ ETA: --:--:-- ||0% …share/doc/elpa-flycheck/ ETA: --:--:-- ||0% …/doc/elpa-flycheck/html/ ETA: --:--:-- ||0% …a-flycheck/html/_images/ ETA: --:--:-- ||0% …s/flycheck-annotated.png ETA: --:--:-- ||0% …/flycheck-error-list.png ETA: --:--:-- ||0% …ycheck-error-reports.png ETA: --:--:-- ||0% …images/flycheck-menu.png ETA: --:--:-- ||0% …check-mode-line-menu.png ETA: --:--:-- ||0% …ycheck-verify-buffer.png ETA: --:--:-- ||0% …-flycheck/html/_sources/ ETA: --:--:-- ||0% …_sources/changes.rst.txt ETA: --:--:-- ||0% …html/_sources/community/ ETA: --:--:-- ||0% …ommunity/conduct.rst.txt ETA: --:--:-- ||0% …unity/extensions.rst.txt ETA: --:--:-- ||0% …mmunity/get-help.rst.txt ETA: --:--:-- ||0% …community/people.rst.txt ETA: --:--:-- ||0% …ml/_sources/contributor/ ETA: --:--:-- ||0% …tor/contributing.rst.txt ETA: --:--:-- ||0% …utor/maintaining.rst.txt ETA: --:--:-- ||0% …utor/style-guide.rst.txt ETA: --:--:-- ||0% …html/_sources/developer/ ETA: --:--:-- ||0% …loper/developing.rst.txt ETA: --:--:-- ||0% …sources/glossary.rst.txt ETA: --:--:-- ||0% …l/_sources/index.rst.txt ETA: --:--:-- ||0% …ources/languages.rst.txt ETA: --:--:-- ||0% …sources/licenses.rst.txt ETA: --:--:-- ||0% …heck/html/_sources/user/ ETA: --:--:-- ||0% …rror-interaction.rst.txt ETA: --:--:-- ||0% …/user/error-list.rst.txt ETA: --:--:-- ||0% …er/error-reports.rst.txt ETA: --:--:-- ||0% …k-versus-flymake.rst.txt ETA: --:--:-- ||0% …ser/installation.rst.txt ETA: --:--:-- ||0% …/user/quickstart.rst.txt ETA: --:--:-- ||0% …/syntax-checkers.rst.txt ETA: --:--:-- ||0% …er/syntax-checks.rst.txt ETA: --:--:-- ||0% …/troubleshooting.rst.txt ETA: --:--:-- ||0% …a-flycheck/html/_static/ ETA: --:--:-- ||0% …ml/_static/alabaster.css ETA: --:--:-- ||0% …k/html/_static/basic.css ETA: --:--:-- ||0% …/html/_static/custom.css ETA: --:--:-- ||0% …documentation_options.js ETA: --:--:-- ||0% …l/_static/favicon.ico.gz ETA: --:--:-- ||0% …html/_static/favicon.png ETA: --:--:-- ||0% …ck/html/_static/file.png ETA: --:--:-- ||0% …ight_darkblue_121621.png ETA: --:--:-- ||0% …ck/html/_static/logo.png ETA: --:--:-- ||0% …k/html/_static/minus.png ETA: --:--:-- ||0% …ck/html/_static/plus.png ETA: --:--:-- ||0% …tml/_static/pygments.css ETA: --:--:-- ||0% …ycheck/html/changes.html ETA: --:--:-- ||0% …flycheck/html/community/ ETA: --:--:-- ||0% …l/community/conduct.html ETA: --:--:-- ||0% …ommunity/extensions.html ETA: --:--:-- ||0% …/community/get-help.html ETA: --:--:-- ||0% …ml/community/people.html ETA: --:--:-- ||0% …ycheck/html/contributor/ ETA: --:--:-- ||0% …ibutor/contributing.html ETA: --:--:-- ||0% …ributor/maintaining.html ETA: --:--:-- ||0% …ributor/style-guide.html ETA: --:--:-- ||0% …flycheck/html/developer/ ETA: --:--:--
Bug#1071708: ITP: emacs-dart-mode -- An Emacs major mode for editing Dart files
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-dart-mode Version : 1.0.7+git20240507.ef6cc89 Upstream Author : Google Inc., Brady Trainor * URL or Web page : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ Programming lang: Emacs Lisp Description : An Emacs major mode for editing Dart files This package implements a major-mode for the Dart language, providing basic syntax highlighting and indentation support. I plan to maintain this package within the Debian Emacsen Team .
Bug#1069210: dh-elpa: Support nested directory in elpa installation
I made another change to dh-elpa enabling better back trace for buttercup tests, so here is the refreshed patchset. TIA! -- Xiyue Deng From cc40a88155029834673a944e1a822ff3b97613ca Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Mon, 20 May 2024 00:49:52 -0700 Subject: [PATCH 1/4] Don't recursively add elpa path to match package.el behavior * Add .nosearch to `/usr/share/emacs/site-lisp/elpa{,-src}' using triggers in dh-elpa, which will disable subdirs.el from processing those directories. --- debian/dh-elpa.postinst | 35 +++ debian/dh-elpa.triggers | 2 ++ 2 files changed, 37 insertions(+) create mode 100644 debian/dh-elpa.postinst create mode 100644 debian/dh-elpa.triggers diff --git a/debian/dh-elpa.postinst b/debian/dh-elpa.postinst new file mode 100644 index 000..7f2e52d --- /dev/null +++ b/debian/dh-elpa.postinst @@ -0,0 +1,35 @@ +#!/bin/sh + +set -e + +ensure_nosearch_in_elpa_directories() { +# Currently there is subdirs.el in `/usr/share/emacs/site-lisp' which causes +# all subdirectories to be added to `load-path' including elpa installation +# directories. This differs from how package.el handles ELPA packages which +# only adds the installation root directory. Here we add `.nosearch' to +# elpa directories to let subdirs.el skip them to follow the package.el +# behavior. +SITE_LISP_DIR=/usr/share/emacs/site-lisp +ELPA_SRC_NOSEARCH=${SITE_LISP_DIR}/elpa-src/.nosearch +ELPA_NOSEARCH=${SITE_LISP_DIR}/elpa/.nosearch +[ -f ${ELPA_SRC_NOSEARCH} ] || touch ${ELPA_SRC_NOSEARCH} +[ -f ${ELPA_NOSEARCH} ] || touch ${ELPA_NOSEARCH} +} + +case "$1" in +configure) +;; + +triggered) +ensure_nosearch_in_elpa_directories +;; + +*) +echo "postinit called with argument \`$1' which is ignored." >&2 +exit 1 +;; +esac + +#DEBHELPER# + +exit 0 diff --git a/debian/dh-elpa.triggers b/debian/dh-elpa.triggers new file mode 100644 index 000..ef84cb6 --- /dev/null +++ b/debian/dh-elpa.triggers @@ -0,0 +1,2 @@ +interest /usr/share/emacs/site-lisp/elpa-src +interest /usr/share/emacs/site-lisp/elpa -- 2.39.2 From 111a07a86a3aa163d6e4da51c3e6389516f2b985 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Mon, 15 Apr 2024 13:03:16 -0700 Subject: [PATCH 2/4] Byte compile recursively during install to handle nested directories * This handles addons that have source files under nested directories in ELPA install directories. --- helper/install | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/helper/install b/helper/install index 39db695..eb68ef5 100755 --- a/helper/install +++ b/helper/install @@ -58,7 +58,8 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}" ${FLAVOR} --quick --batch -l package \ --eval "(setq package-user-dir \"/nonexistent\")" \ --eval "(add-to-list 'package-directory-list \"$src_dir\")" \ - -f package-initialize -f batch-byte-compile ./*.el > Install.log 2>&1 + -f package-initialize \ + --eval "(byte-recompile-directory \".\" 0)" > Install.log 2>&1 if test $? -ne 0 then cat Install.log -- 2.39.2 From 795c82f5c80fc5665905d3763163bef03e8854ca Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 17 Apr 2024 14:06:42 -0700 Subject: [PATCH 3/4] Create symlink from elpa-src to elpa recursively * Instead of using `ln -s', use `cp -rs' so that directories are handled recursively. * In remove we use `rmdir --ignore-fail-on-non-empty' so this was handled automatically as well. --- helper/install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/helper/install b/helper/install index eb68ef5..8d748c8 100755 --- a/helper/install +++ b/helper/install @@ -50,7 +50,7 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}" # policy). This makes complation easy, and also allows find-function # and find-library to work properly. Also link all other top level # files and directories into the flavor directory -(cd "${elc_dir}" && ln -sf "${el_dir}"* .) +(cd "${elc_dir}" && cp -rsf "${el_dir}"* .) # Byte compile them (cd "${elc_dir}" -- 2.39.2 From 374983204ec273c557306821bfce0cbfb0950722 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 17 Apr 2024 14:17:41 -0700 Subject: [PATCH 4/4] Update d/changelog --- debian/changelog | 6 ++ 1 file changed, 6 insertions(+) diff --git a/debian/changelog b/debian/changelog index be10246..e385f81 100644 --- a/debian/changelog +++ b/debian/changelog @@ -9,6 +9,12 @@ dh-elpa (2.1.2) UNRELEASED; urgency=medium * dh_elpa_test: Don't rename files under test/, tests/ (Closes: #1069326). * Use `pretty' stack frame style in buttercup for full back trace. + * Add support for nested directory in e
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Xiyue Deng writes: > So it looks like `normal-top-level-add-subdirs-to-load-path' has a > special handling that ignores directories with a `.nosearch' file. I > have added that to both elpa{,-src} and it seems to work as intended. > So the next question is how/when to add those files. Continuing to > experiment. And my experiment with triggers was successful. This has the advantage of not requiring package to be rebuilt compared with do the handling in helper/install, but may be there are other ways. Suggestions welcome. I have update the implementation to the nest-directory-support branch in my fork[1], and the patches series is attached. Now inviting maintainers to review. Thanks in advance! [1] https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...nested-directory-support?from_project_id=18920 -- Xiyue Deng From 6794099f62fecfdc19152b50170027fb021abdba Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Mon, 20 May 2024 00:49:52 -0700 Subject: [PATCH 1/4] Don't recursively add elpa path to match package.el behavior * Add .nosearch to `/usr/share/emacs/site-lisp/elpa{,-src}' using triggers in dh-elpa, which will disable subdirs.el from processing those directories. --- debian/dh-elpa.postinst | 29 + debian/dh-elpa.triggers | 2 ++ 2 files changed, 31 insertions(+) create mode 100644 debian/dh-elpa.postinst create mode 100644 debian/dh-elpa.triggers diff --git a/debian/dh-elpa.postinst b/debian/dh-elpa.postinst new file mode 100644 index 000..03b65cd --- /dev/null +++ b/debian/dh-elpa.postinst @@ -0,0 +1,29 @@ +#!/bin/sh + +set -e + +ensure_nosearch_in_elpa_directories() { +SITE_LISP_DIR=/usr/share/emacs/site-lisp +ELPA_SRC_NOSEARCH=${SITE_LISP_DIR}/elpa-src/.nosearch +ELPA_NOSEARCH=${SITE_LISP_DIR}/elpa/.nosearch +[ -f ${ELPA_SRC_NOSEARCH} ] || touch ${ELPA_SRC_NOSEARCH} +[ -f ${ELPA_NOSEARCH} ] || touch ${ELPA_NOSEARCH} +} + +case "$1" in +configure) +;; + +triggered) +ensure_nosearch_in_elpa_directories +;; + +*) +echo "postinit called with argument \`$1' which is ignored." >&2 +exit 1 +;; +esac + +#DEBHELPER# + +exit 0 diff --git a/debian/dh-elpa.triggers b/debian/dh-elpa.triggers new file mode 100644 index 000..ef84cb6 --- /dev/null +++ b/debian/dh-elpa.triggers @@ -0,0 +1,2 @@ +interest /usr/share/emacs/site-lisp/elpa-src +interest /usr/share/emacs/site-lisp/elpa -- 2.39.2 From 5243f1f6908093c158840bf0f71cd64d25bbaa18 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Mon, 15 Apr 2024 13:03:16 -0700 Subject: [PATCH 2/4] Byte compile recursively during install to handle nested directories * This handles addons that have source files under nested directories in ELPA install directories. --- helper/install | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/helper/install b/helper/install index 39db695..eb68ef5 100755 --- a/helper/install +++ b/helper/install @@ -58,7 +58,8 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}" ${FLAVOR} --quick --batch -l package \ --eval "(setq package-user-dir \"/nonexistent\")" \ --eval "(add-to-list 'package-directory-list \"$src_dir\")" \ - -f package-initialize -f batch-byte-compile ./*.el > Install.log 2>&1 + -f package-initialize \ + --eval "(byte-recompile-directory \".\" 0)" > Install.log 2>&1 if test $? -ne 0 then cat Install.log -- 2.39.2 From 3fa7763ba5ddb5e177095e683ba55bddd341d364 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 17 Apr 2024 14:06:42 -0700 Subject: [PATCH 3/4] Create symlink from elpa-src to elpa recursively * Instead of using `ln -s', use `cp -rs' so that directories are handled recursively. * In remove we use `rmdir --ignore-fail-on-non-empty' so this was handled automatically as well. --- helper/install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/helper/install b/helper/install index eb68ef5..8d748c8 100755 --- a/helper/install +++ b/helper/install @@ -50,7 +50,7 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}" # policy). This makes complation easy, and also allows find-function # and find-library to work properly. Also link all other top level # files and directories into the flavor directory -(cd "${elc_dir}" && ln -sf "${el_dir}"* .) +(cd "${elc_dir}" && cp -rsf "${el_dir}"* .) # Byte compile them (cd "${elc_dir}" -- 2.39.2 From 1573475d02f9837b859fa6aec6ea01e00c69e751 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 17 Apr 2024 14:17:41 -0700 Subject: [PATCH 4/4] Update d/changelog --- debian/changelog | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/debian/changelog b/debian/changelog index 3c9aa72..467f
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Xiyue Deng writes: > Xiyue Deng writes: > >> Currently there is a behavior difference between elpafied packages and >> upstream ELPA packages on `load-path' handling: for elpafied packages, >> all nested directories are added to `load-path', while for upstream ELPA >> only the root directory is added. Normally this should not be an issue, >> but when trying to elpafy auctex, it's nested directory "style/" >> contains many modules whose names collide with standard modules and >> hence broken Eglot. This sounds like a bad practice of the package, but >> it would still be good to match upstream behavior so as to minimize >> surprises. Will try to figure this out. > > Well it took me quite a while to realize what's going on. > > Initially I thought there were some handling in package.el that somehow > treated the dh-elpa installation path differently than > `package-user-dir'. With extensive code search regarding `load-path', > `package-directory-list', `package-user-dir', as well as other relevant > functions/variables, and I even tried to consult on > emacs-de...@gnu.org[1] where Michael gave multiple suggestions and > pointers, still I didn't find anything. > > Well, not until I tried to search for `load-path' in the whole Emacs > source when I noticed the function > `normal-top-level-add-subdirs-to-load-path', which were added to a > `subdirs.el' file which does what its name suggests. Then it didn't > take long for me I to find the file > `/usr/share/emacs/site-lisp/subdirs.el', and the mystery is solved: this > file causes all the sub-directories of the directory with this file > being added to `load-path', including everything under the dh-elpa > installation path `elpa{,-src}'. > > So, this means that as long as dh-elpa uses > `/usr/share/emacs/site-lisp/elpa{,-src}' as the installation path for > elpafied packages, all its subdirectories will be added to `load-path' > automatically, which is currently different with how package.el handles > ELPA package - it only adds the path holding the *-autoloads.el file to > `load-path'. > > Right now I think there are two obvious directions forward: > > * Move elpa{,-src} out of the path with a subdirs.el file, which means > it should not use `/usr/share/emacs/site-lisp/elpa{,-src}', but > something like `/usr/share/emacs/elpa{,-src}' or > `/usr/share/emacs/${version}/elpa{,-src}'. This would mean a big > migration for all elpafied packages due to the directory change. > > - With the current ongoing discussion on fixing the loading / > configuration dependencies, a migration may happen anyway, so > probably both can be done? > > * Patch the generated subdirs.el to skip any elpa{,-src} directories. > I don't expect that upstream will accept such a change, so we'll > probably have to carry this patch, which would not be ideal anyway. > > There may be other ways. Any advices are welcome! > So it looks like `normal-top-level-add-subdirs-to-load-path' has a special handling that ignores directories with a `.nosearch' file. I have added that to both elpa{,-src} and it seems to work as intended. So the next question is how/when to add those files. Continuing to experiment. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Xiyue Deng writes: > Currently there is a behavior difference between elpafied packages and > upstream ELPA packages on `load-path' handling: for elpafied packages, > all nested directories are added to `load-path', while for upstream ELPA > only the root directory is added. Normally this should not be an issue, > but when trying to elpafy auctex, it's nested directory "style/" > contains many modules whose names collide with standard modules and > hence broken Eglot. This sounds like a bad practice of the package, but > it would still be good to match upstream behavior so as to minimize > surprises. Will try to figure this out. Well it took me quite a while to realize what's going on. Initially I thought there were some handling in package.el that somehow treated the dh-elpa installation path differently than `package-user-dir'. With extensive code search regarding `load-path', `package-directory-list', `package-user-dir', as well as other relevant functions/variables, and I even tried to consult on emacs-de...@gnu.org[1] where Michael gave multiple suggestions and pointers, still I didn't find anything. Well, not until I tried to search for `load-path' in the whole Emacs source when I noticed the function `normal-top-level-add-subdirs-to-load-path', which were added to a `subdirs.el' file which does what its name suggests. Then it didn't take long for me I to find the file `/usr/share/emacs/site-lisp/subdirs.el', and the mystery is solved: this file causes all the sub-directories of the directory with this file being added to `load-path', including everything under the dh-elpa installation path `elpa{,-src}'. So, this means that as long as dh-elpa uses `/usr/share/emacs/site-lisp/elpa{,-src}' as the installation path for elpafied packages, all its subdirectories will be added to `load-path' automatically, which is currently different with how package.el handles ELPA package - it only adds the path holding the *-autoloads.el file to `load-path'. Right now I think there are two obvious directions forward: * Move elpa{,-src} out of the path with a subdirs.el file, which means it should not use `/usr/share/emacs/site-lisp/elpa{,-src}', but something like `/usr/share/emacs/elpa{,-src}' or `/usr/share/emacs/${version}/elpa{,-src}'. This would mean a big migration for all elpafied packages due to the directory change. - With the current ongoing discussion on fixing the loading / configuration dependencies, a migration may happen anyway, so probably both can be done? * Patch the generated subdirs.el to skip any elpa{,-src} directories. I don't expect that upstream will accept such a change, so we'll probably have to carry this patch, which would not be ideal anyway. There may be other ways. Any advices are welcome! P.S. It's worth mentioning that when discussing with upstream, it is unclear whether upstream will consider adding sub-directories of an ELPA package to `load-path'. Currently there are not much such use case, and for the existing one case of auctex it'll cause some breakage, so the likeliness is low for now. [1] https://lists.gnu.org/archive/html/emacs-devel/2024-05/msg00658.html -- Xiyue Deng signature.asc Description: PGP signature
Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries
Xiyue Deng writes: > Daniel Kahn Gillmor writes: > >> >> I decided to look in ~/.reportbugrc and i find i have the following settings: >> >> ``` >> reportbug_version "5.0" >> mode standard >> ui text >> no-cc >> list-cc-me >> ``` >> >> I have no recollection of setting either no-cc or list-cc-me, and i >> confess i don't really understand why these options are distinct. >> Perhaps this was from ancient run (or runs?) of `reportbug --configure`? >> >> Without modifying any env vars, I tried commenting out both the `no-cc` >> and `list-cc-me` options in ~/.reportbugrc, and with both of those >> removed, the generated X-Debbugs-Cc line after a `M-x debian-bug` was >> just: >> >> ``` >> X-Debbugs-Cc: none, Daniel Kahn Gillmor >> ``` >> > > Thanks for testing. So what's happening is that the info debian-bug get > from the envvars are your full name and your email address. On the > other hand with "list-cc-me" you only get the email part there. So from > debian-bug point of view those are different info so the de-duplication > doesn't happen (if both have the same info debian-el will dedup though). > > Ideally there should be a way to let reportbug ignore the configuration > files and only process options passing through command line so that user > configuration doesn't change its behavior, but as far as I can tell > there is no option to do that (yet)[1]. Hopefully it will be > implemented eventually. > After some discussion in Bug#1070881[1], Nis suggested that a possible workaround is to unset $HOME so that reportbug won't read ~/.reportbugrc[2], and I have tested this to be working[3]. As much as I'd like to propose adding an option to skip loading any configuration files for reportbug, I guess this settles our immediate concerns, and Daniel can re-enable "list-cc-me" in ~/.reportbugrc in case he uses reportbug directly. Thanks everyone for the testing and suggestions! [1] https://bugs.debian.org/1070881 [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070881#35 [3] https://salsa.debian.org/emacsen-team/debian-el/-/commit/8e6e55ff1aa56bbc109196a2ac1283769d6f13b0 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1070881: reportbug: Provide an option to skip loading configuration files
Nis Martensen writes: > On 18.05.2024 22.58, Xiyue Deng wrote: >> Using the use case in elpa-debian-el as an example, we handle CCing >> oneself in ELisp, so we assume reportbug is invoked without "list-cc-me" >> by not passing that argument. However, if the user has a >> "~/.reportbugrc" with "list-cc-me" in it, it will break this assumption, >> and reportbug ended up having it's own self CC and elpa-debian-el added >> another self CC, which would be confusing to users. If we have an >> option to disable loading "~/.reportbugrc" we can avoid this situation. > > Well, adding a way to override the "list-cc-me" would also avoid this > situation, wouldn't it? This doesn't scale. What if there is another option that breaks the assumption of elpa-debian-el? What if in the future reportbug adds another option that changes another aspect of reportbug and breaks the assumption of elpa-debian-el again? Being able to let reportbug behave as if there is no other options are passed with minimum effort would solve all the above. > What I'm trying to discuss is the advantages and disadvantages of this > alternative approach compared to your proposal. Right on top of my head I can think of two alternative ways of doing the same includes: * For each option, provides an option to disable it, so that for an option "--foo" there should be an option "--no-foo" to disable it. - This leads to another question of when both "--foo" and "--no-foo" as passed, which takes precedence? What if one of them is set in "~/.reportbugrc"? In short, this option also doesn't scale. * Provide a reportbug library and offer an API to query whether each option is enabled or not. - This doesn't really work for other programs that depends on using reportbug through its command line interface, which currently means every program that uses reportbug. In short, I don't think those options are better than being able to ignore "/etc/reportbug.conf" and "~/.reportbugrc" > "Disable configuration files" seems like a very unspecific override > (that might also break stuff other tools rely upon) to ask for if a > more specific one would do. I don't quite understand what you mean by "Disable configuration files" being an unspecific override: it should give a default reportbug behavior as if no other argument was passed to it except the ones immediately done through the same command. Say if there were an option "-q" to disable loading any configuration files, when I do "reportbug -q --template" I don't have to worry about reportbug will behave as if I was running "reportbug --template --list-cc-me" regardless of whether there exists a "~/.reportbugrc" that has a line "list-cc-me" in it. I believe this is very specific and makes reportbug behave deterministically. > Or maybe no change is actually needed at all, because your case is > already resolved? > Technically nothing is actually resolved but just worked around: the user has to remove the line "list-cc-me" in their "~/.reportbugrc", which potentially makes it harder for them to use reportbug directly from command line. >> The same applies to other arguments that user may set but affect the >> assumptions of other programs. > > I think it would be helpful if there was a real application use case to > discuss here. If there aren't any (valid) assumptions by other programs > that we are breaking then I don't think there is any bug and this should > be closed. > OK. I don't really have an example of another such program yet. But at least elpa-debian-el is a real program, and people are using it, which is why we get bug reports like [1]. So IMHO it's not time to mark this as closed yet. > Since this is about cc-related options, are you already including the -x > (or --no-cc) option when invoking reportbug? Reportbug doesn't actually > read list-cc from its configuration file(s). It does read cc and list-cc-me. As I mentioned, Bug#1069908 is about "--list-cc-me", and currently there is no option to disable this option. And as I mentioned above with both options available precedence becomes another problem to solve. I think I didn't actually mention another point: implementing this is trivial and potentially takes much less developer time compared to other options I mentioned above. I'll try to work on an implementation in the next few days and propose a merge request or patches for you to review, if that's OK. [1] https://bugs.debian.org/1069908 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1070881: reportbug: Provide an option to skip loading configuration files
Hi Nis, Nis Martensen writes: > On 12.05.2024 23.11, Xiyue Deng wrote: >> Nis Martensen writes: >> >>> On 11.05.2024 08.23, Xiyue Deng wrote: >>>> I'd like to propose adding an option to skip loading configuration files >>>> (/etc/reportbug.conf and ~/.reportbugrc). The use case is for external >>>> programs that runs reportbug (e.g. debian-bug in elpa-debian-el) which >>>> provides its own command line switches and have an assumption on the >>>> output. When a user set some custom options, notably CC related ones, >>>> it may interfere with how X-Debbugs-Cc is handled and broke some of the >>>> assumptions of external tools (see https://bugs.debian.org/1032662). >>> >>> Thanks for the report. Did you intend to link to a different bug as your >>> example? The one you cite does not seem to be related to reportbug. >> >> Ah, indeed. I was trying to refer to https://bugs.debian.org/1069908. >> Thanks for the correction! > > Thanks for providing the example. To me it does not give convincing > evidence that an option to skip loading configuration files is a good > idea. Even with such an option one would still be able to get unintended > results by calling reportbug with buggy arguments. ;) > > Can you please clarify what specific assumptions of external tools you > have in mind? Would a command line option to override a "list-cc-me" > specified in the configuration file be sufficient to solve the problem? > Is this an actual problem in your case? > The point is to let other program achieve the exact behavior by the arguments supplied to reportbug. Using the use case in elpa-debian-el as an example, we handle CCing oneself in ELisp, so we assume reportbug is invoked without "list-cc-me" by not passing that argument. However, if the user has a "~/.reportbugrc" with "list-cc-me" in it, it will break this assumption, and reportbug ended up having it's own self CC and elpa-debian-el added another self CC, which would be confusing to users. If we have an option to disable loading "~/.reportbugrc" we can avoid this situation. The same applies to other arguments that user may set but affect the assumptions of other programs. As for buggy arguments, we can also fix that directly in elpa-debian-el by removing the buggy ones without having to change anything in reportbug, so this would not be an actual issue. Wdyt? -- Xiyue Deng
Bug#1071209: RFS: emacs-bazel-mode/0.0~git20230919.769b30d-1 [ITP] -- Bazel support for GNU Emacs
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-bazel-mode": * Package name : emacs-bazel-mode Version : 0.0~git20230919.769b30d-1 Upstream contact : Google LLC * URL : https://github.com/bazelbuild/emacs-bazel-mode * License : Apache-2.0 * Vcs : https://salsa.debian.org/emacsen-team/emacs-bazel-mode Section : editors The source builds the following binary packages: elpa-bazel-mode - Bazel support for GNU Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-bazel-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-bazel-mode/emacs-bazel-mode_0.0~git20230919.769b30d-1.dsc Changes for the initial release: emacs-bazel-mode (0.0~git20230919.769b30d-1) unstable; urgency=medium . * Initial release (Closes: #1071204) Regards, -- Xiyue Deng
Bug#1071204: ITP: emacs-bazel-mode -- Bazel support for GNU Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-bazel-mode Version : 0.0~git20230919.769b30d Upstream Author : Google LLC * URL or Web page : https://github.com/bazelbuild/emacs-bazel-mode * License : Apache-2.0 Programming lang: Emacs Lisp Description : Bazel support for GNU Emacs This repository provides support for Bazel in GNU Emacs. It consists of a single file, bazel.el, which only depends on GNU Emacs and not on other libraries. . The library provides major modes for editing Bazel BUILD files, WORKSPACE files, .bazelrc files, as well as Starlark files. It also provides commands to run Bazel commands and integration with core GNU Emacs infrastructure like compilation and xref. I intended to maintain this package within the Debian Emacsen Team .
Bug#1032662: elpa-debian-el: deb-view fails on zstd compressed debs
Contro: tags -1 pending Xiyue Deng writes: > Hi Sven, > > I'd like to experiment an implementation to add zstd support (as well > as lzma if possible). Do you know which ubuntu deb files are using zstd > or lzma compressions so that I can use to test? I have tested this change[1] with a zstd compressed deb file from ubuntu to be working. I'll merge this soon. Note that there is actually no lzma compiled deb support in dpkg-deb either, so I have dropped that part for now. Will revisit in case this is enabled in dpkg-deb later. [1] https://salsa.debian.org/manphiz/debian-el/-/commit/11bcd8fc563cf36140deab8f4d3293783c7b770c -- Xiyue Deng
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Xiyue Deng writes: > Xiyue Deng writes: > >> Xiyue Deng writes: >> >>> Sean Whitton writes: >>> >>>> Hello, >>>> >>>> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: >>>> >>>>> Sean Whitton writes: >>>>> >>>>>> Hello, >>>>>> >>>>>> Rob, can you review the implementation in d/rules for Xiyue's patch to >>>>>> this bug, please? I'm not sure it's the straightforward way to do it. >>>>>> >>>>>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >>>>>> for the relationships. >>>>> >>>>> Ah indeed, I should update the versions after the Emacs 29.3 upload, >>>>> though I think you meant "1:29.3+1-2". Also, as we are just moving >>>>> files from emacs-common to emacs-pgtk, breaks/replaces is only needed >>>>> from emacs-pgtk to emacs-common but no the other way around, so I >>>>> dropped the breaks on emacs-pgtk from emacs-common. >>>>> >>>>> I have updated the patch accordingly and attached here. PTAL. >>>> >>>> Thanks. >>>> >>>>> (BTW, I'm always curious about the "+1" part of the version number. I >>>>> would expect something like "+dfsg" or "+ds" as we are dropping some >>>>> of the non-DFSG conformant files, but why "+1"? :) >>>> >>>> It's just in case the DFSG split is done incorrectly and another attempt >>>> is required -- given how complex it is. >>> >>> Ack, totally understandable. >>> >>> With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it >>> and bumped the breaks/replaces version. PTAL. >> >> Rob suggested on IRC to be a bit more conservative by removing the file >> and remove the directories upwards recursively so that we can catch >> future addition to the directories more easily. The patch has been >> adjusted accordingly. PTAL. > > Friendly ping. Rob, do you have any more comments on the current approach? Rob has provided more comments which I have adapted and tested. Please see the latest patch attached. Thanks! -- Xiyue Deng >From f88392bd68206d44b3b84a9af43d5751321ed4d2 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 13 Mar 2024 10:22:46 -0700 Subject: [PATCH] Install GSettings schema in pgtk build only (Closes: #1050393) * In PGTK build it generates the GSettings schema file "/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" which is not needed in other variant. * Move the file from emacs-common to emacs-pgtk, and adds proper breaks/replaces to ensure a smooth upgrade. * Also incorporated suggestions by Rob. Suggestions by rlb More fix --- debian/changelog | 7 +++ debian/control | 11 +-- debian/rules | 11 ++- 3 files changed, 26 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index 5d4e9f050ae..e2a31a36fcb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +emacs (1:29.3+1-3) UNRELEASED; urgency=medium + + * Team upload. + * Install GSettings schema in pgtk build only (Closes: #1050393) + + -- Xiyue Deng Wed, 13 Mar 2024 10:22:10 -0700 + emacs (1:29.3+1-2) unstable; urgency=medium * Change native-comp-async-report-warnings-errors to `silent'. diff --git a/debian/control b/debian/control index e168717089f..3c04652c769 100644 --- a/debian/control +++ b/debian/control @@ -138,8 +138,15 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader Recommends: fonts-noto-color-emoji Suggests: emacs-common-non-dfsg Conflicts: emacs-gtk, emacs-lucid, emacs-nox -Replaces: emacs-gtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Replaces: + emacs-gtk, + emacs-lucid, + emacs-nox, + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), +Breaks: + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), Description: GNU Emacs editor (with GTK+ Wayland GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with a graphical user interface diff --git a/debian/rules b/debian/rules index 6250f60ea9b..a50d640e116 100755 --- a/debian/rules +++ b/debian/rules @@ -425,6 +425,11 @@ override_dh_auto_install: $(autogen_install_files) cp -a $(install_dir_pgtk)/* $(pkgdir_common) rm -r $(pkgdir_common)/usr/bin + # Move to emacs-pgtk; only that pkg needs it, and it causes + # a gsettings-related dependency to be added (#1050393). + rm
Bug#1070881: reportbug: Provide an option to skip loading configuration files
Nis Martensen writes: > On 11.05.2024 08.23, Xiyue Deng wrote: >> I'd like to propose adding an option to skip loading configuration files >> (/etc/reportbug.conf and ~/.reportbugrc). The use case is for external >> programs that runs reportbug (e.g. debian-bug in elpa-debian-el) which >> provides its own command line switches and have an assumption on the >> output. When a user set some custom options, notably CC related ones, >> it may interfere with how X-Debbugs-Cc is handled and broke some of the >> assumptions of external tools (see https://bugs.debian.org/1032662). > > Thanks for the report. Did you intend to link to a different bug as your > example? The one you cite does not seem to be related to reportbug. Ah, indeed. I was trying to refer to https://bugs.debian.org/1069908. Thanks for the correction! -- Xiyue Deng
Bug#1069620: RFS: lua-mode/20231023~git-1 -- Emacs major-mode for editing Lua programs
Hi Tobias, Tobias Frost writes: > Hi Xiyue, > > when packaging a git snapshot, I feel this should be indicated in the > upstream version that it is based on the old one, something like > + > > In your case I'd 20210802+git20231023 as upstream version. > > Long time ago I did something like that for dhewm3, you > can see the watch file here: > https://salsa.debian.org/games-team/dhewm3/-/blob/debian/1.5.0+git20181221+dfsg-1/debian/watch?ref_type=tags > > (not marking moreinfo, as other people might see that differently.) Thanks for your comments! I actually also thought about this but ended up not following that idea because it will end up with 3 different versions based on dates: * 20210802 which is the last tagged version[1], * 20221027 which is specified in the upstream source[2] and will end up in the installed elpa package directory but was never tagged, and * 20231023 which is the date of the latest upstream commit[3] when sending this email. I think 20210802+git20231023. follows the current practice but will be *very* confusing when user will find that the package is installed at /usr/share/emacs/site-lisp/elpa/lua-mode-20221027. I chose 20231023~git as a compromise just to avoid having too many dates there, which is still possible to upgrade to 20231023 should that be tagged one day. I think the next choice could be 20221027+git20231023. just so there is one less date to deal with. Wdyt? [1] https://github.com/immerrr/lua-mode/tags [2] https://github.com/immerrr/lua-mode/blob/master/lua-mode.el#L15 [3] https://github.com/immerrr/lua-mode/commit/d074e4134b1beae9ed4c9b512af741ca0d852ba3 > > -- > tobi > > On Sun, Apr 21, 2024 at 10:02:48AM -0700, Xiyue Deng wrote: >> Package: sponsorship-requests >> Severity: normal >> >> Dear mentors, >> >> I am looking for a sponsor for my package "lua-mode": >> >> * Package name : lua-mode >>Version : 20231023~git-1 >>Upstream contact : immerrr >> * URL : https://github.com/immerrr/lua-mode >> * License : GPL-3+ >> * Vcs : https://salsa.debian.org/emacsen-team/lua-mode >>Section : lisp >> >> The source builds the following binary packages: >> >> elpa-lua-mode - Emacs major-mode for editing Lua programs >> >> To access further information about this package, please visit the following >> URL: >> >> https://mentors.debian.net/package/lua-mode/ >> >> Alternatively, you can download the package with 'dget' using this command: >> >> dget -x >> https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20231023~git-1.dsc >> >> Changes since the last upload: >> >> lua-mode (20231023~git-1) unstable; urgency=medium >> . >> * Sync to latest upstream snapshot (d074e41) >>* Drop the patch applied upstream and reorder the remaining patch >>* Update upstream license to GPL-3+ following upstream change >>* Add a missing upstream copyright holder >> >> Regards, >> -- >> Xiyue Deng >> -- Xiyue Deng
Bug#1032662: elpa-debian-el: deb-view fails on zstd compressed debs
Hi Sven, I'd like to experiment an implementation to add zstd support (as well as lzma if possible). Do you know which ubuntu deb files are using zstd or lzma compressions so that I can use to test? -- Xiyue Deng
Bug#1070881: reportbug: Provide an option to skip loading configuration files
Package: reportbug Version: 12.0.0 Severity: wishlist I'd like to propose adding an option to skip loading configuration files (/etc/reportbug.conf and ~/.reportbugrc). The use case is for external programs that runs reportbug (e.g. debian-bug in elpa-debian-el) which provides its own command line switches and have an assumption on the output. When a user set some custom options, notably CC related ones, it may interfere with how X-Debbugs-Cc is handled and broke some of the assumptions of external tools (see https://bugs.debian.org/1032662). With an option to disable loading any configuration files we ensure the default behavior so that external tools have a way to maintain some assumptions. There are probably other ways to assist external tools, but as some have been working in this way having this option may be an easier way to help. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages reportbug depends on: ii apt2.6.1 ii python33.11.2-1+b1 ii python3-reportbug 12.0.0 ii sensible-utils 0.0.17+nmu1 reportbug recommends no packages. Versions of packages reportbug suggests: pn claws-mail ii debconf 1.5.82 ii debsums 3.0.2.1 pn dlocate ii emacs-bin-common1:29.3+1-3~bpo12+0manphiz1 ii file1:5.44-3 ii gnupg 2.2.40-1.1 ii postfix [mail-transport-agent] 3.7.10-0+deb12u1 pn python3-urwid pn reportbug-gtk ii xdg-utils 1.1.3-4.1 Versions of packages python3-reportbug depends on: ii apt2.6.1 ii file 1:5.44-3 ii python33.11.2-1+b1 ii python3-apt2.6.0 ii python3-debian 0.1.49 ii python3-debianbts 4.0.1 ii python3-requests 2.28.1+dfsg-1 ii sensible-utils 0.0.17+nmu1 python3-reportbug suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries
Daniel Kahn Gillmor writes: > Control: tags 1069908 - moreinfo > > Hi Xiyue Deng-- > > On Wed 2024-05-08 19:13:37 -0700, Xiyue Deng wrote: >> For this issue, it looks like debian-bug.el is passing "--list-cc=none" >> to reportbug which then becomes part of the message. This is fixed in >> [1] and pending sponsoring. > > thanks for this analysis and work! > Sure thing! >> I cannot seem to reproduce this. debian-bug.el tries to get full name >> and email from several sources, such as user-full-name, >> user-mail-address, envvars like DEBFULLNAME, DEBNAME, NAME, DEBEMAIL, >> EMAIL, REPORTBUGEMAIL, etc. So there may be something unconventional >> that triggered this. Can you check if your configuration set those info >> in multiple places? What happens if you clear some of them? > > Here are the plausibly relevant env vars i have set (generated by > running `M-1 M-! printenv` from within emacs itself and then manually > pruning for things that include either my name or e-mail address): > > ``` > DEBFULLNAME=Daniel Kahn Gillmor > DEBEMAIL=d...@fifthhorseman.net > DEBSIGN_MAINT=Daniel Kahn Gillmor > EMAIL=d...@fifthhorseman.net > ``` > > None of this seems wrong to me; or even if it does, it still ought to be > able to be correctly interpreted by debian-bug.el, and de-duplicated. > > I decided to look in ~/.reportbugrc and i find i have the following settings: > > ``` > reportbug_version "5.0" > mode standard > ui text > no-cc > list-cc-me > ``` > > I have no recollection of setting either no-cc or list-cc-me, and i > confess i don't really understand why these options are distinct. > Perhaps this was from ancient run (or runs?) of `reportbug --configure`? > > Without modifying any env vars, I tried commenting out both the `no-cc` > and `list-cc-me` options in ~/.reportbugrc, and with both of those > removed, the generated X-Debbugs-Cc line after a `M-x debian-bug` was > just: > > ``` > X-Debbugs-Cc: none, Daniel Kahn Gillmor > ``` > Thanks for testing. So what's happening is that the info debian-bug get from the envvars are your full name and your email address. On the other hand with "list-cc-me" you only get the email part there. So from debian-bug point of view those are different info so the de-duplication doesn't happen (if both have the same info debian-el will dedup though). Ideally there should be a way to let reportbug ignore the configuration files and only process options passing through command line so that user configuration doesn't change its behavior, but as far as I can tell there is no option to do that (yet)[1]. Hopefully it will be implemented eventually. > So perhaps with the fix you have pending, this will be resolved. > Sounds good. > Thanks! > > --dkg > [1] https://salsa.debian.org/reportbug-team/reportbug/-/blob/master/reportbug/utils.py?ref_type=heads#L1458 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1069908: elpa-debian-el: X-Debbugs-Cc: is weirdly overpopulated with duplicate or broken entries
Control: tags -1 +moreinfo +pending Hi Daniel, Daniel Kahn Gillmor writes: > Package: elpa-debian-el > Version: 37.11 > Severity: normal > X-Debbugs-Cc: none, d...@fifthhorseman.net, Daniel Kahn Gillmor > > > When i do "M-x debian-bug P elpa-debian-el RET" i get the template you > see here. > > Weirdly, X-Debbugs-Cc is pre-populated in this way. > > There are at least two things wrong with X-Debbugs-Cc here: > > - the string "none" shouldn't be present. This smells like a bug, >where the empty string is somehow being misinterpreted as the string >"none", but i odn't know where it's happening. > > For this issue, it looks like debian-bug.el is passing "--list-cc=none" to reportbug which then becomes part of the message. This is fixed in [1] and pending sponsoring. > - the two additional addresses are duplicative. Even if there is code >that tries to re-add a duplicate address, it should notice that the >e-mail address parts are identical, and coalesce them into a single >address. > I cannot seem to reproduce this. debian-bug.el tries to get full name and email from several sources, such as user-full-name, user-mail-address, envvars like DEBFULLNAME, DEBNAME, NAME, DEBEMAIL, EMAIL, REPORTBUGEMAIL, etc. So there may be something unconventional that triggered this. Can you check if your configuration set those info in multiple places? What happens if you clear some of them? > I don't understand the codebase well enough to be able to see how these > things are happening, but if you want me to test some changes, or report > on any other config, please let me know. > > --dkg > [1] https://salsa.debian.org/emacsen-team/debian-el/-/commit/116b3e7c839bf52fa01adba0758487a47cade87a -- Xiyue Deng signature.asc Description: PGP signature
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Xiyue Deng writes: > Xiyue Deng writes: > >> Xiyue Deng writes: >> >>> Sean Whitton writes: >>> >>>> Hello, >>>> >>>> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: >>>> >>>>> Sean Whitton writes: >>>>> >>>>>> Hello, >>>>>> >>>>>> Rob, can you review the implementation in d/rules for Xiyue's patch to >>>>>> this bug, please? I'm not sure it's the straightforward way to do it. >>>>>> >>>>>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >>>>>> for the relationships. >>>>> >>>>> Ah indeed, I should update the versions after the Emacs 29.3 upload, >>>>> though I think you meant "1:29.3+1-2". Also, as we are just moving >>>>> files from emacs-common to emacs-pgtk, breaks/replaces is only needed >>>>> from emacs-pgtk to emacs-common but no the other way around, so I >>>>> dropped the breaks on emacs-pgtk from emacs-common. >>>>> >>>>> I have updated the patch accordingly and attached here. PTAL. >>>> >>>> Thanks. >>>> >>>>> (BTW, I'm always curious about the "+1" part of the version number. I >>>>> would expect something like "+dfsg" or "+ds" as we are dropping some >>>>> of the non-DFSG conformant files, but why "+1"? :) >>>> >>>> It's just in case the DFSG split is done incorrectly and another attempt >>>> is required -- given how complex it is. >>> >>> Ack, totally understandable. >>> >>> With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it >>> and bumped the breaks/replaces version. PTAL. >> >> Rob suggested on IRC to be a bit more conservative by removing the file >> and remove the directories upwards recursively so that we can catch >> future addition to the directories more easily. The patch has been >> adjusted accordingly. PTAL. > > Friendly ping. Rob, do you have any more comments on the current > approach? Friendly ping 2 :) -- Xiyue Deng
Bug#1054420: RFS: js2-mode/0.0~git20230628.79bc78d-1 [RC] [Team] -- Emacs mode for editing Javascript programs
Control: retitle -1 RFS: js2-mode/0.0~git20240418.9b90d31-1 [RC] [Team] -- Emacs mode for editing Javascript programs Hi, A new snapshot was available and I have updated the package according with a few more improvements. Please find the latest package on mentors[1] and changes on salsa[2] (sans the finalizing commit.) TIA! [1] https://mentors.debian.net/package/js2-mode/ [2] https://salsa.debian.org/emacsen-team/js2-mode -- Xiyue Deng
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Currently there is a behavior difference between elpafied packages and upstream ELPA packages on `load-path' handling: for elpafied packages, all nested directories are added to `load-path', while for upstream ELPA only the root directory is added. Normally this should not be an issue, but when trying to elpafy auctex, it's nested directory "style/" contains many modules whose names collide with standard modules and hence broken Eglot. This sounds like a bad practice of the package, but it would still be good to match upstream behavior so as to minimize surprises. Will try to figure this out. -- Xiyue Deng
Bug#1070131: RFS: emacs-cfrs/1.6.0-1 [ITP] -- Child-frame based read-string for Emacs
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-cfrs": * Package name : emacs-cfrs Version : 1.6.0-1 Upstream contact : Alexander Miller * URL : https://github.com/Alexander-Miller/cfrs * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-cfrs Section : editors The source builds the following binary packages: elpa-cfrs - Child-frame based read-string for Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-cfrs/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-cfrs/emacs-cfrs_1.6.0-1.dsc Changes for the initial release: emacs-cfrs (1.6.0-1) unstable; urgency=medium . * Initial release (Closes: #1070096) Note that this is a required dependency of newer treemacs versions which I plan to request for RFS soon after this is sponsored. Regards, -- Xiyue Deng
Bug#1070096: ITP: emacs-cfrs -- Child-frame based read-string for Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-cfrs Version : 1.6.0 Upstream Author : Alexander Miller * URL or Web page : https://github.com/Alexander-Miller/cfrs * License : GPL-3+ Programming lang: Emacs Lisp Description : Child-frame based read-string for Emacs cfrs.el is a simple alternative to `read-string' that allows reading input via a small child-frame spawned at the position of the cursor. Its goal is to make the string input interface closer to those used in modern GUI programs and to help the user with having to switch focus from whatever they are doing currently to look at the minibuffer. This is a dependency of newer Emacs treemacs versions. I intend to maintain this package within the Debian Emacsen team .
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Xiyue Deng writes: > Xiyue Deng writes: > >> Sean Whitton writes: >> >>> Hello, >>> >>> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: >>> >>>> Sean Whitton writes: >>>> >>>>> Hello, >>>>> >>>>> Rob, can you review the implementation in d/rules for Xiyue's patch to >>>>> this bug, please? I'm not sure it's the straightforward way to do it. >>>>> >>>>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >>>>> for the relationships. >>>> >>>> Ah indeed, I should update the versions after the Emacs 29.3 upload, >>>> though I think you meant "1:29.3+1-2". Also, as we are just moving >>>> files from emacs-common to emacs-pgtk, breaks/replaces is only needed >>>> from emacs-pgtk to emacs-common but no the other way around, so I >>>> dropped the breaks on emacs-pgtk from emacs-common. >>>> >>>> I have updated the patch accordingly and attached here. PTAL. >>> >>> Thanks. >>> >>>> (BTW, I'm always curious about the "+1" part of the version number. I >>>> would expect something like "+dfsg" or "+ds" as we are dropping some >>>> of the non-DFSG conformant files, but why "+1"? :) >>> >>> It's just in case the DFSG split is done incorrectly and another attempt >>> is required -- given how complex it is. >> >> Ack, totally understandable. >> >> With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it >> and bumped the breaks/replaces version. PTAL. > > Rob suggested on IRC to be a bit more conservative by removing the file > and remove the directories upwards recursively so that we can catch > future addition to the directories more easily. The patch has been > adjusted accordingly. PTAL. Friendly ping. Rob, do you have any more comments on the current approach? -- Xiyue Deng
Bug#1065302: RFS: elpa-rust-mode/1.0.5+git20240415.e54bbae-1 -- Major Emacs mode for editing Rust source code)
Control: retitle -1 RFS: elpa-rust-mode/1.0.5+git20240415.e54bbae-1 -- Major Emacs mode for editing Rust source code Another sync to latest snapshot that fixes precedence with rust-ts-mode. (Mentors[1], team repo[2].) PTAL, TIA! -- Xiyue Deng [1] https://mentors.debian.net/package/elpa-rust-mode/ [2] https://salsa.debian.org/emacsen-team/rust-mode
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Xiyue Deng writes: > Sean Whitton writes: > >> Hello, >> >> On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: >> >>> Sean Whitton writes: >>> >>>> Hello, >>>> >>>> Rob, can you review the implementation in d/rules for Xiyue's patch to >>>> this bug, please? I'm not sure it's the straightforward way to do it. >>>> >>>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >>>> for the relationships. >>> >>> Ah indeed, I should update the versions after the Emacs 29.3 upload, >>> though I think you meant "1:29.3+1-2". Also, as we are just moving >>> files from emacs-common to emacs-pgtk, breaks/replaces is only needed >>> from emacs-pgtk to emacs-common but no the other way around, so I >>> dropped the breaks on emacs-pgtk from emacs-common. >>> >>> I have updated the patch accordingly and attached here. PTAL. >> >> Thanks. >> >>> (BTW, I'm always curious about the "+1" part of the version number. I >>> would expect something like "+dfsg" or "+ds" as we are dropping some >>> of the non-DFSG conformant files, but why "+1"? :) >> >> It's just in case the DFSG split is done incorrectly and another attempt >> is required -- given how complex it is. > > Ack, totally understandable. > > With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it > and bumped the breaks/replaces version. PTAL. Rob suggested on IRC to be a bit more conservative by removing the file and remove the directories upwards recursively so that we can catch future addition to the directories more easily. The patch has been adjusted accordingly. PTAL. -- Xiyue Deng >From 400a3efac8f0d2ab02ba18ac4cb5ee2324bf7c23 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 13 Mar 2024 10:22:46 -0700 Subject: [PATCH] Install GSettings schema in pgtk build only (Closes: #1050393) * In PGTK build it generates the GSettings schema file "/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" which is not needed in other variant. * Move the file from emacs-common to emacs-pgtk, and adds proper breaks/replaces to ensure a smooth upgrade. --- debian/changelog | 7 +++ debian/control | 11 +-- debian/rules | 12 +++- 3 files changed, 27 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index 5d4e9f050ae..e2a31a36fcb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +emacs (1:29.3+1-3) UNRELEASED; urgency=medium + + * Team upload. + * Install GSettings schema in pgtk build only (Closes: #1050393) + + -- Xiyue Deng Wed, 13 Mar 2024 10:22:10 -0700 + emacs (1:29.3+1-2) unstable; urgency=medium * Change native-comp-async-report-warnings-errors to `silent'. diff --git a/debian/control b/debian/control index e168717089f..3c04652c769 100644 --- a/debian/control +++ b/debian/control @@ -138,8 +138,15 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader Recommends: fonts-noto-color-emoji Suggests: emacs-common-non-dfsg Conflicts: emacs-gtk, emacs-lucid, emacs-nox -Replaces: emacs-gtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Replaces: + emacs-gtk, + emacs-lucid, + emacs-nox, + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), +Breaks: + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), Description: GNU Emacs editor (with GTK+ Wayland GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with a graphical user interface diff --git a/debian/rules b/debian/rules index 6250f60ea9b..1262e568c80 100755 --- a/debian/rules +++ b/debian/rules @@ -489,6 +489,12 @@ override_dh_auto_install: $(autogen_install_files) rm -f $(pkgdir_common)/usr/share/info/emacs/dir.old install -d $(pkgdir_common)/usr/local/share/emacs/site-lisp + + # PGTK builds a GSettings schema that is PGTK specific and + # should not be shipped in emacs-common + cd $(pkgdir_common)/usr/share \ + && rm glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml \ + && rmdir --parents glib-2.0/schemas endif ## @@ -548,7 +554,7 @@ override_dh_auto_install: $(autogen_install_files) ## # emacs-pgtk -ifneq (,$(findstring emacs, $(shell dh_listpackages))) +ifneq (,$(findstring emacs-pgtk, $(shell dh_listpackages))) $(call install_common_binpkg_bits,$(install_dir_pgtk),$(pkgdir_pgtk),emacs-pgtk,pgtk)
Bug#1069620: RFS: lua-mode/20231023~git-1 -- Emacs major-mode for editing Lua programs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lua-mode": * Package name : lua-mode Version : 20231023~git-1 Upstream contact : immerrr * URL : https://github.com/immerrr/lua-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/lua-mode Section : lisp The source builds the following binary packages: elpa-lua-mode - Emacs major-mode for editing Lua programs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20231023~git-1.dsc Changes since the last upload: lua-mode (20231023~git-1) unstable; urgency=medium . * Sync to latest upstream snapshot (d074e41) * Drop the patch applied upstream and reorder the remaining patch * Update upstream license to GPL-3+ following upstream change * Add a missing upstream copyright holder Regards, -- Xiyue Deng
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Sean Whitton writes: > Hello, > > On Wed 27 Mar 2024 at 11:40pm -07, Xiyue Deng wrote: > >> Sean Whitton writes: >> >>> Hello, >>> >>> Rob, can you review the implementation in d/rules for Xiyue's patch to >>> this bug, please? I'm not sure it's the straightforward way to do it. >>> >>> Xiyue, I think it would make sense to use emacs-common (<< 1:29.3+2-2), >>> for the relationships. >> >> Ah indeed, I should update the versions after the Emacs 29.3 upload, >> though I think you meant "1:29.3+1-2". Also, as we are just moving >> files from emacs-common to emacs-pgtk, breaks/replaces is only needed >> from emacs-pgtk to emacs-common but no the other way around, so I >> dropped the breaks on emacs-pgtk from emacs-common. >> >> I have updated the patch accordingly and attached here. PTAL. > > Thanks. > >> (BTW, I'm always curious about the "+1" part of the version number. I >> would expect something like "+dfsg" or "+ds" as we are dropping some >> of the non-DFSG conformant files, but why "+1"? :) > > It's just in case the DFSG split is done incorrectly and another attempt > is required -- given how complex it is. Ack, totally understandable. With the release of Emacs 1:29.3+1-2, I have rebased the patch onto it and bumped the breaks/replaces version. PTAL. -- Xiyue Deng >From c0a4ee1d76f2206594ce9897b651bbdd22baf716 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 13 Mar 2024 10:22:46 -0700 Subject: [PATCH] Install GSettings schema in pgtk build only (Closes: #1050393) * In PGTK build it generates the GSettings schema file "/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" which is not needed in other variant. * Move the file from emacs-common to emacs-pgtk, and adds proper breaks/replaces to ensure a smooth upgrade. --- debian/changelog | 7 +++ debian/control | 11 +-- debian/rules | 9 - 3 files changed, 24 insertions(+), 3 deletions(-) diff --git a/debian/changelog b/debian/changelog index 5d4e9f050ae..e2a31a36fcb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +emacs (1:29.3+1-3) UNRELEASED; urgency=medium + + * Team upload. + * Install GSettings schema in pgtk build only (Closes: #1050393) + + -- Xiyue Deng Wed, 13 Mar 2024 10:22:10 -0700 + emacs (1:29.3+1-2) unstable; urgency=medium * Change native-comp-async-report-warnings-errors to `silent'. diff --git a/debian/control b/debian/control index e168717089f..3c04652c769 100644 --- a/debian/control +++ b/debian/control @@ -138,8 +138,15 @@ Provides: editor, emacs, emacsen, info-browser, mail-reader, news-reader Recommends: fonts-noto-color-emoji Suggests: emacs-common-non-dfsg Conflicts: emacs-gtk, emacs-lucid, emacs-nox -Replaces: emacs-gtk, emacs-lucid, emacs-nox, emacs-bin-common (<< 1:29.2) -Breaks: emacs-bin-common (<< 1:29.2) +Replaces: + emacs-gtk, + emacs-lucid, + emacs-nox, + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), +Breaks: + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-3~), Description: GNU Emacs editor (with GTK+ Wayland GUI support) GNU Emacs is the extensible self-documenting text editor. This package contains a version of Emacs with a graphical user interface diff --git a/debian/rules b/debian/rules index 6250f60ea9b..205c45dff65 100755 --- a/debian/rules +++ b/debian/rules @@ -425,6 +425,9 @@ override_dh_auto_install: $(autogen_install_files) cp -a $(install_dir_pgtk)/* $(pkgdir_common) rm -r $(pkgdir_common)/usr/bin + # PGTK builds a GSettings schema that is PGTK specific and + # should not be shipped in emacs-common + rm -r $(pkgdir_common)/usr/share/glib-2.0 rm \ $(pkgdir_common)/$(libexec_dir_emacs)/hexl \ $(pkgdir_common)/$(libexec_dir_emacs)/emacs-*.pdmp \ @@ -548,7 +551,7 @@ override_dh_auto_install: $(autogen_install_files) ## # emacs-pgtk -ifneq (,$(findstring emacs, $(shell dh_listpackages))) +ifneq (,$(findstring emacs-pgtk, $(shell dh_listpackages))) $(call install_common_binpkg_bits,$(install_dir_pgtk),$(pkgdir_pgtk),emacs-pgtk,pgtk) # install desktop entries @@ -557,6 +560,10 @@ override_dh_auto_install: $(autogen_install_files) debian/emacs.desktop \ debian/emacs-term.desktop \ $(pkgdir_pgtk)/usr/share/applications/ + # install GSettings schema + install -d $(pkgdir_pgtk)/usr/share/glib-2.0 + cp -a $(install_dir_pgtk)/usr/share/glib-2.0/* \ + $(pkgdir_pgtk)/usr/share/glib-2.0 endif ## -- 2.39.2
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Control: retitle -1 RFS: scala-mode-el/1:1.1.0+git20240113.4c6d636-1 [RC] [Team] -- Emacs major mode for editing scala source code Xiyue Deng writes: > Hi, > > Xiyue Deng writes: > >> Nicholas D Steeves writes: >> >>> Hi, >>> >>> Paul Wise writes: >>> >>>> On Mon, 2023-12-04 at 02:28 -0800, Xiyue Deng wrote: >>>> >>>>> I think dh_auto_clean is the right place, because the build failure is >>>>> because that the clean target requires the existence of >>>>> scala-mode-pkg.el, which is generated by Cask. As we don't have Cask, >>>>> we need to provide this before dh_auto_clean runs. >>> >>> The generation of this metadata, and file, is one of dh_elpa's primary >>> functions. See the section of the dh_elpa man page that discusses >>> DEB_VERSION_UPSTREAM. >> >> Ah I see what you mean: as long as dh_elpa can detect the version >> correctly we don't need to provide an actual *-pkg.el file and can just >> let dh_elpa generate it, which also avoids the potential policy >> violation Paul pointed out. >> >> So now I make override_dh_auto_clean to call dh_elpa to generate this >> file for use. However, as the generated file is "buried" pretty deep in >> the generated directory, the command becomes pretty long, but it works. >> Admittedly that requiring a generated file during clean is pretty exotic >> and I haven't encountered it elsewhere (yet) which is good. >> >> New handling strategy pushed to team repo. PTAL. >> >>> >>> Read Policy §4.9 closely; Cask cannot be used. >>> >>> Grep the buildlog for "dh_" and if you'd like to see a more >>> comprehensive list of applicable entry points in the sequence, try >>> >>> $ dh binary-indep --no-act >>> >>> It's also worth reading the dh man page. >> >> Ack. >> >>> >>>> I think it is against ftp-master rules to have generated files >>>> present that can't be built using only tools from Debian main. >>> >>> Yes, and thank you for bringing this up. >>> >>>> So I think you would need to package Cask first? >>> >>> Cask is not relevant nor needed, and dh_elpa is used. Whenever this >>> topic comes up on IRC, new contributors are briefed and are additionally >>> referred to the RFP for Cask, where the unsuitability of this type of >>> tool for Debian packaging is discussed (#837922). It's also worth >>> noting that dh_elpa was written by people by current and/or past members >>> of the Debian TC. >>> >>> Xiyue Deng writes: >>> >>>> Cask and similar tools like Eask and Eldev are tools that automatically >>>> install dependencies of an Emacs addon package, which doesn't use and >>>> circumvents the system package management. I think the Emacsen team >>>> chooses not to package those tools and prefers using dh-elpa for the >>>> job, and may override build target to avoid using those tools. >>> >>> If you're familiar with the concept of "hats", then when you're working >>> on debian/* you need to put on your Debian packaging hat, and when >>> you're working on !(debian/*) you use your upstream >>> development/debugging/packaging hat. These tools are not relevant to >>> Debian packaging and referring to them is not useful for describing >>> packaging problems or decisions; there will always be a more direct and >>> useful description. >> >> I think those external tools are not completely irrelevant but just in >> the sense that we do it the Debian way. Usually they provide two types >> of functions: 1) automatic dependency management, and 2) automatic file >> generation required for testing and distribution through elpa. In >> Debian, the former is handled by apt, and the latter by dh_elpa, and we >> take effort to make sure they behave the same. >> >>> >>> Cheers, >>> Nicholas >>> It looks like the bug was archived so the previous mail didn't reach BTS. So unarchived, reopened, and retitle the bug with newer snapshot, and also resending the following from previous message. > > With the release of the new policy version, I have done some more clean > up to the package and update team repo and mentors. PTAL. TIA! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1069326: dh-elpa: Don't rename files under test directories during autopkgtest by default
Package: dh-elpa Version: 2.0.17 Severity: normal X-Debbugs-Cc: none, Xiyue Deng During autopkgtest, dh_elpa_test will rename the non-test source files so as to ensure we are running the test using the Emacs add-on modules from the installed package instead of from the source directories. The way that dh_elpa_test currently works is to only keep files that have a test case defined in it. However, this doesn't take utilities and artifacts, which are usually defined under test directories, under consideration, and without those the tests are broken as well. Therefore I'd like to propose retaining all files under test directories from being renamed in autopkgtest. I have been testing a fix in [1] which seems to work in common cases. I have also attached the patches at the end of the email as well. Please review and comment. TIA! [1] https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...retain-test-files-in-autopkgtest?from_project_id=18920 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-elpa depends on: ii debhelper 13.11.4 ii emacs 1:29.3+1-2~bpo12+0manphiz1 ii emacs-gtk [emacs] 1:29.3+1-2~bpo12+0manphiz1 ii libarray-utils-perl 0.5-3 ii libconfig-tiny-perl 2.28-2 ii libdebian-source-perl 0.122 ii libdpkg-perl1.21.22 ii libfile-find-rule-perl 0.34-3 ii libtext-glob-perl 0.11-3 ii perl5.36.0-7+deb12u1 dh-elpa recommends no packages. dh-elpa suggests no packages. -- no debconf information >From 48514b41927f8601c6e1af7ebcf49c4af9a16b54 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Fri, 19 Apr 2024 14:14:31 -0700 Subject: [PATCH 1/2] Exclude test directories from renaming in autopkgtest by default * Files under test directories may also include utilities that are used in tests but don't have any test in them. It makes sense to keep them by default during autopkgtest to make it work out-of-the-box. --- dh_elpa_test | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/dh_elpa_test b/dh_elpa_test index 14e31dd..b9f1152 100755 --- a/dh_elpa_test +++ b/dh_elpa_test @@ -271,7 +271,9 @@ if ($autopkgtest) { my $rule = File::Find::Rule->new; $rule ->or(File::Find::Rule - ->name('.pc', 'debian', '.git') + ->name('.pc', 'debian', '.git', # exclude non-source directories + 'test', 'tests', # exclude test directories + ) ->directory->prune->discard, File::Find::Rule->new); $rule -- 2.39.2 >From eb4f407d6c1541fda298dcfe8bcaee1fdebd5677 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Fri, 19 Apr 2024 14:24:40 -0700 Subject: [PATCH 2/2] Add more comments to describe the purpose of renaming source files --- dh_elpa_test | 4 1 file changed, 4 insertions(+) diff --git a/dh_elpa_test b/dh_elpa_test index b9f1152..c0e99e0 100755 --- a/dh_elpa_test +++ b/dh_elpa_test @@ -268,6 +268,10 @@ if ($autopkgtest) { exit 0; } +# Compile a list of files to be renamed during autopkgtest. This usually +# renames source *.el file outside the test directories so that during +# autopkgtest we are testing the installed package instead of relying on +# source files from the source directory. my $rule = File::Find::Rule->new; $rule ->or(File::Find::Rule -- 2.39.2
Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Sean Whitton writes: > Hello, > > On Thu 18 Apr 2024 at 06:24pm -07, Xiyue Deng wrote: > >> Sean Whitton writes: >> >>> control: tag -1 + moreinfo >>> >>> Hello Xiyue, >>> >>> Please explain the autopkgtest_keep change. Remember that autopkgtests >>> are to test the installed package. If you need to keep the .el files, >>> it must be for some reason other than because the test suite actually >>> just tests those. >>> >> >> I think this is another example of buttercup tests that requires source >> .el files to run. I'll probably open a bug on buttercup to see whether >> this is required for buttercup. Meanwhile I think it'd probably be >> better to just disable autopkgtest as the tests are already run as part >> of the build process. > > I agree. It is important not to use autopkgtest_keep without being sure > it's the right answer. > So it turns out using "disable" in d/elpa-test also disable dh_elpa_test in d/rules so that the test is not run as part of the package building, which would be suboptimal in that we don't run any test at all. I'll try to see a way to disable it only in autopkgtest in dh-elpa. On the other hand, it looks like I misjudged the situation of the buttercup tests that with "autopkgtest_keep = test/*" it just works, which is much better than disabling. >>> You've removed the Built-Using with the justification that it's an >>> arch:all package, but that doesn't make sense; Built-Using is for >>> licensing reasons, and may well be applicable to an arch:all package (I >>> think this came up before with one of your uploads?). >> >> Ah I was following the suggestions of Lintian which said it cannot be >> used by arch:all packages which is probably wrong. > > See #999785. > Ack. I also checked that bug before and wondering why that lintian tag is still enabled. Hopefully Bug#1069256 will move things forward. >> On the other hand, on a closer look at the policy regarding >> Built-Using on section 7.8[1], it has the following passage: >> >> , >> | This field should be used only when there are license or DFSG >> | requirements to retain the referenced source packages. It should not be >> | added solely as a way to locate packages that need to be rebuilt against >> | newer versions of their build dependencies. >> ` >> >> I checked that lua-mode is of GPL-2+[2], and of all its dependencies >> lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL >> 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using >> requirement. The change was introduced in [3] but it was part of the >> modernization effort so there is no direct justification of adding the >> field. May be I'm missing something here? > > It sounds like it shouldn't have been introduced. So you can remove it > based on your reading of Policy, and briefly note your reasoning in > d/changelog. Updated d/changelog accordingly. Also took this opportunity to add myself to uploaders. That way we don't have to deal with the "team upload" complications for sponsors. Mentors and team repo are both updated. PTAL. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Sean Whitton writes: > control: tag -1 + moreinfo > > Hello Xiyue, > > Please explain the autopkgtest_keep change. Remember that autopkgtests > are to test the installed package. If you need to keep the .el files, > it must be for some reason other than because the test suite actually > just tests those. > I think this is another example of buttercup tests that requires source .el files to run. I'll probably open a bug on buttercup to see whether this is required for buttercup. Meanwhile I think it'd probably be better to just disable autopkgtest as the tests are already run as part of the build process. > You've removed the Built-Using with the justification that it's an > arch:all package, but that doesn't make sense; Built-Using is for > licensing reasons, and may well be applicable to an arch:all package (I > think this came up before with one of your uploads?). Ah I was following the suggestions of Lintian which said it cannot be used by arch:all packages which is probably wrong. On the other hand, on a closer look at the policy regarding Built-Using on section 7.8[1], it has the following passage: , | This field should be used only when there are license or DFSG | requirements to retain the referenced source packages. It should not be | added solely as a way to locate packages that need to be rebuilt against | newer versions of their build dependencies. ` I checked that lua-mode is of GPL-2+[2], and of all its dependencies lua5.3 is of MIT which is compatible with GPL, and the rest are all GPL 2+ or 3+, so I don't see a license or DFSG need to add this Built-Using requirement. The change was introduced in [3] but it was part of the modernization effort so there is no direct justification of adding the field. May be I'm missing something here? -- Xiyue Deng [1] https://www.debian.org/doc/debian-policy/ch-relationships.html#additional-source-packages-used-to-build-the-binary-built-using [2] Upstream switched to GPL-3+ in 2022 but we haven't packaged that yet. [3] https://salsa.debian.org/emacsen-team/lua-mode/-/commit/2e207a6835a3899f6eba0675c4763c1757335bcc signature.asc Description: PGP signature
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Package: dh-elpa Version: 2.0.17 Severity: wishlist Hi, Currently dh-elpa installs all *.el files directly under the root of ELPA installation directory. This handles most ELPA packages without issues, though there are some packages that starts to use nested directory structures, e.g. auctex[1]. Therefore I'd like to propose to add nested directory support in dh-elpa. I have a draft implementation that adds support for recursively create symlink in subdirectories as well as recursive byte-compiling. You can check it out in my salsa repo[2], and the patches are also attached. I have tested with the work-in-progress auctex which seems to work, but it would be good to know whether there are any aspects that I missed from the dh-elpa handling. Any comments are welcome. [1] When installing elpa.gnu.org auctex will have a nested `style/' directory, though for the auctex packaged in Debian has not been elpafied (which I'm trying to experiment in https://bugs.debian.org/1056939) [2] https://salsa.debian.org/manphiz/dh-elpa/-/tree/nested-directory-support?ref_type=heads -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dh-elpa depends on: ii debhelper 13.11.4 ii emacs 1:29.3+1-2~bpo12+0manphiz1 ii emacs-gtk [emacs] 1:29.3+1-2~bpo12+0manphiz1 ii libarray-utils-perl 0.5-3 ii libconfig-tiny-perl 2.28-2 ii libdebian-source-perl 0.122 ii libdpkg-perl1.21.22 ii libfile-find-rule-perl 0.34-3 ii libtext-glob-perl 0.11-3 ii perl5.36.0-7+deb12u1 dh-elpa recommends no packages. dh-elpa suggests no packages. -- no debconf information >From 2df1f0d70c62e322618e7ed64515b33566c2f5f2 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Mon, 15 Apr 2024 13:03:16 -0700 Subject: [PATCH 1/3] Byte compile recursively during install to handle nested directories * This handles addons that have source files under nested directories in ELPA install directories. --- helper/install | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/helper/install b/helper/install index 39db695..eb68ef5 100755 --- a/helper/install +++ b/helper/install @@ -58,7 +58,8 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}" ${FLAVOR} --quick --batch -l package \ --eval "(setq package-user-dir \"/nonexistent\")" \ --eval "(add-to-list 'package-directory-list \"$src_dir\")" \ - -f package-initialize -f batch-byte-compile ./*.el > Install.log 2>&1 + -f package-initialize \ + --eval "(byte-recompile-directory \".\" 0)" > Install.log 2>&1 if test $? -ne 0 then cat Install.log -- 2.39.2 >From 5729f59dfa29bf9acda3959ff00aab179744e6d0 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 17 Apr 2024 14:06:42 -0700 Subject: [PATCH 2/3] Create symlink from elpa-src to elpa recursively * Instead of using `ln -s', use `cp -rs' so that directories are handled recursively. * In remove we use `rmdir --ignore-fail-on-non-empty' so this was handled automatically as well. --- helper/install | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/helper/install b/helper/install index eb68ef5..8d748c8 100755 --- a/helper/install +++ b/helper/install @@ -50,7 +50,7 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}" # policy). This makes complation easy, and also allows find-function # and find-library to work properly. Also link all other top level # files and directories into the flavor directory -(cd "${elc_dir}" && ln -sf "${el_dir}"* .) +(cd "${elc_dir}" && cp -rsf "${el_dir}"* .) # Byte compile them (cd "${elc_dir}" -- 2.39.2 >From b15e026ce0d4166d427aca14d3451eb9b60fb1c9 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 17 Apr 2024 14:17:41 -0700 Subject: [PATCH 3/3] Update d/changelog --- debian/changelog | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/debian/changelog b/debian/changelog index 161b05c..20026ae 100644 --- a/debian/changelog +++ b/debian/changelog @@ -13,7 +13,13 @@ dh-elpa (2.1.2) UNRELEASED; urgency=medium * Add transient to the list of packages packaged separately as well as provided with emacs. - -- Xiyue Deng Sat, 06 Apr 2024 16:41:14 -0700 + [ Xiyue Deng ] + * Add support for nested directory in elpa installation. +- Byte compile recursively during install to handle nested + directories. +- Create symlink from elpa-src to elpa recursively. + + -- Xiyue Deng Wed, 17 Apr 2024 14:16:00 -0700 dh-elpa (2.1.1) experimental; urgency=medium -- 2.39.2
Bug#1056939: auctex: auctex is incompatible with use-package/elpa
I have made a new MR[1] using a separate branch so that I can continue to experiment on master. It also changes how *-pkg.el is generated. PTAL. -- Xiyue Deng [1] https://salsa.debian.org/salve/auctex/-/merge_requests/4
Bug#1069137: auctex: New upstream version 13.3
Package: auctex Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng Hi, A new upstream version 13.3 is available[1]. It is also a little confusing in that the auctex version on ELPA is already at 14.0.4[2]. It may worth figuring out which is the authentic upstream. I have made 2 pull requests based on the 13.3 release, one is for the upstream branch[3] and the other is for the master branch[4]. As noted in [3], a tag `upstream/13.3' should be created on upstream branch for `git deborig' to work. [1] https://www.gnu.org/software/auctex/ [2] https://elpa.gnu.org/packages/auctex.html [3] https://salsa.debian.org/salve/auctex/-/merge_requests/5 [4] https://salsa.debian.org/salve/auctex/-/merge_requests/6 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-20-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1069073: lua-mode: FTBFS: failing tests
Control: tags -1 pending Hi, I have committed a fix to the team repo (together with other tweaks) and prepared a package on mentors. See Bug#1069078[1] for the RFS request. Please help sponsoring. TIA! -- Xiyue Deng [1] https://bugs.debian.org/1069078
Bug#1069078: Acknowledgement (RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs)
Forwarding to the Debian Emacsen Team list. Start of forwarded message From: Xiyue Deng To: sub...@bugs.debian.org Subject: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs Date: Mon, 15 Apr 2024 21:06:11 -0700 Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lua-mode": * Package name : lua-mode Version : 20210802-4 Upstream contact : immerrr * URL : https://github.com/immerrr/lua-mode * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/lua-mode Section : lisp The source builds the following binary packages: elpa-lua-mode - Emacs major-mode for editing Lua programs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20210802-4.dsc Changes since the last upload: lua-mode (20210802-4) unstable; urgency=medium . * Team upload * Mark lexical binding patch as Forwarded and Applied-Upstream * Add patch to use eval in lexical scope to fix tests (Closes: #1069073) * Keep source *.el in autopkgtest to make it work * Add Upstream-Contact in d/copyright * Update homepage to github page in d/control (old link no longer works) * Set Rules-Requires-Root to no in d/control * Drop Built-Using from arch:all package in d/control * Trim trailing whitespace in d/changelog * Bump debhelper from old 10 to 13 * Set debhelper-compat version in Build-Depends * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse * Update Standards-Version to 4.7.0; no change needed * Modernize d/watch with substitute strings to be more robust Regards, -- Xiyue Deng End of forwarded message
Bug#1069078: RFS: lua-mode/20210802-4 [RC] [Team] -- Emacs major-mode for editing Lua programs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "lua-mode": * Package name : lua-mode Version : 20210802-4 Upstream contact : immerrr * URL : https://github.com/immerrr/lua-mode * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/lua-mode Section : lisp The source builds the following binary packages: elpa-lua-mode - Emacs major-mode for editing Lua programs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lua-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lua-mode/lua-mode_20210802-4.dsc Changes since the last upload: lua-mode (20210802-4) unstable; urgency=medium . * Team upload * Mark lexical binding patch as Forwarded and Applied-Upstream * Add patch to use eval in lexical scope to fix tests (Closes: #1069073) * Keep source *.el in autopkgtest to make it work * Add Upstream-Contact in d/copyright * Update homepage to github page in d/control (old link no longer works) * Set Rules-Requires-Root to no in d/control * Drop Built-Using from arch:all package in d/control * Trim trailing whitespace in d/changelog * Bump debhelper from old 10 to 13 * Set debhelper-compat version in Build-Depends * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository, Repository-Browse * Update Standards-Version to 4.7.0; no change needed * Modernize d/watch with substitute strings to be more robust Regards, -- Xiyue Deng
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Hi Nicholas, Xiyue Deng writes: > Nicholas D Steeves writes: > > [..snip..] > >>>>>>* Fix issues in d/copyright >>>>>> - Clarify license to be GPL-3+ to be consistent with upstream >> >> This is unclear. Which licence was it before, and whose license are you >> talking about? Web-mode is a non-native package and debian/* is >> separate from the upstream source. Also, what does it mean to clarify a >> license? >> > > It used to be GPL-2, and I'm talking about the upstream license. The > upstream updated it to GPL-3 in 2022, which was actually after Thomas > last worked on the package. I think maybe I should change the wording > to "Update license to GPL-3+ following upstream changes"[5] > >>>>>> - Update copyright year info for upstream >>>>>> - Add copyright info for debian/* >> >> You added a license grant for debian/* where there was previously none >> with no explanation, notes, nor justification. Are you sure you have >> the right to do this? Contact debian-legal and ask them for a patch >> review of your intended changes. >> > > I checked upstream contributor list and didn't find the original > maintainer in it, so I believe it's a mistake that there is no separate > copyright section for debian/* which Thomas worked on and should be > attributed to him. But I agree that I should consult debian-legal@ on > how to properly handle this. I have sent a mail there[6] and CCed you. > Let's wait for an reply. > I have got some replies on debian-legal@l.d.o from Richard[1] and Soren[2] and both suggested that using GPL-3+ for upstream and GPL-2+ for debian/* is a good path forward. Soren further suggested the possibility of upgrading debian/* to GPL-3+ as GPL-2+ is compatible, but I don't think I'll go this round at this time as I will need to be added to the copyright list, which I might not be doing this time. These suggestions actually are aligned with my change at [3]. PTAL. TIA! -- Xiyue Deng [1] https://lists.debian.org/debian-legal/2024/04/msg2.html [2] https://lists.debian.org/debian-legal/2024/04/msg5.html [3] https://salsa.debian.org/emacsen-team/web-mode/-/commit/9a0a2ac9eb56a11bdeab7a98a42e5726fbb0e967 signature.asc Description: PGP signature
Bug#1068958: RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs
Control: retitle -1 RFS: elpa-snakemake/2.0.0+git20231210.4ad41da-1 [RC] [Team] -- Run Snakemake workflows from Emacs Some obvious silly copy-and-paste error in the title. Now it should be fixed :P -- Xiyue Deng
Bug#1068958: Xiyue Deng
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "elpa-snakemake": * Package name : elpa-snakemake Version : 2.0.0+git20231210.4ad41da-1 Upstream contact : Kyle Meyer * URL : https://git.kyleam.com/snakemake-mode/about * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/elpa-snakemake Section : editors The source builds the following binary packages: elpa-snakemake-mode - provides syntax highlighting for snakekmake files in emacs elpa-snakemake - Run Snakemake workflows from Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elpa-snakemake/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elpa-snakemake/elpa-snakemake_2.0.0+git20231210.4ad41da-1.dsc Changes since the last upload: elpa-snakemake (2.0.0+git20231210.4ad41da-1) unstable; urgency=medium . * Team upload * Sync to latest upstream snapshot (4ad41da) (Closes: #1068956) * Disable autopkgtest as the ERT tests require a writable $HOME * Modernize d/watch with substitute strings to be more robust * Add a version header in snakemake.el to workaround dh-elpa upstream version handling limitation * Commit Debian 3.0 (quilt) metadata * Trim trailing whitespace * Set upstream metadata fields: Repository * Update standards version to 4.7.0, no changes needed Regards, -- Xiyue Deng
Bug#1068956: elpa-snakemake: Failure during Debian Continous Integration
Package: elpa-snakemake Severity: serious X-Debbugs-Cc: debian-emac...@lists.debian.org, Xiyue Deng According to Debian Continuous Integration, elpa-snakemake is having an error during installation (see logs on amd64[1].) [1] https://ci.debian.net/packages/e/elpa-snakemake/unstable/amd64/45273239/ -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068869: mu4e: Cannot open load file: No such file or directory, mu4e
Jeremy Sowden writes: > Control: tags -1 confirmed > > On 2024-04-12, at 16:56:25 +0200, Clément Calmels wrote: >> Package: mu4e >> Version: 1.12.3-2 >> Severity: grave >> Justification: renders package unusable >> >> Dear Maintainer, >> >> I upgraded my Sid machine with the latest mu4e and maildir-utils >> packages : 1.12.3-2. Emacs isn't able to find the mu4e command >> anymore. From *Messages*: "Cannot open load file: No such file or >> directory, mu4e" when trying to load the mu4e library (using >> use-package). >> >> It seems that some files are missing (mu4e.el at least). > > Confirmed. Will get this fixed ASAP. Thanks for the report. > > J. > Hi Jeremy, I made a MR[1] with a potential fix. There is an alternative way to do this (where I left a comment[2]) so would like to hear your opinion before merging. Thanks! -- Xiyue Deng [1] https://salsa.debian.org/emacsen-team/maildir-utils/-/merge_requests/6 [2] https://salsa.debian.org/emacsen-team/maildir-utils/-/merge_requests/6/diffs signature.asc Description: PGP signature
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
Jeremy Sowden writes: > On 2024-04-12, at 19:50:58 +0800, Sean Whitton wrote: >> On Fri 12 Apr 2024 at 12:44pm +01, Jeremy Sowden wrote: >> > On 2024-04-12, at 17:53:15 +0800, Sean Whitton wrote: >> > > Do you have your 1.34 upload of buttercup in git, please? >> > >> > Yup, it's all on Salsa. >> >> Er. I got confused, then, didn't I? Should this RFS be closed? > > I uploaded 1.34, and that is what is currently in the emacsen-team repo. > This bug is for 1.35, which is currently sitting in Xiyue's fork, by the > looks of it. I haven't looked at this yet. I can pick it up over the > week-end. > > J. > So I did it again (pushed to my fork but forgot to push to team repo :P) Just pushed there as well. Please take another look. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1054420: RFS: js2-mode/0.0~git20230628.79bc78d-1 [RC] [Team] -- Emacs mode for editing Javascript programs
Control: retitle -1 RFS: js2-mode/0.0~git20240310.e92829d-1 [RC] [Team] -- Emacs mode for editing Javascript programs Hi, A new snapshot was available and I have updated the package according with a few more improvements. Please find the latest package on mentors[1] and changes on salsa[2] (sans the finalizing commit.) TIA! -- Xiyue Deng [1] https://mentors.debian.net/package/js2-mode/ [2] https://salsa.debian.org/emacsen-team/js2-mode
Bug#1068847: RFS: circe/2.13-1 [RC] [Team] -- client for IRC in Emacs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "circe": * Package name : circe Version : 2.13-1 Upstream contact : Jorgen Schäfer * URL : https://github.com/jorgenschaefer/circe * License : GPL-2+, BSD-3-clause, GPL-3+ * Vcs : https://salsa.debian.org/cgit/emacsen-team/circe.git Section : net The source builds the following binary packages: elpa-circe - client for IRC in Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/circe/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/circe/circe_2.13-1.dsc Changes since the last upload: circe (2.13-1) unstable; urgency=medium . * Team upload * New upstream release * Refresh patches using quilt-fixup * Backport patch adding lexical-cast to test-tracking.el to fix tests (Closes: #1068754) * Drop Built-Using on arch:all binary package * Modernize d/watch with special strings to be more robust * Use secure copyright file specification URI. * debian/copyright: use spaces rather than tabs to start continuation lines. * Bump debhelper from old 10 to 13. * Set debhelper-compat version in Build-Depends. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse. * Update standards version to 4.7.0, no changes needed. * Add Upstream-Contact in d/copyright * Add "Rules-Requires-Root: no" in d/control Regards, -- Xiyue Deng
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Nicholas D Steeves writes: > reopen 1068605 > owner 1068605 ! > thanks > > Hi, > > Sorry I didn't ask this sooner, but would you prefer if I call you Deng, > or Xiyue, or something else? Conventions and understanding vary a lot > from place to place, after all. No worries! My first name is Xiyue, but I acknowledge that this is probably difficult to pronounce in non-Asian countries or even outside of China, so feel free to call me Deng, or even my code name "manphiz" :) > > Xiyue Deng writes: > >> Thanks for pointing out #1019031! Totally missed it. I'll opt for >> option 1 obviously. Updated team repo and mentors accordingly. > > You're welcome, and thank you. On a related note, have you read the > definitions for source and binary packages? > > #1019031 was filed against src:web-mode, so was hidden from the > bin:elpa-web-mode view. On the BTS the src:package view will display > bugs that affect each binary package as well as the src:package. §4 of > Policy has the definition, and here is another good resource: > > https://wiki.debian.org/Packaging/SourcePackage > Actually I should have noticed it through the tracker page[1], which has a panel showing all bugs reported against all source and binary packages. >> Also, accordingly to this comment from Tobias[1] it looks like there are >> opinions that prefer to reuse existing RFS bugs instead of filing new >> ones. Do you think it's OK to reopen this one? > > There are also people who maintain the opposite position, but in the > spirit of harmony I've reopened this bug. [edit: Be careful about only > waiting a day and then going ahead and doing something without having > received a reply, because when you "ask" for something, but then don't > actually wait for a reply, it can make you look disingenuous and/or > impatient and/or pushy.] > I acted fast this time as this is a RFS bug so by reopening I'm not overriding any other people's work and it gives me a higher chance to find a potential sponsor faster. But I acknowledge the concern you pointed out and will be cautious in future. (And I get you as a reviewer which is better than I expected and I'd say it "worked" in my favor :P) > Onto the review: > >>>>>* New upstream release > > Push the upstream tag to salsa, and find a way to mitigate this issue in > the future. > Thanks for pointing this out, and this is something that confuses me. According to the dgit-maint-merge(7) workflow, one should have a upstream branch tracking upstream git repo directly, so that when you merge a tagged release "git deborig" can directly use upstream tags to create the tarball. On the other hand, if we have salsa CI set up there is no upstream tag on salsa so it probably will fail at "git deborig" stage. Still, if I read the dgit-maint-merge workflow correctly (I could be wrong), it only requires a "upstream/%(version)s" tag when the upstream only releases tarballs or when we want to package a snapshot. So I'm not sure whether we always want to have "upstream/%(version)s" tags. Would like to hear your opinion on this. >>>>>* Set upstream metadata fields: Bug-Database, Bug-Submit, >>>>> Repository-Browse >>>>>* Update standards version to 4.6.2; no changes needed > > Update this, since a new Policy version was recently released. Did you > already work through the upgrade checklist stepwise, starting from > 4.3.0? > Yes, I reviewed the policy upgrading checklist[2] and there should not be any changes required (actually from 4.5.0 when Thomas last worked on it). The same applies to 4.7.0 which I've updated to in [3]. > "debian-devel-announce" is a low traffic list that will keep you > appraised of stuff like this. > Ack, and glad I've already subscribed. Just that I worked on web-mode a bit earlier than the announcement. >>>>>* Use https link of homepage in d/control >>>>>* Modernize d/watch using special substitute strings to be more >>>>>robust > > I'm happy to see this clear, concise, and useful phrasing. If you have > any pending not-yet-uploaded work that doesn't use this, please update > it. If you're interested in a nitpick, the key term is "substitution > strings" and not "[special] substitute strings" (see the manpages for > uscan and deb-substvars as well as codesearch.debian.net). > Ack. Dropping the "special" part in changelog[4]. >>>>>* Fix issues in d/copyright >>>>> - Clarify license to be GPL-3+ to be consistent with upstream > > This is unclear. Which licence was it before, and whose lice
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Control: reopen -1 Xiyue Deng writes: > Hi Nicholas, > > Nicholas D Steeves writes: > >> Nicholas D Steeves writes: >> >>> This package cannot be uploaded without a human Uploader. See #1019031 >>> and current git history for more info. Either >>> >>> 1. Add yourself to Uploaders >> >> Yes, this requires a changelog entry too, in case that wasn't obvious. >> > > Thanks for pointing out #1019031! Totally missed it. I'll opt for > option 1 obviously. Updated team repo and mentors accordingly. > > Also, accordingly to this comment from Tobias[1] it looks like there are > opinions that prefer to reuse existing RFS bugs instead of filing new > ones. Do you think it's OK to reopen this one? I took the liberty to opt for reopening. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1065302: Acknowledgement (RFS: elpa-rust-mode/1.0.5+git20240301.6d86af4-1 -- Major Emacs mode for editing Rust source code)
Control: retitle -1 RFS: elpa-rust-mode/1.0.5+git20240329.b2b18aa-1 -- Major Emacs mode for editing Rust source code Now synced to the latest snapshot that adds support for 29.3. Team repo[1] and mentors[2] are updated accordingly. PTAL. -- Xiyue Deng [1] https://salsa.debian.org/emacsen-team/rust-mode [2] https://mentors.debian.net/package/elpa-rust-mode/
Bug#1068687: RFS: activities-el/0.7-1 [ITP] -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "activities-el": * Package name : activities-el Version : 0.7-1 Upstream contact : Adam Porter * URL : https://github.com/alphapapa/activities.el * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/activities-el Section : editors The source builds the following binary packages: elpa-activities - Save/restore sets of windows, tabs/frames, and their buffers in Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/activities-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/a/activities-el/activities-el_0.7-1.dsc Changes for the initial release: activities-el (0.7-1) unstable; urgency=medium . * Initial release (Closes: #1068677). Regards, -- Xiyue Deng
Bug#1068677: Acknowledgement (ITP: emacs-activities -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs)
Control: retitle -1 ITP: activities-el -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs Rename the source package following team recommendations[1]. -- Xiyue Deng [1] https://wiki.debian.org/Teams/DebianEmacsenTeam
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Hi Nicholas, Nicholas D Steeves writes: > Nicholas D Steeves writes: > >> This package cannot be uploaded without a human Uploader. See #1019031 >> and current git history for more info. Either >> >> 1. Add yourself to Uploaders > > Yes, this requires a changelog entry too, in case that wasn't obvious. > Thanks for pointing out #1019031! Totally missed it. I'll opt for option 1 obviously. Updated team repo and mentors accordingly. Also, accordingly to this comment from Tobias[1] it looks like there are opinions that prefer to reuse existing RFS bugs instead of filing new ones. Do you think it's OK to reopen this one? -- Xiyue Deng [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1067127#15 signature.asc Description: PGP signature
Bug#1068677: ITP: emacs-activities -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-activities Version : 0.7 Upstream Author : Adam Porter * URL or Web page : https://github.com/alphapapa/activities.el * License : GPL-3 Programming lang: Emacs Lisp Description : Save/restore sets of windows, tabs/frames, and their buffers in Emacs Inspired by Genera's and KDE's concepts of "activities", this library allows the user to select an "activity", the loading of which restores a window configuration into a `tab-bar' tab or frame, along with the buffers shown in each window. Saving an activity saves the state for later restoration. Switching away from an activity saves the last-used state for later switching back to, while still allowing the activity's initial or default state to be restored on demand. Resuming an activity loads the last-used state, or the initial/default state when a universal argument is provided. . The implementation uses the bookmark system to save buffers' states--that is, any major mode that supports the bookmark system is compatible. A buffer whose major mode does not support the bookmark system (or does not support it well enough to restore useful state) is not compatible and can't be fully restored, or perhaps not at all; but solving that is as simple as implementing bookmark support for the mode, which is usually trivial. . Integration with Emacs's `tab-bar-mode' is provided: a window configuration or can be restored to a `tab-bar' tab or to a frame. . Various hooks are provided, both globally and per-activity, so that the user can define functions to be called when an activity is saved, restored, or switched from/to. For example, this could be used to limit the set of buffers offered for switching to within an activity, or to track the time spent in an activity. I intend to maintain this package within the Debian Emacsen Team .
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "web-mode": * Package name : web-mode Version : 17.3.13-1 Upstream contact : François-Xavier Bois * URL : https://web-mode.org * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/web-mode Section : lisp The source builds the following binary packages: elpa-web-mode - major emacs mode for editing web templates To access further information about this package, please visit the following URL: https://mentors.debian.net/package/web-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/w/web-mode/web-mode_17.3.13-1.dsc Changes since the last upload: web-mode (17.3.13-1) unstable; urgency=medium . * Team upload * New upstream release * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.6.2; no changes needed * Use https link of homepage in d/control * Modernize d/watch using special substitute strings to be more robust * Fix issues in d/copyright - Clarify license to be GPL-3+ to be consistent with upstream - Update copyright year info for upstream - Add copyright info for debian/* - Add Upstream-Contact Regards, -- Xiyue Deng
Bug#1059065: Acknowledgement (RFS: lsp-mode/8.0.0+git20231219.2cdb9bc-1 [RC] -- Emacs client/library for the Language Server Protocol)
Control: retitle -1 RFS: lsp-mode/9.0.0-1 [RC] -- Emacs client/library for the Language Server Protocol A new tagged version was released upstream and I have updated both the team repository[1] and the package on mentors[2]. Please review and sponsor. TIA! -- Xiyue Deng [1] https://salsa.debian.org/emacsen-team/lsp-mode [2] https://mentors.debian.net/package/lsp-mode/
Bug#1068564: RFS: emacs-buttercup/1.35-1 -- behaviour-driven testing for Emacs Lisp packages
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-buttercup": * Package name : emacs-buttercup Version : 1.35-1 Upstream contact : Jorgen Schaefer * URL : https://github.com/jorgenschaefer/emacs-buttercup/ * License : GFDL-1.2+ or CC-BY-SA-3.0, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-buttercup Section : lisp The source builds the following binary packages: elpa-buttercup - behaviour-driven testing for Emacs Lisp packages To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-buttercup/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-buttercup/emacs-buttercup_1.35-1.dsc Changes since the last upload: emacs-buttercup (1.35-1) unstable; urgency=medium . * New upstream release * Add myself to uploaders Regards, -- Xiyue Deng
Bug#1068558: [Xiyue Deng] RFS: flycheck/34.1-1 -- modern on-the-fly syntax checking for Emacs - documentation
Forwarding to Debian Emacsen Team mailing list. Start of forwarded message From: Xiyue Deng To: sub...@bugs.debian.org Subject: RFS: flycheck/34.1-1 -- modern on-the-fly syntax checking for Emacs - documentation Date: Sun, 07 Apr 2024 02:19:21 -0700 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "flycheck": * Package name : flycheck Version : 34.1-1 Upstream contact : Bozhidar Batsov * URL : https://www.flycheck.org/ * License : CC-BY-SA-4.0, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/flycheck Section : lisp The source builds the following binary packages: elpa-flycheck - modern on-the-fly syntax checking for Emacs flycheck-doc - modern on-the-fly syntax checking for Emacs - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/flycheck/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/f/flycheck/flycheck_34.1-1.dsc Changes since the last upload: flycheck (34.1-1) unstable; urgency=medium . * New upstream release. * Update skipped flaky tests * Refresh patches * Drop obsolete handling in elpa-test and ert-helper.el * Update d/watch to track releases now that upstream releases have resumed * Update lintian overrides name: debian-watch-does-not-check-{,open}gpg-signature * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse. * Add Upstream-Contact in d/copyright Regards, -- Xiyue Deng End of forwarded message -- Xiyue Deng
Bug#1068558: RFS: flycheck/34.1-1 -- modern on-the-fly syntax checking for Emacs - documentation
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "flycheck": * Package name : flycheck Version : 34.1-1 Upstream contact : Bozhidar Batsov * URL : https://www.flycheck.org/ * License : CC-BY-SA-4.0, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/flycheck Section : lisp The source builds the following binary packages: elpa-flycheck - modern on-the-fly syntax checking for Emacs flycheck-doc - modern on-the-fly syntax checking for Emacs - documentation To access further information about this package, please visit the following URL: https://mentors.debian.net/package/flycheck/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/f/flycheck/flycheck_34.1-1.dsc Changes since the last upload: flycheck (34.1-1) unstable; urgency=medium . * New upstream release. * Update skipped flaky tests * Refresh patches * Drop obsolete handling in elpa-test and ert-helper.el * Update d/watch to track releases now that upstream releases have resumed * Update lintian overrides name: debian-watch-does-not-check-{,open}gpg-signature * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse. * Add Upstream-Contact in d/copyright Regards, -- Xiyue Deng
Bug#1068491: RFS: emacs-popon/0.13-1 [ITP] -- Pop floating text on an Emacs window
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-popon": * Package name : emacs-popon Version : 0.13-1 Upstream contact : Akib Azmain Turja * URL : https://codeberg.org/akib/emacs-popon * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-popon Section : editors The source builds the following binary packages: elpa-popon - Pop floating text on an Emacs window To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-popon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-popon/emacs-popon_0.13-1.dsc Changes for the initial release: emacs-popon (0.13-1) unstable; urgency=medium . * Initial release (Closes: #1068441). Regards, -- Xiyue Deng
Bug#1068477: RFS: emacs-corfu/1.3-1 [Team] -- Completion Overlay Region FUnction in Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-corfu": * Package name : emacs-corfu Version : 1.3-1 Upstream contact : Daniel Mendler * URL : https://github.com/minad/corfu/ * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-corfu Section : editors The source builds the following binary packages: elpa-corfu - Completion Overlay Region FUnction in Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-corfu/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-corfu/emacs-corfu_1.3-1.dsc Changes since the last upload: emacs-corfu (1.3-1) unstable; urgency=medium . * Team upload * New upstream release * Drop file name from lintian overrides so that it works either compressed or not Regards, -- Xiyue Deng
Bug#1068441: ITP: emacs-popon -- Pop floating text on an Emacs window
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-popon Version : 0.13 Upstream Author : Akib Azmain Turja * URL or Web page : https://codeberg.org/akib/emacs-popon * License : GPL-3 Programming lang: Emacs Lisp Description : Pop floating text on an Emacs window Popon allows you to pop text on a window, what we call a popon. Popons are window-local and sticky, they don't move while scrolling, and they even don't go away when switching buffer, but you can bind a popon to a specific buffer to only show on that buffer. This package is a dependency of emacs-corfu-terminal[1]. I intend to maintain this package in the Debian Emacsen Team . [1] https://bugs.debian.org/1068440
Bug#1068440: ITP: emacs-corfu-terminal -- Corfu popup on terminal
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-corfu-terminal Version : 0.7 Upstream Author : Akib Azmain Turja * URL or Web page : https://codeberg.org/akib/emacs-corfu-terminal * License : GPL-3 Programming lang: Emacs Lisp Description : Corfu popup on terminal Corfu uses child frames to display candidates. This makes Corfu unusable on terminal. This package replaces that with popup/popon, which works everywhere. I intend to maintain this package in the Debian Emacsen Team .
Bug#1068427: RFS: dpkg-dev-el/37.12 -- Emacs helpers specific to Debian development
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dpkg-dev-el": * Package name : dpkg-dev-el Version : 37.12 Upstream contact : Debian Emacsen Team * URL : [fill in URL of upstream's web site] * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/dpkg-dev-el Section : lisp The source builds the following binary packages: elpa-dpkg-dev-el - Emacs helpers specific to Debian development dpkg-dev-el - Transition package, dpkg-dev-el to elpa-dpkg-dev-el To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dpkg-dev-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dpkg-dev-el/dpkg-dev-el_37.12.dsc Changes since the last upload: dpkg-dev-el (37.12) unstable; urgency=medium . [ Niels Thykier ] * Update list of known d/control fields for debian-control-mode . [ Xiyue Deng ] * Untabify and reindent source code in Emacs 29 for consistency * Fix fill-paragraph in debian-changelog-mode (Closes: #620185) * Improve highlighting in debian-copyright (Closes: #557594, #1067589) - Add highlighting for more field names - Properly highlight common URLs - Add highlighting for emails - Add highlighting for common licenses as defined in base-files * Fix comp warnings (Closes: #1026450, #1028470) - Drop calls to obsolete easy-menu-add - Guard XEmacs functions - Require debian-bug for function usage - There are still some warnings due to compatibility with XEmacs which are being tracked in Bug#1068370. - Replace obsolete `max-specpdl-size' with `max-lisp-eval-depth' - Drop calls to no-op function `easy-menu-add' - Use defvar for variables without a require - Replace `position' with `seq-position' - Replace `subseq' with `seq-subseq' - Fix long docstring - Use `goto-char' instead of `goto-line' * Initial support for autopkgtest control files (Closes: #1067590) - Add initial highlighting for field names, dependency extensions, and restrictions * Bump version to prepare for release * Add myself to uploaders Regards, -- Xiyue Deng
Bug#1068370: elpa-dpkg-dev-el: Comp warnings due to XEmacs compatible code
David Bremner writes: > Xiyue Deng writes: > >> >> Will re-evaluate if XEmacs compatibility would be dropped. >> >> [1] >> https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b >> > > Does the package currently work (somehow?) with XEmacs? At least dh-elpa > byte compilation does not support XEmacs, but I have not tested the > binary package with XEmacs. I don't know, but I guess we will find out once "someone" packages XEmacs again ;) My hope was those legacy compatibility code will help a little for the transition, which may turn out to be useless, but will see. > > d -- Xiyue Deng
Bug#557594: Highlight DEP-3 and DEP-5 keywords.
Control: tags -1 pending FYI the DEP-5 headers in copyright files are implemented[1] and will be shipped in the next version. The DEP-3 part still needs to be done but may be more involved as it should work with diff mode. Please feel free to file a separate tracking bug for this. [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/d475bd2f0746f2cae65c71cbdf53f70c3bb2e128 -- Xiyue Deng
Bug#1067590: elpa-dpkg-dev-el: Please provide major mode for debian/tests/control
Control: tags -1 pending FYI an implementation is committed[1] and will be shipped with the next release. [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/7f438a42f33f31b86ec2e36bc2cc303cd1d298c6 -- Xiyue Deng
Bug#1067589: elpa-dpkg-dev-el: Please improve syntax highlighting of d/copyright
Xiyue Deng writes: > Control: tags -1 pending > > FYI an implementation is committed[1] and will be shipped with the next > release. > > [1] > https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/7f438a42f33f31b86ec2e36bc2cc303cd1d298c6 Sorry the commit should be: https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/d475bd2f0746f2cae65c71cbdf53f70c3bb2e128 -- Xiyue Deng
Bug#1067589: elpa-dpkg-dev-el: Please improve syntax highlighting of d/copyright
Control: tags -1 pending FYI an implementation is committed[1] and will be shipped with the next release. [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/7f438a42f33f31b86ec2e36bc2cc303cd1d298c6 -- Xiyue Deng
Bug#1028470: elpa-dpkg-dev-el: elisp warnings
Control: tags -1 pending FYI a fix is applied[1] and will be shipped with the next release. Note that there are still some code that are retained for potential XEmacs compatibility, which will be tracked in Bug#1068370[2]. [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b [2] https://bugs.debian.org/1068370
Bug#1026450: readme-debian.el and debian-copyright.el throw lots of warnings on startup
Control: tags -1 pending FYI a fix is applied[1] and will be shipped with the next release. Note that there are still some code that are retained for potential XEmacs compatibility, which will be tracked in Bug#1068370[2]. [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b [2] https://bugs.debian.org/1068370 -- Xiyue Deng
Bug#1068370: elpa-dpkg-dev-el: Comp warnings due to XEmacs compatible code
Package: elpa-dpkg-dev-el Version: 37.11 Severity: minor We have attempted to fix most comp warnings in [1]. However, there are XEmacs compatible code that still causes some comp warnings, so using this bug to track this. The current list of warnings are as the following: , | ■ Warning (comp): debian-changelog-mode.el:1694:12: Warning: the function ‘set-extent-property’ is not known to be defined. | ■ Warning (comp): debian-changelog-mode.el:1691:25: Warning: the function ‘make-extent’ is not known to be defined. | ■ Warning (comp): debian-changelog-mode.el:1669:18: Warning: the function ‘delete-extent’ is not known to be defined. | ■ Warning (comp): debian-changelog-mode.el:1668:42: Warning: the function ‘extent-end-position’ is not known to be defined. | ■ Warning (comp): debian-changelog-mode.el:1667:42: Warning: the function ‘extent-start-position’ is not known to be defined. | ■ Warning (comp): debian-changelog-mode.el:1666:22: Warning: the function ‘extent-detached-p’ is not known to be defined. | ■ Warning (comp): debian-changelog-mode.el:1640:14: Warning: the function ‘set-keymap-name’ is not known to be defined. ` Will re-evaluate if XEmacs compatibility would be dropped. [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-dpkg-dev-el depends on: ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 ii elpa-debian-el 37.12~bpo12+0manphiz1 ii emacsen-common 3.0.5 Versions of packages elpa-dpkg-dev-el recommends: ii emacs 1:29.3+1-2~bpo12+0manphiz1 ii emacs-gtk [emacs] 1:29.3+1-2~bpo12+0manphiz1 elpa-dpkg-dev-el suggests no packages. -- no debconf information
Bug#620185: M-q problem in changelog mode
Control: tags 620185 + pending FYI a potential fix is applied[1] and will be shipped with the next release. [1] https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/d9cb4cce57d2c887bdb9e74c97b0f8951cbd8b1b
Bug#1068124: exec-path-from-shell-el 2.1-1 FTBFS if network is unavailable
"Brendan O'Dea" writes: > Package: exec-path-from-shell-el > Version: 2.1-1 > Tags: patch > > The upstream Makefile attempts to run some sanity checks on the > library, including running `package-lint`, which it attempts to > download via `package.el`. This fails when the build daemon does not > have network access: > > * > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exec-path-from-shell-el.html > * > https://bugs.launchpad.net/ubuntu/+source/exec-path-from-shell-el/+bug/2034630 > > Given that the Makefile doesn't actually do anything useful to anyone > other than the upstream maintainer (package-lint, byte compile, remove > byte compile output), the attached patch disables the build entirely. > > --bod > > Thanks Brendan for filing the tracking bug! I happened to be investigating the same issue as well. I initially intend to convert the build process to use elpa-package-lint as a dependency, but it turned out that package-lint stable releases might be broken for each Emacs release and this happened for 29.3 as well. Currently I'm discussing this with upstream[1]. If that turns out to be in feasible, I'll fallback to what you proposed. Stay tuned. -- Xiyue Deng [1] https://github.com/purcell/package-lint/issues/269
Bug#1067933: RFS: graphviz-dot-mode/0.4.2+git20230325.8ff793b-1 [Team] -- Emacs mode for the dot-language used by graphviz
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "graphviz-dot-mode": * Package name : graphviz-dot-mode Version : 0.4.2+git20230325.8ff793b-1 Upstream contact : Pieter Pareit * URL : https://ppareit.github.io/graphviz-dot-mode/ * License : GFDL-1.3+, GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/graphviz-dot-mode Section : lisp The source builds the following binary packages: elpa-graphviz-dot-mode - Emacs mode for the dot-language used by graphviz To access further information about this package, please visit the following URL: https://mentors.debian.net/package/graphviz-dot-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/g/graphviz-dot-mode/graphviz-dot-mode_0.4.2+git20230325.8ff793b-1.dsc Changes since the last upload: graphviz-dot-mode (0.4.2+git20230325.8ff793b-1) unstable; urgency=medium . * Team upload. * Sync to latest snapshot (8ff793b). - Implement completion based on capf and drop company dependency. - Switch to lexical-binding. * Drop dependency on company in d/control now that it is capf-based. * Trim trailing whitespace. * Bump debhelper from old 10 to 13. * Set debhelper-compat version in Build-Depends. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse. * Update standards version to 4.6.2. No change needed. * Add Homepage in d/control. * Add "Rules-Requires-Root: no" in d/control. * Do not end description with a sentence end in d/control. * Drop extra license file LICENSE.md. * Modernize d/watch with special substitute strings to be more robust. * Update upstream copyright year in d/changelog. * Add Source and Upstream-Contact in d/copyright. Regards, -- Xiyue Deng
Bug#1067895: RFS: emacs-format-all-the-code/0.6.0-1 [Team] -- Auto-format C, C++, JS, Python, Ruby and 50 other languages
Sean Whitton writes: > control: tag -1 + moreinfo > > Looks like the Source: in d/copyright is bogus? Ah indeed. Fixed in [1], recompiled and uploaded to mentors as well. PTAL. [1] https://salsa.debian.org/emacsen-team/emacs-format-all-the-code/-/commit/92cfb4b866bfe4fb3200f13c42850b3febfe -- Xiyue Deng
Bug#1067902: elpa-debian-el: regression regarding apt-sources-mode and still warnings (comp)
Control: retitle -1 elpa-debian-el: regression regarding apt-sources-mode Control: tags -1 pending Xiyue Deng writes: > > BTW, please feel free to file one bug per issue which helps us tracking > those issues. Thanks for your reports! > I have filed a separate bug[1] for tracking the comp warnings issue. Meanwhile, the regression should be handled by this commit[2]. I'll try to request another release with other fixes when ready. [1] https://bugs.debian.org/1067922 [2] https://salsa.debian.org/emacsen-team/debian-el/-/commit/84f1eb293bb57fe888c274fa8533217060651a57 -- Xiyue Deng
Bug#1067922: elpa-debian-el: Comp warnings
Package: elpa-debian-el Version: 37.11 Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org, Xiyue Deng , Jörg-Volker Peetz This is the second part of the bug report from Bug#1067902 by Jörg-Volker Peetz : , | And there are still comp warnings when using debian-bug: | | Warning (comp): debian-bug.el:858:29: Warning: reference to free variable | ‘term-exec-hook’ | Warning (comp): debian-bug.el:931:16: Warning: ‘message’ called with 1 args | to fill 0 format field(s) | Warning (comp): debian-bug.el:861:10: Warning: the function ‘term-exec’ might | not be defined at runtime. ` Filing a separate bug here to ease tracking. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (200, 'proposed-updates') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-18-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-5+b1 ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 ii emacsen-common 3.0.5 ii reportbug 12.0.0 ii xz-utils5.4.1-0.2 Versions of packages elpa-debian-el recommends: ii emacs 1:29.3+1-2~bpo12+0manphiz1 ii emacs-gtk [emacs] 1:29.3+1-2~bpo12+0manphiz1 ii wget 1.21.3-1+b2 elpa-debian-el suggests no packages. -- no debconf information
Bug#1067902: elpa-debian-el: regression regarding apt-sources-mode and still warnings (comp)
Hi Jörg-Volker, Jörg-Volker Peetz writes: > Package: elpa-debian-el > Version: 37.11 > Severity: normal > > Dear Debian Emacsen team, > > thanks for taking care. > Unfortunately, there is a regression when detecting > apt-sources-mode. Previously, loading the file /etc/apt/sources.list > activated the apt-sources-mode. Now it doesn't. This seems to be a regression caused by https://salsa.debian.org/emacsen-team/debian-el/-/commit/67dbe593b650b7748e8cbe93fdb8f0cf883563ad. I'll test a fix soon. Meanwhile, you can temporarily add "(require 'debian-el)" or "(use-package debian-el)" in your init.el as a workaround > And there are still comp warnings when using debian-bug: > > Warning (comp): debian-bug.el:858:29: Warning: reference to free variable > ‘term-exec-hook’ > Warning (comp): debian-bug.el:931:16: Warning: ‘message’ called with 1 args > to fill 0 format field(s) > Warning (comp): debian-bug.el:861:10: Warning: the function ‘term-exec’ > might > not be defined at runtime. Will also take a look. BTW, please feel free to file one bug per issue which helps us tracking those issues. Thanks for your reports! > > Regards, > Jörg. > > -- System Information: > Debian Release: trixie/sid > APT prefers testing > APT policy: (600, 'testing'), (500, 'unstable'), (5, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.8.2 (SMP w/8 CPU threads) > Locale: LANG=C.utf8, LC_CTYPE=C.utf8 (charmap=UTF-8), LANGUAGE not set > Shell: /bin/sh linked to /usr/bin/dash > Init: sysvinit (via /sbin/init) > > Versions of packages elpa-debian-el depends on: > ii bzip2 1.0.8-5.1 > ii dh-elpa-helper 2.0.17 > ii emacsen-common 3.0.5 > ii reportbug 13.0.1 > ii xz-utils5.6.1-1 > > Versions of packages elpa-debian-el recommends: > ii emacs1:29.3+1-1 > ii emacs-lucid [emacs] 1:29.3+1-1 > pn wget > > elpa-debian-el suggests no packages. > > -- no debconf information > -- Xiyue Deng
Bug#1067895: RFS: emacs-format-all-the-code/0.6.0-1 [Team] -- Auto-format C, C++, JS, Python, Ruby and 50 other languages
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-format-all-the-code": * Package name : emacs-format-all-the-code Version : 0.6.0-1 Upstream contact : Lassi Kortela * URL : https://github.com/lassik/emacs-format-all-the-code * License : MIT * Vcs : https://salsa.debian.org/emacsen-team/emacs-format-all-the-code Section : editors The source builds the following binary packages: elpa-format-all - Auto-format C, C++, JS, Python, Ruby and 50 other languages To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-format-all-the-code/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-format-all-the-code/emacs-format-all-the-code_0.6.0-1.dsc Changes since the last upload: emacs-format-all-the-code (0.6.0-1) unstable; urgency=medium . * Team upload. * New upstream release. * Refresh patches and add forwarded info. - Add `:features' in puppet-lint which is required now. * Drop obsolete emacs version from Recommends. * Update Standards-Version to 4.6.2 (no change needed.) * Add d/upstream/metadata. * Fix d/watch with special substitute strings. * Add Upstream-Contact in d/copyright. Regards, -- Xiyue Deng