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
Bug#1067581: RFS: package-lint-el/0.22-1 [Team] -- package-lint Flymake backend
Sean Whitton writes: > control: tag -1 + moreinfo > > Hello, > > Looks like you didn't push to master :) Ah indeed. Just done (with tags). PTAL, thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
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. (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"? :) > > Thanks both. -- Xiyue Deng From 2eeb19bc6b532c5b32ae1b523c29c6c3387701e4 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 6ffab5c7af8..18c502de26d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,10 @@ +emacs (1:29.3+1-2) 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-1) unstable; urgency=high * Merge upstream version 29.3. Thanks to David Bremner for the diff --git a/debian/control b/debian/control index e168717089f..2cb0ab16239 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-2~), +Breaks: + emacs-bin-common (<< 1:29.2), + emacs-common (<< 1:29.3+1-2~), 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 38965316f3d..8448d7c9be3 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 signature.asc Description: PGP signature
Bug#1067854: elpa-magit: emacs-pgtk 29.2+1-2 emits deprecation warnings when using magit
Daniel Kahn Gillmor writes: > Package: elpa-magit > Version: 3.3.0-3 > Severity: normal > X-Debbugs-Cc: d...@fifthhorseman.net > > Dear Maintainer, > > I'm using emacs-pgtk 29.2+1-2, with magit. > > I opened a revision controlled file in magit, and got the following > warnings in my *Messages* buffer: > > ⛔ Warning (comp): magit-utils.el:571:33: Warning: ‘crm-default-separator’ is > an obsolete variable (as of 29.1); use ‘crm-separator’ instead. > ⛔ Warning (comp): magit-section.el:369:8: Warning: the function ‘linum-mode’ > is not known to be defined. > ⛔ Warning (comp): magit-git.el:257:2: Warning: custom-declare-variable > `magit-list-refs-sortby' docstring has wrong usage of unescaped single quotes > (use \= or different quoting) > ⛔ Warning (comp): magit-process.el:803:2: Warning: docstring has wrong usage > of unescaped single quotes (use \= or different quoting) > ⛔ Warning (comp): git-commit.el:741:25: Warning: ‘point-at-bol’ is an > obsolete function (as of 29.1); use ‘line-beginning-position’ or ‘pos-bol’ > instead. > ⛔ Warning (comp): magit-log.el:456:12: Warning: the function > ‘magit--any-wip-mode-enabled-p’ is not known to be defined. > ⛔ Warning (comp): magit-status.el:312:2: Warning: docstring has wrong usage > of unescaped single quotes (use \= or different quoting) > > It would be great if magit didn't produce warnings unless there was an > actual warning i should be paying attention to. > >--dkg > It would be good that upstream will take care of them, which should happen over time. Meanwhile, this should happen only once when the source files are native compiled the first time. You may also wish to set `native-comp-async-report-warnings-errors' to `nil' or `silent' to suppress the popups if you'd like. -- Xiyue Deng
Bug#1067806: RFS: dockerfile-mode/1.9-1 [Team] -- Major mode for editing Docker's Dockerfiles
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dockerfile-mode": * Package name : dockerfile-mode Version : 1.9-1 Upstream contact : Spotify * URL : https://github.com/spotify/dockerfile-mode * License : Apache-2.0 * Vcs : https://salsa.debian.org/emacsen-team/dockerfile-mode Section : lisp The source builds the following binary packages: elpa-dockerfile-mode - Major mode for editing Docker's Dockerfiles To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dockerfile-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dockerfile-mode/dockerfile-mode_1.9-1.dsc Changes since the last upload: dockerfile-mode (1.9-1) unstable; urgency=medium . * Team upload. . [ Aymeric Agon-Rambosson ] * d/control : Add Rules-Requires-Root field to satisfy Policy. * d/copyright : bump copyright years for debian/*. . [ Xiyue Deng ] * New upstream release. * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse. * Update standards version to 4.6.2, no changes needed. * Modernize d/watch with special substitute strings to be more robust. * Update upstream copyright year in d/copyright. * Add Upstream-Contact in d/copyright. Regards, -- Xiyue Deng
Bug#1067725: lintian: lintian should consider warning when one of many signing keys is missing
Xiyue Deng writes: > Package: lintian > Version: 2.116.3 > Severity: wishlist > X-Debbugs-Cc: none, Xiyue Deng > > We encountered a case that persist[1] from elpa has more than signing > keys and one of the public keys is missing. As the output of `gbp > import-orig --uscan' shows[2], the EDDSA public key could not be found. > Instead, the RSA was available in the repo[3] and passed the signature > check. So instead I used the `uscan --skip-signature' to get the > upstream tarball and prepared the packaging. Paul Wise asked me to > check whether lintian would still warning about the missing key in the > built package, and it didn't. > > This might be considered a rather rare case with multiple signing keys, > and Paul suggested to file a bug against lintian nonetheless to keep a > record on this case. > > [1] https://elpa.gnu.org/packages/persist.html > > [2] Command output: > , > | $ gbp import-orig --uscan > | gbp:info: Launching uscan... > | Newest version of persist-el on remote site is 0.6, local version is 0.5 > |(mangled local version is 0.5) > | => Newer package available from: > | => https://elpa.gnu.org/packages/persist-0.6.tar > | gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST > | gpgv:using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40 > | gpgv: Good signature from "GNU ELPA Signing Agent (2019) > " > | gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST > | gpgv:using EDDSA key > 0327BE68D64D9A1A66859F15645357D2883A0966 > | gpgv: Can't check signature: No public key > | uscan die: OpenPGP signature did not verify. at > /usr/share/perl5/Devscripts/Uscan/Output.pm line 77. > | gbp:error: Uscan failed: OpenPGP signature did not verify. > ` > > [3] > https://salsa.debian.org/emacsen-team/persist-el/-/blob/master/debian/upstream/signing-key.asc?ref_type=heads > > [..snip..] CCing Paul which I forgot to do so in the first email. Also Paul suggested a new lintian tag for this use case: "upstream-signature-uses-key-missing-from-upstream-signing-keys". -- Xiyue Deng
Bug#1067725: lintian: lintian should consider warning when one of many signing keys is missing
Package: lintian Version: 2.116.3 Severity: wishlist X-Debbugs-Cc: none, Xiyue Deng We encountered a case that persist[1] from elpa has more than signing keys and one of the public keys is missing. As the output of `gbp import-orig --uscan' shows[2], the EDDSA public key could not be found. Instead, the RSA was available in the repo[3] and passed the signature check. So instead I used the `uscan --skip-signature' to get the upstream tarball and prepared the packaging. Paul Wise asked me to check whether lintian would still warning about the missing key in the built package, and it didn't. This might be considered a rather rare case with multiple signing keys, and Paul suggested to file a bug against lintian nonetheless to keep a record on this case. [1] https://elpa.gnu.org/packages/persist.html [2] Command output: , | $ gbp import-orig --uscan | gbp:info: Launching uscan... | Newest version of persist-el on remote site is 0.6, local version is 0.5 |(mangled local version is 0.5) | => Newer package available from: | => https://elpa.gnu.org/packages/persist-0.6.tar | gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST | gpgv:using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40 | gpgv: Good signature from "GNU ELPA Signing Agent (2019) " | gpgv: Signature made Sat 13 Jan 2024 02:05:03 AM PST | gpgv:using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966 | gpgv: Can't check signature: No public key | uscan die: OpenPGP signature did not verify. at /usr/share/perl5/Devscripts/Uscan/Output.pm line 77. | gbp:error: Uscan failed: OpenPGP signature did not verify. ` [3] https://salsa.debian.org/emacsen-team/persist-el/-/blob/master/debian/upstream/signing-key.asc?ref_type=heads -- 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 lintian depends on: ii binutils2.40-2 ii bzip2 1.0.8-5+b1 ii diffstat1.65-1 ii dpkg1.21.22 ii dpkg-dev1.21.22 ii file1:5.44-3 ii gettext 0.21-12 ii gpg 2.2.40-1.1 ii intltool-debian 0.35.0+20060710.6 ii iso-codes 4.15.0-1 ii libapt-pkg-perl 0.1.40+b2 ii libarchive-zip-perl 1.68-1 ii libberkeleydb-perl 0.64-2+b1 ii libcapture-tiny-perl0.48-2 ii libclass-xsaccessor-perl1.19-4+b1 ii libclone-perl 0.46-1 ii libconfig-tiny-perl 2.28-2 ii libconst-fast-perl 0.014-2 ii libcpanel-json-xs-perl 4.35-1 ii libdata-dpath-perl 0.58-2 ii libdata-validate-domain-perl0.10-1.1 ii libdata-validate-uri-perl 0.07-2 ii libdevel-size-perl 0.83-2+b1 pn libdigest-sha-perl ii libdpkg-perl1.21.22 ii libemail-address-xs-perl1.05-1+b1 ii libencode-perl 3.19-1+b1 ii libfile-basedir-perl0.09-2 ii libfile-find-rule-perl 0.34-3 ii libfont-ttf-perl1.06-2 ii libhtml-html5-entities-perl 0.004-3 ii libhtml-tokeparser-simple-perl 3.16-4 ii libio-interactive-perl 1.023-2 ii libipc-run3-perl0.048-3 ii libjson-maybexs-perl1.004004-1 ii liblist-compare-perl0.55-2 ii liblist-someutils-perl 0.59-1 ii liblist-utilsby-perl0.12-2 ii libmldbm-perl 2.05-4 ii libmoo-perl 2.005005-1 ii libmoox-aliases-perl0.001006-2 ii libnamespace-clean-perl 0.27-2 ii libpath-tiny-perl 0.144-1 ii libperlio-gzip-perl 0.20-1+b1 ii libperlio-utf8-strict-perl 0.010-1 ii libproc-processtable-perl 0.634-1+b2 ii libregexp-wildcards-perl1.05-3 ii libsereal-decoder-perl 5.003+ds-1 ii libsereal-encoder-perl 5.003+ds-1 ii libsort-versions-perl 1.62-3 ii libsyntax-keyword-try-perl 0.28-1 ii libterm-readkey-perl2.38-2+b1 ii libtext-levenshteinxs-perl 0.03-5+b1 ii libtext-markdown-discount-perl 0.16-1 ii libtext-xslate-perl 3.5.9-1+b2 ii libtime-duration-perl 1.21-2 ii libtime-moment-perl 0.44-2+b1 ii libtimedate-perl2.3300-2 ii libunicode-utf8-perl0.62-2 ii liburi-perl 5.17-1 ii libwww-mechanize-perl 2.16-1
Bug#1067721: RFS: emacs-corfu/1.2-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.2-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.2-1.dsc Changes since the last upload: emacs-corfu (1.2-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 * Update copyright year in d/copyright * Modernize d/watch with special substitute strings to be more robust * Add d/gbp.conf to match current packaging practice * Mark vendored patch as "Forwarded: not-needed" * Add lintian-overrides for org format changelog Regards, -- Xiyue Deng
Bug#1067698: RFS: persist-el/0.6+dfsg-1 [Team] -- persist variables between Emacs Sessions
Hi Nicholas, Nicholas D Steeves writes: > Control: owner -1 ! > > Xiyue Deng writes: > >>[ Xiyue Deng ] >>* New upstream release. >>* Re-export upstream signing key without extra signatures. > > $ uscan --download-current-version > Newest version of persist-el on remote site is 0.6, specified download > version is 0.6 > gpgv: Signature made Sat 13 Jan 2024 05:05:03 EST > gpgv:using RSA key C433554766D3DDC64221BFAA066DAFCB81E42C40 > gpgv: Good signature from "GNU ELPA Signing Agent (2019) > " > gpgv: Signature made Sat 13 Jan 2024 05:05:03 EST > gpgv:using EDDSA key 0327BE68D64D9A1A66859F15645357D2883A0966 > gpgv: Can't check signature: No public key > uscan die: OpenPGP signature did not verify. at > /usr/share/perl5/Devscripts/Uscan/Output.pm line 77. I have been in contact with upstream maintainer Joseph Turner about this issue. He replied that he recently took over the maintenance of persist and was not aware about this key either. I have followed his suggestion and filed a bug report to bug-gnu-em...@gnu.org about this issue[1]. Meanwhile, as the RSA key signature is good, I resorted to use "uscan --skip-signature" to get the current version, dropped the GFDL document source and repacked the source tarball. Hope this process sounds ok to you. -- Xiyue Deng [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=70003
Bug#1050393: Unneeded dependency on "dconf-gsettings-backend | gsettings-backend"?
Xiyue Deng writes:
> Xiyue Deng writes:
>
>> Control: tags -1 patch
>>
>> Hi,
>>
>> It looks like the gsettings-backend dependency was introduced since
>> Emacs 29.1. Tried to debug this a little, and it looks like the
>> dependencies was pulled in through ${misc:Depends} due to the GSettings
>> schema file[1]. With helps from folks on IRC, we found that this file
>> was installed only in PGTK mode[2], so technically this is not required
>> by other modes and should be safe to be moved from emacs-common to
>> emacs-pgtk.
>>
>> I have prepared a MR[3] (patch also attached) as an attempt and verified
>> that it moved the "dconf-gsettings-backend | gsettings-backend" from
>> emacs-common to emacs-pgtk. I'll try to use this locally with emacs-nox
>> to further verify that it doesn't cause any issues.
>>
>> Meanwhile, would be great to have people review the patch. TIA!
>>
>> [1] Search for
>> "/usr/share/glib-2.0/schemas/org.gnu.emacs.defaults.gschema.xml" on
>> https://packages.debian.org/sid/all/emacs-common/filelist
>>
>> [2]
>> https://salsa.debian.org/rlb/deb-emacs/-/blob/deb/emacs/d/sid/master/Makefile.in?ref_type=heads#L1334-1337
>>
>> [3] https://salsa.debian.org/rlb/deb-emacs/-/merge_requests/12
>
> I have made a few updates to the merge request, and please see the
> updated patch attached. Do refer to the merge request[1] for the latest
> updates.
>
> [1] https://salsa.debian.org/rlb/deb-emacs/-/merge_requests/12
I have attached the refreshed patches after the release of 29.3+1-1. TIA!
(Note that merge requests were closed so the salsa link is no longer valid.)
--
Xiyue Deng
>From 2ce769b9ea45d72ed54d6168875626b10c8e7321 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/conflicts to ensure a smooth upgrade.
---
debian/changelog | 7 +++
debian/control | 12 ++--
debian/rules | 9 -
3 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 6ffab5c7af8..18c502de26d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+emacs (1:29.3+1-2) 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-1) unstable; urgency=high
* Merge upstream version 29.3. Thanks to David Bremner for the
diff --git a/debian/control b/debian/control
index e168717089f..0c6fab0bfeb 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.2+1-3~),
+Breaks:
+ emacs-bin-common (<< 1:29.2),
+ emacs-common (<< 1:29.2+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
@@ -184,6 +191,7 @@ Breaks:
emacs-gtk (<< 1:25),
emacs-lucid (<< 1:25),
emacs-nox (<< 1:25),
+ emacs-pgtk (<< 1:29.2+1-3~),
Replaces:
emacs-bin-common (<< 1:28)
Description: GNU Emacs editor's shared, architecture independent infrastructure
diff --git a/debian/rules b/debian/rules
index 38965316f3d..8448d7c9be3 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
Bug#1067698: RFS: persist-el/0.6+dfsg-1 [Team] -- persist variables between Emacs Sessions
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "persist-el": * Package name : persist-el Version : 0.6+dfsg-1 Upstream contact : Phillip Lord * URL : https://elpa.gnu.org/packages/persist.html * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/persist-el Section : editors The source builds the following binary packages: elpa-persist - persist variables between Emacs Sessions To access further information about this package, please visit the following URL: https://mentors.debian.net/package/persist-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/persist-el/persist-el_0.6+dfsg-1.dsc Changes since the last upload: persist-el (0.6+dfsg-1) unstable; urgency=medium . * Team upload. . [ Debian Janitor ] * Remove constraints unnecessary since buster (oldstable): + elpa-persist: Drop versioned constraint on emacs in Recommends. . [ Xiyue Deng ] * New upstream release. * Re-export upstream signing key without extra signatures. * Update standards version to 4.6.2, no changes needed. Regards, -- Xiyue Deng
Bug#1067587: src:exec-path-from-shell-el: Fails to build during reproducibility testing
Source: elpa-exec-path-from-shell Severity: normal X-Debbugs-Cc: debian-emac...@lists.debian.org, Xiyue Deng It was reported that exec-path-from-shell-el fails to build reproducibly. Upon checking the log[1], it looks like the upstream Makefile will download the snapshot version of package-lint for verifying the source file, which will fail the reproducibility test as it doesn't provide Internet access. We could instead add elpa-package-lint to Build-Depends so that we don't need Internet anymore. However, checking the current exec-path-from-shell sources using the current packaged version of package-lint-el (0.21) fails due to a few bugs. Upstream has just tagged version 0.22[2], and I'm working on its packaging[3] and seeking sponsoring[4]. Once that's uploaded, I'll update this package as described above, if no one gets to it first of course. [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/exec-path-from-shell-el.html [2] https://github.com/purcell/package-lint/issues/266 [3] https://mentors.debian.net/package/package-lint-el/ [4] https://bugs.debian.org/1067581 -- 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 -- no debconf information
Bug#1067581: RFS: package-lint-el/0.22-1 [Team] -- package-lint Flymake backend
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "package-lint-el": * Package name : package-lint-el Version : 0.22-1 Upstream contact : Steve Purcell * URL : https://github.com/purcell/package-lint * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/package-lint-el Section : lisp The source builds the following binary packages: elpa-package-lint - linting library for Elisp package authors elpa-package-lint-flymake - package-lint Flymake backend To access further information about this package, please visit the following URL: https://mentors.debian.net/package/package-lint-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/p/package-lint-el/package-lint-el_0.22-1.dsc Changes since the last upload: package-lint-el (0.22-1) unstable; urgency=medium . * Team upload * New upstream version 0.22 * Update copyright year in d/copyright * Add Upstream-Contact in d/copyright * Modernize d/watch with special substitute string to be more robust Regards, -- Xiyue Deng
Bug#1067127: marked as done (RFS: emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake sources)
Tobias Frost writes: > Control: reopen -1 > Control: retitle -1 RFS: emacs-cmake-mode/3.29.0+ds-1 [Team] -- Emacs major > mode for editing CMake sources > Control: forcemerge -1 1067530 > >> Date: Sat, 23 Mar 2024 00:15:55 -0700 >> From: Xiyue Deng >> To: 1067127-d...@bugs.debian.org >> Subject: Re: Bug#1067127: Acknowledgement (RFS: >> emacs-cmake-mode/3.28.3+ds-1 [Team] -- Emacs major mode for editing CMake >> sources) >> User-Agent: Gnus/5.13 (Gnus v5.13) >> >> 3.29.0 has just been released. Will send a new RFS. > > Please do not open new RFS when the old one has not been sponsored. > Instead, use the old one and update it accordingly. > > Thanks! > >> -- >> Xiyue Deng > Acknowledged. Will follow your advice in future. -- Xiyue Deng
Bug#1067530: RFS: emacs-cmake-mode/3.29.0+ds-1 [Team] -- Emacs major mode for editing CMake sources
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-cmake-mode": * Package name : emacs-cmake-mode Version : 3.29.0+ds-1 Upstream contact : Brad King * URL : https://cmake.org * License : BSD-3-Clause * Vcs : https://salsa.debian.org/emacsen-team/emacs-cmake-mode Section : editors The source builds the following binary packages: elpa-cmake-mode - Emacs major mode for editing CMake sources To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-cmake-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-cmake-mode/emacs-cmake-mode_3.29.0+ds-1.dsc Changes since the last upload: emacs-cmake-mode (3.29.0+ds-1) unstable; urgency=medium . * Team upload * New upstream version 3.29.0+ds * Add d/upstream/metadata * Add Upstream-Contact to d/copyright * Update year in d/copyright Regards, -- Xiyue Deng
Bug#1067526: RFS: company-mode/0.10.2-1 [Team] -- Modular in-buffer completion framework for Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "company-mode": * Package name : company-mode Version : 0.10.2-1 Upstream contact : Dmitry Gutov * URL : https://company-mode.github.io/ * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/company-mode Section : lisp The source builds the following binary packages: elpa-company - Modular in-buffer completion framework for Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/company-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/company-mode/company-mode_0.10.2-1.dsc Changes since the last upload: company-mode (0.10.2-1) unstable; urgency=medium . * Team upload * New upstream version * Migrate from debhelper >= 11 to debhelper-compat version 13 * Update Standards-Version to 4.6.2 (no change needed) * Set Rules-Requires-Root as no in d/control * Check DEB_BUILD_OPTIONS against nocheck in override_dh_auto_test * Modernize d/watch to version 4 with substitute strings to be robust * Add Upstream-Contact in d/copyright Regards, -- Xiyue Deng
Bug#1067471: RFS: emacs-language-id/0.20-1 [Team] -- Library to work with programming language identifiers
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-language-id": * Package name : emacs-language-id Version : 0.20-1 Upstream contact : Lassi Kortela * URL : https://github.com/lassik/emacs-language-id * License : ISC * Vcs : https://salsa.debian.org/emacsen-team/emacs-language-id Section : editors The source builds the following binary packages: elpa-language-id - Library to work with programming language identifiers To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-language-id/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-language-id/emacs-language-id_0.20-1.dsc Changes since the last upload: emacs-language-id (0.20-1) unstable; urgency=medium . * Team upload. * New upstream release. * Drop 0001-Add-Puppet-mode.patch (applied upstream.) * Update Standards-Version to 4.6.2 (no change needed.) * Drop obsolete emacs version in Recommends. * Fix d/watch with special substitue strings. * Add d/upstream/metadata. * Add Upstream-Contact and add upstream maintainer's email in d/copyright Regards, -- Xiyue Deng
Bug#1067408: RFS: compat-el/29.1.4.5+dfsg-1 [Team] -- COMPATibility Library for Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "compat-el": * Package name : compat-el Version : 29.1.4.5+dfsg-1 Upstream contact : Daniel Mendler * URL : https://github.com/emacs-compat/compat * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/compat-el Section : editors The source builds the following binary packages: elpa-compat - COMPATibility Library for Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/compat-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/compat-el/compat-el_29.1.4.5+dfsg-1.dsc Changes since the last upload: compat-el (29.1.4.5+dfsg-1) unstable; urgency=medium . * Team upload. * New upstream release. * Add Upstream-Contact in d/copyright. * Add d/upstream/metadata. Regards, -- Xiyue Deng
Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest
Sean Whitton writes: > control: tag -1 + pending > control: close 1067133 > > Hello, > > On Wed 20 Mar 2024 at 12:06am -07, Xiyue Deng wrote: > >> Found the upstream fix for the test failures[1]. I have backported the >> patch in [2] > > In the future, especially with dgit-maint-merge(7), it's a good idea to > use 'git cherry-pick -x' to backport upstream patches like this, so that > it's easily traceable by others. In lieu of this, I've added a note of > the upstream commit in d/changelog. > Good tip! Will use this in future. >> Meanwhile, it looks like I was jumping to conclusion a little too >> soon. TL;DR it will still get stuck without running in the source >> directory. So IMHO disabling autopkgtest would be a sensible choice, >> which I did in [3]. >> >> Also built and uploaded the latest version to mentors[4]. PTAL. TIA! >> >> Longer analysis of tests getting stuck: >> >> Comparing working and not working settings using strace, I noticed that >> during buttercup tests it would get stuck closing >> test/clojure-mode-refactor-rename-ns-alias-test.el, which I still didn't >> know why unfortunately. If I disabled/renamed this file, buttercup >> would finish running, and would fail due to unable to load clojure-mode >> in the source tree. And yes, specifically the file in the source tree >> as in the following error message: >> >> , >> | Cannot open load file: No such file or directory, >> | /home/manphiz/Projects/debian-packaging/clojure-mode/clojure-mode >> ` >> >> I even tried directly using `--eval "(load-library \"clojure-mode\")"` >> which actually succeeded, but it still failed with the same error. >> Given this I would have to assume that buttercup requires running in the >> source tree. > > It's likely possible to patch the tests; I doubt it's fundamental to > Buttercup. > I got the same feeling. Will continue to investigate. > Thanks for adopting the package. Np! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest
Sean Whitton writes: > Hello, > > On Tue 19 Mar 2024 at 04:04pm -07, Xiyue Deng wrote: > >> Sean Whitton writes: >> >>> Hello, >>> >>> On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote: >>> >>>> Control: tags -1 pending >>>> >>>> I have prepared a fixed version and uploaded to mentors[1] with RFS[2]. >>> >>> Thanks for looking at this, but I'm not sure the fix is valid. >>> >>> The idea behind autopkgtest_keep is to ensure we test the installed >>> package, not the files in the source tree. But if you just include them >>> all, don't the files in the source tree get tested? >> >> After some testing this turns out to be an issue with buttercup: if the >> required module is not immediately in the current loading path it will >> get stuck. I've tested with `-L` and directly `--eval "(load-library >> 'clojure-mode)"` and while the load-library succeeded it will still get >> stuck. >> >> Meanwhile I have tested locally that with a newer buttercup version 1.34 >> this won't be an issue anymore. However it fails some other tests which >> we'll have to deal with later. >> >> So this is a workaround of the buttercup issue in 1.31. An alternative >> is to disable autopkgtest as it's doing basically the same thing as the >> test during building. >> >> Wdyt? > > Looks like buttercup 1.34 is now in unstable, so perhaps worth making an > attempt at fixing those failing tests, before considering disabling? Found the upstream fix for the test failures[1]. I have backported the patch in [2] Meanwhile, it looks like I was jumping to conclusion a little too soon. TL;DR it will still get stuck without running in the source directory. So IMHO disabling autopkgtest would be a sensible choice, which I did in [3]. Also built and uploaded the latest version to mentors[4]. PTAL. TIA! Longer analysis of tests getting stuck: Comparing working and not working settings using strace, I noticed that during buttercup tests it would get stuck closing test/clojure-mode-refactor-rename-ns-alias-test.el, which I still didn't know why unfortunately. If I disabled/renamed this file, buttercup would finish running, and would fail due to unable to load clojure-mode in the source tree. And yes, specifically the file in the source tree as in the following error message: , | Cannot open load file: No such file or directory, /home/manphiz/Projects/debian-packaging/clojure-mode/clojure-mode ` I even tried directly using `--eval "(load-library \"clojure-mode\")"` which actually succeeded, but it still failed with the same error. Given this I would have to assume that buttercup requires running in the source tree. -- Xiyue Deng [1] https://github.com/clojure-emacs/clojure-mode/commit/af0e518a6b86f2c6f32dfb30b99c067071ed5cd4 [2] https://salsa.debian.org/emacsen-team/clojure-mode/-/commit/48fbd64f041d7ea103bce6c6bb0996d80303ed4d [3] https://salsa.debian.org/emacsen-team/clojure-mode/-/commit/27b4687a873aef80213e502f0838463aa7f28a58 [4] https://mentors.debian.net/package/clojure-mode/ signature.asc Description: PGP signature
Bug#1067131: clojure-mode: Tests stuck when running under autopkgtest
Xiyue Deng writes: > Sean Whitton writes: > >> Hello, >> >> On Tue 19 Mar 2024 at 02:00am -07, Xiyue Deng wrote: >> >>> Control: tags -1 pending >>> >>> I have prepared a fixed version and uploaded to mentors[1] with RFS[2]. >> >> Thanks for looking at this, but I'm not sure the fix is valid. >> >> The idea behind autopkgtest_keep is to ensure we test the installed >> package, not the files in the source tree. But if you just include them >> all, don't the files in the source tree get tested? > > After some testing this turns out to be an issue with buttercup: if the > required module is not immediately in the current loading path it will > get stuck. I've tested with `-L` and directly `--eval "(load-library > 'clojure-mode)"` and while the load-library succeeded it will still get > stuck. > > Meanwhile I have tested locally that with a newer buttercup version 1.34 > this won't be an issue anymore. However it fails some other tests which > we'll have to deal with later. > > So this is a workaround of the buttercup issue in 1.31. An alternative > is to disable autopkgtest as it's doing basically the same thing as the > test during building. > > Wdyt? As Jeremy just uploaded buttercup 1.34, I'll probably wait a little and deal with the failed tests I mentioned then. Will update later with more info. -- Xiyue Deng signature.asc Description: PGP signature
