Dear Emacsen Maintainers,
It looks like a few Emacsen packages are marked as testing auto-removal
due to bug#999962[1]. It looks like this pcre to pcre2 migration is non-trivial, and the upstream of silversearcher-ag[2] seems to be silent since Dec. 2020. The list of affected packages are in [3]. As most of
them have silversearcher-ag as an optional dependency, should it be considered to drop silversearcher-ag support for now and wait for the
fixes or alternatives to be available before re-enabling the support?
Manphiz <manphiz@gmail.com> writes:
Dear Emacsen Maintainers,
It looks like a few Emacsen packages are marked as testing auto-removal
due to bug#999962[1]. It looks like this pcre to pcre2 migration is
non-trivial, and the upstream of silversearcher-ag[2] seems to be silent
since Dec. 2020. The list of affected packages are in [3]. As most of
them have silversearcher-ag as an optional dependency, should it be
considered to drop silversearcher-ag support for now and wait for the
fixes or alternatives to be available before re-enabling the support?
I'm not a silversearch-ag user, but your suggestion makes sense to me.
d
I'm not a silversearch-ag user, but your suggestion makes sense to me.
d
Thanks David! I've prepared a merge request[1] on emacs-wgrep to
implement this idea. Would be great to have your reviews and comments.
If this is an acceptable direction to go forward I will do similar work
on other affect packages. Thanks!
[1] https://salsa.debian.org/emacsen-team/emacs-wgrep/-/merge_requests/1
Manphiz <manphiz@gmail.com> writes:l wgrep-test.el --eval \(ert-run-tests-batch-and-exit\)
I'm not a silversearch-ag user, but your suggestion makes sense to me.
d
Thanks David! I've prepared a merge request[1] on emacs-wgrep to
implement this idea. Would be great to have your reviews and comments.
If this is an acceptable direction to go forward I will do similar work
on other affect packages. Thanks!
[1] https://salsa.debian.org/emacsen-team/emacs-wgrep/-/merge_requests/1
To be fair, the following issue wasn't introduced by this MR, but was
this MR tested? I got:
…
Ignoring upstream Makefile and building/installing with dh-elpa.
make[1]: Leaving directory '/<<PKGBUILDDIR>>'
dh_elpa_test
emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -l wgrep-subtest.el -
Error: error ("Test ‘wgrep-normal’ redefined")concat "grep -nH -e FOO -C 1 " file)) (wgrep-change-to-wgrep-mode) (goto-char (point-min)) (let* ((fn-122 #'re-search-forward) (args-123 (condition-case err (let ((signal-hook-function #'ert--should-signal-hook)) (list "^grep" nil t)) (error (progn (setq
mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode 0x1381f8c5ebae87c2>))
debug-early-backtrace()
debug-early(error (error "Test ‘wgrep-normal’ redefined"))
error("Test `%s' redefined" wgrep-normal)
ert-set-test(wgrep-normal #s(ert-test :name wgrep-normal :documentation nil :body (lambda nil (let ((wgrep-change-readonly-file nil) (wgrep-auto-save-buffer nil)) (progn (wgrep-test-fixture "HOGE\nFOO\nBAZ\n" #'(lambda (file) (wgrep-test--grep (
) (if (eql value-141 'ert-form-evaluation-aborted-142) nil (let* ((-explainer- (and t (ert--get-explainer 're-search-forward)))) (if -explainer- (list :explanation (apply -explainer- args-140)) nil))))) (ert--signal-should-execution form-description-143)) nil (ert-fail form-description-143))) value-141)) (replace-match "FOO2") (goto-char (point-max)) (let* ((fn-144 #'delete-char) (args-145 (condition-case err (let ((signal-hook-function #'ert--should-signal-hook)) (list -1)) (error (progn (setq fn-
load-with-code-conversion("/<<PKGBUILDDIR>>/wgrep-test.el" "/<<PKGBUILDDIR>>/wgrep-test.el" nil t)wgrep-subtest.el" "-l" "wgrep-test.el" "--eval" "(ert-run-tests-batch-and-exit)"))
command-line-1(("-l" "package" "--eval" "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" "--eval" "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" "-f" "package-initialize" "-L" "." "-l" "
command-line()wgrep-subtest.el -l wgrep-test.el --eval \(ert-run-tests-batch-and-exit\) returned exit code 255
normal-top-level()
dh_elpa_test: error: emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -l
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
I think that's unrelated to silversearcher-ag though ;)
Meanwhile (non Emacs), if you want to fix all packages in the archive
that depend on silversearcher-ag, in one shot:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999962#18
BTW, are you subscribed to this mailing list? In Debian we
conventionally don't CC people on mailing lists, even though we do CC
people on bugs.
Regards,
Nicholas
Nicholas D Steeves <sten@debian.org> writes:[snip]
Manphiz <manphiz@gmail.com> writes:
To be fair, the following issue wasn't introduced by this MR, but was
wgrep-subtest.el -l wgrep-test.el --eval \(ert-run-tests-batch-and-exit\) returned exit code 255dh_elpa_test: error: emacs -batch -Q -l package --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval "(add-to-list 'package-directory-list \"/usr/share/emacs/site-lisp/elpa-src\")" -f package-initialize -L . -l
make: *** [debian/rules:4: binary] Error 25
dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
I think that's unrelated to silversearcher-ag though ;)
I don't remember seeing this (or I missed it :P)
But as I mentioned somewhere (mailing list or IRC, I forgot) it's
probably easier just to fix siversearcher-ag directly. So I'll
retract this MR soon :)
It seems that the maintainer has been MIA. Do you suggest proposing an
NMU?
BTW, are you subscribed to this mailing list? In Debian we
conventionally don't CC people on mailing lists, even though we do CC
people on bugs.
I'm subscribed. Feel free to directly reply to the mailing list.
Manphiz <manphiz@gmail.com> writes:
[..snip..]
It seems that the maintainer has been MIA. Do you suggest proposing an
NMU?
Until a package has been orphaned by the MIA team, the question is NMU
vs salvaging:
https://wiki.debian.org/PackageSalvaging
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
If a minimal, targeted fix is possible (with a quilt patch) then an NMU
is faster, and doesn't implicate the uploader with long-term responsibilities. The allowed changes are narrow, and strict.
If that's not possible, then salvaging the package is the only way to
save it and its reverse dependencies. Salvaging implies adoption. I
took a look at the available forks and I suspect that salvaging the
Debian package is what will be required.
BTW, are you subscribed to this mailing list? In Debian we
conventionally don't CC people on mailing lists, even though we do CC
people on bugs.
I'm subscribed. Feel free to directly reply to the mailing list.
Thanks!
Nicholas
Nicholas D Steeves <nsteeves@gmail.com> writes:
Manphiz <manphiz@gmail.com> writes:
[..snip..]
It seems that the maintainer has been MIA. Do you suggest proposing an
NMU?
Until a package has been orphaned by the MIA team, the question is NMU
vs salvaging:
https://wiki.debian.org/PackageSalvaging
https://www.debian.org/doc/manuals/developers-reference/pkgs.en.html#package-salvaging
If a minimal, targeted fix is possible (with a quilt patch) then an NMU
is faster, and doesn't implicate the uploader with long-term
responsibilities. The allowed changes are narrow, and strict.
If that's not possible, then salvaging the package is the only way to
save it and its reverse dependencies. Salvaging implies adoption. I
took a look at the available forks and I suspect that salvaging the
Debian package is what will be required.
Added a note on the bug[1] mentioning an MR with cherrypicked/adapted a
patch set from upstream branch/fork that adds pcre2 support. Hopefully
an NMU can be considered.
BTW, are you subscribed to this mailing list? In Debian we
conventionally don't CC people on mailing lists, even though we do CC
people on bugs.
I'm subscribed. Feel free to directly reply to the mailing list.
Thanks!
Nicholas
Manphiz <manphiz@gmail.com> writes:
Manphiz <manphiz@gmail.com> writes:
Added a note on the bug[1] mentioning an MR with cherrypicked/adapted a
patch set from upstream branch/fork that adds pcre2 support. Hopefully
an NMU can be considered.
Seems I forgot about the link :P
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999962#23
Manphiz <manphiz@gmail.com> writes:
Manphiz <manphiz@gmail.com> writes:
Manphiz <manphiz@gmail.com> writes:
Added a note on the bug[1] mentioning an MR with cherrypicked/adapted a
patch set from upstream branch/fork that adds pcre2 support. Hopefully
an NMU can be considered.
Seems I forgot about the link :P
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=999962#23
Wow, that was fast! To be honest, I'd appreciate a second opinion about
if that meets the criteria for an NMU. To do this in the fastest way possible probably means consulting the general mentor & sponsor pool by filing an RFS.
https://mentors.debian.net/sponsors/
Did you check if enable_pcre2_support.patch looks like it might have
some new copyright statements that are not yet covered in
debian/copyright? Please note that I didn't check, but your sponsor
will expect that you have checked, and it would be best to check before filing an RFS
Nicholas D Steeves <sten@debian.org> writes:
Manphiz <manphiz@gmail.com> writes:
Did you check if enable_pcre2_support.patch looks like it might have
some new copyright statements that are not yet covered in
debian/copyright? Please note that I didn't check, but your sponsor
will expect that you have checked, and it would be best to check before
filing an RFS
This patch is merged from a patch set from a fork[1] of the upstream.
On the surface it doesn't look like it has a different copyright notice
so it should be of the same Apache 2.0 license. Still it may be better
for a license expert to take another look.
As for facts: It looks like the Debian maintainer of this package didn't document copyright and license for the m4 stuff (your sponsor might
require this), and your patch is not work by Geoff Greer, so you'll
probably need to add Greer to the copyright file.
Nicholas D Steeves <sten@debian.org> writes:
As for facts: It looks like the Debian maintainer of this package didn't
document copyright and license for the m4 stuff (your sponsor might
require this), and your patch is not work by Geoff Greer, so you'll
probably need to add Greer to the copyright file.
Gah, it looks like I wasn't paying close enough attention. "…so you'll probably need to add the copyright holder who is not Greer to the
copyright file"
Nicholas D Steeves <sten@debian.org> writes:
Nicholas D Steeves <sten@debian.org> writes:
As for facts: It looks like the Debian maintainer of this package didn't >>> document copyright and license for the m4 stuff (your sponsor might
require this), and your patch is not work by Geoff Greer, so you'll
probably need to add Greer to the copyright file.
Gah, it looks like I wasn't paying close enough attention. "…so you'll
probably need to add the copyright holder who is not Greer to the
copyright file"
Thanks Nicholas! I used licensecheck and checked manually and updated d/copyright accordingly in my merge request[1]. PTAL, thanks!
[1] https://salsa.debian.org/debian/silversearcher-ag/-/merge_requests/1
Sysop: | Keyop |
---|---|
Location: | Huddersfield, West Yorkshire, UK |
Users: | 300 |
Nodes: | 16 (2 / 14) |
Uptime: | 26:43:44 |
Calls: | 6,707 |
Calls today: | 1 |
Files: | 12,239 |
Messages: | 5,352,575 |