Bug#1055431: Simpler fix for #1052917
Hi,
Xiyue Deng writes:
> Jeremy Sowden writes:
>
>> [[PGP Signed Part:Undecided]]
>> On 2024-07-26, at 16:24:52 -0400, Nicholas D Steeves wrote:
>>> Jeremy Sowden writes:
>>> > This error:
>>> >> debian/rules clean
>>> >> dh clean --with elpa
>>> >>dh_auto_clean
>>> >> make -j8 clean
>>> >> make[1]: Entering directory '/<>'
>>> >> End of file during parsing
>>> >> rm -f *.elc .latest-* autoloads.el scala-mode- Error: end-of-file nil
>>> >> mapbacktrace(#f(compiled-function (evald func args flags) #>> >> 0x943b01ebae87e2>)) debug-early-backtrace() debug-early(error
>>> >> (end-of-file)) read(#) (nth 2 (read
>>> >> (find-file "./scala-mode-pkg.el"))) (format "%s\n" (nth 2 (read
>>> >> (find-file "./scala-mode-pkg.el" (princ (format "%s\n" (nth 2
>>> >> (read (find-file "./scala-mode-pkg.el") command-line-1(("-L" "."
>>> >> "--eval" "(princ (format \"%s\\n\" (nth 2 (read (find-file
>>> >> \"./scala-mode-pkg.el\")")) command-line() normal-top-level().tar
>>> >> /bin/sh: 1: Syntax error: "(" unexpected
>>> >> make[1]: *** [Makefile:55: clean] Error 2
>>> >
>>> > occurs because the Makefile does this (trimmed):
>>> >
>>> > VERSION := $(shell ${ELISP_COMMAND} $(ELISP_OPTIONS)
>>> > --eval '(princ (format "%s\n" (nth 2 (read (find-file "$(PKG_FILE)")')
>>> > MODE_NAME_VERSION = $(MODE_NAME)-$(VERSION)
>>> >
>>> > clean:
>>> > $(RM) *.elc .latest-* autoloads.el $(MODE_NAME_VERSION).tar
>>> >
>>> > It tries to use Emacs to get the version from the scala-mode-pkg.el
>>> > file, but that doesn't exist, so the output from the `$(shell)` command
>>> > is a stack-trace, not a version number.
>>> >
>>> > Make prefers variable definitions given as arguments at the command line
>>> > to those defined in the Makefile, so if `VERSION=X.Y.Z` is passed to
>>> > `make clean`:
>>> >
>>> > override_dh_autoclean:
>>> > dh_auto_clean -- VERSION=X.Y.Z
>>> >
>>> > Emacs isn't called, and the error goes away.
>>
>> Actually, it turns out that emacs _is_ called:
>>
>> dh clean --with elpa
>> debian/rules override_dh_auto_clean
>> make[1]: Entering directory
>> '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
>> dh_auto_clean -- VERSION=1.1.0
>> make -j16 clean VERSION=1.1.0
>> make[2]: Entering directory
>> '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
>> End of file during parsing
>> ^^
>>
>> but the stack-trace doesn't get assigned to the variable, and the build
>> continues successfully:
>>
>> rm -f *.elc .latest-* autoloads.el scala-mode-1.1.0.tar
>> [ ! -d scala-mode-1.1.0 ] || rm -f scala-mode-1.1.0/*
>> [ ! -d scala-mode-1.1.0 ] || rmdir scala-mode-1.1.0
>> make[2]: Leaving directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
>> make[1]: Leaving directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
>>
>>> Thank you, yes, this is one of the right ways to solve this issue, and I
>>> hope it's evident to everyone following this thread why this is the
>>> case. :)
>>>
>>> Please use Xiyue Deng (manphiz)'s work on SUBSTVARS for "VERSION=X.Y.Z",
>>> and feel free to apply any fixups; I seem to remember that there's
>>> something like a fragile regex.
>>
>> This?
>>
>> BASE_UPSTREAM_VERSION=$(shell echo ${DEB_VERSION_UPSTREAM} | sed
>> "s/\+git.*//")
>>
>> I replaced it with:
>>
>> BASE_UPSTREAM_VERSION = $(word 1,$(subst +git, ,$(DEB_VERSION_UPSTREAM)))
>>
>>> > I will push this change and review the rest of this (lengthy :))
>>> > report.
>>>
>>> Rather than reading this mentoring thread--long form for educational
>>> value--it's probably faster to review d/changelog, diff
>>> debian/20111005-2.1, and check for consistency.
>>>
>>> P.S. did you forget to push?
>>
>> Indeed. Now done.
>>
>> J.
>>
>> [[End of PGP Signed Part]]
>
> Thanks Jeremy! It looks much cleaner now. I have also merged from
> dgit/sid with the recent rebuild done by Sean so that the changelogs are
> now consistent.
>
> --
> Xiyue Deng
This RFS has been open for a while, and I believe most of the comments
have been addressed.
Can Nicholas or Jeremy help sponsor the uploading? Or if you have more
comments I'll try to address them as well.
TIA!
--
Xiyue Deng
signature.asc
Description: PGP signature
signature.asc
Description: PGP signature
Bug#1081131: RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol
Friendly ping for sponsoring :) -- Xiyue Deng
Bug#1074622: RFS: emacs-dape/0.13.0-1 [ITP] -- Debug Adapter Protocol for Emacs
Phil Wyett writes: > Xiyue, > > Preamble... > > Thank you for taking the time to create this package and your contribution > to the Debian project. > > The review below is for assistance. This review is offered to help > package submitters to Debian mentors inorder to improve their packages > prior to possible sponsorship into Debian. There is no obligation on behalf > of the submitter to make any alterations based upon information provided > in the review. > > Review... > > 1. Build[1]: Good > > 2. Lintian[2]: Good > > 3. Licenses (lrc[3]): Good > > 4. Watch file (uscan --force-download): Good > > 5. Build Twice (sudo pbuilder build --twice .dsc): Good > > 6. Reproducible builds (reporotest)[3]: Good > > 7. Install (No previous installs): Good > > 8. Upgrade (Over previous installs if any): N/A > > Summary... > > I believe emacs-dape is ready for sponsorship/upload. Could a Debian > Developer (DD) with available free time, please review this package and > upload if you feel it is ready and appropriate for the distribution. > > Regards > > Phil > > [1] Using: > * pbuilder - https://wiki.ubuntu.com/PbuilderHowto. > * https://wiki.debian.org/PbuilderTricks > and > * sbuild - https://wiki.debian.org/sbuild. > > [2] Command: lintian -v -i -I -E --pedantic --profile debian (*.dsc, > *.changes, *.buildinfo). Each can throw up different, so be thorough. > > [3] 'lrc' from 'licenserecon' is located in Debian testing and newer. > > [4] https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method > > -- > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Internet Relay Chat (IRC): kathenas > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > -- > Friendly ping for sponsoring :) -- Xiyue Deng
Bug#1027433: Change upstream away from Aegisub/Aegisub
It looks like https://github.com/TypesettingTools/Aegisub is active every few months (last active in July 2024 at the time of writing), and it looks like arch1t3cht has been pushing commits. So it now looks like a proper new upstream if the maintainer considers to switch. -- Xiyue Deng
Bug#1081486: aegisub: Startup warnings after migrating to wxWidgets 3.2
Package: aegisub Version: 3.2.2+dfsg-7 Severity: normal Dear Maintainer, aegisub starts to show warnings on startup like below: , | ./src/common/sizer.cpp(2288): assert "CheckSizerFlags(!((flags) & (wxALIGN_RIGHT | wxALIGN_CENTRE_HORIZONTAL | wxALIGN_BOTTOM | wxALIGN_CENTRE_VERTICAL)))" failed in DoInsert(): wxALIGN_RIGHT | wxALIGN_CENTRE_HORIZONTAL | wxALIGN_BOTTOM | wxALIGN_CENTRE_VERTICAL will be ignored in this sizer: wxEXPAND overrides alignment flags in box sizers | | DO NOT PANIC !! | | If you're an end user running a program not developed by you, please ignore this message, it is harmless, and please try reporting the problem to the program developers. | | You may also set WXSUPPRESS_SIZER_FLAGS_CHECK environment variable to suppress all such checks when running this program. | | If you're the developer, simply remove this flag from your code to avoid getting this message. You can also call wxSizerFlags::DisableConsistencyChecks() to globally disable all such checks, but this is strongly not recommended. ` I believe this starts to happen after migrating to wxWidgets 3.2 which added those checks. I have proposed a merge request on Salsa[1] that gets rid of the warnings, and I'm attaching the patches here as well. PTAL. (Also, version 3.2.2 was from 2014 and it would be great if aegisub can start tracking the more active repo at https://github.com/TypesettingTools/Aegisub. But let's track this in Bug#1027433.) TIA. [1] https://salsa.debian.org/debian/aegisub/-/merge_requests/4 -- System Information: Debian Release: 12.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-25-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 aegisub depends on: ii libasound2 1.2.8-1+b1 ii libass91:0.17.1-1 ii libboost-chrono1.74.0 1.74.0+ds1-21 ii libboost-filesystem1.74.0 1.74.0+ds1-21 ii libboost-locale1.74.0 1.74.0+ds1-21 ii libboost-regex1.74.0 [libboost-regex1.74. 1.74.0+ds1-21 0-icu72] ii libboost-thread1.74.0 1.74.0+ds1-21 ii libc6 2.36-9+deb12u8 ii libffms2-5 2.40+git20211209-2+b1 ii libfftw3-double3 3.3.10-1 ii libfontconfig1 2.14.1-4 ii libgcc-s1 12.2.0-14 ii libgl1 1.6.0-1 ii libhunspell-1.7-0 1.7.1-1 ii libicu72 72.1-3 ii libluajit-5.1-22.1.0~beta3+git20220320+dfsg-4.1 ii libpulse0 16.1+dfsg1-2+b1 ii libstdc++6 12.2.0-14 ii libwxbase3.2-1 3.2.2+dfsg-2 ii libwxgtk-gl3.2-1 3.2.2+dfsg-2 ii libwxgtk3.2-1 3.2.2+dfsg-2 ii zlib1g 1:1.2.13.dfsg-1 aegisub recommends no packages. Versions of packages aegisub suggests: pn aegisub-l10n -- no debconf information -- Xiyue Deng >From 24e7af1e78c9401c4a9b23e40252e187c3e4ba55 Mon Sep 17 00:00:00 2001 From: Xiyue Deng Date: Wed, 11 Sep 2024 15:22:01 -0700 Subject: [PATCH 1/2] Add patch to suppress startup warnings on newer wxWidgets versions * Newer wxWidgets added more checks for wxSizer and the old code base has not migrated yet. * Added "wxSizerFlags::DisableConsistencyChecks()" to disable the checks. * Use newer API to get rid of a warning. --- debian/patches/series | 1 + .../patches/suppress-startup-warnings.patch | 51 +++ 2 files changed, 52 insertions(+) create mode 100644 debian/patches/suppress-startup-warnings.patch diff --git a/debian/patches/series b/debian/patches/series index bc373f1..2c3e6a0 100644 --- a/debian/patches/series +++ b/debian/patches/series @@ -27,3 +27,4 @@ update-ffms2-doindexing2.patch update-ffms2-x11-none.patch update-ffms2-log-levels.patch fix_boost183.patch +suppress-startup-warnings.patch diff --git a/debian/patches/suppress-startup-warnings.patch b/debian/patches/suppress-startup-warnings.patch new file mode 100644 index 000..55919ae --- /dev/null +++ b/debian/patches/suppress-startup-warnings.patch @@ -0,0 +1,51 @@ +From bb124f7cced4a117de6adc3caceffed827050e52 Mon Sep 17 00:00:00 2001 +From: Xiyue Deng +Date: Wed, 11 Sep 2024 16:01:12 -0700 +Subject: [PATCH] Suppress startup warnings +Forwarded: not-needed + +* Newer wxWidgets added more si
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
Xiyue Deng writes: > Hi Jeremy, > > Jeremy Sowden writes: > >> On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: >>> Package: sponsorship-requests >>> Severity: normal >>> >>> Dear mentors, >>> >>> I am looking for a sponsor for my package "emacs-buttercup": >>> >>> * Package name : emacs-buttercup >>>Version : 1.36-1 >>>Upstream contact : Jorgen Schaefer >>> * URL : https://github.com/jorgenschaefer/emacs-buttercup/ >>> * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 >>> * 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.36-1.dsc >>> >>> Changes since the last upload: >>> >>> emacs-buttercup (1.36-1) unstable; urgency=medium >>> . >>>* New upstream release >> >> This doesn't work: >> >>>* Drop override_dh_auto_test to use default dh_elpa_test >> >> dh_elpa_test only runs a package's test-suite if the package build- >> depends on elpa-buttercup. Since this is the source package for >> elpa-buttercup, that is not the case, and dh_elpa_test exits without >> doing anything. >> >> Because we can't use dh_elpa_test, we also can't do this: >> >>>* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the >>> default >> >> As it happens, the existing dh_auto_test override doesn't actually work >> any more: the upstream code has changed sufficiently that it just loads >> tests/test-buttercup.el without actually running any tests. However, >> the default make target, "all", has no rules and one dependency on a >> target that _does_ run the full test-suite, so dh_auto_build has been >> running it instead by accident. My suggestion, therefore, is to skip >> dh_auto_build, remove the dh_auto_test override, and let dh_auto_test >> just run `make check`. I have pushed a branch to Salsa that implements >> this and makes a few other changes: >> >> >> https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads >> >> Seem reasonable? >> > > Thanks for checking and the fixes! I have removed the package on > mentors to prevent any premature sponsoring/uploading. > > One small suggestion: instead of using a comment, add @echo with the > message in override_dh_auto_build so that we get this info in the build > log. > > Please feel free to merge to debian/master. > I took the liberty and merged your branch, as well as the small suggestion from my other email. Thanks again for the fix. BTW, will you do the uploading? In which case I'll avoid re-uploading to mentors. Thanks in advance! >>>* Update d/watch with filenamemangle for generating sane package name >>>* Update Standards-Version to 4.7.0; no change needed >> >> J. -- Xiyue Deng
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
Jeremy Sowden writes: > On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: >> Package: sponsorship-requests >> Severity: normal >> >> Dear mentors, >> >> I am looking for a sponsor for my package "emacs-buttercup": >> >> * Package name : emacs-buttercup >>Version : 1.36-1 >>Upstream contact : Jorgen Schaefer >> * URL : https://github.com/jorgenschaefer/emacs-buttercup/ >> * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 >> * 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.36-1.dsc >> >> Changes since the last upload: >> >> emacs-buttercup (1.36-1) unstable; urgency=medium >> . >>* New upstream release > > This doesn't work: > >>* Drop override_dh_auto_test to use default dh_elpa_test > > dh_elpa_test only runs a package's test-suite if the package build- > depends on elpa-buttercup. Since this is the source package for > elpa-buttercup, that is not the case, and dh_elpa_test exits without > doing anything. > > Because we can't use dh_elpa_test, we also can't do this: > >>* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the >> default Forgot to mention: unsetting this doesn't cause any build failure anymore when I'm testinglly locally with "dgit sbuild", so it is possible that the current version of buttercup no longer writes to $HOME. But let's keep it just in case. > > As it happens, the existing dh_auto_test override doesn't actually work > any more: the upstream code has changed sufficiently that it just loads > tests/test-buttercup.el without actually running any tests. However, > the default make target, "all", has no rules and one dependency on a > target that _does_ run the full test-suite, so dh_auto_build has been > running it instead by accident. My suggestion, therefore, is to skip > dh_auto_build, remove the dh_auto_test override, and let dh_auto_test > just run `make check`. I have pushed a branch to Salsa that implements > this and makes a few other changes: > > > https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads > > Seem reasonable? > >>* Update d/watch with filenamemangle for generating sane package name >>* Update Standards-Version to 4.7.0; no change needed > > J. -- Xiyue Deng
Bug#1081113: RFS: emacs-buttercup/1.36-1 -- behaviour-driven testing for Emacs Lisp packages
Hi Jeremy, Jeremy Sowden writes: > On 2024-09-07, at 22:50:28 -0700, Xiyue Deng wrote: >> Package: sponsorship-requests >> Severity: normal >> >> Dear mentors, >> >> I am looking for a sponsor for my package "emacs-buttercup": >> >> * Package name : emacs-buttercup >>Version : 1.36-1 >>Upstream contact : Jorgen Schaefer >> * URL : https://github.com/jorgenschaefer/emacs-buttercup/ >> * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 >> * 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.36-1.dsc >> >> Changes since the last upload: >> >> emacs-buttercup (1.36-1) unstable; urgency=medium >> . >>* New upstream release > > This doesn't work: > >>* Drop override_dh_auto_test to use default dh_elpa_test > > dh_elpa_test only runs a package's test-suite if the package build- > depends on elpa-buttercup. Since this is the source package for > elpa-buttercup, that is not the case, and dh_elpa_test exits without > doing anything. > > Because we can't use dh_elpa_test, we also can't do this: > >>* Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the >> default > > As it happens, the existing dh_auto_test override doesn't actually work > any more: the upstream code has changed sufficiently that it just loads > tests/test-buttercup.el without actually running any tests. However, > the default make target, "all", has no rules and one dependency on a > target that _does_ run the full test-suite, so dh_auto_build has been > running it instead by accident. My suggestion, therefore, is to skip > dh_auto_build, remove the dh_auto_test override, and let dh_auto_test > just run `make check`. I have pushed a branch to Salsa that implements > this and makes a few other changes: > > > https://salsa.debian.org/emacsen-team/emacs-buttercup/-/tree/dh-auto-test-fixes?ref_type=heads > > Seem reasonable? > Thanks for checking and the fixes! I have removed the package on mentors to prevent any premature sponsoring/uploading. One small suggestion: instead of using a comment, add @echo with the message in override_dh_auto_build so that we get this info in the build log. Please feel free to merge to debian/master. >>* Update d/watch with filenamemangle for generating sane package name >>* Update Standards-Version to 4.7.0; no change needed > > J. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1081131: RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol
Phil Wyett writes: > On Tue, 2024-09-10 at 03:43 -0700, Xiyue Deng wrote: >> Phil Wyett writes: >> >> > On Tue, 2024-09-10 at 08:54 +0100, Phil Wyett wrote: >> > > On Tue, 2024-09-10 at 00:25 -0700, Xiyue Deng wrote: >> > > > Xiyue Deng writes: >> > > > >> > > > > Phil Wyett writes: >> > > > > >> > > > > > On Sun, 2024-09-08 at 14:21 -0700, Xiyue Deng wrote: >> > > > > > > Phil Wyett writes: >> > > > > > > >> > > > > > > > Control: tags -1 +moreinfo >> > > > > > > > >> > > > > > > > Xiyue, >> > > > > > > > >> > > > > > > > Preamble... >> > > > > > > > >> > > > > > > > Thank you for taking the time to prepare this package and your >> > > > > > > > contribution >> > > > > > > > to the Debian project. >> > > > > > > > >> > > > > > > > The review below is for assistance. This review is offered to >> > > > > > > > help package >> > > > > > > > submitters to Debian mentors inorder to improve their packages >> > > > > > > > prior to >> > > > > > > > possible sponsorship into Debian. There is no obligation on >> > > > > > > > behalf of the >> > > > > > > > submitter to make any alterations based upon information >> > > > > > > > provided in the >> > > > > > > > review. >> > > > > > > > >> > > > > > > > Review... >> > > > > > > > >> > > > > > > > 1. Build: >> > > > > > > > >> > > > > > > > * pbuilder [1]: Good >> > > > > > > > * sbuild [2]: Good >> > > > > > > > >> > > > > > > > 2. Lintian [3]: Good >> > > > > > > > >> > > > > > > > 3. Licenses [4]: Good >> > > > > > > > >> > > > > > > > 4. Watch file [uscan --force-download]: Issue >> > > > > > > > >> > > > > > > > philwyett@ks-tarkin:~/Development/builder/debian/mentoring/emacs-oauth2-0.17$ >> > > > > > > > uscan --force-download >> > > > > > > > uscan warn: Possible OpenPGP signature found at: >> > > > > > > >https://elpa.gnu.org/packages/oauth2-0.17.tar.sig >> > > > > > > > * Add opts=pgpsigurlmangle=s/$/.sig/ or opts=pgpmode=auto to >> > > > > > > > debian/watch >> > > > > > > > * Add debian/upstream/signing-key.asc. >> > > > > > > > See uscan(1) for more details >> > > > > > > > uscan: error: tar is not a supported compression >> > > > > > > >> > > > > > > Note that on GNU ELPA (GNU Emacs Lisp Package Archive) tar is the >> > > > > > > default option used by all packages. I think this can be >> > > > > > > considered as >> > > > > > > a restriction on uscan which should support tar. >> > > > > > > >> > > > > > > On the other hand, I'm mainly using uscan to check for new >> > > > > > > upstream >> > > > > > > version. The Salsa repository uses DEP14 recommended layout and >> > > > > > > doesn't >> > > > > > > use pristine-tar but tags and "git deborig" for generating the >> > > > > > > tarball >> > > > > > > for Debian archive (which will be in .tar.xz), so this is not an >> > > > > > > actual >> > > > > > > issue. >> > > > > > > >> > > > > > > Hope this helps clarify the situation :) >> > > > > > > >> > > > > > > >> > > > > > >> > > > > > Hi, >> > > > > > >> > > > > > I feel tar support in uscan is not a discussion for Debian >> > > > > > Mentors. An >&
Bug#1081131: RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol
Phil Wyett writes: > On Tue, 2024-09-10 at 08:54 +0100, Phil Wyett wrote: >> On Tue, 2024-09-10 at 00:25 -0700, Xiyue Deng wrote: >> > Xiyue Deng writes: >> > >> > > Phil Wyett writes: >> > > >> > > > On Sun, 2024-09-08 at 14:21 -0700, Xiyue Deng wrote: >> > > > > Phil Wyett writes: >> > > > > >> > > > > > Control: tags -1 +moreinfo >> > > > > > >> > > > > > Xiyue, >> > > > > > >> > > > > > Preamble... >> > > > > > >> > > > > > Thank you for taking the time to prepare this package and your >> > > > > > contribution >> > > > > > to the Debian project. >> > > > > > >> > > > > > The review below is for assistance. This review is offered to help >> > > > > > package >> > > > > > submitters to Debian mentors inorder to improve their packages >> > > > > > prior to >> > > > > > possible sponsorship into Debian. There is no obligation on behalf >> > > > > > of the >> > > > > > submitter to make any alterations based upon information provided >> > > > > > in the >> > > > > > review. >> > > > > > >> > > > > > Review... >> > > > > > >> > > > > > 1. Build: >> > > > > > >> > > > > > * pbuilder [1]: Good >> > > > > > * sbuild [2]: Good >> > > > > > >> > > > > > 2. Lintian [3]: Good >> > > > > > >> > > > > > 3. Licenses [4]: Good >> > > > > > >> > > > > > 4. Watch file [uscan --force-download]: Issue >> > > > > > >> > > > > > philwyett@ks-tarkin:~/Development/builder/debian/mentoring/emacs-oauth2-0.17$ >> > > > > > uscan --force-download >> > > > > > uscan warn: Possible OpenPGP signature found at: >> > > > > >https://elpa.gnu.org/packages/oauth2-0.17.tar.sig >> > > > > > * Add opts=pgpsigurlmangle=s/$/.sig/ or opts=pgpmode=auto to >> > > > > > debian/watch >> > > > > > * Add debian/upstream/signing-key.asc. >> > > > > > See uscan(1) for more details >> > > > > > uscan: error: tar is not a supported compression >> > > > > >> > > > > Note that on GNU ELPA (GNU Emacs Lisp Package Archive) tar is the >> > > > > default option used by all packages. I think this can be considered >> > > > > as >> > > > > a restriction on uscan which should support tar. >> > > > > >> > > > > On the other hand, I'm mainly using uscan to check for new upstream >> > > > > version. The Salsa repository uses DEP14 recommended layout and >> > > > > doesn't >> > > > > use pristine-tar but tags and "git deborig" for generating the >> > > > > tarball >> > > > > for Debian archive (which will be in .tar.xz), so this is not an >> > > > > actual >> > > > > issue. >> > > > > >> > > > > Hope this helps clarify the situation :) >> > > > > >> > > > > >> > > > >> > > > Hi, >> > > > >> > > > I feel tar support in uscan is not a discussion for Debian Mentors. An >> > > > appropriate bug filed elsewhere to start a discussion is a better >> > > > course. >> > > > >> > > >> > > A bit of a backtrack: I was puzzled when you mentioned that uscan had an >> > > error when running with "--force-download" because it worked for me. >> > > Then I realized that I was running Bookworm which has an older version >> > > of devscripts and uscan somehow still created the archive after it >> > > didn't detect any compression suffix so it kind of worked by >> > > unexpectedly. I manually backported devscripts 2.23.7 and can reproduce >> > > the issue. I have filed Bug#1081182 for tracking this. >> > > >> > > > We work with what we have. If a working 'debian/watch' file
Bug#1081131: RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol
Xiyue Deng writes: > Phil Wyett writes: > >> On Sun, 2024-09-08 at 14:21 -0700, Xiyue Deng wrote: >>> Phil Wyett writes: >>> >>> > Control: tags -1 +moreinfo >>> > >>> > Xiyue, >>> > >>> > Preamble... >>> > >>> > Thank you for taking the time to prepare this package and your >>> > contribution >>> > to the Debian project. >>> > >>> > The review below is for assistance. This review is offered to help package >>> > submitters to Debian mentors inorder to improve their packages prior to >>> > possible sponsorship into Debian. There is no obligation on behalf of the >>> > submitter to make any alterations based upon information provided in the >>> > review. >>> > >>> > Review... >>> > >>> > 1. Build: >>> > >>> > * pbuilder [1]: Good >>> > * sbuild [2]: Good >>> > >>> > 2. Lintian [3]: Good >>> > >>> > 3. Licenses [4]: Good >>> > >>> > 4. Watch file [uscan --force-download]: Issue >>> > >>> > philwyett@ks-tarkin:~/Development/builder/debian/mentoring/emacs-oauth2-0.17$ >>> > uscan --force-download >>> > uscan warn: Possible OpenPGP signature found at: >>> >https://elpa.gnu.org/packages/oauth2-0.17.tar.sig >>> > * Add opts=pgpsigurlmangle=s/$/.sig/ or opts=pgpmode=auto to debian/watch >>> > * Add debian/upstream/signing-key.asc. >>> > See uscan(1) for more details >>> > uscan: error: tar is not a supported compression >>> >>> Note that on GNU ELPA (GNU Emacs Lisp Package Archive) tar is the >>> default option used by all packages. I think this can be considered as >>> a restriction on uscan which should support tar. >>> >>> On the other hand, I'm mainly using uscan to check for new upstream >>> version. The Salsa repository uses DEP14 recommended layout and doesn't >>> use pristine-tar but tags and "git deborig" for generating the tarball >>> for Debian archive (which will be in .tar.xz), so this is not an actual >>> issue. >>> >>> Hope this helps clarify the situation :) >>> >>> >> >> Hi, >> >> I feel tar support in uscan is not a discussion for Debian Mentors. An >> appropriate bug filed elsewhere to start a discussion is a better course. >> > > A bit of a backtrack: I was puzzled when you mentioned that uscan had an > error when running with "--force-download" because it worked for me. > Then I realized that I was running Bookworm which has an older version > of devscripts and uscan somehow still created the archive after it > didn't detect any compression suffix so it kind of worked by > unexpectedly. I manually backported devscripts 2.23.7 and can reproduce > the issue. I have filed Bug#1081182 for tracking this. > >> We work with what we have. If a working 'debian/watch' file is not possible >> in the package, it would in my opinion be best to remove it. >> > > In fact, "uscan --report-status" still works and can be used for > detecting new versions. I wonder whether UDD or qa.debian.org requires > actually downloading the newer archive for detecting newer versions, and > if "--report-status" is sufficient, maybe we can keep it as-is as I'm > not using pristine-tar anyway. Alternatively, I can change it to track > the git head instead if desired. > When debugging another issue with watch file result (Bug#1081249) I found that DDPO may be using "uscan --dehs" for detecting newer versions. The command succeeded and output the following for emacs-oauth2: , | $ uscan --dehs | | emacs-oauth2 | 0.17 | 0.17 | 0.17 | https://elpa.gnu.org/packages/oauth2-0.17.tar | up to date | ` So hopefully this is good enough for new-version-detection purpose. >> Regards >> >> Phil >> >> -- >> >> "I play the game for the game’s own sake" >> >> Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans >> >> -- >> >> Buy Me A Coffee: https://buymeacoffee.com/kathenasorg >> >> Internet Relay Chat (IRC): kathenas >> >> Matrix: #kathenas:matrix.org >> >> Website: https://kathenas.org >> >> Instagram: https://instagram.com/kathenasorg/ >> >> Threads: https://www.threads.net/@kathenasorg -- Xiyue Deng
Bug#1081254: msmtp: New upstream version 1.8.26 available
Package: msmtp Version: 1.8.24-1 Severity: wishlist Dear Maintainer, A newer upstream version 1.8.26 is now available. It would be great to have it packaged. I have attempted a local "gbp import-orig --uscan" and it worked smoothly so hopefully the changes required is minimal. Thanks in advance! -- System Information: Debian Release: 12.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-25-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 -- Xiyue Deng
Bug#1081251: RFS: dh-make-elpa/0.19.5 -- helper for creating Debian packages from ELPA packages
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "dh-make-elpa": * Package name : dh-make-elpa Version : 0.19.5 Upstream contact : Debian Emacsen team * URL : https://salsa.debian.org/emacsen-team/dh-make-elpa * License : GPL-2 * Vcs : https://salsa.debian.org/emacsen-team/dh-make-elpa Section : devel The source builds the following binary packages: dh-make-elpa - helper for creating Debian packages from ELPA packages To access further information about this package, please visit the following URL: https://mentors.debian.net/package/dh-make-elpa/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/dh-make-elpa/dh-make-elpa_0.19.5.dsc Changes since the last upload: dh-make-elpa (0.19.5) unstable; urgency=medium . * Use substitute strings in filenamemangle to make it more robust * Reformat default watch file content to be multiline with heredoc * Skip `.git' from github project name when generating d/watch * Update generated Standards-Version to 4.7.0 * Update Standards-Version to 4.7.0; no change needed * Trim whitespace when detecting the short description * Add myself to uploaders Regards, -- Xiyue Deng
Bug#1081249: qa.debian.org: DDPO watch page shows error while uscan working locally
Package: qa.debian.org Severity: normal Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** The watch page for one of my package emacs-bazel-mode reports "error: failed to parse XML:"[1]. However, locally uscan works fine for me (tried both --report-status and --force-download). The tracker page of the package also shows the same error with "failed to parse XML: "[2]. FYI the watch file can be found at [3]. Do let me know if more info is needed. Thanks in advance. [1] https://qa.debian.org/cgi-bin/watch?pkg=emacs-bazel-mode [2] https://tracker.debian.org/pkg/emacs-bazel-mode [3] https://salsa.debian.org/emacsen-team/emacs-bazel-mode/-/blob/master/debian/watch?ref_type=heads -- Xiyue Deng
Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory
David Bremner writes: > Xiyue Deng writes: > >> >> Make sense. AIUI rebuild is not necessary for enabling this because >> currently there is no package depending on this feature, and before and >> after this patch existing package will behave the same. It is only >> making a difference when a package has source code in a sub-directory >> and this patch will disable loading that sub-directory into `load-path'. >> Currently AFAIK only auctex has this issue, and it's not yet elpafied so >> we are good. > > Right, I'm just being extra paranoid (and not investingating very much > yet) about something breaking in the maintainer scripts via this change. Understood. The addition to the install and remove scripts is independent and doesn't touch other parts and should not break any existing logic. But do let me know if I missed anything. -- Xiyue Deng
Bug#1081131: RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol
Phil Wyett writes: > On Sun, 2024-09-08 at 14:21 -0700, Xiyue Deng wrote: >> Phil Wyett writes: >> >> > Control: tags -1 +moreinfo >> > >> > Xiyue, >> > >> > Preamble... >> > >> > Thank you for taking the time to prepare this package and your contribution >> > to the Debian project. >> > >> > The review below is for assistance. This review is offered to help package >> > submitters to Debian mentors inorder to improve their packages prior to >> > possible sponsorship into Debian. There is no obligation on behalf of the >> > submitter to make any alterations based upon information provided in the >> > review. >> > >> > Review... >> > >> > 1. Build: >> > >> > * pbuilder [1]: Good >> > * sbuild [2]: Good >> > >> > 2. Lintian [3]: Good >> > >> > 3. Licenses [4]: Good >> > >> > 4. Watch file [uscan --force-download]: Issue >> > >> > philwyett@ks-tarkin:~/Development/builder/debian/mentoring/emacs-oauth2-0.17$ >> > uscan --force-download >> > uscan warn: Possible OpenPGP signature found at: >> >https://elpa.gnu.org/packages/oauth2-0.17.tar.sig >> > * Add opts=pgpsigurlmangle=s/$/.sig/ or opts=pgpmode=auto to debian/watch >> > * Add debian/upstream/signing-key.asc. >> > See uscan(1) for more details >> > uscan: error: tar is not a supported compression >> >> Note that on GNU ELPA (GNU Emacs Lisp Package Archive) tar is the >> default option used by all packages. I think this can be considered as >> a restriction on uscan which should support tar. >> >> On the other hand, I'm mainly using uscan to check for new upstream >> version. The Salsa repository uses DEP14 recommended layout and doesn't >> use pristine-tar but tags and "git deborig" for generating the tarball >> for Debian archive (which will be in .tar.xz), so this is not an actual >> issue. >> >> Hope this helps clarify the situation :) >> >> > > Hi, > > I feel tar support in uscan is not a discussion for Debian Mentors. An > appropriate bug filed elsewhere to start a discussion is a better course. > A bit of a backtrack: I was puzzled when you mentioned that uscan had an error when running with "--force-download" because it worked for me. Then I realized that I was running Bookworm which has an older version of devscripts and uscan somehow still created the archive after it didn't detect any compression suffix so it kind of worked by unexpectedly. I manually backported devscripts 2.23.7 and can reproduce the issue. I have filed Bug#1081182 for tracking this. > We work with what we have. If a working 'debian/watch' file is not possible > in the package, it would in my opinion be best to remove it. > In fact, "uscan --report-status" still works and can be used for detecting new versions. I wonder whether UDD or qa.debian.org requires actually downloading the newer archive for detecting newer versions, and if "--report-status" is sufficient, maybe we can keep it as-is as I'm not using pristine-tar anyway. Alternatively, I can change it to track the git head instead if desired. > Regards > > Phil > > -- > > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > Internet Relay Chat (IRC): kathenas > > Matrix: #kathenas:matrix.org > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Threads: https://www.threads.net/@kathenasorg -- Xiyue Deng
Bug#1081182: devscripts: uscan: does not support tar archive
n pristine-lfs ii quilt 0.67+really0.66-1 pn ratt pn reprotest pn svn-buildpackage ii w3m 0.5.3+git20230121-2 -- no debconf information -- Xiyue Deng
Bug#1081131: RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol
Phil Wyett writes: > Control: tags -1 +moreinfo > > Xiyue, > > Preamble... > > Thank you for taking the time to prepare this package and your contribution > to the Debian project. > > The review below is for assistance. This review is offered to help package > submitters to Debian mentors inorder to improve their packages prior to > possible sponsorship into Debian. There is no obligation on behalf of the > submitter to make any alterations based upon information provided in the > review. > > Review... > > 1. Build: > > * pbuilder [1]: Good > * sbuild [2]: Good > > 2. Lintian [3]: Good > > 3. Licenses [4]: Good > > 4. Watch file [uscan --force-download]: Issue > > philwyett@ks-tarkin:~/Development/builder/debian/mentoring/emacs-oauth2-0.17$ > uscan --force-download > uscan warn: Possible OpenPGP signature found at: >https://elpa.gnu.org/packages/oauth2-0.17.tar.sig > * Add opts=pgpsigurlmangle=s/$/.sig/ or opts=pgpmode=auto to debian/watch > * Add debian/upstream/signing-key.asc. > See uscan(1) for more details > uscan: error: tar is not a supported compression Note that on GNU ELPA (GNU Emacs Lisp Package Archive) tar is the default option used by all packages. I think this can be considered as a restriction on uscan which should support tar. On the other hand, I'm mainly using uscan to check for new upstream version. The Salsa repository uses DEP14 recommended layout and doesn't use pristine-tar but tags and "git deborig" for generating the tarball for Debian archive (which will be in .tar.xz), so this is not an actual issue. Hope this helps clarify the situation :) > > 5. Build Twice [sudo pbuilder build --twice .dsc]: Good > > 6. Reproducible builds [5]: Good > > 7. Install [No previous installs]: Good > > 8. Upgrade [Over previous installs if any]: N/A > > Summary... > > I believe emacs-oauth2 is not yet ready for sponsorship at this time. Could > the contributor rectify one of more of the rasied issues. > > Once updated to your satisfaction and a new upload done, please remove the > 'moreinfo' tag on the Request For Sponsorship (RFS) bug report. > > Regards > > Phil > > [1] pbuilder: > > * Command: sudo pbuilder build .dsc > * Document: https://wiki.ubuntu.com/PbuilderHowto. > * Document: https://wiki.debian.org/PbuilderTricks > > [2] sbuild: > > * Command: sbuild .dsc > * Document: https://wiki.kathenas.org/pmwiki.php/Kathenas/Article0002 > * Document: https://wiki.debian.org/sbuild > > [3] lintian: > > * Command: lintian -v -i -I -E --pedantic --profile debian (*.dsc, > *.changes, *.buildinfo). Each can throw up different results, so be thorough. > * Document: https://wiki.debian.org/Lintian > > [4] lrc: > > * Command: lrc > * Document: https://wiki.debian.org/CopyrightReviewTools#licenserecon > > [5] reprotest > > * Command: sudo reprotest --vary=-build_path,domain_host.use_sudo=1 --auto- > build .dsc -- schroot unstable-amd64-sbuild > * Document: https://wiki.kathenas.org/pmwiki.php/Kathenas/Article0004 > * Document: https://wiki.debian.org/ReproducibleBuilds/ > * Document: https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method > > -- > > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > Internet Relay Chat (IRC): kathenas > > Matrix: #kathenas:matrix.org > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Threads: https://www.threads.net/@kathenasorg -- Xiyue Deng signature.asc Description: PGP signature
Bug#1081131: RFS: emacs-oauth2/0.17-1 [ITP] -- OAuth 2.0 Authorization Protocol
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-oauth2": * Package name : emacs-oauth2 Version : 0.17-1 Upstream contact : Julien Danjou * URL : https://elpa.gnu.org/packages/oauth2.html * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/oauth2 Section : editors The source builds the following binary packages: elpa-oauth2 - OAuth 2.0 Authorization Protocol To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-oauth2/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-oauth2/emacs-oauth2_0.17-1.dsc Changes for the initial release: emacs-oauth2 (0.17-1) unstable; urgency=medium . * Initial Debianisation (Closes: #1080374) Regards, -- Xiyue Deng
Bug#1081113: RFS: emacs-buttercup/1.36-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.36-1 Upstream contact : Jorgen Schaefer * URL : https://github.com/jorgenschaefer/emacs-buttercup/ * License : GPL-3+, GFDL-1.2+ or CC-BY-SA-3.0 * 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.36-1.dsc Changes since the last upload: emacs-buttercup (1.36-1) unstable; urgency=medium . * New upstream release * Drop override_dh_auto_test to use default dh_elpa_test * Drop setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION now it is the default * Update d/watch with filenamemangle for generating sane package name * Update Standards-Version to 4.7.0; no change needed Regards, -- Xiyue Deng
Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory
Hi David, David Bremner writes: > Xiyue Deng writes: > >> >> I have tested running the previously failed tests, e.g. clojure-mode >> which uses buttercup and flycheck which uses both buttercup and ERT, and >> they are now passing using the new implementation. >> > > Build failures are (relatively) fine. What I really want to avoid is > having to do a mass rebuild to fix maintainer scripts (or worse, to have > broken maintainer scripts shipped in stable). So we need to take some > extra care and attention with changes to dh-elpa. Make sense. AIUI rebuild is not necessary for enabling this because currently there is no package depending on this feature, and before and after this patch existing package will behave the same. It is only making a difference when a package has source code in a sub-directory and this patch will disable loading that sub-directory into `load-path'. Currently AFAIK only auctex has this issue, and it's not yet elpafied so we are good. -- Xiyue Deng
Bug#1080374: ITP: emacs-oauth2 -- OAuth 2.0 Authorization Protocol for Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-oauth2 Version : 0.17 Upstream Author : Julien Danjou * URL or Web page : https://elpa.gnu.org/packages/oauth2.html * License : GPL-3+ Programming lang: Emacs Lisp Description : OAuth 2.0 Authorization Protocol for Emacs Implementation of the OAuth 2.0 draft. . The main entry point is `oauth2-auth-and-store' which will return a token structure. This token structure can be then used with `oauth2-url-retrieve-synchronously' or `oauth2-url-retrieve' to retrieve any data that need OAuth authentication to be accessed. . If the token needs to be refreshed, the code handles it automatically and store the new value of the access token. I will maintain this package within the Debian Emacsen Team . -- Xiyue Deng
Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory
Hi David, David Bremner writes: > Xiyue Deng writes: > >> Xiyue Deng writes: >> >>> [[PGP Signed Part:Undecided]] >>> Sean Whitton writes: >>> >>>> Hello Xiyue, >>>> >>>> On Thu 25 Jul 2024 at 11:54pm -07, Xiyue Deng wrote: >>>> >>>>> I have prepared a patch at [3] and also attached. Please help review >>>>> and comment. I'll merge it once it's approved. >>>> >>>> Please don't merge this yourself; let me or David do it. Thanks. >>> >>> Ack. Will wait for your reviews. Thanks. >> >> Friendly ping for comments. > > No review yet, but what have you done for testing? I have tested running the previously failed tests, e.g. clojure-mode which uses buttercup and flycheck which uses both buttercup and ERT, and they are now passing using the new implementation. -- Xiyue Deng
Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory
Xiyue Deng writes: > [[PGP Signed Part:Undecided]] > Sean Whitton writes: > >> Hello Xiyue, >> >> On Thu 25 Jul 2024 at 11:54pm -07, Xiyue Deng wrote: >> >>> I have prepared a patch at [3] and also attached. Please help review >>> and comment. I'll merge it once it's approved. >> >> Please don't merge this yourself; let me or David do it. Thanks. > > Ack. Will wait for your reviews. Thanks. Friendly ping for comments. -- Xiyue Deng
Bug#1079954: RFS: elpa-rust-mode/1.0.6-1 -- Major Emacs mode for editing Rust source code
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "elpa-rust-mode": * Package name : elpa-rust-mode Version : 1.0.6-1 Upstream contact : The Rust Project Developers * URL : https://github.com/rust-lang/rust-mode * License : Apache-2.0 or MIT * Vcs : https://salsa.debian.org/emacsen-team/rust-mode Section : editors The source builds the following binary packages: elpa-rust-mode - Major Emacs mode for editing Rust source code To access further information about this package, please visit the following URL: https://mentors.debian.net/package/elpa-rust-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/elpa-rust-mode/elpa-rust-mode_1.0.6-1.dsc Changes since the last upload: elpa-rust-mode (1.0.6-1) unstable; urgency=medium . * New upstream version Regards, -- Xiyue Deng
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Control: retitle -1 RFS: markdown-mode/2.6-3 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs Xiyue Deng writes: > Xiyue Deng writes: > >> [[PGP Signed Part:Undecided]] >> Hi Nicholas, >> >> Nicholas D Steeves writes: >> >>> Xiyue Deng writes: >>> >>> Git pull, then read along with the reply that follows inline. >>> >>>>> Xiyue Deng writes: >>>>> >>>>>>* Drop unused override_dh_auto_test in d/rules (dh_elpa_test is in >>>>>> effect) >>>>> >>>>> override_dh_auto_test: >>>>> @echo Using dh_elpa_test to run tests instead of upstream Makefile >>>>> >>>>> Used to be useful, because the Makefile tests used to run as well as the >>>>> dh_elpa_test ones. Dh_elpa_test was also "in effect then"... >>>>> >>>> >>>> I believe dh_elpa_test disables dh_auto_test by default unless it is >>>> disabled in debian/elpa-test[1]. I think you did this change back in >>>> this commit[2] back in 2019. On the other hand, it looks like >>>> dh_auto_test was disabled by dh-elpa even earlier[3]. Maybe you were >>>> referring to even more back then? Anyway, would be good to figure this >>>> out. >>> >>> Some team members voluntarily accommodate backports and/or >>> oldstable-backports. Write something like "No longer needed" or >>> something to that effect, if it's buildable on bookworm and bullseye. >>> If not buildable, talk to whoever added the B-D. >>> >>> If "Drop unnecessary Build-Depends on markdown" were true than discount >>> shouldn't become a B-D. So there's a major contradiction in your >>> changelog entries and/or thinking. Likewise, in the interest of >>> timeliness I'm fixing this myself. Read the updated changelog carefully >>> and recursively follow any references. Also, consider that if markdown >>> wasn't a B-D we wouldn't have received this RC bug notifying us of >>> markdowns removal, and it's probable no one would have noticed until >>> users complained. That might have been after Trixie's release. If >>> nothing else, the B-D is worth it for that. >>> >> >> (Here your response was below a past discussion on dh_elpa_test but was >> really about B-D, and I got a bit confused, but I'll assume the >> previously quoted texts are not relevant here. I believe your were >> referring to a later part that discusses B-D.) >> >> I'd like to clarify that the contradiction in the changelog was an >> oversight and I tried to fix that: I realized that `discount' provides a >> compatible markdown command and should be a suitable replacement of the >> `markdown' and used that in place of markdown. I tried to remove that >> entry about dropping, as you can see from my first upload on mentors[1]. >> It got overwritten due to a later `gbp dch` as I didn't commit that >> changelog yet and added more work and hence that change was lost. So in >> retrospect, I realized the early change mentioning that `markdown' is >> "unnecessary" was incorrect and tried to replace it with `discount', but >> forgot to remove the earlier entry generated from `gbp dch`. Please >> also see my previous reply (quoted below) for my analysis on how >> markdown-mode checks for available commands to process. I guess the >> better word to describe it is "optional" instead of "unused" indeed, >> which I tried to remove from d/changelog anyway. >> >>> Why should your colleagues give you the time of day (ie: spend any of >>> their time to review your work) if you systematically refuse to trust >>> their work? Doing security audits would be a better use >>> skepticism/suspicion ;) >>> >> >> I hope the previous explanation would clarify that there is no >> ill-intent to discredit any of the existing work. >> >>>>>>* Update debian copyright year in d/copyright >>>>> >>>>> -Copyright: 2015-2017 David Bremner >>>>> +Copyright: 2015-2024 David Bremner >>>>> >>>>> In terms of copyright, please explain your understanding of copyright >>>>> what you're doing here. This is not a mere 's/17/24/' symbol >>>>> manipulation. >>>>> >>>> >>>> I was th
Bug#1073236: RFS: muse-el/3.20+git20240209.8710add+dfsg-1 -- author and publish projects using Wiki-like markup
.2/
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 7657 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/cgi.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 1624 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/htmlize-
> hack.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 9807 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/httpd.el
> │ │ │ │ │ +-rw-r--r-- 0 root (0) root (0)13383 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> autoloads.el
> │ │ │ │ │ --rw-r--r-- 0 root (0) root (0)13273 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> autoloads.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0)12128 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> backlink.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0)11597 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> blosxom.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0)11497 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> book.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0) 4768 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> cite.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0)42210 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> colors.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0)16614 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> context.el
> │ │ │ │ │ -rw-r--r-- 0 root (0) root (0)13691 2024-08-
> 04 11:01:37.00 ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> docbook.el
> │ │ │ │ ├── ./usr/share/emacs/site-lisp/elpa-src/muse-3.20.2/muse-
> autoloads.el
> │ │ │ │ │ @@ -431,14 +431,19 @@
> │ │ │ │ │ (register-definition-prefixes "muse-xml-common" '("muse-xml-"))
> │ │ │ │ │
> │ │ │ │ │ ;;;***
> │ │ │ │ │
>
> │ │ │ │ │ ;;;### (autoloads nil nil ("../contrib/htmlize-hack.el") (0 0 0
> 0))
> │ │ │ │ │
> │ │ │ │ │ ;;;***
> │ │ │ │ │ +
> │ │ │ │ │ +
>
> │ │ │ │ │ +;;; Generated autoloads from muse-latex2png.el
> │ │ │ │ │ +
> │ │ │ │ │ +(register-definition-prefixes "muse-latex2png" '("muse-"))
> │ │ │ │ │
>
> │ │ │ │ │ ;;;### (autoloads nil "muse-backlink" "muse-backlink.el" (0 0 0
> 0))
> │ │ │ │ │ ;;; Generated autoloads from muse-backlink.el
> │ │ │ │ │
> │ │ │ │ │ (register-definition-prefixes "muse-backlink" '("muse-backlink-"))
> │ │ │ │ │
> │ │ │ │ │ ;;;***
> Observed unreproducibility when varying each of the following:
> timezone fileordering user_group
> The build is probably reproducible when varying other things.
>
This seems to be a known issue with dblatex[1][2], and exists in
previous versions as well (stable and testing). I wouldn't consider
this a blocking issue yet as Debian has not mandated reproducible build
as release criteria yet. Cab we consider this package ready for now
while we work on a fix?
> 7. Install [No previous installs]: Good
>
> 8. Upgrade [Over previous installs if any]: Good
>
> Summary...
>
> I believe muse-el is not yet ready for sponsorship/upload. Could the
> contributor rectify one of more of the rasied issues. Once updated to your
> satisfaction and a new upload done, please remove the 'moreinfo' on the
> Request For Sponsorship (RFS) bug report.
>
> Regards
>
> Phil
>
> [1] pbuilder:
>
> * Command: sudo pbuilder build .dsc
> * Document: https://wiki.ubuntu.com/PbuilderHowto.
> * Document: https://wiki.debian.org/PbuilderTricks
>
> [2] sbuild:
>
> * Command: sbuild .dsc
> * Document: https://wiki.debian.org/sbuild
>
> [3] lintian:
>
> * Command: lintian -v -i -I -E --pedantic --profile debian (*.dsc,
> *.changes, *.buildinfo). Each can throw up different results, so be thorough.
> * Document: https://wiki.debian.org/Lintian
>
> [4] lrc:
>
> * Command: lrc -t
> * Document: https://wiki.debian.org/CopyrightReviewTools#licenserecon
>
> [5] reprotest
>
> * Command: sudo reprotest --vary=-build_path,domain_host.use_sudo=1 --auto-
> build dsc -- schroot unstable-amd64-sbuild
> * Document: https://wiki.debian.org/ReproducibleBuilds/
> * Document: https://wiki.debian.org/ReproducibleBuilds/Howto#Newer_method
>
> --
>
> "I play the game for the game’s own sake"
>
> Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans
>
> --
>
> Buy Me A Coffee: https://buymeacoffee.com/kathenasorg
>
> Internet Relay Chat (IRC): kathenas
>
> Matrix: #kathenas:matrix.org
>
> Website: https://kathenas.org
>
> Instagram: https://instagram.com/kathenasorg/
>
> Threads: https://www.threads.net/@kathenasorg
[1]
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/muse-el.html
[2]
https://tests.reproducible-builds.org/debian/issues/unstable/random_id_in_pdf_generated_by_dblatex_issue.html
--
Xiyue Deng
Bug#1077939: RFS: emacs-libvterm/0.0.2+git20240705.d9ea29f-1 -- fully-fledged terminal emulator inside GNU Emacs based on libvterm - module
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-libvterm": * Package name : emacs-libvterm Version : 0.0.2+git20240705.d9ea29f-1 Upstream contact : Lukas Fürmetz * URL : https://github.com/akermu/emacs-libvterm * License : GPL-3+, GPL-3, GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-libvterm Section : editors The source builds the following binary packages: emacs-libvterm - fully-fledged terminal emulator inside GNU Emacs based on libvterm - module elpa-vterm - fully-fledged terminal emulator inside GNU Emacs based on libvterm - elisp To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-libvterm/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-libvterm/emacs-libvterm_0.0.2+git20240705.d9ea29f-1.dsc Changes since the last upload: emacs-libvterm (0.0.2+git20240705.d9ea29f-1) unstable; urgency=medium . * New upstream snapshot Regards, -- Xiyue Deng
Bug#1069620: RFS: lua-mode/20231023~git-1 -- Emacs major-mode for editing Lua programs
Control: retitle -1 RFS: lua-mode/20221027+git20231023.d074e41-1 -- Emacs major-mode for editing Lua programs Hi Phil, Phil Wyett writes: > [[PGP Signed Part:Undecided]] > Hi all, > > Do we have a consensus as yet on the versioning? > I actually lost track of this. I have now changed to use the version of the package with git snapshot date plus hash. New changes pushed to team repo[1] and rebuilt package uploaded to mentors[2]. PTAL. > Regards > > Phil > > > On Sat, 11 May 2024 10:29:56 -0700 Xiyue Deng wrote: >> 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 > > -- > > "I play the game for the game’s own sake" > > Arthur Conan Doyle - The Adventure of the Bruce-Partington Plans > > -- > > Buy Me A Coffee: https://buymeacoffee.com/kathenasorg > > Internet Relay Chat (IRC): kathenas > > Matrix: #kathenas:matrix.org > > Website: https://kathenas.org > > Instagram: https://instagram.com/kathenasorg/ > > Threads: https://www.threads.net/@kathenasorg [1] https://salsa.debian.org/emacsen-team/lua-mode [2] https://mentors.debian.net/package/lua-mode/ -- Xiyue Deng signature.asc Description: PGP signature
Bug#1077826: RFS: emacs-corfu/1.5-1 -- 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.5-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.5-1.dsc Changes since the last upload: emacs-corfu (1.5-1) unstable; urgency=medium . * New upstream release Regards, -- Xiyue Deng
Bug#1077775: RFS: activities-el/0.7.1-1 -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "activities-el": * Package name : activities-el Version : 0.7.1-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-1.dsc Changes since the last upload: activities-el (0.7.1-1) unstable; urgency=medium . * New upstream release. Regards, -- Xiyue Deng
Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory
Sean Whitton writes: > Hello Xiyue, > > On Thu 25 Jul 2024 at 11:54pm -07, Xiyue Deng wrote: > >> I have prepared a patch at [3] and also attached. Please help review >> and comment. I'll merge it once it's approved. > > Please don't merge this yourself; let me or David do it. Thanks. Ack. Will wait for your reviews. Thanks. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1055431: Simpler fix for #1052917
Jeremy Sowden writes:
> [[PGP Signed Part:Undecided]]
> On 2024-07-26, at 16:24:52 -0400, Nicholas D Steeves wrote:
>> Jeremy Sowden writes:
>> > This error:
>> >> debian/rules clean
>> >> dh clean --with elpa
>> >>dh_auto_clean
>> >> make -j8 clean
>> >> make[1]: Entering directory '/<>'
>> >> End of file during parsing
>> >> rm -f *.elc .latest-* autoloads.el scala-mode- Error: end-of-file nil
>> >> mapbacktrace(#f(compiled-function (evald func args flags) #> >> 0x943b01ebae87e2>)) debug-early-backtrace() debug-early(error
>> >> (end-of-file)) read(#) (nth 2 (read
>> >> (find-file "./scala-mode-pkg.el"))) (format "%s\n" (nth 2 (read
>> >> (find-file "./scala-mode-pkg.el" (princ (format "%s\n" (nth 2 (read
>> >> (find-file "./scala-mode-pkg.el") command-line-1(("-L" "." "--eval"
>> >> "(princ (format \"%s\\n\" (nth 2 (read (find-file
>> >> \"./scala-mode-pkg.el\")")) command-line() normal-top-level().tar
>> >> /bin/sh: 1: Syntax error: "(" unexpected
>> >> make[1]: *** [Makefile:55: clean] Error 2
>> >
>> > occurs because the Makefile does this (trimmed):
>> >
>> > VERSION := $(shell ${ELISP_COMMAND} $(ELISP_OPTIONS)
>> > --eval '(princ (format "%s\n" (nth 2 (read (find-file "$(PKG_FILE)")')
>> > MODE_NAME_VERSION = $(MODE_NAME)-$(VERSION)
>> >
>> > clean:
>> > $(RM) *.elc .latest-* autoloads.el $(MODE_NAME_VERSION).tar
>> >
>> > It tries to use Emacs to get the version from the scala-mode-pkg.el
>> > file, but that doesn't exist, so the output from the `$(shell)` command
>> > is a stack-trace, not a version number.
>> >
>> > Make prefers variable definitions given as arguments at the command line
>> > to those defined in the Makefile, so if `VERSION=X.Y.Z` is passed to
>> > `make clean`:
>> >
>> > override_dh_autoclean:
>> > dh_auto_clean -- VERSION=X.Y.Z
>> >
>> > Emacs isn't called, and the error goes away.
>
> Actually, it turns out that emacs _is_ called:
>
> dh clean --with elpa
> debian/rules override_dh_auto_clean
> make[1]: Entering directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
> dh_auto_clean -- VERSION=1.1.0
> make -j16 clean VERSION=1.1.0
> make[2]: Entering directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
> End of file during parsing
> ^^
>
> but the stack-trace doesn't get assigned to the variable, and the build
> continues successfully:
>
> rm -f *.elc .latest-* autoloads.el scala-mode-1.1.0.tar
> [ ! -d scala-mode-1.1.0 ] || rm -f scala-mode-1.1.0/*
> [ ! -d scala-mode-1.1.0 ] || rmdir scala-mode-1.1.0
> make[2]: Leaving directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
> make[1]: Leaving directory '/build/scala-mode-el-1.1.0+git20240113.4c6d636'
>
>> Thank you, yes, this is one of the right ways to solve this issue, and I
>> hope it's evident to everyone following this thread why this is the
>> case. :)
>>
>> Please use Xiyue Deng (manphiz)'s work on SUBSTVARS for "VERSION=X.Y.Z",
>> and feel free to apply any fixups; I seem to remember that there's
>> something like a fragile regex.
>
> This?
>
> BASE_UPSTREAM_VERSION=$(shell echo ${DEB_VERSION_UPSTREAM} | sed
> "s/\+git.*//")
>
> I replaced it with:
>
> BASE_UPSTREAM_VERSION = $(word 1,$(subst +git, ,$(DEB_VERSION_UPSTREAM)))
>
>> > I will push this change and review the rest of this (lengthy :))
>> > report.
>>
>> Rather than reading this mentoring thread--long form for educational
>> value--it's probably faster to review d/changelog, diff
>> debian/20111005-2.1, and check for consistency.
>>
>> P.S. did you forget to push?
>
> Indeed. Now done.
>
> J.
>
> [[End of PGP Signed Part]]
Thanks Jeremy! It looks much cleaner now. I have also merged from
dgit/sid with the recent rebuild done by Sean so that the changelogs are
now consistent.
--
Xiyue Deng
signature.asc
Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Nicholas D Steeves writes: > [[PGP Signed Part:Undecided]] > Xiyue Deng writes: > >> Nicholas D Steeves writes: >>> Xiyue Deng writes: >>>> Nicholas D Steeves writes: >> >>> Also, do you use this package? >>> >> >> Not on a regular basis, but I do use it a bit once in a while as I try >> to learn a bit of new programming languages every few months. > > Putting yourself in Uploaders means you're going to take a special (and > regular) interest in a package in the long term. Is that really what > you intend? > I will regularly monitor the bug tracker and fix any issues regarding building and tests. I hope this is sufficient to become an uploader. >>> Meanwhile, compression type isn't the problem: >>> >>> gbp:info: Tarballs 'scala-mode-el_1.1.0+git20221025.5d7cf21.orig.tar.gz' >>> not found at '/home/sten/devel/tarballs/' >>> gbp:error: v1.1.0+git20221025.5d7cf21 is not a valid treeish >>> >> >> This is because I didn't push the tag to the repo yet. Now this is >> done. > > Thanks. When pushing upstream history, one needs to also push the > upstream tag. > >>> and at the same time, the proposed switch to xz is also arguably a >>> regression, because the actual upstream release tarballs of scala-mode >>> are currently being used: >>> >>> $ apt source scala-mode-el >>> $ md5sum scala-mode-el_1.1.0.orig.tar.gz >>> 615b1f38ed083137fee99fa83fe452a1 scala-mode-el_1.1.0.orig.tar.gz >>> # Download release tarball from github manually, or use uscan >>> $ md5sum ~/Downloads/emacs-scala-mode-1.1.0.tar.gz >>> 615b1f38ed083137fee99fa83fe452a1 >>> /home/sten/Downloads/emacs-scala-mode-1.1.0.tar.gz >>> >>> This indicates that the human maintainer doesn't use "git deborig". >>> Being able to reproduce the imports of official upstream tarballs is >>> important to a number of developers, and some workflows depend on this >>> assumption, so please don't break it. >>> >> >> In this specific case as I'm targeting a snapshot so there is no >> upstream tarball, so using xz provides the benefits of a smaller source >> tarball that saves space for the Debian source repository. >> >> For the aspect of the consistency with upstream release tarball, I'm >> trying to understand how to make this work. I believe "gbp import-orig >> --uscan" should grab the upstream release tarball which follows your >> suggestion. However IIUC the repository is configure using the >> dgit-maint-merge workflow that uses upstream branch to target upstream >> repo and hence uses the tagged version to generate upstream tarball, >> which I believe is incompatible with "gbp import-orig --uscan" approach >> which directly import the release tarball without the git history. > > What does "IIUC" mean? "If I understand correctly" > This repository doesn't use dgit workflow. Gbp can optionally merge > git history. Ack. I also converted my patch using Gbp Pq and updated the forward info[1]. > > If upstream provides release tarballs in gz rather than xz, and the > Debian Maintainer/Uploader uses those, then the repository needs to be > configured for gz and not xz. Note that d/watch previously specified > gz. Changing that configuration is working against the > Maintainer/Uploader. Given this, it is more correct to configure gbp to > use gz until upstream switches to xz. I will buy your argument in this package and hence revert that change in [2]. Though I still believe preparing a release from a git tag has its value in general, especially in post-Jia-Tan world. I believe tag2upload is another step towards that goal. > "Git deborig" should also be invoked to use gz. > See above. >> I wonder whether there is a way for "git deborig" or "gbp >> buildpackage" to grab upstream tarball automatically? I'm guessing >> not, so someone has to do it manually, but please let me know if there >> is a way. > > What do you mean? Just use uscan, or origtargz. Or do you mean > accommodating the case where you think moving from a stable release to a > snapshot is justified? Tell upstream that Debian highly values stable > releases, and convince them to tag one. Problem solved. P.S. I read a > message you wrote to an upstream about this, and that github issue > didn't look like it would convince anyone of the value of tagged > releases...please do better in the future. > Well, I think part of the problem is that the upstream is essentially MIA as the last commit was 6 months ago, which means a new tagged release is not likely to happen any time soon. Preparing the latest snapshot would be the next best thing we can do IMHO. Anyway, PTAL with my recent commits that fixes some of the issues you mentioned. > Nicholas > > [[End of PGP Signed Part]] [1] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/ed8cf56a432351c743a139173c5f121f1f73db6c [2] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/857b767743df6548a821f070711dcc9e1b8df739 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Hi Nicholas, Nicholas D Steeves writes: > [[PGP Signed Part:Undecided]] > Xiyue Deng writes: > >> 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! > > Please stop making copyright assertions for other people. We've > discussed this before, and it's the actual copyright situation is what > counts and not lintian's experimental "update-debian-copyright" tag. > That tag is to remind contributors in the d/copyright file to check > whether they've done any work that meets the > > https://en.wikipedia.org/wiki/Threshold_of_originality > Acknowledged. I was trying to revert that change and saw you already did it in [1]. Thanks. Also thanks for the link. I was trying to find more explanations regarding Copyright concepts. This also explains why some DDs consider the contents under `debian/' not copyrightable because the lack of originality. Anyway, in normal case, I would think adding oneself to the copyright list of `File: debian/*' when doing any changes is acceptable as the changes reflects the intention of oneself to improve the package, even only incrementally. > You also need to explain what "Drop old version on emacs in recommends." > means, and *why* you made this change, because it's not self-evident. Clarified in [2]. > > Cheers, > Nicholas > > [[End of PGP Signed Part]] [1] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/5d670b9cc33f22d34d3003c6606f785f05644d36 [2] https://salsa.debian.org/emacsen-team/scala-mode-el/-/commit/0f7d996aaf8efc4ffc36f63351045fc8e498bb68 -- Xiyue Deng
Bug#1077155: dh-elpa: enable `load-path' handling of sub-directory
Package: dh-elpa
Version: 2.1.5
Severity: important
This is a follow-up of bug#1069210[1] and bug#1076964[2]. The
implementation of supporting sub-directories for elpa packages has
mostly been released in dh-elpa except for the `load-path' handling.
The original approach of adding `.nosearch' sentinels in
`/usr/share/emacs/site-lisp/elpa{,-src}' was discovered to be broken[2]:
though it works for normal mode, in batch mode it will disable loading
path for all sub-directories from these two path. This was reverted in
2.1.5.
I am now proposing another approach: only adding `.nosearch' sentinels
in any sub-directories from the root directory of a package, e.g. for
package `foo' with a sub-directory `bar', only add `.nosearch' under
`foo/bar' but no `foo'. This was proven to work well using an elpafied
auctex package, and doesn't break any tests using ERT or Buttercup.
I have prepared a patch at [3] and also attached. Please help review
and comment. I'll merge it once it's approved.
[1] https://bugs.debian.org/1069210
[2] https://bugs.debian.org/1076964
[3]
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...no-recursive-handling?from_project_id=18920
-- System Information:
Debian Release: 12.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.1.0-23-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.4+1-3~bpo12+0manphiz1
ii emacs-gtk [emacs] 1:29.4+1-3~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
--
Xiyue Deng
From ff24a2bcaf7f8fdb4e3507842b822974163d2843 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Wed, 24 Jul 2024 14:22:05 -0700
Subject: [PATCH] Properly disable recursive load-path handling in
sub-directories
* Create the `.nosearch' files only in package sub-directories in
helper/install, and remove them in helper/remove.
---
helper/install | 3 +++
helper/remove | 7 +++
2 files changed, 10 insertions(+)
diff --git a/helper/install b/helper/install
index 8d748c8..0139b84 100755
--- a/helper/install
+++ b/helper/install
@@ -42,6 +42,9 @@ elc_dir=/usr/share/${FLAVOR}/site-lisp/elpa/${ELPA_DIR}/
export EMACSLOADPATH
EMACSLOADPATH=${ELPA_LOAD_PATH}
+# Disable adding sub-directories to `load-path'
+for DIR in ${el_dir}/*; do [ -d ${DIR} ] && touch ${DIR}/.nosearch; done
+
echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}"
[ -d "${elc_dir}" ] || mkdir -p "${elc_dir}"
diff --git a/helper/remove b/helper/remove
index 3182eeb..6ab9d17 100755
--- a/helper/remove
+++ b/helper/remove
@@ -24,6 +24,8 @@ ELPA_DIR=${ELPA_PACKAGE}-${ELPA_VERSION}
elpa_root="/usr/share/${FLAVOR}/site-lisp/elpa"
elc_dir="${elpa_root}/${ELPA_DIR}"
+elpa_src_root="/usr/share/${FLAVOR}/site-lisp/elpa-src"
+el_dir="${elpa_src_root}/${ELPA_DIR}"
FLAVOR=$1
case $FLAVOR in
@@ -43,6 +45,11 @@ echo dh-elpa: purging flavor specific files for ${FLAVOR}
rm -f ${elc_dir}/*.elc
[ -d ${elc_dir} ] && find ${elc_dir} -type l -delete
rm -f ${elc_dir}/Install.log*
+
+# Remove entries that disable recursive `load-path' handling in sub-directories
+find ${elc_dir} -name ".nosearch" -exec rm {} \;
+find ${el_dir} -name ".nosearch" -exec rm {} \;
+
if test -e "${elc_dir}"
then
rmdir --ignore-fail-on-non-empty "${elc_dir}"
--
2.39.2
signature.asc
Description: PGP signature
Bug#1076964: Acknowledgement (dh-elpa: load-path handling broken)
I have reverted the commit causing the issue in team repo[1].
I have also implemented another approach to avoid sub-directories in
`load-path', and tested with some success. You can find the diff in [2]
or attached. Please let me know what you think. Will push after
getting some approvals.
Meanwhile, if reviewing the patch takes longer, please consider making
another release with just [1] to fix the current issue.
[1]
https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/852d8613798708178f2b0dff53798826e45c9ac9
[2]
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...no-recursive-handling?from_project_id=18920
--
Xiyue Deng
>From cc38abc38dea77814c691913fab51593ed7da584 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Wed, 24 Jul 2024 14:22:05 -0700
Subject: [PATCH] Properly disable recursive load-path handling in
sub-directories
* Create the `.nosearch' files only in package sub-directories in
helper/install, and remove them in helper/remove.
---
helper/install | 3 +++
helper/remove | 7 +++
2 files changed, 10 insertions(+)
diff --git a/helper/install b/helper/install
index 8d748c8..0139b84 100755
--- a/helper/install
+++ b/helper/install
@@ -42,6 +42,9 @@ elc_dir=/usr/share/${FLAVOR}/site-lisp/elpa/${ELPA_DIR}/
export EMACSLOADPATH
EMACSLOADPATH=${ELPA_LOAD_PATH}
+# Disable adding sub-directories to `load-path'
+for DIR in ${el_dir}/*; do [ -d ${DIR} ] && touch ${DIR}/.nosearch; done
+
echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}"
[ -d "${elc_dir}" ] || mkdir -p "${elc_dir}"
diff --git a/helper/remove b/helper/remove
index 3182eeb..6ab9d17 100755
--- a/helper/remove
+++ b/helper/remove
@@ -24,6 +24,8 @@ ELPA_DIR=${ELPA_PACKAGE}-${ELPA_VERSION}
elpa_root="/usr/share/${FLAVOR}/site-lisp/elpa"
elc_dir="${elpa_root}/${ELPA_DIR}"
+elpa_src_root="/usr/share/${FLAVOR}/site-lisp/elpa-src"
+el_dir="${elpa_src_root}/${ELPA_DIR}"
FLAVOR=$1
case $FLAVOR in
@@ -43,6 +45,11 @@ echo dh-elpa: purging flavor specific files for ${FLAVOR}
rm -f ${elc_dir}/*.elc
[ -d ${elc_dir} ] && find ${elc_dir} -type l -delete
rm -f ${elc_dir}/Install.log*
+
+# Remove entries that disable recursive `load-path' handling in sub-directories
+find ${elc_dir} -name ".nosearch" -exec rm {} \;
+find ${el_dir} -name ".nosearch" -exec rm {} \;
+
if test -e "${elc_dir}"
then
rmdir --ignore-fail-on-non-empty "${elc_dir}"
--
2.39.2
Bug#1076964: dh-elpa: load-path handling broken
Package: dh-elpa Version: 2.1.2 Severity: serious My recent commit[1] breaks `load-path' handling, which disables recursive adding load-path from `/usr/share/emacs/site-lisp/elpa' but should have been in each package root directory. Reverting the commit should be safe as no package holds source code in a sub-directory yet, and should fix this issue for now. Will properly handle `load-path' for sub-directory in a future commit. [1] https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/bd738e3a38e0409bbe8d19d31f7569af8d920436 -- System Information: Debian Release: 12.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-23-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.4+1-3~bpo12+0manphiz1 ii emacs-gtk [emacs] 1:29.4+1-3~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 -- Xiyue Deng
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Xiyue Deng writes: > [[PGP Signed Part:Undecided]] > Hi Nicholas, > > Nicholas D Steeves writes: > >> Xiyue Deng writes: >> >> Git pull, then read along with the reply that follows inline. >> >>>> Xiyue Deng writes: >>>> >>>>>* Drop unused override_dh_auto_test in d/rules (dh_elpa_test is in >>>>> effect) >>>> >>>> override_dh_auto_test: >>>> @echo Using dh_elpa_test to run tests instead of upstream Makefile >>>> >>>> Used to be useful, because the Makefile tests used to run as well as the >>>> dh_elpa_test ones. Dh_elpa_test was also "in effect then"... >>>> >>> >>> I believe dh_elpa_test disables dh_auto_test by default unless it is >>> disabled in debian/elpa-test[1]. I think you did this change back in >>> this commit[2] back in 2019. On the other hand, it looks like >>> dh_auto_test was disabled by dh-elpa even earlier[3]. Maybe you were >>> referring to even more back then? Anyway, would be good to figure this >>> out. >> >> Some team members voluntarily accommodate backports and/or >> oldstable-backports. Write something like "No longer needed" or >> something to that effect, if it's buildable on bookworm and bullseye. >> If not buildable, talk to whoever added the B-D. >> >> If "Drop unnecessary Build-Depends on markdown" were true than discount >> shouldn't become a B-D. So there's a major contradiction in your >> changelog entries and/or thinking. Likewise, in the interest of >> timeliness I'm fixing this myself. Read the updated changelog carefully >> and recursively follow any references. Also, consider that if markdown >> wasn't a B-D we wouldn't have received this RC bug notifying us of >> markdowns removal, and it's probable no one would have noticed until >> users complained. That might have been after Trixie's release. If >> nothing else, the B-D is worth it for that. >> > > (Here your response was below a past discussion on dh_elpa_test but was > really about B-D, and I got a bit confused, but I'll assume the > previously quoted texts are not relevant here. I believe your were > referring to a later part that discusses B-D.) > > I'd like to clarify that the contradiction in the changelog was an > oversight and I tried to fix that: I realized that `discount' provides a > compatible markdown command and should be a suitable replacement of the > `markdown' and used that in place of markdown. I tried to remove that > entry about dropping, as you can see from my first upload on mentors[1]. > It got overwritten due to a later `gbp dch` as I didn't commit that > changelog yet and added more work and hence that change was lost. So in > retrospect, I realized the early change mentioning that `markdown' is > "unnecessary" was incorrect and tried to replace it with `discount', but > forgot to remove the earlier entry generated from `gbp dch`. Please > also see my previous reply (quoted below) for my analysis on how > markdown-mode checks for available commands to process. I guess the > better word to describe it is "optional" instead of "unused" indeed, > which I tried to remove from d/changelog anyway. > >> Why should your colleagues give you the time of day (ie: spend any of >> their time to review your work) if you systematically refuse to trust >> their work? Doing security audits would be a better use >> skepticism/suspicion ;) >> > > I hope the previous explanation would clarify that there is no > ill-intent to discredit any of the existing work. > >>>>>* Update debian copyright year in d/copyright >>>> >>>> -Copyright: 2015-2017 David Bremner >>>> +Copyright: 2015-2024 David Bremner >>>> >>>> In terms of copyright, please explain your understanding of copyright >>>> what you're doing here. This is not a mere 's/17/24/' symbol >>>> manipulation. >>>> >>> >>> I was thinking about adding myself to copyright, but I remember one of >>> the early reviews I got (which I forgot from whom) suggested that adding >>> oneself to copyright list would require significant change to the >>> debian/ files so I didn't do it and instead extending the copyright year >>> coverage of the existing entry. Maybe in such case like this one, I >>> should go over the git history and add all people that had contribut
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Hi Nicholas, Nicholas D Steeves writes: > Replying from my phone: > > On Wed, 3 Jul 2024, 22:40 Sean Whitton, wrote: > > Hello, > > Sorry to keep asking for these minor changes, but it does help me > understand the change better. > > Why can't you just use debian/install to install the .nosearch? Are you > trying to avoid creating an empty .nosearch in the source package, or is > there some other reason? > > While we're discussing interface, I'm curious about a "debian:rules:dh --with > dh-elpa --nosearch, norecurse, flat, or > similar". > > For the fine-grained approach, I'm curious about special handling for > debian/foo.elpa: subdir/.nosearch. Like an > autoload cookie, but a " do not recourse and do not load" cookie. > > Ie can't this problem be resolved such that it enables declarative style and > doesn't require a debian/[foo.]install file? Are you suggesting that we make this a configuration for "--with dh-elpa"? I think that is outside the scope of this proposal, and I'm not sure making that configurable is desirable. Upstream has acknowledged non-recursive handling of `load-path' is intended, and supporting other types of handling is diverging from ELPA behavior. Or if you are suggesting we can make this a per-package setting of /.nosearch, I think this is sub-optimal as it requires rebuilding/binNMU of all packages, while the current approach only requires a new dh-elpa version. Or maybe I'm missing something? -- Xiyue Deng signature.asc Description: PGP signature
Bug#1075767: elpa-debian-el: debian-bug fails with Lisp error for some packages
et ((type (let ((cursor-in-echo-area t)) (message "Report a bug > | for a [P]ackage or [F]ile: (default P) ") (capitalize > | (read-char-exclusive) (cond ((or (equal 13 type) (equal 13 type) > | (equal 32 type) (equal 32 type) (equal 112 type) (equal 80 type)) > | (debian-bug-package)) ((equal 70 type) (debian-bug-filename)) (t > | (message "Sorry, try that again" > | debian-bug() > | funcall-interactively(debian-bug) > | call-interactively(debian-bug record nil) > | command-execute(debian-bug record) > | execute-extended-command(nil "debian-bug" nil) > | funcall-interactively(execute-extended-command nil "debian-bug" nil) > | call-interactively(execute-extended-command nil nil) > | command-execute(execute-extended-command) > ` > > > -- System Information: > Debian Release: trixie/sid > APT prefers unstable > APT policy: (500, 'unstable'), (101, 'experimental') > Architecture: amd64 (x86_64) > Foreign Architectures: i386 > > Kernel: Linux 6.1.96-nouveau (SMP w/2 CPU threads; PREEMPT) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > > Versions of packages elpa-debian-el depends on: > ii bzip2 1.0.8-5.1 > ii dh-elpa-helper 2.0.17.1 > ii emacsen-common 3.0.5 > ii reportbug 13.0.1 > ii xz-utils5.6.2-2 > ii zstd1.5.6+dfsg-1 > > Versions of packages elpa-debian-el recommends: > ii emacs 1:29.4+1-3 > ii emacs-gtk [emacs] 1:29.4+1-3 > ii wget 1.24.5-1 > > elpa-debian-el suggests no packages. > > -- no debconf information Thanks for your report! Looks like this was an oversight when I tried to implement specifying optional version when reporting bug against uninstalled packages. A fix is committed in team repo[1]. I have prepared a new version on mentors[2] with an RFS[3]. Sponsoring welcome :) [1] https://salsa.debian.org/emacsen-team/debian-el/-/commit/8e41a9b4957b9d56ec6c55ee5d4ce84038d01dd6 [2] https://mentors.debian.net/package/debian-el/ [3] https://bugs.debian.org/1075779 -- Xiyue Deng
Bug#1075779: RFS: debian-el/37.14 -- Emacs helpers specific to Debian users
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "debian-el": * Package name : debian-el Version : 37.14 Upstream contact : Debian Emacsen team * URL : https://salsa.debian.org/emacsen-team/debian-el * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/debian-el Section : lisp The source builds the following binary packages: elpa-debian-el - Emacs helpers specific to Debian users debian-el - Transition package, debian-el to elpa-debian-el To access further information about this package, please visit the following URL: https://mentors.debian.net/package/debian-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/debian-el/debian-el_37.14.dsc Changes since the last upload: debian-el (37.14) unstable; urgency=medium . * Add missing version parameter for debian-bug-script-sentinel (Closes: #1075767) Regards, -- Xiyue Deng -- Xiyue Deng
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Hi Sean,
Sean Whitton writes:
> Hello,
>
> Sorry to keep asking for these minor changes, but it does help me
> understand the change better.
>
> Why can't you just use debian/install to install the .nosearch? Are you
> trying to avoid creating an empty .nosearch in the source package, or is
> there some other reason?
Actually that's pretty much it. And now I realize there is a downside
of using a custom command to create those empty files during install: I
forgot to implement the clean-up logic. So to make things simple I now
just put those two files in the source and install them using d/install
in [1]. Please see updated full diff in [2] and attached.
[1]
https://salsa.debian.org/manphiz/dh-elpa/-/commit/7e2bad6bf74d91f9cd876a4620796fe4eb5f3514
[2]
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...nested-directory-support?from_project_id=18920
--
Xiyue Deng
From 7e2bad6bf74d91f9cd876a4620796fe4eb5f3514 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Thu, 4 Jul 2024 02:16: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/install | 2 ++
elpa-src/.nosearch | 0
elpa/.nosearch | 0
3 files changed, 2 insertions(+)
create mode 100644 elpa-src/.nosearch
create mode 100644 elpa/.nosearch
diff --git a/debian/install b/debian/install
index d6e2470..64fc1fc 100644
--- a/debian/install
+++ b/debian/install
@@ -2,3 +2,5 @@ elpa.pm usr/share/perl5/Debian/Debhelper/Sequence
emacsen-common usr/share/debhelper/dh_elpa
autoscripts/prerm-elpa usr/share/debhelper/autoscripts
usr/bin
+elpa/.nosearch usr/share/emacs/site-lisp/elpa
+elpa-src/.nosearch usr/share/emacs/site-lisp/elpa-src
diff --git a/elpa-src/.nosearch b/elpa-src/.nosearch
new file mode 100644
index 000..e69de29
diff --git a/elpa/.nosearch b/elpa/.nosearch
new file mode 100644
index 000..e69de29
--
2.39.2
From b8e71ae56587bbc8ba069b66a882fd7862c25c0a 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 e68c5e9d4b6cf0509afc402b71464c6dda273fdb 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 0a57ca5d4456ed1a41f0646e2ae4ac9fa486a8b8 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 c6211de..4b91ec7 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 elpa installation (Closes:
+#1069210).
+- Don't recursively add elpa path to match packa
Bug#1074622: RFS: emacs-dape/0.13.0-1 [ITP] -- Debug Adapter Protocol for Emacs
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-dape": * Package name : emacs-dape Version : 0.13.0-1 Upstream contact : Daniel Pettersson * URL : https://github.com/svaante/dape * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-dape Section : editors The source builds the following binary packages: elpa-dape - Debug Adapter Protocol for Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-dape/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-dape/emacs-dape_0.13.0-1.dsc Changes for the initial release: emacs-dape (0.13.0-1) unstable; urgency=medium . * Initial Debianisation (Closes: #1074569) Regards, -- Xiyue Deng
Bug#1074569: ITP: emacs-dape -- Debug Adapter Protocol for Emacs
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-dape Version : 0.13.0 Upstream Author : Daniel Pettersson * URL or Web page : https://github.com/svaante/dape * License : GPL-3+ Programming lang: Emacs Lisp Description : Debug Adapter Protocol for Emacs Dape is a debug adapter client for Emacs. The debug adapter protocol, much like its more well-known counterpart, the language server protocol, aims to establish a common API for programming tools. However, instead of functionalities such as code completions, it provides a standardized interface for debuggers. . To begin a debugging session, invoke the `dape' command. In the minibuffer prompt, enter a debug adapter configuration name from `dape-configs'. . For complete functionality, make sure to enable `eldoc-mode' in your source buffers and `repeat-mode' for more pleasant key mappings. . Package looks is heavily inspired by gdb-mi.el I intend to maintain this package in the Debian Emacsen Team. I'll need a sponsor for uploading.
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Control: forwarded -1 https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71817
(CCing Nicholas who also provided feedbacks on IRC.)
I have opened an upstream bug[1] asking for opinions on the ELPA path
handling and they confirmed that the current status is expected:
byte-compiling recursively, and only add source root path to
`load-path'. I believe this confirms that this wishlist is going in the
right direction.
I have also updated the implementation so that adding `.nosearch' files
is done directly in d/rules instead of relying on triggers which adds
unnecessary overload when installing each elpa package[2]. The full
diff can be found on salsa[3] and also attached.
[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=71817
[2]
https://salsa.debian.org/manphiz/dh-elpa/-/commit/1e59035004fd6d6ad12412ce0239ed6ef4abe93f
[3]
https://salsa.debian.org/manphiz/dh-elpa/-/compare/master...nested-directory-support?from_project_id=18920
--
Xiyue Deng
From 1e59035004fd6d6ad12412ce0239ed6ef4abe93f Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Wed, 26 Jun 2024 17:37:41 -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/install | 1 +
debian/rules | 5 +
2 files changed, 6 insertions(+)
diff --git a/debian/install b/debian/install
index d6e2470..fc4ef32 100644
--- a/debian/install
+++ b/debian/install
@@ -2,3 +2,4 @@ elpa.pm usr/share/perl5/Debian/Debhelper/Sequence
emacsen-common usr/share/debhelper/dh_elpa
autoscripts/prerm-elpa usr/share/debhelper/autoscripts
usr/bin
+usr/share/emacs/site-lisp
diff --git a/debian/rules b/debian/rules
index c93d80f..474b500 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,6 +6,9 @@ DESTDIR=$(CURDIR)/debian/tmp
# this is not needed, and only included as a test of the feature.
ELPA_NAME_dh-elpa=dh-elpa
+# Sentinels to disable recursively adding to `load-path'.
+SITE_LISP_PATH=$(DESTDIR)/usr/share/emacs/site-lisp
+
%:
dh $@
@@ -21,3 +24,5 @@ override_dh_install:
override_dh_auto_install:
install -m 755 -D dh_elpa $(DESTDIR)/usr/bin/dh_elpa
install -m 755 -D dh_elpa_test $(DESTDIR)/usr/bin/dh_elpa_test
+ mkdir -p $(SITE_LISP_PATH)/elpa && touch $(SITE_LISP_PATH)/elpa/.nosearch
+ mkdir -p $(SITE_LISP_PATH)/elpa-src && touch $(SITE_LISP_PATH)/elpa-src/.nosearch
--
2.39.2
From 0ea18b198d06b11b854dfa7347e39e4e71001093 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 71417bf830c76a21dfe84bb4b7d6be7fd7d04148 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 427efab8b6a4f8ca950353066126c44ab57cad83 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 c6211de..4b91ec
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Hi Nicholas, Nicholas D Steeves writes: > Xiyue Deng writes: > > Git pull, then read along with the reply that follows inline. > >>> Xiyue Deng writes: >>> >>>>* Drop unused override_dh_auto_test in d/rules (dh_elpa_test is in >>>> effect) >>> >>> override_dh_auto_test: >>> @echo Using dh_elpa_test to run tests instead of upstream Makefile >>> >>> Used to be useful, because the Makefile tests used to run as well as the >>> dh_elpa_test ones. Dh_elpa_test was also "in effect then"... >>> >> >> I believe dh_elpa_test disables dh_auto_test by default unless it is >> disabled in debian/elpa-test[1]. I think you did this change back in >> this commit[2] back in 2019. On the other hand, it looks like >> dh_auto_test was disabled by dh-elpa even earlier[3]. Maybe you were >> referring to even more back then? Anyway, would be good to figure this >> out. > > Some team members voluntarily accommodate backports and/or > oldstable-backports. Write something like "No longer needed" or > something to that effect, if it's buildable on bookworm and bullseye. > If not buildable, talk to whoever added the B-D. > > If "Drop unnecessary Build-Depends on markdown" were true than discount > shouldn't become a B-D. So there's a major contradiction in your > changelog entries and/or thinking. Likewise, in the interest of > timeliness I'm fixing this myself. Read the updated changelog carefully > and recursively follow any references. Also, consider that if markdown > wasn't a B-D we wouldn't have received this RC bug notifying us of > markdowns removal, and it's probable no one would have noticed until > users complained. That might have been after Trixie's release. If > nothing else, the B-D is worth it for that. > (Here your response was below a past discussion on dh_elpa_test but was really about B-D, and I got a bit confused, but I'll assume the previously quoted texts are not relevant here. I believe your were referring to a later part that discusses B-D.) I'd like to clarify that the contradiction in the changelog was an oversight and I tried to fix that: I realized that `discount' provides a compatible markdown command and should be a suitable replacement of the `markdown' and used that in place of markdown. I tried to remove that entry about dropping, as you can see from my first upload on mentors[1]. It got overwritten due to a later `gbp dch` as I didn't commit that changelog yet and added more work and hence that change was lost. So in retrospect, I realized the early change mentioning that `markdown' is "unnecessary" was incorrect and tried to replace it with `discount', but forgot to remove the earlier entry generated from `gbp dch`. Please also see my previous reply (quoted below) for my analysis on how markdown-mode checks for available commands to process. I guess the better word to describe it is "optional" instead of "unused" indeed, which I tried to remove from d/changelog anyway. > Why should your colleagues give you the time of day (ie: spend any of > their time to review your work) if you systematically refuse to trust > their work? Doing security audits would be a better use > skepticism/suspicion ;) > I hope the previous explanation would clarify that there is no ill-intent to discredit any of the existing work. >>>>* Update debian copyright year in d/copyright >>> >>> -Copyright: 2015-2017 David Bremner >>> +Copyright: 2015-2024 David Bremner >>> >>> In terms of copyright, please explain your understanding of copyright >>> what you're doing here. This is not a mere 's/17/24/' symbol >>> manipulation. >>> >> >> I was thinking about adding myself to copyright, but I remember one of >> the early reviews I got (which I forgot from whom) suggested that adding >> oneself to copyright list would require significant change to the >> debian/ files so I didn't do it and instead extending the copyright year >> coverage of the existing entry. Maybe in such case like this one, I >> should go over the git history and add all people that had contributed >> and also add myself to the list. Wdyt? > > For upstream, we copy what upstream says, and it's non-authoritative. > For debian/*, we are the authority, and it affects all of our > downstreams. This means one needs to get it right. > > Rather than communicating on the level of symbol manipulation, I expect > you to write in a way that demonstrates a minimal understanding of > copyright and
Bug#1074413: elpa-web-mode: Clarify license of Debian packaging
Hi Thomas, Thomas Koch writes: > Hello Xiyue, > > thank you for taking over my packages after the Debian project kicked > me out[1] and orphaned all my packages. I'm not interested in holding > copyright[2] and actually believe, that the obsession with copyright > for insignificant stuff in the Debian project is another example of > submission to authority without independent thinking. > > One can only claim copyright for something that has any level of > creativity or originality. The debian/* part of emacs packages however > is almost 100% auto-generated. > > That having said, I hereby grant anybody permission to assign any > license of their liking to any packaging work I ever did in the Debian > project or to claim copyright for my work or to not mention my > contribution at all. > > [1] https://blog.koch.ro/posts/2023-03-15-debian-exclusion.html > [2] https://lists.debian.org/debian-project/2013/02/msg00023.html > Thanks for your prompt reply! I didn't know about this part of history and sorry if my previous email may sound inconsiderate. In any case, I'd like to thank you for your packaging work and for giving permission to handle copyright according to the current Debian practice. I'll leave this bug open for now as a reference during cleaning up d/copyright for the various packages. > Thomas Koch > >> Xiyue Deng hat am 28.06.2024 13:36 EEST geschrieben: >> >> >> Package: elpa-web-mode >> Version: 16.0.21-1 >> Severity: important >> X-Debbugs-Cc: debian-emac...@lists.debian.org, Thomas Koch , >> Thomas Koch >> >> When working on updating the packaging of web-mode, it is noticed that >> the Debian packaging work of `debian/*' does not have a copyright holder >> documented in debian/copyright file[1]. How the copyright of the >> packaging should be interpreted is still being discussed[2]. Meanwhile, >> it would make it easier if Thomas can clarify the copyright license and >> status of his packaging work, which will make it easier to process >> moving forward. >> >> Besides web-mode, there are other packages maintained by Thomas that >> seem to share the same issue, including editorconfig[3], >> emacs-lsp-haskell[4], git-auto-commit-mode[5], and org-drill[6]. >> >> Therefore I'm CCing Thomas in hope to receive his reply on clarifying >> this matter, and if possible, for all the aforementioned packages. >> >> Thanks in advance. >> >> [1] >> https://salsa.debian.org/emacsen-team/web-mode/-/commit/df7a8cc10bef7d057bd728b3fa92b930d4eabde2 >> [2] https://lists.debian.org/debian-legal/2024/04/msg1.html >> [3] >> https://salsa.debian.org/emacsen-team/editorconfig/-/blob/master/debian/copyright?ref_type=heads >> [4] >> https://salsa.debian.org/emacsen-team/editorconfig/-/blob/master/debian/copyright?ref_type=heads >> [5] >> https://salsa.debian.org/emacsen-team/git-auto-commit-mode/-/blob/master/debian/copyright?ref_type=heads >> [6] >> https://salsa.debian.org/emacsen-team/org-drill/-/blob/master/debian/copyright?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-21-amd64 (SMP w/16 CPU threads; PREEMPT) >> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not >> set >> Shell: /bin/sh linked to /usr/bin/dash >> Init: systemd (via /run/systemd/system) >> LSM: AppArmor: enabled >> >> Versions of packages elpa-web-mode depends on: >> ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 >> ii emacsen-common 3.0.5 >> >> Versions of packages elpa-web-mode recommends: >> ii emacs 1:29.3+1-3~bpo12+1 >> ii emacs-gtk [emacs] 1:29.3+1-3~bpo12+1 >> >> elpa-web-mode suggests no packages. >> >> -- no debconf information >> >> -- >> Xiyue Deng -- Xiyue Deng signature.asc Description: PGP signature
Bug#1074413: elpa-web-mode: Clarify license of Debian packaging
Package: elpa-web-mode Version: 16.0.21-1 Severity: important X-Debbugs-Cc: debian-emac...@lists.debian.org, Thomas Koch , Thomas Koch When working on updating the packaging of web-mode, it is noticed that the Debian packaging work of `debian/*' does not have a copyright holder documented in debian/copyright file[1]. How the copyright of the packaging should be interpreted is still being discussed[2]. Meanwhile, it would make it easier if Thomas can clarify the copyright license and status of his packaging work, which will make it easier to process moving forward. Besides web-mode, there are other packages maintained by Thomas that seem to share the same issue, including editorconfig[3], emacs-lsp-haskell[4], git-auto-commit-mode[5], and org-drill[6]. Therefore I'm CCing Thomas in hope to receive his reply on clarifying this matter, and if possible, for all the aforementioned packages. Thanks in advance. [1] https://salsa.debian.org/emacsen-team/web-mode/-/commit/df7a8cc10bef7d057bd728b3fa92b930d4eabde2 [2] https://lists.debian.org/debian-legal/2024/04/msg1.html [3] https://salsa.debian.org/emacsen-team/editorconfig/-/blob/master/debian/copyright?ref_type=heads [4] https://salsa.debian.org/emacsen-team/editorconfig/-/blob/master/debian/copyright?ref_type=heads [5] https://salsa.debian.org/emacsen-team/git-auto-commit-mode/-/blob/master/debian/copyright?ref_type=heads [6] https://salsa.debian.org/emacsen-team/org-drill/-/blob/master/debian/copyright?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-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-web-mode depends on: ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 ii emacsen-common 3.0.5 Versions of packages elpa-web-mode recommends: ii emacs 1:29.3+1-3~bpo12+1 ii emacs-gtk [emacs] 1:29.3+1-3~bpo12+1 elpa-web-mode suggests no packages. -- no debconf information -- Xiyue Deng
Bug#1068605: RFS: web-mode/17.3.13-1 [Team] -- major emacs mode for editing web templates
Hi Nicholas, Xiyue Deng writes: > 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! Friendly ping. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Hi Nicholas, Xiyue Deng writes: > Xiyue Deng writes: > >> Nicholas D Steeves writes: >> >>>>* Update debian copyright year in d/copyright >>> >>> -Copyright: 2015-2017 David Bremner >>> +Copyright: 2015-2024 David Bremner >>> >>> In terms of copyright, please explain your understanding of copyright >>> what you're doing here. This is not a mere 's/17/24/' symbol >>> manipulation. >>> >> >> I was thinking about adding myself to copyright, but I remember one of >> the early reviews I got (which I forgot from whom) suggested that adding >> oneself to copyright list would require significant change to the >> debian/ files so I didn't do it and instead extending the copyright year >> coverage of the existing entry. Maybe in such case like this one, I >> should go over the git history and add all people that had contributed >> and also add myself to the list. Wdyt? >> > > This is now implemented in [1]. PTAL. > > [1] > https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/85029b71af13e8279930cea2645cb060857de4b4 Friendly ping. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1055431: RFS: scala-mode-el/1:1.1.0+git20221025.5d7cf21-1 [RC] [Team] -- Emacs major mode for editing scala source code
Xiyue Deng writes: > > > 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. > Friendly ping for comments. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1073099: markdown-mode: replace to-be-removed markdown build-dependency
Control: tags -1 pending Hi Chris, Chris Hofstaedtler writes: > Source: markdown-mode > Version: 2.6-1 > Severity: serious > Control: block 1072958 by -1 > > Your package build-depends on markdown. Per bug #1063645, markdown is not > maintained upstream or in Debian and should be removed. > Drop-in alternatives, for examples the suggested `discount` or > `python3-markdown` or `libtext-markdown-perl`. > > `discount` and `libtext-markdown-perl` provide a `markdown` program if your > package needs that. > Thanks for your report! Actually, this has been implemented in team repo (see commits [1][2][3]). Please also see Bug#1072906[4] for the RFS of markdown-mode, and please feel free to add any comments there. [1] https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/a5348a075464f77701df1c138985f4976fe6a8a0 [2] https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/10deb2fb6c00fb83a96226fb0c7645af0672d676 [3] https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/adfe33a78fac11877c32fe2f5c87284b0c1d6463 [4] https://bugs.debian.org/1072906 -- Xiyue Deng
Bug#1072556: RFS: elpa-rust-mode/1.0.5+git20240520.d00d83d-1 [ITA] [RC] -- Major Emacs mode for editing Rust source code
Hi Gianfranco, Gianfranco Costamagna writes: > Hello, just add the previous changelog entry, at least we know that something > was in the archive? > Thanks for the suggestion. Actually, I managed to find the comment right before I finalize the changelog and uploaded the previous version, with which I managed to make another commit to refinalize it (that can be used as the released commit for version 1.0.5+git20240301.6d86af4-1). I then merged the current master branch with this small divergence and merged the changelog so that everything is synced from now on. I have recompiled and reuploaded the package to mentors. Please help take another look. Thanks! -- Xiyue Deng signature.asc Description: PGP signature
Bug#1072555: elpa-rust-mode: This is an obsolete snapshot of the packaging
Version: 1.0.5+git20240301.6d86af4-1 Found a way to reconcile git history. Marking as closed with current version. -- Xiyue Deng
Bug#1073236: RFS: muse-el/3.20+git20240209.8710add+dfsg-1 -- author and publish projects using Wiki-like markup
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "muse-el": * Package name : muse-el Version : 3.20+git20240209.8710add+dfsg-1 Upstream contact : Michael Olson * URL : https://www.gnu.org/software/emacs-muse/index.html * License : Expat, GPL-2, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/muse-el Section : editors The source builds the following binary packages: elpa-muse - author and publish projects using Wiki-like markup To access further information about this package, please visit the following URL: https://mentors.debian.net/package/muse-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/muse-el/muse-el_3.20+git20240209.8710add+dfsg-1.dsc Changes since the last upload: muse-el (3.20+git20240209.8710add+dfsg-1) unstable; urgency=medium . * Switch upstream to elpa and sync to latest upstream head (8710add). * Drop patches applied upstream * Drop comments in d/watch now that we are tracking elpa (Closes: #1051247) * Update year and add Upstream-Contact in d/copyright * Drop unused lintian overrides. * Declare Standards-Version 4.7.0; no change needed Regards, -- Xiyue Deng
Bug#1072556: RFS: elpa-rust-mode/1.0.5+git20240520.d00d83d-1 [ITA] [RC] -- Major Emacs mode for editing Rust source code
Hi Gianfranco, On Sun, 9 Jun 2024 23:58:29 +0200 Gianfranco Costamagna wrote: > control: tags -1 moreinfo > > Hello, you are not adding a new changelog entry, but editing the current one. > Please > check the version in sid, and add a new one. > > G. Unfortunately the previous uploaded one is an older snapshot of the packaging work which is not available in the git history on the Salsa repository anymore. I was hoping that this newer version can be uploaded to override the previous one. I have reopened the bug closed by the previous version in hope that it passes the check on mentors. Will this work? If not, what is your recommendation on reconciling the git history? Thanks again for your reviews and sponsoring. -- Xiyue Deng signature.asc Description: PGP signature
Bug#1073185: RFS: dpkg-dev-el/37.13 [Team] -- Transition package, dpkg-dev-el to elpa-dpkg-dev-el
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.13 Upstream contact : Debian Emacsen Team * URL : https://salsa.debian.org/emacsen-team/dpkg-dev-el * 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.13.dsc Changes since the last upload: dpkg-dev-el (37.13) unstable; urgency=medium . * Add Homepage in d/control * Add Source in d/copyright * Drop explicit dependency on elpa-debian-el in favor of Package-Requires * Add optional version support to `reassign' (Closes: #503108) * Rename forward paragraph helper function using the internal function convention * Implement toggling team upload (Closes: #595067) - Also bind to "C-c C-t" * Fix fontification for frozen to properly detect proposed updates * Improve fontification of backports to only detect stable and oldstable * Add fontification for known release code names - Currently includes Debian and Ubuntu release code names * Add font lock for emails in debian-control-mode * Add font lock regexp for URLs in debian-control-mode * Improve email and url detection regexps Regards, -- Xiyue Deng
Bug#1073184: RFS: debian-el/37.13 -- Emacs helpers specific to Debian users
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "debian-el": * Package name : debian-el Version : 37.13 Upstream contact : Debian Emacsen team * URL : https://salsa.debian.org/emacsen-team/debian-el * License : GPL-2+ * Vcs : https://salsa.debian.org/emacsen-team/debian-el Section : lisp The source builds the following binary packages: elpa-debian-el - Emacs helpers specific to Debian users debian-el - Transition package, debian-el to elpa-debian-el To access further information about this package, please visit the following URL: https://mentors.debian.net/package/debian-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/d/debian-el/debian-el_37.13.dsc Changes since the last upload: debian-el (37.13) unstable; urgency=medium . * Add Homepage in d/control * Add Source in d/copyright * Implement debian-bug-request-for-sponsor (Closes: #1072787) * Add prompt for version when reporting bugs (Closes: #529611) Regards, -- Xiyue Deng
Bug#1073153: RFS: emacs-lsp-docker/0.0~git20240507.16a0cfb-1 [ITP] -- LSP Docker integration for lsp-mode
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-lsp-docker": * Package name : emacs-lsp-docker Version : 0.0~git20240507.16a0cfb-1 Upstream contact : Jen-Chieh Shen * URL : https://github.com/emacs-lsp/lsp-docker * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-lsp-docker Section : editors The source builds the following binary packages: elpa-lsp-docker - LSP Docker integration for lsp-mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-lsp-docker/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-lsp-docker/emacs-lsp-docker_0.0~git20240507.16a0cfb-1.dsc Changes for the initial release: emacs-lsp-docker (0.0~git20240507.16a0cfb-1) unstable; urgency=medium . * Initial release (Closes: #1073121) Note: this is a build dependency of newer dap-mode versions. Regards, -- Xiyue Deng
Bug#1073121: ITP: emacs-lsp-docker -- LSP Docker integration for lsp-mode
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-lsp-docker Version : 0.0~git20240507.16a0cfb-1 Upstream Author : Ivan Yonchovski * URL or Web page : https://github.com/emacs-lsp/lsp-docker * License : GPL-3+ Programming lang: Emacs Lisp Description : LSP Docker integration for lsp-mode lsp-mode uses lsp-docker to run language servers in containers This is a build dependency of dap-mode. I plan to maintain this within the Debian Emacsen Team .
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Xiyue Deng writes: > Nicholas D Steeves writes: > >>>* Update debian copyright year in d/copyright >> >> -Copyright: 2015-2017 David Bremner >> +Copyright: 2015-2024 David Bremner >> >> In terms of copyright, please explain your understanding of copyright >> what you're doing here. This is not a mere 's/17/24/' symbol >> manipulation. >> > > I was thinking about adding myself to copyright, but I remember one of > the early reviews I got (which I forgot from whom) suggested that adding > oneself to copyright list would require significant change to the > debian/ files so I didn't do it and instead extending the copyright year > coverage of the existing entry. Maybe in such case like this one, I > should go over the git history and add all people that had contributed > and also add myself to the list. Wdyt? > This is now implemented in [1]. PTAL. [1] https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/85029b71af13e8279930cea2645cb060857de4b4 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1069210: dh-elpa: Support nested directory in elpa installation
Xiyue Deng writes: > I made another change to dh-elpa enabling better back trace for > buttercup tests, so here is the refreshed patchset. TIA! Friendly ping for comments from David :) -- Xiyue Deng signature.asc Description: PGP signature
Bug#1021460: ITA: elpa-rust-mode -- Major Emacs mode for editing Rust source code
Control: reopen -1 Control: tags -1 pending Reopen and pending closing with latest prepared package. -- Xiyue Deng
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Hi Nicholas, Thanks for your review! Please see my replies inline below. Nicholas D Steeves writes: > Xiyue Deng writes: > > You're incorrect about: > >>* Drop unused override_dh_auto_test in d/rules (dh_elpa_test is in >> effect) > > override_dh_auto_test: > @echo Using dh_elpa_test to run tests instead of upstream Makefile > > Used to be useful, because the Makefile tests used to run as well as the > dh_elpa_test ones. Dh_elpa_test was also "in effect then"... > I believe dh_elpa_test disables dh_auto_test by default unless it is disabled in debian/elpa-test[1]. I think you did this change back in this commit[2] back in 2019. On the other hand, it looks like dh_auto_test was disabled by dh-elpa even earlier[3]. Maybe you were referring to even more back then? Anyway, would be good to figure this out. >>* Update debian copyright year in d/copyright > > -Copyright: 2015-2017 David Bremner > +Copyright: 2015-2024 David Bremner > > In terms of copyright, please explain your understanding of copyright > what you're doing here. This is not a mere 's/17/24/' symbol > manipulation. > I was thinking about adding myself to copyright, but I remember one of the early reviews I got (which I forgot from whom) suggested that adding oneself to copyright list would require significant change to the debian/ files so I didn't do it and instead extending the copyright year coverage of the existing entry. Maybe in such case like this one, I should go over the git history and add all people that had contributed and also add myself to the list. Wdyt? >> Note: this revision drops the dependency on markdown, which is important >> so that itself and all its reverse dependencies are free from >> bug#1063645 so that they are free from being removed from testing. > > This is premature. Also, does upstream skip functional tests if a > $PATH/markdown binary cannot be called? If this is the case then the > correct action is to configure a $PATH/compatible-markdown-replacement. > I checked by a simple grep in tests/markdown-test.el. I had a closer look just now and it looks like it will consider 3 commands, `markdown', `pandoc', `markdown_py', and use one that is available[4]. As we already depends on pandoc, it will use it instead of markdown. That said, it would be better if we use an alternative markdown implementation to replace the out-of-date markdown, so I have now used discount to replace markdown and reworked the Build-Depends list in the source stanza[5], as well as the Recommends list in binary stanza[6]. I have also compared the output with or without markdown and with discount: With markdown dependency: , | Ran 543 tests, 540 results as expected, 0 unexpected, 3 skipped (2024-06-11 04:04:39+, 1.465706 sec) | 1 expected failures | | 3 skipped results: | SKIPPED test-markdown-flyspell/check-word-p | SKIPPED test-markdown-flyspell/remove-overlay | SKIPPED test-markdown-flyspell/yaml-metadata ` Without markdown dependency: , | Ran 543 tests, 540 results as expected, 0 unexpected, 3 skipped (2024-06-11 03:56:33+, 1.504459 sec) | 1 expected failures | | 3 skipped results: | SKIPPED test-markdown-flyspell/check-word-p | SKIPPED test-markdown-flyspell/remove-overlay | SKIPPED test-markdown-flyspell/yaml-metadata ` With discount replacing markdown: , | Ran 543 tests, 540 results as expected, 0 unexpected, 3 skipped (2024-06-11 04:55:59+, 1.410098 sec) | 1 expected failures | | 3 skipped results: | SKIPPED test-markdown-flyspell/check-word-p | SKIPPED test-markdown-flyspell/remove-overlay | SKIPPED test-markdown-flyspell/yaml-metadata ` So regardless of dropping markdown or adding discount, the test behavior did not change. I think now with discount replacing markdown it is in a better state. Thanks, and PTAL. [1] https://salsa.debian.org/emacsen-team/dh-elpa/-/blob/master/dh_elpa#L44 [2] https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/d900ef55bb0ecfc91609355ad6dd4cad2a578f4d [3] https://salsa.debian.org/emacsen-team/dh-elpa/-/blob/master/elpa.pm?blame=1 [4] https://salsa.debian.org/emacsen-team/markdown-mode/-/blob/master/markdown-mode.el?ref_type=heads#L97 [5] https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/10deb2fb6c00fb83a96226fb0c7645af0672d676 [6] https://salsa.debian.org/emacsen-team/markdown-mode/-/commit/adfe33a78fac11877c32fe2f5c87284b0c1d6463 -- Xiyue Deng signature.asc Description: PGP signature
Bug#1072910: RFS: lsp-treemacs/0.5-1 -- treemacs integration for Emacs LSP
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "lsp-treemacs": * Package name : lsp-treemacs Version : 0.5-1 Upstream contact : Ivan Yonchovski * URL : https://github.com/emacs-lsp/lsp-treemacs * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/lsp-treemacs Section : editors The source builds the following binary packages: elpa-lsp-treemacs - treemacs integration for Emacs LSP To access further information about this package, please visit the following URL: https://mentors.debian.net/package/lsp-treemacs/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/l/lsp-treemacs/lsp-treemacs_0.5-1.dsc Changes since the last upload: lsp-treemacs (0.5-1) unstable; urgency=medium . * New upstream release * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Fix indentation of package description * Update Standards-Version to 4.7.0; no change needed * Remove constraints unnecessary since buster (oldstable) * Add Source and Upstream-Contact in d/copyright * Update section from lisp to editors * Remove Thomas from uploaders. Thanks for your work! (Closes: #1019016) * Add myself to uploaders * Add myself to copyright list of `debian/*' with current year Regards, -- Xiyue Deng
Bug#1072906: RFS: markdown-mode/2.6-2 [Team] -- mode for editing Markdown-formatted text files in GNU Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "markdown-mode": * Package name : markdown-mode Version : 2.6-2 Upstream contact : Jason Blevins * URL : https://jblevins.org/projects/markdown-mode/ * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/markdown-mode Section : lisp The source builds the following binary packages: elpa-markdown-mode - mode for editing Markdown-formatted text files in GNU Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/markdown-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/m/markdown-mode/markdown-mode_2.6-2.dsc Changes since the last upload: markdown-mode (2.6-2) unstable; urgency=medium . * Team upload * Fix ERT test by ensuring correct build directory in d/ert-helper.el * Drop patches disabling tests now that they all pass * Drop unused override_dh_auto_test in d/rules (dh_elpa_test is in effect) * Drop unnecessary Build-Depends on markdown * Update Standards-Version to 4.7.0; no change needed * Update debian copyright year in d/copyright Note: this revision drops the dependency on markdown, which is important so that itself and all its reverse dependencies are free from bug#1063645 so that they are free from being removed from testing. Regards, -- Xiyue Deng
Bug#1072787: elpa-debian-el: support filing RFS bugs
Package: elpa-debian-el Version: 37.12 Severity: wishlist It would be useful to support filing RFS bugs through debian-bug. Nowadays people mostly use mentors.d.n to host packages waiting for sponsors, which also provide an RFS template for filing such bugs, therefore the most straightforward way to support it is to take advantage of the `mailto' link generated on that page instead of using a custom built template which may become out-of-sync with the RFS template. I am experimenting an implementation and will push to team repo once proven to be stable. -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-debian-el depends on: ii bzip2 1.0.8-5+b1 ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 ii emacsen-common 3.0.5 ii reportbug 12.0.0 ii xz-utils5.4.1-0.2 ii zstd1.5.4+dfsg2-5 Versions of packages elpa-debian-el recommends: ii emacs 1:29.3+1-3~bpo12+1 ii emacs-gtk [emacs] 1:29.3+1-3~bpo12+1 ii wget 1.21.3-1+b2 elpa-debian-el suggests no packages. -- no debconf information
Bug#1072556: RFS: elpa-rust-mode/1.0.5+git20240520.d00d83d-1 [ITA] [RC] -- Major Emacs mode for editing Rust source code
Package: sponsorship-requests
Severity: important
Dear mentors,
I am looking for a sponsor for my package "elpa-rust-mode":
* Package name : elpa-rust-mode
Version : 1.0.5+git20240520.d00d83d-1
Upstream contact : The Rust Project Developers
* URL : https://github.com/rust-lang/rust-mode
* License : Apache-2.0 or MIT
* Vcs : https://salsa.debian.org/emacsen-team/rust-mode
Section : editors
The source builds the following binary packages:
elpa-rust-mode - Major Emacs mode for editing Rust source code
To access further information about this package, please visit the following
URL:
https://mentors.debian.net/package/elpa-rust-mode/
Alternatively, you can download the package with 'dget' using this command:
dget -x
https://mentors.debian.net/debian/pool/main/e/elpa-rust-mode/elpa-rust-mode_1.0.5+git20240520.d00d83d-1.dsc
Changes since the last upload:
elpa-rust-mode (1.0.5+git20240520.d00d83d-1) unstable; urgency=medium
.
[ Nicholas D Steeves ]
* Drop emacs24 from Enhances (package does not exist in bullseye).
* Matthew Kraai has moved to Emeritus status; remove him from
Uploaders on his request.
.
[ Xiyue Deng ]
* Sync to latest upstream snapshot (d00d83d) (Closes: #1072555)
* Drop obsolete patches
* Skip upstream Makefile which relies on eask
* Drop obsolete override_dh_auto_test and refine override_dh_auto_clean
* Include all source files in d/elpa
* Migrate from compat to debhelper-compat version 13
* Drop unnecessary parameter "--parallel" with debhelper-compat 13
* Drop obsolete version requirements from dh-elpa and emacs
* Declare Standards-Version 4.7.0; no change needed
* Extend package description using upstream introduction
* Drop Built-Using from "Architecture: all" package
* Add myself as uploader (Closes: 1021460)
* Modernize d/watch with special substitute strings
* Rename license from Expat to MIT following upstream
* Use https in Format URL
* Update copyright years
* Add copyright information for debian/*
* Add Upstream-Contact
* Add d/upstream/metadata
* Add "Rules-Requires-Root: no" to source package
* Add ${elpa:Depends} to Depends of binary package
Regards,
--
Xiyue Deng
Bug#1072555: elpa-rust-mode: This is an obsolete snapshot of the packaging
Package: elpa-rust-mode Version: 1.0.5+git20240301.6d86af4-1 Severity: serious Dear Maintainer, This is a placeholder bug for the current version in unstable, which is now being obsoleted by a newer snapshot prepared on mentors[1]. [1] https://mentors.debian.net/package/elpa-rust-mode/ -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages elpa-rust-mode depends on: ii dh-elpa-helper 2.1.2~bpo12+0manphiz1 ii emacsen-common 3.0.5 Versions of packages elpa-rust-mode recommends: ii emacs 1:29.3+1-3~bpo12+1 ii emacs-gtk [emacs] 1:29.3+1-3~bpo12+1 elpa-rust-mode suggests no packages. -- no debconf information
Bug#1072554: RFS: emacs-dart-mode/1.0.7+git20240523.44beb62-2 -- Major mode for editing Dart files
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-dart-mode": * Package name : emacs-dart-mode Version : 1.0.7+git20240523.44beb62-2 Upstream contact : Jen-Chieh Shen * URL : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-dart-mode Section : editors The source builds the following binary packages: elpa-dart-mode - Major mode for editing Dart files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-dart-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-dart-mode/emacs-dart-mode_1.0.7+git20240523.44beb62-2.dsc Changes since the last upload: emacs-dart-mode (1.0.7+git20240523.44beb62-2) unstable; urgency=medium . * Source-only upload This is required for emacs-dart-mode to migrate to testing Regards, -- Xiyue Deng
Bug#1072553: RFS: emacs-corfu-terminal/0.7-2 -- Corfu popup on terminal
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-corfu-terminal": * Package name : emacs-corfu-terminal Version : 0.7-2 Upstream contact : Akib Azmain Turja * URL : https://codeberg.org/akib/emacs-corfu-terminal * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-corfu-terminal Section : editors The source builds the following binary packages: elpa-corfu-terminal - Corfu popup on terminal To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-corfu-terminal/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-corfu-terminal/emacs-corfu-terminal_0.7-2.dsc Changes since the last upload: emacs-corfu-terminal (0.7-2) unstable; urgency=medium . * Source-only upload This is required for it to migrate to testing. Regards, -- Xiyue Deng
Bug#1072552: RFS: clojure-mode/5.19.0-1 -- extra font-locking for clojure-mode
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "clojure-mode": * Package name : clojure-mode Version : 5.19.0-1 Upstream contact : Bozhidar Batsov * URL : https://github.com/clojure-emacs/clojure-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/clojure-mode Section : lisp The source builds the following binary packages: elpa-clojure-mode - Emacs major mode for Clojure code elpa-clojure-mode-extra-font-locking - extra font-locking for clojure-mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/clojure-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/c/clojure-mode/clojure-mode_5.19.0-1.dsc Changes since the last upload: clojure-mode (5.19.0-1) unstable; urgency=medium . * New upstream release * Add d/salsa-ci.yml with default settings * Stop using single-debian-patch to be compatible with dgit * Update Standards-Version to 4.7.0; no change needed * Keep testing files * Add patch to drop code for detecting clojure-mode source directory - This fixes autopkgtest stucking * Reinstate dh_elpa_test now that autopkgtest is fixed * Update debian copyright year in d/copyright * Add `Rules-Requires-Rules: no' in d/control Regards, -- Xiyue Deng
Bug#1072384: RFS: emacs-dart-mode/1.0.7+git20240523.44beb62-1 [ITP] -- Major mode for editing Dart files
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-dart-mode": * Package name : emacs-dart-mode Version : 1.0.7+git20240523.44beb62-1 Upstream contact : Jen-Chieh Shen * URL : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-dart-mode Section : editors The source builds the following binary packages: elpa-dart-mode - Major mode for editing Dart files To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-dart-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-dart-mode/emacs-dart-mode_1.0.7+git20240523.44beb62-1.dsc Changes for the initial release: emacs-dart-mode (1.0.7+git20240523.44beb62-1) unstable; urgency=medium . * Initial release (Closes: #1071708) Regards, -- Xiyue Deng
Bug#1072324: RFS: emacs-lsp-ui/9.0.0-1 -- UI modules for lsp-mode
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-lsp-ui": * Package name : emacs-lsp-ui Version : 9.0.0-1 Upstream contact : [fill in name and email of upstream] * URL : https://github.com/emacs-lsp/lsp-ui * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-lsp-ui Section : lisp The source builds the following binary packages: elpa-lsp-ui - UI modules for lsp-mode To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-lsp-ui/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-lsp-ui/emacs-lsp-ui_9.0.0-1.dsc Changes since the last upload: emacs-lsp-ui (9.0.0-1) unstable; urgency=medium . [ Debian Janitor ] * Remove constraints unnecessary since buster * Remove MIA uploaders. Thanks Thomas Koch for your maintenance (Closes: #1019024) * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.6.1, no changes needed * Set upstream metadata fields: Repository * Update standards version to 4.6.2, no changes needed . [ Xiyue Deng ] * New upstream version * Update Standards-Version to 4.7.0; no change needed * Disable pristine-tar in d/gbp.conf to match the current practice * Add myself to uploaders * Add elpa-lsp-mode and elpa-flycheck to build-depends in d/control as required by tests * Enable ERT tests * Keep testing files to fix autopkgtest * Add d/salsa-ci.yml with default settings * Refresh patches * Add patches to fix tests - Properly provide and require test-helper - Fix lsp-ui-doc--make-smaller-empty-lines - Disable tests using rustic * Update metadata for patches - Add upstream bug and forwarded status Regards, -- Xiyue Deng
Bug#1072279: RFS: treemacs/3.1-1 [Team] -- tree layout file explorer for Emacs - projectile support
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "treemacs": * Package name : treemacs Version : 3.1-1 Upstream contact : Alexander Miller * URL : https://github.com/Alexander-Miller/treemacs * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/treemacs Section : editors The source builds the following binary packages: elpa-treemacs - tree layout file explorer for Emacs elpa-treemacs-evil - tree layout file explorer for Emacs - evil support elpa-treemacs-magit - tree layout file explorer for Emacs - magit support elpa-treemacs-projectile - tree layout file explorer for Emacs - projectile support To access further information about this package, please visit the following URL: https://mentors.debian.net/package/treemacs/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/t/treemacs/treemacs_3.1-1.dsc Changes since the last upload: treemacs (3.1-1) unstable; urgency=medium . * Team upload * New upstream release * Update patches with new version and mark forwarded as not-needed * Set upstream metadata fields: Bug-Database, Bug-Submit, Repository-Browse * Update standards version to 4.7.0; no changes needed * Update description of extensions to clarify which supports are added * Update debian copyright year in d/copyright * Add lintian-overrides for elpa-treemacs * Add d/salsa-ci.yml with default settings * Disable pristine-tar by default in d/gbp.conf Regards, -- Xiyue Deng
Bug#1072267: RFS: emacs-corfu-terminal/0.7-1 [ITP] -- Corfu popup on terminal
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "emacs-corfu-terminal": * Package name : emacs-corfu-terminal Version : 0.7-1 Upstream contact : Akib Azmain Turja * URL : https://codeberg.org/akib/emacs-corfu-terminal * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-corfu-terminal Section : editors The source builds the following binary packages: elpa-corfu-terminal - Corfu popup on terminal To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-corfu-terminal/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-corfu-terminal/emacs-corfu-terminal_0.7-1.dsc Changes for the initial release: emacs-corfu-terminal (0.7-1) unstable; urgency=medium . * Initial release (Closes: #1068440). Regards, -- Xiyue Deng
Bug#1072266: RFS: emacs-cfrs/1.6.0-2 -- Child-frame based read-string for Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-cfrs": * Package name : emacs-cfrs Version : 1.6.0-2 Upstream contact : Alexander Miller * URL : https://github.com/Alexander-Miller/cfrs * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-cfrs Section : editors The source builds the following binary packages: elpa-cfrs - Child-frame based read-string for Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-cfrs/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-cfrs/emacs-cfrs_1.6.0-2.dsc Changes since the last upload: emacs-cfrs (1.6.0-2) unstable; urgency=medium . * Add d/salsa-ci.yml with default settings This is also required as a source-only upload for migrating to testing. Regards, -- Xiyue Deng
Bug#1072265: RFS: emacs-popon/0.13-2 -- Pop floating text on an Emacs window
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-popon": * Package name : emacs-popon Version : 0.13-2 Upstream contact : Akib Azmain Turja * URL : https://codeberg.org/akib/emacs-popon * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-popon Section : editors The source builds the following binary packages: elpa-popon - Pop floating text on an Emacs window To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-popon/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-popon/emacs-popon_0.13-2.dsc Changes since the last upload: emacs-popon (0.13-2) unstable; urgency=medium . * Add d/salsa-ci.yml with default settings This is also required as a source-only upload for migrating to testing. Regards, -- Xiyue Deng
Bug#1072263: RFS: activities-el/0.7-2 -- Save/restore sets of windows, tabs/frames, and their buffers in Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "activities-el": * Package name : activities-el Version : 0.7-2 Upstream contact : Adam Porter * URL : https://github.com/alphapapa/activities.el * License : GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/activities-el Section : editors The source builds the following binary packages: elpa-activities - Save/restore sets of windows, tabs/frames, and their buffers in Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/activities-el/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/a/activities-el/activities-el_0.7-2.dsc Changes since the last upload: activities-el (0.7-2) unstable; urgency=medium . * Add d/salsa-ci.yml with default settings This is also required as a source-only upload for migrating to testing. Regards, -- Xiyue Deng
Bug#1072262: RFS: emacs-bazel-mode/0.0~git20230919.769b30d-2 -- Bazel support for GNU Emacs
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-bazel-mode": * Package name : emacs-bazel-mode Version : 0.0~git20230919.769b30d-2 Upstream contact : Google LLC * URL : https://github.com/bazelbuild/emacs-bazel-mode * License : Apache-2.0 * Vcs : https://salsa.debian.org/emacsen-team/emacs-bazel-mode Section : editors The source builds the following binary packages: elpa-bazel-mode - Bazel support for GNU Emacs To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-bazel-mode/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-bazel-mode/emacs-bazel-mode_0.0~git20230919.769b30d-2.dsc Changes since the last upload: emacs-bazel-mode (0.0~git20230919.769b30d-2) unstable; urgency=medium . * Remove upstream-tag in d/gbp.conf for better detection * Add d/salsa-ci.yml using default settings * Add git to Build-Depends required by Salsa CI This is also required as a source-only upload so as to help migrating to testing. Regards, -- Xiyue Deng
Bug#1072223: RFS: rtags/2.38-11 [RC] -- C/C++ client/server indexer with integration for Emacs
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "rtags": * Package name : rtags Version : 2.38-11 Upstream contact : Anders Bakken * URL : https://github.com/Andersbakken/rtags * License : BSD-4-Clause, Expat, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/rtags Section : devel The source builds the following binary packages: rtags - C/C++ client/server indexer with integration for Emacs elpa-rtags - emacs front-end for RTags elpa-company-rtags - company back-end for RTags elpa-flycheck-rtags - flycheck integration for RTags elpa-ac-rtags - auto-complete back-end for RTags elpa-ivy-rtags - ivy back-end for RTags elpa-helm-rtags - helm interface for RTags To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rtags/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rtags/rtags_2.38-11.dsc Changes since the last upload: rtags (2.38-11) unstable; urgency=medium . * Add missing dependency of emacs to d/tests/control (Closes: #1072201) * Add Upstream-Contact in d/copyright * Update debian copyright year in d/copyright Regards, -- Xiyue Deng
Bug#1072201: rtags: autopkgtest failure due to missing depends on emacs
Control: tags -1 patch pending Xiyue Deng writes: > Package: rtags > Version: 2.38-10 > Severity: serious > > Dear Maintainer, > > rtags is now failing autopkgtest due to missing dependency on emacs. > See the autopkgtest regression test from flycheck[1]. It used to work > because it pulls in emacs through the dependency of flycheck. The > recent upload of flycheck 34.1-1 has downgraded this dependency to > recommends (by me, actually) which triggered this failure. As this is > causing build failure on rebuild, I'm using the serious severity. > > I'll prepare a fix patch/MR soon. > > [1] https://ci.debian.net/packages/r/rtags/testing/amd64/47083927/ > > -- System Information: > Debian Release: 12.5 > APT prefers stable-updates > APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, > 'stable') > Architecture: amd64 (x86_64) > > Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled As I have team repo access, I have pushed the fix[1] and it has passed autopkgtest on Salsa CI[2]. [1] https://salsa.debian.org/emacsen-team/rtags/-/commit/af72d9a977846760ce7b21de36955e4083a34a68 [2] https://salsa.debian.org/emacsen-team/rtags/-/jobs/5789916 -- Xiyue Deng
Bug#1072201: rtags: autopkgtest failure due to missing depends on emacs
Package: rtags Version: 2.38-10 Severity: serious Dear Maintainer, rtags is now failing autopkgtest due to missing dependency on emacs. See the autopkgtest regression test from flycheck[1]. It used to work because it pulls in emacs through the dependency of flycheck. The recent upload of flycheck 34.1-1 has downgraded this dependency to recommends (by me, actually) which triggered this failure. As this is causing build failure on rebuild, I'm using the serious severity. I'll prepare a fix patch/MR soon. [1] https://ci.debian.net/packages/r/rtags/testing/amd64/47083927/ -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1068186: mozc: FTBFS with abseil 20230802: ../../base/init_mozc.cc:90:29: error: ‘absl::debian5::flags_internal::ArgvListAction’ has not been declared
Hi,
I have tested the patches from Hayashi-san to be working. It would be
great to have this applied to fix mozc (which has since been removed
from testing due to this bug.)
As an attempt to help, I took the liberty to incorporate Hayashi-san's
patches and provided the compiled packages on mentors[1], as well as
created a merge request on salsa[2] (I have also attached the patch set
in case people prefer these for reviewing.) I haven't filed an RFS bug
for the packages on mentors yet, but let me know if that's a good idea.
According the Salsa CI pipeline[3], the building went fine. There are 2
failed tests: blhc fails due to missing suggested building/linking
flags, piuparts fails because the current version (-2.2) fails to
install due to the fact that it is still depending on the previous
version of abseil which is no longer available in testing. (Also, the
crossbuild test has been marked as expected to fail.) So I hope the
Salsa-CI pipeline results show that the NMU package in a good-enough
shape.
I am adding Gunnar who previously provided NMU of this package as well
as the maintainer hoping them to review and sponsor my NMU attempt.
(Also CCed Kentaro Hayashi as FYI.)
[1] https://mentors.debian.net/package/mozc/
[2] https://salsa.debian.org/debian/mozc/-/merge_requests/10
[3] https://salsa.debian.org/manphiz/mozc/-/pipelines/683514
--
Xiyue Deng
>From 7c83a80bb31420e76ae96746a8192673988f8a7e Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Tue, 28 May 2024 02:39:45 -0700
Subject: [PATCH 1/3] Apply patches by Kentaro HAYASHI to fix FTBFS with latest
abseil (Closes: #1068186)
---
...-error-of-ParseCommandLineFlags-with.patch | 34 +
...Fix-missing-abseil-gyp-link-settings.patch | 38 +++
debian/patches/series | 2 +
3 files changed, 74 insertions(+)
create mode 100644 debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch
create mode 100644 debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch
diff --git a/debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch b/debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch
new file mode 100644
index 0..361fa959f
--- /dev/null
+++ b/debian/patches/0010-Fix-the-compile-error-of-ParseCommandLineFlags-with.patch
@@ -0,0 +1,34 @@
+From: Kentaro Hayashi
+Date: Fri, 17 May 2024 18:21:29 +0900
+Subject: Fix the compile error of ParseCommandLineFlags with Abseil LTS
+ 20230802.
+
+Origin: https://github.com/google/mozc/commit/cad4064c8884eb711e0e19b4b79d2ff5610823dc
+Description: Fix the compile error of ParseCommandLineFlags with Abseil LTS 20230802.
+ * Added the check of the Abseil version to the arguments of ParseCommandLineImpl.
+ * https://github.com/google/mozc/issues/790
+ #codehealth
+ PiperOrigin-RevId: 561867167
+Author: Hiroyuki Komatsu
+
+Released in 2.29.5374.102
+
+Signed-off-by: Kentaro Hayashi
+---
+ src/base/init_mozc.cc | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/src/base/init_mozc.cc b/src/base/init_mozc.cc
+index eee8b62..5e5b558 100644
+--- a/src/base/init_mozc.cc
b/src/base/init_mozc.cc
+@@ -87,7 +87,9 @@ std::string GetLogFilePathFromProgramName(const std::string &program_name) {
+ void ParseCommandLineFlags(int argc, char **argv) {
+ absl::flags_internal::ParseCommandLineImpl(
+ argc, argv,
++#if defined(ABSL_LTS_RELEASE_VERSION) && ABSL_LTS_RELEASE_VERSION < 20230802
+ absl::flags_internal::ArgvListAction::kRemoveParsedArgs,
++#endif // ABSL_LTS_RELEASE_VERSION < 20230802
+ // Suppress help messages invoked by --help and others.
+ // Use UsageFlagsAction::kHandleUsage to enable it.
+ absl::flags_internal::UsageFlagsAction::kIgnoreUsage,
diff --git a/debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch b/debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch
new file mode 100644
index 0..9eba7f14d
--- /dev/null
+++ b/debian/patches/0011-Fix-missing-abseil-gyp-link-settings.patch
@@ -0,0 +1,38 @@
+From: Kentaro Hayashi
+Date: Sat, 18 May 2024 17:05:16 +0900
+Subject: Fix missing abseil libraries
+
+It fixes the following error:
+
+ /usr/bin/ld: obj/base/base_core.file_util.o: undefined reference to
+ symbol '_ZN4absl7debian5lsERSoNS0_11string_viewE'
+ /usr/bin/ld:
+ /lib/x86_64-linux-gnu/libabsl_string_view.so.20230802: error adding
+ symbols: DSO missing from command line
+
+ /usr/bin/ld: obj/unix/emacs/mozc_emacs_helper_lib.client_pool.o:
+ undefined reference to symbol
+ '_ZN4absl7debian516raw_log_internal21internal_log_functionB5cxx11E'
+ /usr/bin/ld:
+ /lib/x86_64-linux-gnu/libabsl_raw_logging_internal.so.20230802: error
+ adding symbols: DSO missing from command line collect2: error: ld
+ returned 1 exit status
+
+Signed-off-by: Kentaro Hayashi
+---
+ src/base/absl.gyp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+d
Bug#1072044: RFS: emacs-libvterm/0.0.2+git20240520.df057b1-1 -- fully-fledged terminal emulator inside GNU Emacs based on libvterm - module
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "emacs-libvterm": * Package name : emacs-libvterm Version : 0.0.2+git20240520.df057b1-1 Upstream contact : Lukas Fürmetz * URL : https://github.com/akermu/emacs-libvterm * License : GPL-3, GPL-2+, GPL-3+ * Vcs : https://salsa.debian.org/emacsen-team/emacs-libvterm Section : editors The source builds the following binary packages: emacs-libvterm - fully-fledged terminal emulator inside GNU Emacs based on libvterm - module elpa-vterm - fully-fledged terminal emulator inside GNU Emacs based on libvterm - elisp To access further information about this package, please visit the following URL: https://mentors.debian.net/package/emacs-libvterm/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/e/emacs-libvterm/emacs-libvterm_0.0.2+git20240520.df057b1-1.dsc Changes since the last upload: emacs-libvterm (0.0.2+git20240520.df057b1-1) unstable; urgency=medium . * New upstream snapshot * Add myself to Uploaders as permitted by Martin * Update Standards-Version to 4.7.0; no change needed * Use posix export in d/rules * Add Upstream-Name in d/copyright * Update copyright year for debian/* in d/copyright * Refresh patches using gbp pq Regards, -- Xiyue Deng
Bug#1068477: RFS: emacs-corfu/1.4-1 [Team] -- Completion Overlay Region FUnction in Emacs
Control: retitle -1 RFS: emacs-corfu/1.4-1 [Team] -- Completion Overlay Region FUnction in Emacs A new upstream release 1.4 is available. I have updated the packaging on team repo[1] and mentors[2]. PTAL. [1] https://salsa.debian.org/emacsen-team/emacs-corfu [2] https://mentors.debian.net/package/emacs-corfu/ -- Xiyue Deng
Bug#1071719: python3-sphinx: produces non-deterministic searchindex.js which breaks reproducibility tests
Package: python3-sphinx Version: 7.2.6-7 Severity: normal Dear Maintainer, The current latest python3-sphinx version () may still produce non-deterministic searchindex.js file which breaks reproducibility tests. See attached for a diffoscope result of the diff between two built flycheck-doc. This issue has been reported upstream[1] and has since been fixed[2]. Please consider packaging a newer version or backport the patch. TIA! [1] https://github.com/sphinx-doc/sphinx/issues/11622 [2] https://github.com/sphinx-doc/sphinx/pull/11665 -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-21-amd64 (SMP w/16 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libjs-sphinxdoc depends on: ii libjs-jquery 3.6.1+dfsg+~3.5.14-1 ii libjs-underscore 1.13.4~dfsg+~1.11.4-3 libjs-sphinxdoc recommends no packages. libjs-sphinxdoc suggests no packages. -- no debconf information ||0% ETA: --:--:-- ||0% control.tar.xz ETA: --:--:-- ||0% /control ETA: --:--:-- ||0% /md5sums ETA: --:--:-- ||0% ETA: --:--:-- ||0% ETA: --:--:-- ||0%data.tar.xz ETA: --:--:-- ||0% /usr/ ETA: --:--:-- ||0%/usr/share/ ETA: --:--:-- ||0%/usr/share/doc/ ETA: --:--:-- ||0% …share/doc/elpa-flycheck/ ETA: --:--:-- ||0% …/doc/elpa-flycheck/html/ ETA: --:--:-- ||0% …a-flycheck/html/_images/ ETA: --:--:-- ||0% …s/flycheck-annotated.png ETA: --:--:-- ||0% …/flycheck-error-list.png ETA: --:--:-- ||0% …ycheck-error-reports.png ETA: --:--:-- ||0% …images/flycheck-menu.png ETA: --:--:-- ||0% …check-mode-line-menu.png ETA: --:--:-- ||0% …ycheck-verify-buffer.png ETA: --:--:-- ||0% …-flycheck/html/_sources/ ETA: --:--:-- ||0% …_sources/changes.rst.txt ETA: --:--:-- ||0% …html/_sources/community/ ETA: --:--:-- ||0% …ommunity/conduct.rst.txt ETA: --:--:-- ||0% …unity/extensions.rst.txt ETA: --:--:-- ||0% …mmunity/get-help.rst.txt ETA: --:--:-- ||0% …community/people.rst.txt ETA: --:--:-- ||0% …ml/_sources/contributor/ ETA: --:--:-- ||0% …tor/contributing.rst.txt ETA: --:--:-- ||0% …utor/maintaining.rst.txt ETA: --:--:-- ||0% …utor/style-guide.rst.txt ETA: --:--:-- ||0% …html/_sources/developer/ ETA: --:--:-- ||0% …loper/developing.rst.txt ETA: --:--:-- ||0% …sources/glossary.rst.txt ETA: --:--:-- ||0% …l/_sources/index.rst.txt ETA: --:--:-- ||0% …ources/languages.rst.txt ETA: --:--:-- ||0% …sources/licenses.rst.txt ETA: --:--:-- ||0% …heck/html/_sources/user/ ETA: --:--:-- ||0% …rror-interaction.rst.txt ETA: --:--:-- ||0% …/user/error-list.rst.txt ETA: --:--:-- ||0% …er/error-reports.rst.txt ETA: --:--:-- ||0% …k-versus-flymake.rst.txt ETA: --:--:-- ||0% …ser/installation.rst.txt ETA: --:--:-- ||0% …/user/quickstart.rst.txt ETA: --:--:-- ||0% …/syntax-checkers.rst.txt ETA: --:--:-- ||0% …er/syntax-checks.rst.txt ETA: --:--:-- ||0% …/troubleshooting.rst.txt ETA: --:--:-- ||0% …a-flycheck/html/_static/ ETA: --:--:-- ||0% …ml/_static/alabaster.css ETA: --:--:-- ||0% …k/html/_static/basic.css ETA: --:--:-- ||0% …/html/_static/custom.css ETA: --:--:-- ||0% …documentation_options.js ETA: --:--:-- ||0% …l/_static/favicon.ico.gz ETA: --:--:-- ||0% …html/_static/favicon.png ETA: --:--:-- ||0% …ck/html/_static/file.png ETA: --:--:-- ||0% …ight_darkblue_121621.png ETA: --:--:-- ||0% …ck/html/_static/logo.png ETA: --:--:-- ||0% …k/html/_static/minus.png ETA: --:--:-- ||0% …ck/html/_static/plus.png ETA: --:--:-- ||0% …tml/_static/pygments.css ETA: --:--:-- ||0% …ycheck/html/changes.html ETA: --:--:-- ||0% …flycheck/html/community/ ETA: --:--:-- ||0% …l/community/conduct.html ETA: --:--:-- ||0% …ommunity/extensions.html ETA: --:--:-- ||0% …/community/get-help.html ETA: --:--:-- ||0% …ml/community/people.html ETA: --:--:-- ||0% …ycheck/html/contributor/ ETA: --:--:-- ||0% …ibutor/contributing.html ETA: --:--:-- ||0% …ributor/maintaining.html ETA: --:--:-- ||0% …ributor/style-guide.html ETA: --:--:-- ||0% …flycheck/html/developer/ ETA: --:--:--
Bug#1071708: ITP: emacs-dart-mode -- An Emacs major mode for editing Dart files
Package: wnpp Severity: wishlist Owner: Xiyue Deng * Package name: emacs-dart-mode Version : 1.0.7+git20240507.ef6cc89 Upstream Author : Google Inc., Brady Trainor * URL or Web page : https://github.com/emacsorphanage/dart-mode * License : GPL-3+ Programming lang: Emacs Lisp Description : An Emacs major mode for editing Dart files This package implements a major-mode for the Dart language, providing basic syntax highlighting and indentation support. I plan to maintain this package within the Debian Emacsen Team .
Bug#1069210: dh-elpa: Support nested directory in elpa installation
I made another change to dh-elpa enabling better back trace for
buttercup tests, so here is the refreshed patchset. TIA!
--
Xiyue Deng
From cc40a88155029834673a944e1a822ff3b97613ca Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Mon, 20 May 2024 00:49:52 -0700
Subject: [PATCH 1/4] Don't recursively add elpa path to match package.el
behavior
* Add .nosearch to `/usr/share/emacs/site-lisp/elpa{,-src}' using
triggers in dh-elpa, which will disable subdirs.el from processing
those directories.
---
debian/dh-elpa.postinst | 35 +++
debian/dh-elpa.triggers | 2 ++
2 files changed, 37 insertions(+)
create mode 100644 debian/dh-elpa.postinst
create mode 100644 debian/dh-elpa.triggers
diff --git a/debian/dh-elpa.postinst b/debian/dh-elpa.postinst
new file mode 100644
index 000..7f2e52d
--- /dev/null
+++ b/debian/dh-elpa.postinst
@@ -0,0 +1,35 @@
+#!/bin/sh
+
+set -e
+
+ensure_nosearch_in_elpa_directories() {
+# Currently there is subdirs.el in `/usr/share/emacs/site-lisp' which causes
+# all subdirectories to be added to `load-path' including elpa installation
+# directories. This differs from how package.el handles ELPA packages which
+# only adds the installation root directory. Here we add `.nosearch' to
+# elpa directories to let subdirs.el skip them to follow the package.el
+# behavior.
+SITE_LISP_DIR=/usr/share/emacs/site-lisp
+ELPA_SRC_NOSEARCH=${SITE_LISP_DIR}/elpa-src/.nosearch
+ELPA_NOSEARCH=${SITE_LISP_DIR}/elpa/.nosearch
+[ -f ${ELPA_SRC_NOSEARCH} ] || touch ${ELPA_SRC_NOSEARCH}
+[ -f ${ELPA_NOSEARCH} ] || touch ${ELPA_NOSEARCH}
+}
+
+case "$1" in
+configure)
+;;
+
+triggered)
+ensure_nosearch_in_elpa_directories
+;;
+
+*)
+echo "postinit called with argument \`$1' which is ignored." >&2
+exit 1
+;;
+esac
+
+#DEBHELPER#
+
+exit 0
diff --git a/debian/dh-elpa.triggers b/debian/dh-elpa.triggers
new file mode 100644
index 000..ef84cb6
--- /dev/null
+++ b/debian/dh-elpa.triggers
@@ -0,0 +1,2 @@
+interest /usr/share/emacs/site-lisp/elpa-src
+interest /usr/share/emacs/site-lisp/elpa
--
2.39.2
From 111a07a86a3aa163d6e4da51c3e6389516f2b985 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Mon, 15 Apr 2024 13:03:16 -0700
Subject: [PATCH 2/4] Byte compile recursively during install to handle nested
directories
* This handles addons that have source files under nested directories
in ELPA install directories.
---
helper/install | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/helper/install b/helper/install
index 39db695..eb68ef5 100755
--- a/helper/install
+++ b/helper/install
@@ -58,7 +58,8 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}"
${FLAVOR} --quick --batch -l package \
--eval "(setq package-user-dir \"/nonexistent\")" \
--eval "(add-to-list 'package-directory-list \"$src_dir\")" \
- -f package-initialize -f batch-byte-compile ./*.el > Install.log 2>&1
+ -f package-initialize \
+ --eval "(byte-recompile-directory \".\" 0)" > Install.log 2>&1
if test $? -ne 0
then
cat Install.log
--
2.39.2
From 795c82f5c80fc5665905d3763163bef03e8854ca Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Wed, 17 Apr 2024 14:06:42 -0700
Subject: [PATCH 3/4] Create symlink from elpa-src to elpa recursively
* Instead of using `ln -s', use `cp -rs' so that directories are
handled recursively.
* In remove we use `rmdir --ignore-fail-on-non-empty' so this was
handled automatically as well.
---
helper/install | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/helper/install b/helper/install
index eb68ef5..8d748c8 100755
--- a/helper/install
+++ b/helper/install
@@ -50,7 +50,7 @@ echo "install/${ELPA_DIR}: byte-compiling for ${FLAVOR}"
# policy). This makes complation easy, and also allows find-function
# and find-library to work properly. Also link all other top level
# files and directories into the flavor directory
-(cd "${elc_dir}" && ln -sf "${el_dir}"* .)
+(cd "${elc_dir}" && cp -rsf "${el_dir}"* .)
# Byte compile them
(cd "${elc_dir}"
--
2.39.2
From 374983204ec273c557306821bfce0cbfb0950722 Mon Sep 17 00:00:00 2001
From: Xiyue Deng
Date: Wed, 17 Apr 2024 14:17:41 -0700
Subject: [PATCH 4/4] Update d/changelog
---
debian/changelog | 6 ++
1 file changed, 6 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index be10246..e385f81 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -9,6 +9,12 @@ dh-elpa (2.1.2) UNRELEASED; urgency=medium
* dh_elpa_test: Don't rename files under test/, tests/ (Closes:
#1069326).
* Use `pretty' stack frame style in buttercup for
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/cha
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
