Bug#958955: Update package description wrt Puppet 3
Hi Moritz, Moritz Muehlenhoff writes: > On Tue, Apr 28, 2020 at 08:57:39PM -0400, Nicholas D Steeves wrote: >> Control: tag -1 upstream >> >> Hi Moritz, >> >> Moritz Muehlenhoff writes: >> >> > Source: puppet-mode >> > Version: 0.4-1 >> > Severity: minor >> > >> > The short description currently reads "major mode for Puppet 3 manifests >> > in Emacs", >> > which sounds as if the support were limited to older Puppet versions, let's >> > simply use "major mode for Puppet manifests in Emacs"? After all the mode >> > supports >> > keywords of the current 5.x releases just fine. >> > >> >> I'm not sure why the upstream description specifies "Puppet 3", but if I >> had to speculate it might be because 0.4 doesn't support all Puppet 5 >> keywords. Do you know if support for Puppet 5 manifests is complete in >> this version? > > https://github.com/voxpupuli/puppet-mode/pull/106 and > https://github.com/voxpupuli/puppet-mode/pull/107 added support for > Puppet type annotations and keywords from 5.3, so this seems complete. > > I've been using this mode with a Puppet repository based on 5.5.10 > (as shipped in Debian buster) and I haven't noticed any missing > keywords or syntax elements, so from my PoV this seems to support > Puppet 5 just fine. > >> At any rate, would you like to open an upstream issue, or would you >> prefer if I do so? > > Ack, I just did that at https://github.com/voxpupuli/puppet-mode/issues/124 > Sorry for the delay. Thanks for filing the issue, it's odd that they didn't properly fix their description, and I've fixed ours in git. Cheers, Nicholas signature.asc Description: PGP signature
Bug#975901: RFS: scala-mode-el/1:1.1.0-1 [ITA] -- Emacs major mode for editing scala source code (reintroduce to Debian)
Package: sponsorship-requests Severity: normal Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "scala-mode-el": * Package name: scala-mode-el Version : 1:1.1.0-1 Upstream Author : Heikki Vesalainen * URL : https://github.com/hvesalai/emacs-scala-mode * License : GPL-3+, SCALA-LICENSE * Vcs : https://salsa.debian.org/emacsen-team/emacs-scala-mode Section : editors It builds those binary packages: scala-mode-el - transitional dummy package, scala-mode-el to elpa-scala-mode elpa-scala-mode - Emacs major mode for editing scala source code To access further information about this package, please visit the following URL: https://mentors.debian.net/package/scala-mode-el/ Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/s/scala-mode-el/scala-mode-el_1.1.0-1.dsc Changes since the last upload: scala-mode-el (1:1.1.0-1) unstable; urgency=medium . [ Sławomir Wójcik ] * Adopt package; this package is now maintained by the Debian Emacsen team. (Closes: #766441) * control: updated binary name to elpa-scala-mode, repositories addresses, maintainer/uploaders, standards version, long description and dependencies * Updated rules to use dh_elpa, added necessary elpa and elpa-test files * Added watch file * Updated docs file * Added source format * Added NEWS file * Removed emacsen-install, emacsen-remove and emacsen-startup files which were no longer necessary due to migration to dh_elpa . [ Sławomir Wójcik and Nicholas D Steeves] * New upstream version 1.1.0. * Migrate to debhelper-compat 13. * Update copyright file to reflect new upstream source, and migrate to a machine-readable copyright file. * Add gbp.conf. * Declare Standards-Version 4.5.1. . [ Nicholas D Steeves ] * Add Breaks, Replaces, and Provides to elpa-scala-mode to ensure smooth upgrades. * Add epoch to version, so that apt will upgrade existing users from 20111005-2.1 to 1.1.0-1. * Declare Rules-Requires-Root: no. * Declare dummy transitional package scala-mode-el as Section: oldlibs so that deborphan will suggest its removal. * elpa-test: Fix autopkgtests by setting autopkgtest_keep, thus retaining the files that contain scala-mode's tests. * Add myself to Uploaders. Regards, Nicholas
Bug#840336: elpa-markdown-mode: Freezes Emacs when using TeX input mode in a header
Control: tags -1 = unreproducible Control: fixed -1 markdown-mode/2.3+154-2 Hi Christophe, I was unable reproduce the issue on sid with emacs 1:27.1+1-3 and elpa-markdown-mode 2.4-1. This bug looks safe to close now, but I'll leave it open for six months on the off chance a new trigger can be identified. Regards, Nicholas signature.asc Description: PGP signature
Bug#975535: elpy's autopkg tests fail with Python 3.9
Hi Matthias, On Mon, Nov 23, 2020 at 11:21:29AM +0100, Matthias Klose wrote: > Package: src:elpy > Version: 1.34.0-2 > Severity: serious > Tags: sid bullseye > User: debian-pyt...@lists.debian.org > Usertags: python3.9 > > https://ci.debian.net/data/autopkgtest/testing/amd64/e/elpy/8349971/log.gz > > [...] > Ran 436 tests, 432 results as expected, 3 unexpected, 1 skipped (2020-11-22 > 10:13:43+, 71.268224 sec) > > 3 unexpected results: >FAILED elpy-company-backend-should-add-shell-candidates >FAILED elpy-fold-at-point-should-fold-and-unfold-comments >FAILED elpy-pdb-debug-buffer-should-ignore-breakpoints > > 1 skipped results: > SKIPPED elpy-shell-send-region-or-buffer-should-notify-of-removing-main I've made progress with this, and encountered a couple blockers along the way (one outstanding at this time). Currently the need for Jedi 0.18 means the work in git (Elpy 1.35 minus rope, plus cherrypicked support for Jedi refactoring) cannot yet be uploaded. One nice thing about all this: it was good to have a high priority practice reason to enhance Elpy's packaging and test output for more complete and useful debugging output. Regards, Nicholas signature.asc Description: PGP signature
Re: addons build with old dh_elpa
Hi! David Bremner writes: > David Bremner writes: > >> >> We are down to less than 161 packages; several packages have been >> rebuilt. Note also that several packages reported twice do to >> limitations in my sql query. >> > > Down to at most 77 packages. Wonderful news, thank you for the updated list :-) [snip] > rainbow-delimiters | 2.1.3-4 | 1.16 > | Debian/2019/08/26/rainbow-delimiters_2.1.3-4_all.buildinfo > rainbow-identifiers-el | 0.2.2-4 | 1.16 > | Debian/2019/08/26/rainbow-identifiers-el_0.2.2-4_all.buildinfo > redtick | 00.01.02+git20170220.e6d2e9b+dfsg-3 | 1.16 > | Debian/2019/08/26/redtick_00.01.02+git20170220.e6d2e9b+dfsg-3_all.buildinfo > rich-minority | 1.0.3-1 | 1.16 > | Debian/2019/07/08/rich-minority_1.0.3-1_all.buildinfo > s-el| 1.12.0-3| 1.16 > | Debian/2019/08/30/s-el_1.12.0-3_all.buildinfo > sesman | 0.3.4-1 | 1.16 > | Debian/2019/07/14/sesman_0.3.4-1_all.buildinfo > spinner-el | 1.7.3-2 | 1.16 > | Debian/2019/08/29/spinner-el_1.7.3-2_all.buildinfo [snip] Rich-minority is a false positive; I uploaded 1.0.3-2 08 Dec 2020, built with dh-elpa 2.x. Is this list long enough to make it worth to do something like iterate over the src:pkg list with rmadison, then dropping TODOs for false positives, where false positives are when the archive has a newer version than the list provided by the UDD SQL query? Best, Nicholas signature.asc Description: PGP signature
Re: addons build with old dh_elpa
> [snip] > > Rich-minority is a false positive; I uploaded 1.0.3-2 08 Dec 2020, built > with dh-elpa 2.x. Thanks for the ping on IRC David. Indeed, you're right, it looks like: I misread rmadison output, didn't actually upload 1.0.3-2, and also didn't push the branch and tag...sorry for the noise, yes, this is a case of human error, and the error is mine. Regards, Nicholas signature.asc Description: PGP signature
Re: Bug#934977: verilog-mode: unbuildable in testing due to missing B-D emacs25
...so, it looks like verilog-mode won't be in bullseye, which is a shame. I also wonder if Verilog's importance is going to increase due to: https://beaglev.seeed.cc/ (RISC-V with NVDLA Engine) which appears to support Verilog as well as the (usual?) SystemC. http://nvdla.org/primer.html http://nvdla.org/hw/v1/integration_guide.html Given that no one was/is interested in supporting a non-elpafied verilog-mode, and Kiwamu Okabe won't have a XEmacs-supported verilog-mode for bullseye, I would like to strongly recommend that the team reevaluates the existing position. Thank you, Nicholas signature.asc Description: PGP signature
Bug#975535: elpy's autopkg tests fail with Python 3.9
Hi Adrian, Thank you for checking in with this bug! Please let me know ASAP if another autoremoval exception will be provided, because if necessary I can do the shady thing of disabling tests to buy time...but I'd really prefer not to! My primary upstream contacts appear to be on holiday and/or seem to be unavailable for some reason, but the upstream community has stepped forward to fix these issues. My primary worry is that this won't happen fast enough to prevent autoremoval during the next phase of the freeze, with no reentry into testing. Adrian Bunk writes: > On Fri, Dec 25, 2020 at 08:57:49PM -0500, Nicholas D Steeves wrote: >>... >> I've made progress with this, and encountered a couple blockers along >> the way (one outstanding at this time). Currently the need for Jedi >> 0.18 means the work in git (Elpy 1.35 minus rope, plus cherrypicked >> support for Jedi refactoring) cannot yet be uploaded. >>... > > Jedi 0.18.0 is now in unstable: > https://tracker.debian.org/pkg/python-jedi > Unfortunately it looks like the upstreams PRs for Jedi 0.18 support are insufficient/incomplete, and I'll need more time to work on bugs introduced by dependencies that introduced various incompatible changes. The state of Elpy is worse than I'd like to see...on my moderately patched local HEAD (based on upstream master branch) I'm seeing upwards of 27 tests that must be skipped. It also looks like Python 3.9 may have made breaking changes to how pdb works. The good news is 438/465 tests are still good (on my local HEAD), so on the whole it's better to have Elpy in Bullseye than to not :-) Version 1.34 has 423/436 passing. IIRC 1.35 has only seven failing tests, but less coverage than upstream master's HEAD. At this point I'm using an upstream snapshot in the Debian git project for Elpy, because staying close to the next upstream release will make cherry picking any fixes much easier, and I've recently seen a nontrivial amount of code churn and refactoring. My hope is that the PR discussed at the following link will provide the solution for bullseye: https://github.com/jorgenschaefer/elpy/issues/1868 Regards, Nicholas signature.asc Description: PGP signature
Bug#975535: elpy's autopkg tests fail with Python 3.9
Hi Adrian, Adrian Bunk writes: > On Sat, Jan 30, 2021 at 10:09:03PM -0500, Nicholas D Steeves wrote: >> Hi Adrian, > > Hi Nicholas, > >> Thank you for checking in with this bug! Please let me know ASAP if >> another autoremoval exception will be provided, because if necessary I >> can do the shady thing of disabling tests to buy time...but I'd really >> prefer not to! > > I am not a member of a release team, just a normal developer. > ACK :-) > Personally, I would go with disabling some (or all) tests if the package > is overally working and the tests are the only worry for missing bullseye. > Basic functionality is ok, depending on the working definition of "basic", but my feeling is that it's a minefield for intermediate and advanced use of the IDE features due to a big wave of breaking changes introduced by various dependencies in the period right between this bug was filed, continuing until shortly before our soft freeze. Active upstream issues that affect Elpy in bullseye have been multiplying, and at this point I'm starting to find it strange that this (#975535) is the only reported bug. The primary maintainer has injured hands and will be AFK for a while as he recovers. The second maintainer has a new job and no time, but my hope is the upstream community will band together in time to get Elpy into a good state in time for bullseye. I will contribute what I can, but worry that it won't be enough. Coordination is occurring here: https://github.com/jorgenschaefer/elpy/issues/1884 Regards, Nicholas signature.asc Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Antoine and Lev! Antoine Beaupré writes: > That didn't work, but I manually bisected my .emacs.d/init.el file and > came up with this minimal reproducer: > > (when (require 'package nil t) > (setq-default >load-prefer-newer t >package-enable-at-startup nil) > (package-initialize) I wonder if this "(package-initialize)" line, while using Emacs >= 27 is exposing a bug in lsp-mode? Since Emacs 27 now automatically runs package-initialize in between the new early-init.el and the classic .emacs.el/init.el/etc, maybe lsp-mode has an autoload cookie that gets evaluated twice, leading to the broken state of the lsp sentinel? Alternatively, maybe lsp-mode now assumes we live in a post-Emacs 27 world where all users have already dropped package-initialize from their configs? These Emacs >= 27 changes also affect the point in emacs init where package-enable-at-startup can be set: If non-nil, packages are made available before reading the init file (but after reading the early init file). This means that if you wish to set this variable, you must do so in the early init file. I think this bug is still valid and actionable even if removing package-initialize from the minimum reproducer, and/or after moving package-enable-at-startup to early-init.el makes the bug unreproducible. If nothing else, it seems like our src:emacs might need a NEWS entry on the topic, but that said, my suspicion is that lsp-mode could be more defensive. Cheers, Nicholas signature.asc Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Antoine Beaupré writes: > On 2021-04-29 13:54:05, Nicholas D. Steeves wrote: [snip] >> These Emacs >= 27 changes also affect the point in emacs init where >> package-enable-at-startup can be set: >> >> If non-nil, packages are made available before reading the init file >> (but after reading the early init file). This means that if you >> wish to set this variable, you must do so in the early init file. >> >> I think this bug is still valid and actionable even if removing >> package-initialize from the minimum reproducer, and/or after moving >> package-enable-at-startup to early-init.el makes the bug unreproducible. >> If nothing else, it seems like our src:emacs might need a NEWS entry on >> the topic, but that said, my suspicion is that lsp-mode could be more >> defensive. > > So what you're saying is that in Emacs >= 27, I don't need the > package-initialize anymore and that will fix my bug? > Yup, you don't need to manually call package-initialize anymore; also, please see the note about package-enable-at-startup, because that variable "must" now be set in the new early-init.el. AFAICT These easy config changes are normal major version migration stuff, but I'm not sure if they'll be enough to solve your bug. Definitely worth a shot though! Cheers, Nicholas signature.asc Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Antoine,
I had started on a draft of this email before receiving your latest
update; however, I the info below is still relevant.
Antoine Beaupré writes:
> I still need to get to the office to confirm the fix, but this totally
> makes sense. I have a very old Emacs configuration, which I've been
> carrying for over two decades at this point. Cruft is bound to creep up
> in there, and I'm actually surprised things still work in any meaningful
> way. :)
>
:-) I feel that way about some of my config too! And I think you'll
agree that Emacs is great because it accommodates this, and that its
config and customisation becomes more of a "story" than the way some
people are using "story" as a synonym for "new user experience". It's
tangential to this bug, but I'm curious what you think about the new
trendy "literate programming" style configs? (I'm not sure if/when I
will switch to one, but I think it's a cool idea!):
https://harryrschwartz.com/2016/02/15/switching-to-a-literate-emacs-configuration
https://raw.githubusercontent.com/sachac/.emacs.d/gh-pages/Sacha.org
> I'm still kind of confused. What's the proper way to (say) setup package
> repositories and then `use-package'?
>
If I understand the new Emacs init process correctly, then a simplified
form describing the init process looks something like this:
(lambda ()
(load early-init.el)
;; I suspect the init for the UI goes here
(package-initialize) ;; automatic
(mapc 'load (list of all supported init.el locations)))
I'm not a `use-package` user, but I think use-package stuff is supposed
to continue be configured from a supported init.el location...rationale
being that `use-package` seems like it ought to be
post-`package-initialize`.
> In other words, what's the modern equivalent of this in my
> `.emacs.d/init.el`?
>
> (when (require 'package nil t)
> (setq-default
>load-prefer-newer t
>package-enable-at-startup nil)
Please see note in previous emails about the location where
`package-enable-at-startup` *must* be set. There may also be other bits
of your init.el that must now be moved to early-init.el. Sorry, I don't
have a list... I trust the docstrings, so I don't think this is an
optional thing that can be ignored.
> (when (< emacs-major-version 27)
> (package-initialize))
> (setq package-archives '(("gnu" . "https://elpa.gnu.org/packages/";)
> ("melpa" . "https://melpa.org/packages/";)))
> ;; in elpa-use-package debian package since stretch
> (unless (package-installed-p 'use-package)
> (package-refresh-contents)
> (package-install 'use-package)))
>
> (eval-when-compile
> (require 'use-package)
> (setq-default
>use-package-always-defer nil
>use-package-always-ensure t))
>
> Note that I added this `(when (< emacs-major-version 27)' blob to try to
> workaround the bug. But now it seems that this packaging stuff might
> belong to early-init.el? What if I want this config to still work in
> Emacs 26?
>
There are a couple of ways to do this, take your pick ;-)
1. Use early-init.el on Emacs 27 hosts and add special cases everywhere
it may be required in init.el (icky, imho!)
* Note, init.el will need at least one special case for `package-initialize`.
2. Move what must go in early-init.el to that file, and then (load
early-init.el) at the top of init.el for emacs < 27 hosts.
* I wonder if there will be corner case breakage with this?
3. If you don't need Emacs 25, that means you're on buster, which means
Emacs 27 is available from buster-backports.
* This is the option I chose, to keep my config as simple as possible.
* Please note there's a IMHO RC (to backports) bug in the declared
dependencies. IIRC the workaround is to manually 'apt install -t
buster-backports emacs-common'. It might have also been this
issue: https://lists.debian.org/debian-backports/2021/03/msg00012.html
Sorry, I can't clearly remember...
* Buster-backports is also missing emacs-common-non-dfsg for Emacs 27
:-( Luckily it's arch:all so can be installed from unstable.
* Additionally, take care to either remove elpa-org, or upgrade it to
the version in unstable, since IIRC the version bundled with Emacs 27
is newer than the version in buster.
> Thanks for holding my hand through the new millenia. ;)
>
Anytime! Oh, one more thing, I've read about how old elc files (in
$HOME) have caused problems this release, so it's probably also a good
idea to erase them all and re[byte]compile them.
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#987683: crashes with "Wrong type argument: (or eieio-object class), nil, obj"
Hi Lev, Lev Lamberov writes: > That's interesting! Thanks for your input. Thanks! And you're welcome :-) > I've tried Antoine's minimal configuration and can confirm that > commenting out (package-initialize) resolves the problem. So, it > really means that lsp-mode has an autoload cookie which when evaluated > twice causes the bug. > Thank you for confirming this. > But now I wonder to which package should we assign the bug report, > lsp-mode, emacs, some other package?.. > Hmm...let's start with lsp-mode, which should defend against double evaluation of an autoload cookie. I'm CCing Rob in case there's something our emacs package could do (like release notes, or some kind of init.el checks)...reason being, all users comes from prior Debian releases will have (package-initialize) in their init.el files, and there's an undefined but possibly huge subset of these users whose configs may be broken by the new requirements to move a portion of their configs to init-early.el. We can always clone, reassign, and retitle as necessary. Arguably this is just a normal "adapt to the new Emacs version" stuff, but I feel like it might not be sufficiently well documented (ie: that the fixes are "lore" rather than "documentation"), and I also feel like we might get a lot of bug reports from users who aren't aware of these changes. To be completely honest, I'm not sure what the "balanced" option is for this issue. Rob, does this issue sound significant enough that we (in Debian) need to do something more than usual? Cheers, Nicholas signature.asc Description: PGP signature
Bug#988297: README.Debian contains instructions that result in RC bugs in other packages
Source: zenburn-emacs Version: 2.6-3 Severity: important README.Debian contains the obsolete and now harmful requirement to run (package-initialize) in init.el. Package-initialize is now executed automatically in between early-init.el and init.el, and continuing to call it from init.el (or one of the many alternative '~/.emacs' locations) results in RC bugs like #987683 (see bug for discussion about the bug type). This bug in zenburn-emacs docs is arguably release critical. On the upside, if it's RC then ftpmasters may approve an unblock :-) And on the topic of unblocks, I see that zenburn-emacs doesn't have autopkgtests, which are an automatic migration requirement. As this package does not appear to contain tests of any kind, it may be advantageous to Raúl if this bug was RC, because an RC bug that justifies an unblock will allow his work to be included in Bullseye. I'm also wondering if src:emacs should also do something like provide a NEWS file and/or check user config for 'package-initialize' and warn in the modeline. Cheers, Nicholas
Bug#988583: elpa-debian-el: Cannot report any bugs at all. It is broken.
Hi Salman, Salman Mohammadi writes: > I could reproduce this bug under this environment: > > 1. clean install debian stable in a vm > > 2. upgrade debian to sid > > 3. install emacs and debian-el: $ sudo apt -y install emacs > elpa-debian-el > > > Now, M-x debian-bug command does not work correctly. > I think there's something missing from your steps to reproduce. I tried this: 1. With a clean chroot, 'sudo apt install emacs-nox elpa-debian-el' * Given that Emacs was not installed in the stable VM until post-upgrade, I don't think my digression is a relevant variable. 2. Start Emacs 3. M-x debian-bug 4. Everything appears to work fine. After composing the full text of the bug, I hit C-c C-c, and then see the *Emacs Mail Setup Help* window appear, along with a minibuffer prompt. From the original bug report email it sounds like this is farther along then you were able to get? a. My hostname is a real FQDN (however no longer functional due to expired dyndns subscription--post-Oracle acquisition is a rip-off). It's possible that this bug only exists on hosts that don't have a FQDN hostname. b. Reportbug has not been configured. Regards, Nicholas signature.asc Description: PGP signature
Bug#988982: apt-utils: does not sort the numbers correctly. Should be smallest to largest.
On Sat, 22 May 2021 at 10:51, David Bremner wrote: > > Salman Mohammadi writes: > > > the command `apt-utils-search` does not sort the numbers based on integer value > > from smallest to largest. > > > > How to reproduce: > > - > > 1. M-x apt-utils-search > > 2. Search packages for regexp: google-android-platform > > Since the function does not promise any particular order, and the order > matches "apt search" on the command line, this seems more like a request > for an enhancement. I guess sorting by version might be possible, > although not trivial due to versions being complicated. Sorting by some > number embedded in the package name sounds messy. Salman, are you asking for a natural short, like piping a newline separated list to "sort -V" would provide? I think this is what you're asking for. David, AFAIK Emacs doesn't yet provide a natural sort algorithm, but is there any reason why it wouldn't be a good idea to pass the data to "sort -V" before outputting to the *APT package info* buffer? I guess there's also the question of if a non-interactive call to apt-utils-search should return a natural sorted list... But isn't the big question: If a user-friendly natural sorted list is a reasonable expectation, shouldn't "apt (and aptitude) search" do this directly? Better to fix it there, rather than in a way specific to debian-el, no? Cheers, Nicholas
Bug#990294: RFP: explain-pause-mode-el -- Emacs mode for session profiling and identification of poorly performing code
Package: wnpp Severity: wishlist * Package name: explain-pause-mode-el Version : 0.2~dev~gitsnapshot Upstream Author : Lin Xu * URL : https://github.com/lastquestion/explain-pause-mode * License : GPL2+ (appears to be GPL3+ effective) Programming Lang: elisp Description : Emacs major mode for session profiling and the identification of poorly performing code I'm filing this RFP since another team member mentioned that it looked useful. Obviously I agree, and this looks like something that should be in Debian. If someone else doesn't adopt this bug I expect I'll package it later this year. So what does it do? Explain-pause-mode is an Emacs major mode that provides simple profiling of an Emacs session; it displays the following data in columns: Command [name], slow, avg ms, ms, calls. "Slow" marks the top offenders for things that are keeping Emacs' single thread busy and/or are causing latency spikes with interactivity (thus degrading the user experience and/or making the UI unusable with a combination of hard-blocking and/or stuttering echoing of input). It uses a numerical system that I haven't yet found a definition for, where "0" presumably correlates to "not an issue", "1" maybe and issue, "2" definitely and issue, and so on. "Avg ms, ms" is presumably how long the call took, and calls is the number of times the command was called since profiling was initiated. This software is useful for an average Emacs end user who wonders what is causing the experience with their favourite editor to be less than stellar. It simplifies benchmark.el into something analogous to a process monitor that provides an answer to "what is making Emacs slow, and for how long, and how often?" The ability to effortlessly identify poorly performing functions will also provide Debian maintainers with user-facing problems that can be solved with upstream MRs/PRs--said another way, clear opportunities for upstream contributions. Best, Nicholas
Re: Auctex and dh-elpa #debian-emacs
Hi Vagrant! Yes, I think we met at DebConf17, in a classroom that was used for a BoF I think? (no idea which one) If my memory is correct you do a lot of work getting Arm boards working with Debian, and I mentioned that I thought the Volumio project wouldn't exist if not for your work :-) Maybe we also ran into each other at a party at Koumbit and/or a Debian & Stuff meeting? As for Auctex and dh-elpa, if I remember correctly dh-elpa doesn't yet know how to do anything with include files like auctex.el.in, preview.el.in, tex-site.el.in, so at first glance it looks like ./configure is inescapable...and the only workaround that comes to mind is something like an override_dh_elpa to do variable substitution using something like sed and dh_elpa-detected values. I might be wrong...but with a quick look dh-elpa doesn't appear to do anything with SOURCE_DATE_EPOCH, so it would need to be used in the override. At any rate, mainly I think that dh-elpa would be used to get the version and install target directory. As far as I can tell, methods that use debhelper's automatic generation of SOURCE_DATE_EPOCH from d/changelog are best practises: https://reproducible-builds.org/docs/source-date-epoch/ and IIRC this uses the date in the current changelog entry's footer rather than something like statting changelog and then "touch -d $date_from_stat" or "touch --reference" (TIL! Cool :-)). Of course I'll trust you that there's a good reason to use this last command rather than SOURCE_DATE_EPOCH ;-) Sorry, I have no idea about this style of date stamp: ;;;###·(autoloads·nil·"tex"·"tex.el"·(25292·55595·0·0)) Norbert Preining would know if it's a TeX-style date stamp. Oh yeah, that Aug 2020 upload! I forgot about that since I was travelling to a wedding at that time. Before that upload Auctex looked like a candidate for salvaging. Cheers, Nicholas signature.asc Description: PGP signature
NEWS: Adapting our packages to unversioned bin:emacs
Hi Team, Bullseye drops emacs24 and emacs25 transitional packages. I think I found and removed all incidences of these (plus a couple old emacs23!) in our packages' control files. If I remember correctly, I'm working off of an Oct 2020 list of our packages, so if any new packages were created after that, and they added emacs24 or emacs25 Enhances to the control file, then I missed them. I also ignored verilog-mode which spwhitton NACKed for elpafication, and which I will consequently not touch. I can't remember whether or not it's Policy RC, but haskell-mode had: Build-Depends: emacs | emacs25 | emacs24 So yeah, maybe this wasn't be best task to do when feeling burnt out, but I wasn't satisfied with our team's progress on this admittedly non-RC front. Cheers! Nicholas signature.asc Description: PGP signature
NEWS: Adapting our packages to unversioned bin:emacs
Hi Team, Bullseye drops emacs24 and emacs25 transitional packages. I think I found and removed all incidences of these (plus a couple old emacs23!) in our packages' control files. If I remember correctly, I'm working off of an Oct 2020 list of our packages, so if any new packages were created after that, and they added emacs24 or emacs25 Enhances to the control file, then I missed them. I also ignored verilog-mode which spwhitton NACKed for elpafication, and which I will consequently not touch. I can't remember whether or not it's Policy RC, but haskell-mode had: Build-Depends: emacs | emacs25 | emacs24 So yeah, maybe this wasn't be best task to do when feeling burnt out, but I wasn't satisfied with our team's progress on this admittedly non-RC front. Cheers! Nicholas
Bug#991668: [RFC] proposal for solving the discoverability problem (eg: eintr.info !)
Package: emacs-common-non-dfsg Version: 1:27.1+1-2 Severity: normal Control: affects -1 emacs Control: owner -1 ! Hi, I recently became aware that "An Introduction to Programming in Emacs Lisp" is non-discoverable, to the point that I doubt that any of the target audience will be able to find it; I think this is something that is hurting Emacs adoption rate, and there is some overlap between this RFC and my DebConf17 documentation improvement proposal. Looking at the existing bugs (what users want), here is what I propose: 1. I think it's worth having a "too long" long description for bin:emacs (and maybe emacs-nox) that notes the most significant documentation that new users will need. Eintr.info is one of these, and I think that that document in particular is essential to empowering new users, and that without this empowerment, learning Emacs is a lot of work for a very distant dream. Being able to keyword or pattern search from apt, or a GUI frontend is invaluable, and because in Debian we want users to avoid non-free whenever possible, the manual titles (or keywords) need to be in bin:emacs. I would assume that it's not needed in emacs-nox, unless blind users prefer the -nox variant and having the titles (or keywords) in bin:emacs but not bin:emacs-nox would reduce accessibility for these users. 2. As for #627434, I'm not sure if a package rename would be best, or if emacs-common-non-dfsg should "Provide: emacs-doc", and maybe also create a symlink to /usr/share/doc/emacs-doc. It would be nice if src:emacs documentation could be more unified, but the maintenance burden and regression risk of this is higher, so I'm not sure if proceeding along a "more unified documentation" avenue would be wise. 3. I fully support #893711 with one specific qualifier: I think the single vs multiple page question should be decided by whichever is a better source for conversion to ePubs; I suspect this will be the multiple page variant. On this topic, I still think that ePub is a superior format to plain HTML, because readers are ubiquitous, and because it provides a more book-like (yet reflowable) experience with the option for an ever present table of contents (like PDF, and more visibly than Info). And of course, this format provides a more consistent experience across many different types of devices. I may be biased, but it seems to me that the only advantage of HTML is that it can be grepped/silversearched/etc; however, desktop indexers (Tracker, Baloo, Recoll) handle ePub just fine. But I digress... Other than to say that many (most?) DDs outside of the Python Team don't seem to know about the alleged consensus of Policy §12.4. Yes really, I've asked many over the years, but admittedly this is anecdotal. To be clear, whatever the case, I think that discoverability for new users should be the focus, because everyone else knows where to ask, or what to search for...unless we have a morbid discoverability problem! 4. Now for more experienced users, we also have docbase. Yeah, it has become optional rather than recommended, but maybe it would be nice to have? 5. Did I miss anything? Is there any hope of getting these documentation discoverability fixes into bullseye as a stable-update? Comments welcome! I am volunteering for this work; however, I cannot commit to it before October, and I would sincerely appreciate if any interested parties would ping me at that time. Oh, and of course I'll submit an MR, subject to Rob's approval :-) Sincerely, Nicholas
Bug#960268: Update to 3.1.0 or newer
David Bremner writes: > Nicholas D Steeves writes: > >> Package: elpa-fountain-mode >> Severity: normal >> >> Fountain-mode is out of date. I have not imported the new series yet, >> because it drops support for exporting to PDF. Afterwriting looks >> like a viable replacement for this functionality. Afterwriting >> functionality exposed to Emacs should at least be equivalent to Atom's >> implementation: >> >> https://atom.io/packages/fountain > > Hi Nicholas; > > If PDF export is a dealbreaker for you maintaining the package, please > orphan it; if no-one picks it up and updates it we can remove it per > Paul's request. > Shipping a newer version with missing support for print output was a functionality regression (within the context of the self-contained Debian archive) that is, in my opinion, in no way appropriate for Bullseye (Debian 11)--ditto for this year's Ubuntu LTS; It took me longer than expected to find my notes on this! Now that the two have been released, and we're beginning a new cycle, I agree that now is the time to ship a newer, more polished, yet with reduced functionality version. But first, I'm going to file an RFP for Wrap, a Golang alternative to Afterwriting that has a much more reasonable and manageable dependency tree, and which I believe is a better fit for Debian due to its support for non-English languages--it's been taking me far too long to get up to speed with Golang packaging. Sorry about that. I also need to apologise to Wrap's maintainer for missing that deadline :-$ Paul, as communicated previously, the deadline for completing that work was 2021-02-12 (https://release.debian.org/bullseye/freeze_policy.html), and I wasn't able to learn Debian Golang packaging quickly enough. To give the ftpmasters time to review all the new dependencies would have pushed the deadline closer to 2021-01-12 or even 2020-12-12. Other than the RFP for Wrap, I'll update NEWS.Debian file to note the regression and document the RFP bugs, and then the new Fountain-mode release can be quickly prepared for upload. Best, Nicholas signature.asc Description: PGP signature
Bug#960268: clone bug and split b/t import new version and restore print export
clone 12345 -1 retitle -1 fountain-mode: restore print export functionality unblock 960268 by 960269 thanks signature.asc Description: PGP signature
Bug#984066: irony-mode: ftbfs with GCC-11
Control: tags + upstream fixed-upstream pending Fixed upstream with a trivial one line fix: https://github.com/Sarcasm/irony-mode/commit/ec6dce7ee16ffaa9a735204534aa4aa074d14487 Build log attached. irony-mode_1.5.0-1~exp1_amd64.build.xz Description: proof of ftbfs resolution with GCC-11 As uploads to bookworm are now open, I plan to upload directly to unstable, minus the explicit GCC-11 dependency. Regards, Nicholas signature.asc Description: PGP signature
Bug#985459: dh-elpa: install error when root user has packages under /root/.emacs.d/elpa
CCing #989905 (base-files) > Setting user-package-dir to a nonexistent directory also seems to > work. Nick, can you try the dh-elpa version at > https://salsa.debian.org/emacsen-team/dh-elpa ? Or just apply > > https://salsa.debian.org/emacsen-team/dh-elpa/-/commit/600a1133903eb2f7d3b7d954467dcee0b2d0277b > > to /usr/lib/dh-elpa/helper/install > That's a cool low-friction solution! :-) P.S. How likely is a future where Emacs will return non-zero exit status if package-user-dir is not found? I'm guessing unlikely? > Some possible alternatives: > > 1) maybe Sean remembers the proposed convention for a known empty > directory? Is this usable in stable? > > 2) We could create and clean up an empty temporary directory > > 3) We could create /usr/lib/dh-elpa/empty I have no strong opinion towards any of these options, but I was shocked to discover that Debian didn't already have a /var/run/empty. So I filed #989905 requesting /var/run/empty (present in Fedora, RedHat, CentOS, SUSE, Arch, FreeBSD, and probably more). It's not FHS, but it seems like maybe it should be; although, a systemd-centric future probably dynamically creates empty paths as-needed... https://bugs.debian.org/989905 Maybe a TC member could say something about whether a canonical empty directory equivalent to /dev/null is good design? Unfortunately it won't help the situation in stable--unless base-files receives a stable-update. It seems like it might also require a point in Policy along the lines of "packages must not install files nor write to /var/run/empty". #1 (via #989905) seems the cleanest, most standard, and conventional to me, #2 seems like a maintscript (which are increasingly discouraged) or a dpkg feature, and it seems to me that #3 sets a precedent that sanctions the proliferation of empty directories (which is maybe harmless and only kind of ugly and confusing?). It's possible I'm biased, so I leave it to you! Cheers, Nicholas signature.asc Description: PGP signature
Re: Help needed with splitting elpa-modus-themes
Hi Dhavan, Unfortunately the non-dfsg files have already been merged and pushed, so a team member with group-level admin access will need to do a hard reset of the pristine-tar, upstream, and master branches, and you'll need to do the same on your local copy, and reimport using 'gbp import-orig --uscan'. Imho this is the fastest, easiest, and most maintainable way forward. To not lose your commits, you can do something like: git checkout master (before the reset) git branch master-non-free-backup git reset --hard pre-upstream-import-commit and then either run 'git cherry-pick commit' for each commit that you need, or use magit to apply a series of commits in one go :-) Reply follows inline: Dhavan V writes: > Hello! > > Debian Stable has shipped with v1.0.2 of modus-themes, which had no > licensing conflicts with Debian. > > Since then, upstream has been included in emacs28 requiring docs license > to change to GFDL, which is incompatible with Debian because of GFDL > Invariant sections[1]. > > Because of this, we need to either “split” the package or not ship the > docs at all. I would like to “split” the package into free and non-free > parts. However, I do not know if “splitting” is the right terminology > here, and would like to have some help in finding documentation / > guidance as to how I should be doing this. > Sorry for the delay replying to this email, I rebooted for a kernel upgrade and lost the WIP draft that replied to this email. On IRC I just mentioned how gbp import-orig --uscan leverages Files-Excluded (d/copyright); this method prevents the non-dfsg files from being merged to the salsa repo. Currently documentation of Files-Excluded only exists in uscan's man page, and the documentation is incomplete. The non-dfsg source shouldn't be maintained on Debian infrastructure. Yes, you're using the correct terminology, assuming the future src:modus-themes-non-dfsg-docs exclusively contains what was excluded from src:modus-themes. There are lots of options on how to maintain this second source package. One can use a d/rules Makefile-style target to automate the exclusion of the source that is present in src:modus-themes, or a custom script. Basically the solution is "tar cJf modus-themes-non-dfsg-docs_$version.tar.xz docs", plus a mechanism to get the correct $version from either the upstream tag or the current changelog entry. 'hope this helps! Nicholas signature.asc Description: PGP signature
Re: Help needed with splitting elpa-modus-themes
P.S. I was assuming a tarball-based workflow for the docs package. If you'd prefer to create modus-themes-non-dfsg-docs tags then gbp can leverage those in a local-only src:modus-theme-non-dfsg-docs package. 'git deborig' can also be used to create the docs package's tarball from the debian packaging branch of src:modus-theme-non-dfsg-docs so long as you've merged the tag you created. It's also worth evaluating whether one feels the documentation is useful enough to justify the time/effort of maintaining a non-free package, or whether the work will demotivate you. When I initially packaged src:emacs-ivy, I chose--with the support of our team--to not ship the non-free package. There is no obligation to ship the docs, and no shame in not doing so :-) Take care, Nicholas signature.asc Description: PGP signature
Re: Help needed with splitting elpa-modus-themes
Hi Sean, Sean Whitton writes: > Hello, > > On Sun 19 Sep 2021 at 01:13PM -04, Nicholas D Steeves wrote: > >> Hi Dhavan, >> >> Unfortunately the non-dfsg files have already been merged and pushed, so >> a team member with group-level admin access will need to do a hard reset >> of the pristine-tar, upstream, and master branches, and you'll need to >> do the same on your local copy, and reimport using 'gbp import-orig >> --uscan'. > > This is not the case. The history on salsa need not be rewritten for > DFSG reasons. > >> The non-dfsg source shouldn't be maintained on Debian infrastructure. > > Again, this is not so. It is no problem to maintain it on salsa. > Are you sure, and if so, when was this policy changed? At DC17 (yes, we were still on alioth IIRC) the team was rather explicit in its warning to me to *not* put GDFL with invariant section and/or cover page on Debian infrastructure. That package was src:emacs-ivy. You were one of the people who insisted... Cheers, Nicholas signature.asc Description: PGP signature
Re: Bug#993370: RFP: rg-el -- elpa-rg
Hi Antoine,
It looks like I forgot to send this draft... (Dated 07 Sep 2021). So,
here's an update on the packaging: It's done, but the software seems to
be fundamentally broken by something that I haven't yet been able to
identify. I also confess to low motivation, and to worrying that this
package could become a huge time/energy sink like Elpy...I should
probably share my WIP soon so someone can go "Aha! That this is what
you missed!", and I'm hoping that's all it is, because I'm appalled that
the most basic function (rg) is nonfunctional. Meanwhile, counsel-rg
works perfectly.
--
If you're short on time, skip to "As an aside" for some new info (you've
read the rest on IRC).
Antoine Beaupré writes:
>> If you think the process might be interesting content for
>> Debian Planet, please let me know :-)
>
> That would be interesting, for sure, but no pressure. :)
Ok, will do! Casual deadline of mid-October.
>>> I'm not actually sure why Nicholas picked rg.el.
>>
>> I can update this bug with my rationale (from IRC) if you think it would
>> be useful to others.
>
> That, however, seems like an important thing to document here, for
> posterity.
>
Ok, for posterity :-)
Why this source package name? Rg-el, because we can't have src:rg.el,
and the -el suffix denotes elisp; you're totally right, src:rg-el will
produce bin:elpa-rg :-) Finally, ITPs are for source package names, but
I can't remember if this is a rule or convention.
I chose rg.el over alternatives (such as the excellent Deadgrep) for a
variety of reasons. First, based on the README, it seemed to fit what I
think your use case (and criteria for an improved grep) was; second, it
(subjectively) seemed like a more familiar interface (standard Emacs
conventions and expectations), and it has (rg-enable-menu) which uses
Magit's transient.el. The menu mode has a "magit-like" interface, and
UI consistency between modes is part of my overarching goal of making
contributions that make Emacs more accessible and less arcane for new
users; third, it impresses me that rg.el provides a backward-compatible
config key for keybindings when it moved to new, allegedly more
consistent ones ("new is better" is a pet peeve of mine, and I believe
that Emacs projects that have churn in this area would annoy you);
finally, the test suite impresses me, especially how it takes care to
test interoperation with other modes for possible regressions.
Rg.el also seems to be significantly more popular on MELPA, which is
more of a "probability of popularity in Debian" than a quality
thing... (eg: number of people who benefit to hours of work ratio thing)
As an aside, personally I'm happy with counsel-ag, and cousel-rg works
great; I packaged bin:elpa-counsel as part of src:emacs-ivy, which used
to be a hard dependency of elpa-find-file-in-project, which used to be a
dependency of src:elpy, my first big project (and your RFP).
Unfortunately upstream wasn't able to keep pace with Python breaking
changes, Python 3.9 broke Elpy's ERT tests badly.
For a user who doesn't know which to choose, at this point it seems like
this:
Choose rg.el for the traditional Emacs interface or Magit-like interface
Choose Ivy/Counsel for a completion framework that is non-jarring for
long-time Emacs users, and that is fast (in both cases, in when
compared to Helm). In other words, it seems to be a case of UI
preference and inclination due to established habits.
At the moment I'm currently stumped about why "M-x rg" doesn't find
hits/matches that /usr/bin/rg does, even thought the ERT tests indicate
that this codepath is functional and correct. My hypothesis is that
someone made a perfectly reasonable assumption that may have now been
revealed to be a technical deficiency.
Worse case scenario: please ping me in mid-October.
Regards,
Nicholas
signature.asc
Description: PGP signature
Bug#997370: emacs-wgrep: FTBFS: build-dependency not installable: elpa-dash-functional
reassign 997370 silversearcher-ag-el 0.48-1 affects emacs-wgrep fixed 997370 silversearcher-ag-el/0.48-1.1 thanks Lucas Nussbaum writes: > Source: emacs-wgrep > Version: 2.3.2+9.gf0ef9bf-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): >> +--+ >> | Install package build dependencies >> | >> +--+ >> >> >> Setup apt archive >> - >> >> Merged Build-Depends: debhelper-compat (= 13), dh-elpa, elpa-ag, >> build-essential, fakeroot >> Filtered Build-Depends: debhelper-compat (= 13), dh-elpa, elpa-ag, >> build-essential, fakeroot >> dpkg-deb: building package 'sbuild-build-depends-main-dummy' in >> '/<>/apt_archive/sbuild-build-depends-main-dummy.deb'. >> Ign:1 copy:/<>/apt_archive ./ InRelease >> Get:2 copy:/<>/apt_archive ./ Release [957 B] >> Ign:3 copy:/<>/apt_archive ./ Release.gpg >> Get:4 copy:/<>/apt_archive ./ Sources [388 B] >> Get:5 copy:/<>/apt_archive ./ Packages [459 B] >> Fetched 1804 B in 0s (0 B/s) >> Reading package lists... >> Reading package lists... >> >> Install main build dependencies (apt-based resolver) >> >> >> Installing build dependencies >> Reading package lists... >> Building dependency tree... >> Some packages could not be installed. This may mean that you have >> requested an impossible situation or if you are using the unstable >> distribution that some required packages have not yet been created >> or been moved out of Incoming. >> The following information may help to resolve the situation: >> >> The following packages have unmet dependencies: >> elpa-ag : Depends: elpa-dash-functional but it is not installable >> E: Unable to correct problems, you have held broken packages. >> apt-get failed. > > > The full build log is available from: > http://qa-logs.debian.net/2021/10/23/emacs-wgrep_2.3.2+9.gf0ef9bf-2_unstable.log > > A list of current common problems and possible solutions is available at > http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! > > If you reassign this bug to another package, please marking it as > 'affects'-ing > this package. See https://www.debian.org/Bugs/server-control#affects > > If you fail to reproduce this, please provide a build log and diff it with > mine > so that we can identify if something relevant changed in the meantime. signature.asc Description: PGP signature
Re: Processed: block 984066 with 987379
Control: unblock -1 by 987379
> Processing commands for cont...@bugs.debian.org:
>
>> block 984066 with 987379
> Bug #984066 {Done: Adrian Bunk } [src:irony-mode]
> irony-mode: ftbfs with GCC-11
> 984066 was not blocked by any bugs.
> 984066 was not blocking any bugs.
> Added blocking bug(s) of 984066: 987379
>> thanks
This block is incorrect, please see the following:
irony-mode (1.5.0-1) unstable; urgency=medium
* New upstream release.
* Update my email address.
* Switch to llvm-toolchain-12, and build with libclang-12-dev, clang-12,
and llvm-12-dev.
* Switch to watch file v4 (no further changes required).
-- Nicholas D Steeves Wed, 15 Sep 2021 16:56:37 -0400
Additionally, I think it may be a better use of time to focus on
stabilising llvm-toolchain-13 rather than 11 and 12. Of course, that's
not my call, but I'd like to do what I can to support the effort to ship
fewer llvm-toolchain-versions in bookwork. Consequently I will be
moving this package to version 13 at some point in the near future.
Also, on the upstream bug tracker, users have expressed the desire to
have a Debian irony-mode package that uses the newest Clang available on
Debian systems, so there is a concrete "for our users" reason to do this.
I hope that this position is acceptable to everyone! :-)
Regards,
Nicholas
signature.asc
Description: PGP signature
Re: Bug#993370: RFP: rg-el -- elpa-rg
Antoine Beaupré writes: > On 2021-10-20 18:58:03, Nicholas D. Steeves wrote: [snip] > Thanks for the update! That's interesting! I've been meaning to look at > other completion frameworks, I keep getting confused because I can't > even remember which one I'm using. I think it might have been the built-in ido mode, if you're using one at all--IIRC you weren't using one last we discussed our Emacs configs and preferences. > For the record, I'm probably going to switch away from elpy towards the > more standard lsp-mode, which covers more languages and actually works > with Python (and other tools like mypy/pyright). That's totally reasonable, and in fact in upstream Elpy issue tracker there was a discussion about whether the future of Elpy would be an extension to lsp-mode. > I'm sorry you had to work so hard on this package only to see it miss > bullseye and end up in that state. But I guess that's the life of > software: a few of my own personal projects didn't make it to bullseye > due to bitrot and I was also sad about that... It's ok, I learned a lot on the way, and never would have discovered find-file-in-project and Ivy/Counsel/Swiper. I hear you! So much work is keeping up with all the breaking changes... Elpy had a bit of a crisis when Jorgen Schaefer retired, Gaby Launay carried the banner, but then RSI got him :-( If you want to send a message of support/solidarity, his email's in the control file. > I am not sure we should continue with rg-el. Maybe deadgrep or > counsel-rg are better paths forward? > Quite possibly yes. That said, I *really* don't like the feeling of being beaten, so I took a crack at it today, and I think the cause of the total dysfunction of rg-el might actually be a bug in our ripgrep. I'll send a follow up email momentarily that CCs the maintainers. > Thanks again! > You're very welcome :-) > a. > > -- > La démocratie réelle se définit d'abord et avant tout par la > participation massive des citoyens à la gestion des affaires de la cité. > Elle est directe et participative. Elle trouve son expression la plus > authentique dans l'assemblée populaire et le dialogue permanent sur > l'organisation de la vie en commun. - De la servitude moderne Je suis d'accord, la démocratie directe est l'idéal, mais pendant mes cours de science politique j'ai appris comment il y a un scaling problem insurmontable quand le cadre dépasse une certaine population :-/ Cheers, Nicholas signature.asc Description: PGP signature
Bug#999692: creates watch files with invalid URLs causing uscan to error
Package: dh-make-elpa Version: 0.19.1 Severity: normal Hi, This bug has existed for a while, but finally annoyed me enough to file a bug. Briefly, it seems like the URLs generated may be designed for use with mode=git, or with the assumption that all git project hosting sites will map a https://foo.git URL to https://foo. Github is a notable exception. Here is an example of the type of manual fixup that is required for all watch files that point to Github: -opts="filenamemangle=s/(?:.*?)?v?(\d[\d.]*)\.tar\.gz/yaml.el.git-$1.tar.gz/" \ -https://github.com/zkry/yaml.el.git/tags \ +opts="filenamemangle=s/(?:.*?)?v?(\d[\d.]*)\.tar\.gz/yaml.el-$1.tar.gz/" \ +https://github.com/zkry/yaml.el/tags \ The tarball suffix is functionally cosmetic, of course, because uscan creates an orig.tarball symlink. Sorry, I will not be submitting an MR, because learning Perl isn't on my roadmap for the near future ;-) Regards, Nicholas
Bug#1001131: [RFC PATCH] Enhance docs with answers for common questions
Package: dh-elpa
Version: 2.0.9
Severity: normal
Control: tag -1 patch
Hello,
I've noticed that these questions are still coming up on
#debian-emacs, so I thought I'd work on a documentation enhancement
proposal. I've attached a patch series, and--if preferred--a git remote is
available at: https://salsa.debian.org/sten/dh-elpa.git
The commit messages further information, and short changelog messages
have also been provided.
Thanks,
Nicholas
>From e9d5277aaf7bdc2acf5f282dd17f276781505a35 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves
Date: Sat, 4 Dec 2021 19:31:54 -0500
Subject: [PATCH 1/3] =?UTF-8?q?Eliminate=20potential=20ambiguity=20by=20ch?=
=?UTF-8?q?anging=20the=20case=20of=20"elpa"=20to=E2=80=A6?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
"ELPA" everywhere it makes sense to do so. Previously a mix of the
two existed.
---
debian/changelog | 5 +
dh_elpa | 18 +-
2 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index b94a950..f99ee4c 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,7 +1,12 @@
dh-elpa (2.0.10) UNRELEASED; urgency=medium
+ [ David Bremner ]
* Update dh_elpa_test documentation
+ [ Nicholas D Steeves ]
+ * Eliminate potential ambiguity by changing the case of "elpa" to "ELPA"
+everywhere it makes sense to do so. Previously a mix of the two existed.
+
-- David Bremner Fri, 24 Sep 2021 10:14:54 -0300
dh-elpa (2.0.9) unstable; urgency=medium
diff --git a/dh_elpa b/dh_elpa
index f51a592..0370f50 100755
--- a/dh_elpa
+++ b/dh_elpa
@@ -21,7 +21,7 @@ B [S>] [S>]
=head1 DESCRIPTION
B is a debhelper program that is responsible for installing
-elpa style emacs lisp packages into package build directories.
+ELPA style emacs lisp packages into package build directories.
B will attempt to run ERT and Buttercup test suites using
dh_elpa_test(1) if the debhelper compat level is 10 or higher. This
@@ -38,19 +38,19 @@ dh_elpa_test(1).
=item debian/elpa
List of files to be installed into I (respectively into the
-first binary package) as an elpa package. The format is a set of
+first binary package) as an ELPA package. The format is a set of
lines, where each line is either (i) a single filename or glob, or
(ii) a space-separated list of one or more filenames or globs,
followed by the name of a destination subdirectory (which should not
begin with a slash).
For lines with a single file or glob, B will install matching
-file(s) into the top level elpa package directory.
+file(s) into the top level ELPA package directory.
For lines which include a destination subdirectory, B will
install matching file(s) into the named subdirectory.
-Only elisp files in the top level elpa package directory will be
+Only elisp files in the top level ELPA package directory will be
automatically byte-compiled.
=item I-pkg.el
@@ -185,7 +185,7 @@ sub maybe_install_helper{
error "elpa package name not found";
my $elpaversion = $desc->{'ELPA-Version'};
-error "elpa version not found" if (!defined($elpaversion));
+error "ELPA version not found" if (!defined($elpaversion));
sed_file (sub {s/#ELPAPACKAGE#/$elpapackage/;
s/#ELPAVERSION#/$elpaversion/;
@@ -219,12 +219,12 @@ foreach my $package (getpackages()) {
my $varname="ELPA_NAME_${package}";
my $elpapkg = $ENV{$varname} || $ENV{ELPA_NAME};
if (!defined($elpapkg)) {
-verbose_print("Guessing elpa package name from package name $package");
+verbose_print("Guessing ELPA package name from package name $package");
$elpapkg = $package;
$elpapkg =~ s/^elpa-//;
}
- verbose_print("Using elpa package name $elpapkg");
+ verbose_print("Using ELPA package name $elpapkg");
my @lines;
my @actions;
@@ -235,7 +235,7 @@ foreach my $package (getpackages()) {
# as a side effect.
isnative($package);
if ($file) {
-# Read in the contents of the elpa control file into an array of
+# Read in the contents of the ELPA control file into an array of
# arrays. Don't glob yet, we need to count the words first.
@lines=filedoublearray($file);
@@ -250,7 +250,7 @@ foreach my $package (getpackages()) {
# Glob expand every word in the current line
$action->{src} = [ map { glob_expand(["."],
\&glob_expand_error_handler_warn_and_discard, $_) } @$line ];
- # Check for an multi-file elpa package control file
+ # Check for an multi-file ELPA package control file
$has_package_file ||= (grep m/\b${elpapkg}-pkg.el$/, @{$action->{src}});
push @actions, $action;
--
2.30.2
>From e06d515b6d0a863cd367c3c1afc769b9e56e7504 Mon Sep 17 00:00:00 2001
From: Nicholas D Steeves
D
Bug#1001131: [RFC PATCH] Enhance docs with answers for common questions
Hi David, Thank you for replying quickly, and sorry for the tardiness of mine. Holiday season, you know? ;-) David Bremner writes: > Nicholas D Steeves writes: > [snip] >> >> I've noticed that these questions are still coming up on >> #debian-emacs, so I thought I'd work on a documentation enhancement >> proposal. I've attached a patch series, and--if preferred--a git remote is >> available at: https://salsa.debian.org/sten/dh-elpa.git >> >> The commit messages further information, and short changelog messages >> have also been provided. > > Overall this seems like a good idea. I have a few suggestions. > Thanks! >> +An "Emacs Lisp Package Archive" style package is a library that >> +includes the metadata that is necessary to integrate with GNU Emacs >> +via B This metadata is provided using headers and/or an >> +B file. B will attempt to autogenerate >> +this file from headers, and will warn when this is not possible. When >> +converting a legacy-style Debian Emacs package to a new-style ELPA >> +package, maintainers will typically choose to hand-craft this file; >> +When upstream releases no longer occur, the B variable of >> +this file will not need to be updated, thus for such packages, a >> +B involves neglegible to zero maintenance burden. >> + > > - I did wonder if all of "legacy-style" discussion should be > together, perhaps under a subheading. I've been wondering that too :-) I hope some ideas for the name of that subheading will emerge in the course of this discussion. > - it might be useful to define "legacy-style" Would referring to /usr/share/doc/emacsen-common/debian-emacs-policy.gz do the trick? More broadly, Policy §11.10 maintains that this Emacs Policy is still the standard, while lintian complains that packages should migrate to dh-elpa. I suspect this is a source of confusion, but at the same time we don't want to throw Rob (and his excellent documentation) under the bus. > - I tripped over "neglegible to zero", perhaps replace with something > simpler like "minimal". > Fair point! Likewise, it appears that the onus is on us to make a case for dh-elpa vis à vis debian-emacs-policy. What would you suggest would communicate "less than minimal"? The impression I've gotten from other maintainers of legacy/maintscript/debian-emacs-policy packages is that their packages work fine with minimal maintenance burden, so I think we need to say something that communicates that dh-elpa saves time/future headaches vs the existing status quo. It might also be worth referencing dh_elpa_test, and expanding those docs to expand on the value of the autopkgtests that using it enables. >> +Why convert a legacy-style Debian Emacs package to a new-style ELPA >> +one? Using B centralises maintscripts, allowing one to drop > > - "maintscripts" seems a bit jargony, and the real point is that the > packager does not need to maintain emacsen-common install/remove > scripts. However, maybe it is better to be concise than precise here. > Good point, and yes, I'm not sure. The phrase used in the doc referenced above is "maintainer scripts". >> +them from the package; this eliminates a source of bugs, and allows >> +all B-using packages to inherit cross-archive updates to >> +emacsen packages. Integration with the GNU Emacs package manager is >> +consistent with a better user experience, and the primary reason to > > - The phrase "consistent with a better user experience" sounds quite a > bit overcomplicated and overqualified. > Yeah, I suppose that phrase is a bit marketing-speak ;-) To be honest I'm not sure what precise point to make here, because I'm not sure that most users will mix dh-elpa packages with user-specific ELPA/MELPA ones, and because the expectation in a Debian-context is that users don't have to worry about dependency resolution...so additional package.el dependency checks might not add a tonne of practical value for users. I feel like, here, there's a fine line between a tangential and an orthogonal explanation. For example, it would be cool if package.el could prompt the user to resolve ELPA-level dependencies with elpa-foo.deb via one of the interfaces to apt, and fall back to ELPA/MELPA repos if the user can't get root. The use case for this would be when installing a leaf package from ELPA/MELPA, but to fulfill its deps with apt. What would you suggest? >>>From 6b1105955c1eb56ace4413d37f06973409417629 Mon Sep 17 00:00:00 2001 >> From: Nicholas D Steeves >> Date: Sat, 4 Dec 2021 19:34:17 -0500 >> Subject: [PATCH 3/3] =?UTF-8?q?Replace=20occurrences=20of=20=20wi?= >
Bug#1005680: irony-mode: FTBFS: The imported target "RemoteIndexProto" references the file "/usr/lib/llvm-13/lib/libRemoteIndexProto.a" but this file does not exist.
Control: tag -1 moreinfo unreproducible Control: tag -1 important Hi Lucas, I was not able to reproduce, nor was reprobuilds on 2022-02-15 04:13:00 UTC: https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/irony-mode_1.5.0-2.rbuild.log.gz https://tests.reproducible-builds.org/debian/buildinfo/unstable/amd64/irony-mode_1.5.0-2_amd64.buildinfo nor was DebCI on 2022-02-14 17:17:51 UTC: https://ci.debian.net/data/autopkgtest/unstable/amd64/i/irony-mode/19201514/log.gz https://ci.debian.net/data/autopkgtest/unstable/amd64/i/irony-mode/19201514/artifacts.tar.gz https://ci.debian.net/packages/i/irony-mode/unstable/amd64/ Reply follows inline: Lucas Nussbaum writes: > Source: irony-mode > Version: 1.5.0-2 > Severity: serious > Justification: FTBFS > Tags: bookworm sid ftbfs > User: lu...@debian.org > Usertags: ftbfs-20220212 ftbfs-bookworm > > Hi, > > During a rebuild of all packages in sid, your package failed to build > on amd64. > > > Relevant part (hopefully): [snip] >> -- Found LibXml2: /usr/lib/x86_64-linux-gnu/libxml2.so (found version "2.9.12") >> CMake Error at /usr/lib/llvm-13/lib/cmake/clang/ClangTargets.cmake:737 (message): >> The imported target "RemoteIndexProto" references the file >> >> "/usr/lib/llvm-13/lib/libRemoteIndexProto.a" >> >> but this file does not exist. Possible reasons include: >> >> * The file was deleted, renamed, or moved to another location. >> >> * An install or uninstall procedure did not complete successfully. >> >> * The installation package was faulty and contained >> >> "/usr/lib/llvm-13/lib/cmake/clang/ClangTargets.cmake" >> >> but not all the files it references. >> >> Call Stack (most recent call first): >> /usr/lib/cmake/clang-13/ClangConfig.cmake:20 (include) >> src/CMakeLists.txt:4 (find_package) >> >> "/usr/lib/llvm-13/lib/libRemoteIndexProto.a" comes from libclang-13-dev, which is set up in L994 of your log, so this error doesn't make sense. Forgive me for wondering if there's something wrong with your test system ;-) [snip] > If you fail to reproduce this, please provide a build log and diff it with mine > so that we can identify if something relevant changed in the meantime. > I didn't see anything meaningful in the diff of the build log, other than the fact that your build system appears to have GCC preinstalled (which shouldn't be meaningful). Cheers, Nicholas
Bug#1009218: Please upgrade to upstream 0.3.7 or newer
Source: esxml Version: 0.3.5-1 Severity: normal X-Debbugs-Cc: Sean Whitton Hi, I remembered that our esxml package had been out of date for a while, and when I checked to see what the latest upstream version was I found that it was at 0.3.7. Please upgrade to upstream 0.3.7 or newer. Thanks, Nicholas
Bug#1009219: Please import upstream version 2.5
Source: markdown-mode Version: 2.4-1 Severity: normal X-Debbugs-Cc: David Bremner Hi David, I took a look at importing upstream version 2.5 and ran into an autopkgtest failure that looks like the same type that afflicts newer versions of find-file-in-project. I haven't been able to solve the ffip case in many months, so it's unlikely I'll solve this one either. Thus my request for someone else to import the new version ;-) Cheers, Nicholas
Bug#1009219: Please import upstream version 2.5
Hi David, I suspect the failing test in markdown-mode 2.5 (test-markdown-ext/wiki-link-search-under-project) is failing for a similar reasons to why 'ffip-test-relative-path-commands' was failing in find-file-in-project from 6.0.7 to a minimum of 1d2f0b3. The nature of the problem appears to be an upstream bug, and in find-file-in-project's case, the bug was fixed between 1d2f0b3 and 6.2.0. My hypothesis is that upstream makes a normally-valid assumption about path handling that breaks on sbuild and buildds. Cheers, Nicholas signature.asc Description: PGP signature
Re: Bug#993370: RFP: rg-el -- elpa-rg
Control: retitle -1 RFP: rg-el -- elpa-rg Control: noowner -1 It doesn't look like #997974 is going to be solved anytime soon, so I'm converting this bug to an RFP to signal that anyone who wants to work on this bug, and to pursue resolution of #997974 is welcome to do so. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1009219: Please import upstream version 2.5
David Bremner writes: > Nicholas D Steeves writes: > >> I suspect the failing test in markdown-mode 2.5 >> (test-markdown-ext/wiki-link-search-under-project) is failing for a >> similar reasons … [snip] >> … My hypothesis is >> that upstream makes a normally-valid assumption about path handling that >> breaks on sbuild and buildds. > > Sounds like we should just disable this test for now? Sounds good to me. Can I leave this bug to you? I'm juggling one too many things at the moment. If not, please ping me in a few weeks :) Thanks, Nicholas signature.asc Description: PGP signature
Re: projectile_2.1.0-1.1_source.changes ACCEPTED into unstable
Hi Thomas, Debian FTP Masters writes: > Accepted: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Format: 1.8 > Date: Thu, 19 May 2022 17:10:12 +0300 > Source: projectile > Architecture: source > Version: 2.1.0-1.1 > Distribution: unstable > Urgency: medium > Maintainer: Debian Emacsen team > Changed-By: Thomas Koch > Closes: 1009433 > Changes: > projectile (2.1.0-1.1) unstable; urgency=medium > . >* Non-maintainer upload. >* Fix FTBFS due to mkdocs changes. (Closes: #1009433) FYI, an NMU is incorrect. The maintainer of projectile is debian-emacsen@lists.debian.org, you're a member of this team, so you should use `dch --team`. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1014033: installing info page to a location accessible by standalone viewer
Package: elpa-geiser Version: 0.10-1 Severity: wishlist X-Debbugs-Cc: r...@debian.org Hi, I'm filing this wishlist bug on Rob's behalf, as discussed in #debian-emacs. Currently src:geiser uses debian/elpa to install the info page to the elpa-src dir rather than to /usr/share/info/ (which appears to be the only way for the standalone info viewer to find pages, short of calling it with a filesystem path as an argument). It seems like a good time to make this change may be when solving #1013686, which links to the text "packages should just drop their Info files in /usr/share/info/" and notes that some Policy changes are planned ( https://wiki.debian.org/Transitions/DpkgToGnuInstallInfo ). Regards, Nicholas
Bug#1017835: elpa-evil: emacs 28.1 upgrade fails with byte compiling elpa-evil
Dear Gregory and Cédric, FYI evil-el has been orphaned. It is currently in the Debian Emacsen Team's salsa group, but it needs a new human maintainer. See the orphan bug at #981120, and here is its git remote (writable for team members): g...@salsa.debian.org:emacsen-team/evil-el.git Regards, Nicholas signature.asc Description: PGP signature
Bug#1019030: Updating the org-drill Uploaders list
Dear Sebastian, As the src:org-mode maintainer, I thought you would want to know about this bug, because org-drill used to be part of src:org-mode. Tobias Frost writes: > Source: org-drill > Version: 2.7.0+20200412+dfsg1-2 > Severity: minor > User: m...@qa.debian.org > Usertags: mia-teammaint > > Thomas Koch is no longer maintaining org-drill. > > We are tracking their status in the MIA team and would like to ask you > to remove them from the Uploaders list of the package so we can close > that part of the file. > > (If the person is listed as Maintainer, what we are asking is to please > step in as a new maintainer.) > > Thanks. Regards, Nicholas signature.asc Description: PGP signature
Bug#1019202: dh-make-elpa: crashes with: Can't locate object method "gecos"
Lev Lamberov writes:
> Пн 05 сен 2022 @ 09:51 David Bremner :
>
>> Package: dh-make-elpa
>> Version: 0.19.1
>> Severity: important
[snip]
> Hmm... have you changed directory to srv.el before running dh-make-elpa?
> Because I cannot reproduce this, see:
>
> $ git clone -o upstream https://github.com/legoscia/srv.el
> $ cd srv.el/
> $ dh-make-elpa --pkg-emacsen
> I: couldn't generate d/docs: not fully implemented
> $ ls
> debian srv.el
> $ ls debian/
> changelog control copyright elpa gbp.conf rules source watch
>
Interesting! I can confirm two failures, and the second is the one
David reported. In an up-to-date clean sid schroot:
$ sudo apt install dh-make-elpa && cd /tmp
$ git clone -o upstream https://github.com/legoscia/srv.el && cd srv.el
$ dh-make-elpa --pkg-emacsen
Can't locate Email/Date/Format.pm in @INC (you may need to install the
Email::Date::Format module) (@INC contains: /etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.34.0 /usr/local/share/perl/5.34.0
/usr/lib/x86_64-linux-gnu/perl5/5.34 /usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl-base /usr/lib/x86_64-linux-gnu/perl/5.34
/usr/share/perl/5.34 /usr/local/lib/site_perl) at
/usr/share/perl5/DhMakeELPA/Command/make.pm line 28. BEGIN
failed--compilation aborted at
/usr/share/perl5/DhMakeELPA/Command/make.pm line 28. Compilation failed
in require at /usr/share/perl5/DhMakeELPA.pm line 58.
#1, dh-make-elpa is missing a depends on libemail-date-format-perl
Presumably this dependency was previously transitively fulfilled?
$ sudo apt install libemail-date-format-perl
#2, (the one this bug is about)
$ dh-make-elpa --pkg-emacsen
Can't locate object method "gecos" via package "sten" (perhaps you
forgot to load "sten"?) at /usr/share/perl5/DhMakeELPA/Command/Packaging.pm
line 127.
$ ls debian/
changelog elpa source
$ rm -rf debian
$ perl -d `which dh-make-elpa` --pkg-emacsen
DB<1> n
Can't locate object method "gecos" via package "sten" (perhaps you forgot
to load "sten"?) at /usr/share/perl5/DhMakeELPA/Command/Packaging.pm line 127.
at /usr/share/perl5/DhMakeELPA/Command/Packaging.pm line 127.
DhMakeELPA::Command::Packaging::get_name(DhMakeELPA::Command::make=HASH(0x55e6f856ff18))
called at /usr/share/perl5/DhMakeELPA/Command/Packaging.pm line 137
DhMakeELPA::Command::Packaging::get_developer(DhMakeELPA::Command::make=HASH(0x55e6f856ff18))
called at /usr/share/perl5/DhMakeELPA/Command/make.pm line 131
DhMakeELPA::Command::make::create_changelog(DhMakeELPA::Command::make=HASH(0x55e6f856ff18),
"/tmp/srv.el/debian/changelog", undef) called at
/usr/share/perl5/DhMakeELPA/Command/make.pm line 50
DhMakeELPA::Command::make::execute(DhMakeELPA::Command::make=HASH(0x55e6f856ff18))
called at /usr/share/perl5/DhMakeELPA.pm line 65
DhMakeELPA::run("DhMakeELPA") called at /usr/bin/dh-make-elpa line
14
Debugged program terminated.
Sorry I can't help more...Perl idioms look backwards to my simple mind...
I don't understand why "getpwent" isn't being used here to get the 5th
field for the account that matches $name. Also, probably a red herring,
but the Perl docs I've read all call the gecos field "$gcos" for some
reason.
Regards,
Nicholas
signature.asc
Description: PGP signature
Re: Bug#1021459: O: elm-mode
Ah, now I see what's happening. Reportbug only inserts a description when a bin:package is orphaned. Description: Major Emacs mode for editing Elm source code A major Emacs mode for editing Elm source code. and correct links are: Vcs-Browser: https://salsa.debian.org/emacsen-team/elm-mode Vcs-Git: https://salsa.debian.org/emacsen-team/elm-mode.git Homepage: https://github.com/jcollard/elm-mode signature.asc Description: PGP signature
Bug#1020180: bug 1020180 is forwarded to https://github.com/abo-abo/swiper/commit/23bdb5ab7003694aa880655d092fa9c321a31bb3
Adrian Bunk writes: > forwarded 1020180 > https://github.com/abo-abo/swiper/commit/23bdb5ab7003694aa880655d092fa9c321a31bb3 > thanks Thank you for setting this metadata, and for finding the specific commit :) I've leaning towards packaging a git snapshot, and then encouraging upstream to make a release if it seems release-candidate-like, because then our source will be closer to upstream. Of course, ideally we'll have a tagged release in bookworm, Also, upstream hasn't made a release in over 18 months, and abo-abo, the primary developer hasn't been heard from in something like a year, so I think upstream may appreciate the vote of confidence! What do you think? Kind regards, Nicholas
yasnippet commits review
Dear Aymeric, Following up from our conversation on IRC: ca55bc8: Nice find, and fix, thank you! (I haven't tested it yet, but assume you have, that it's good, and that it will pass when I test it) 2ff39eb: Nitpick: If you patch fixes the incompatibility, please say so :) Also, it may be nice to say that it's related to #1020143 if that's the case. 8aa6556: Thank you for noting "no changes required" because this item requires a human to check for compliance :) 7c4ae4a: Oh wow, this looks like something that may may have been out of date for years. Thanks! b9ccd2b: What's the purpose of this digression from the way dh_elpa does things? It looks like it introduces potential indeterminacy. At a minimum, an explanation needs to be provided. 0a76135: I will not sponsor due to this action, because it's not ok to disable all 91 tests, when only 7 are failing https://ci.debian.net/data/autopkgtest/unstable/amd64/y/yasnippet/28997908/log.gz Feel skip these seven tests using another method, but please say why this is the correct action. Regards, Nicholas signature.asc Description: PGP signature
Re: yasnippet commits review
Hi Aymeric, I've created the branch "temp-agon-reviewed_by_sten" which is fast-forwardable relative from "temp". This was necessary because the following are not doc-related...self tests for core functionality shouldn't break: 3 unexpected results: FAILED basic-jit-loading FAILED basic-jit-loading-with-compiled-snippets FAILED visiting-compiled-snippets (ert-deftest basic-jit-loading () "Test basic loading and expansion of snippets" … (ert-deftest basic-jit-loading-with-compiled-snippets () "Test basic loading and expansion of compiled snippets" … (ert-deftest visiting-compiled-snippets () "Test snippet visiting for compiled snippets." Aymeric Agon-Rambosson writes: > Le mercredi 4 janvier 2023 à 13:13, Nicholas D Steeves > a écrit : > >> ca55bc8: Nice find, and fix, thank you! (I haven't tested it >> yet, but >> assume you have, that it's good, and that it will pass when I >> test it) > > I have, and I have checked that the generated HTML documentation > is the same as in currently installed versions of yasnippet (from > what I can tell, only the order of the documented symbols in the > documentation changes, which could be related to changes in the > way org export works). If you think the patch is good, I'll > forward it upstream and explain my thinking. > This patch has "Forwarded: yes" in the header, so you've already claimed that it's been forwarded ;) It would be nice to have the URL it was/will be forwarded to rather than "yes" here, so that the next person who works on this package can track upstream discussion and status of your patch. I think it's likely upstream will accept it, an in the interim I think other people will appreciate having it made public. Ie makes it easier for someone to fork and apply all the important PRs to get yasnippet working again. Also if for some reason the upstream project becomes inaccessible, it's worthwhile to have a line or two in your patch header that explains your thinking (for the future maintainer of the Debian package). Sometimes the Debian packages ends up being the only living project, and thus the defacto "upstream" (hopefully only until an upstream fork is made). >> b9ccd2b: What's the purpose of this digression from the way >> dh_elpa does >> things? It looks like it introduces potential indeterminacy. >> At a >> minimum, an explanation needs to be provided. > > I just modeled the override according to what I did in my other > packages (see vertico or consult, for instance), for which I had > no objection. But it turns out that dh_elpa does "emacs -Q -L > /path/to/needed/elpa/src/" rather than "emacs -q". The second one > seemed simpler, but they are not entirely equivalent, the debian > site-files do a little bit more than just adding directories to > the load-path. I will remove this commit. > Thanks! [edit: I've reverted on my branch] >> 0a76135: I will not sponsor due to this action, because it's not >> ok >> to disable all 91 tests, when only 7 are failing >> >> https://ci.debian.net/data/autopkgtest/unstable/amd64/y/yasnippet/28997908/log.gz >> >> Feel skip these seven tests using another method, but please say >> why >> this is the correct action. > > The thinking was the following : > > The tests' failing has nothing to do with us, a simple "rake > tests" on the upstream repo fails the same, and upstream seems > unconcerned about this. In fact, there is a PR upstream (#1125) > that solves some of the failing tests that hasn't been merged in > more than a year. > It sounds like a new upstream [co]maintainer is be needed. > I would have liked the failing tests not to prevent the build from > succeeding, but still be able to see that there are some > failing. By disabling dh-elpa-test, we make the build succeed, but > autopkgtest still runs after the build, and the failure can still > be visible on ci.debian.net (which is good). If we skip the tests, > we're making them disappear from the build and from autopkgtest. > Unfortunately this Debian package doesn't have an active human maintainer, so this becomes an "if someone happens to notice and care about the failure" rather than the existing early warning system. The hard failure alerts team members and interested parties, and correctly removes the package from testing. > I have neither the time nor the inclination to investigate the > failing tests. Fair point. Thanks for mentioning upstream PR. I've imported it. Cheers, Nicholas signature.asc Description: PGP signature
Re: yasnippet commits review
Hi Aymeric, Aymeric Agon-Rambosson writes: > > Le dimanche 8 janvier 2023 à 18:12, Nicholas D Steeves > a écrit : > >> I've created the branch "temp-agon-reviewed_by_sten" which is >> fast-forwardable relative from "temp". > > Very well, I've seen the branch. Since we can rewrite history as > long as we haven't merged into master, will you let me remove my > commits from your branch rather than simply revert them ? I can do > it whenever its convenient for you, just before you merge to > master. > Right now, please fast-forward your branch (temp) to the reviewed state and rebase & squash that one (temp); I asked for help reviewing the failing tests on my reviewed branch, so it should not be rebased. >> This patch has "Forwarded: yes" in the header, so you've already >> claimed >> that it's been forwarded ;) It would be nice to have the URL it >> was/will >> be forwarded to rather than "yes" here, so that the next person >> who >> works on this package can track upstream discussion and status >> of your >> patch. > > I haven't forwarded it yet, this is exactly what I wanted to do > after you reviewed the patch. I'll open a PR on the upstream repo, > reference the issue David opened, explain my thinking there and on > the patch header as well. > It sounds like you'd like to write a draft of your thinking in the patch, have me review it, and forward the reviewed patch upstream, so please write your thinking in the patch header now. >> Unfortunately this Debian package doesn't have an active human >> maintainer, so this becomes an "if someone happens to notice and >> care >> about the failure" rather than the existing early warning >> system. The >> hard failure alerts team members and interested parties, and >> correctly >> removes the package from testing. >> >> Fair point. Thanks for mentioning upstream PR. I've imported >> it. > > Sorry for this. What I thought would be a (not so) simple unbreak > of the documentation build turned out to be hiding other > errors. I've seen that you and David discuss it on > #debian-emacsen, I'll try and look into the remaining tests this > weekend if I have the time. > No worries, this is why the social side of Debian exists, and why gaining upload rights is an incremental process :) Thanks again for your contributions! Regards, Nicholas signature.asc Description: PGP signature
Re: yasnippet commits review
Hi Aymeric, Aymeric Agon-Rambosson writes: > According to the function `comp-trampoline-compile', the > EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION environment variable > does not prevent trampoline compilation, only the saving of the > output of said trampoline compilation to the file system. > > I just checked, EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION is > already set to t anyway. Sean exported it from dh_elpa_test just > before Christmas (65a588ca). > It would be nice to see some of the above text in the patch header and/or Debian changelog (it's not relevant for the upstream PR as far as I can tell) > As of now, from what I understood of what I read in the upstream > mailing list and the comp.el file, the only way to truly prevent > trampoline compilation of a primitive is to add it to the variable > `native-comp-never-optimize-functions'. I think it could also be > possible to prevent the trampoline compilation of *any* primitive > by setting `comp-enable-subr-trampolines' to nil. > Cool approach vs skipping the tests. It would be nice to see a couple of words that show you've thought about why/how this approach doesn't hide potential bugs in real-world yasnippet usage. I hope you believe it's more likely that there's something weird with these three tests than that the tests are triggering a difficult to reproduce bug in Emacs ;) Also, please forward that patch. Go ahead and finalise the changelog with a commit message that mentions the version (0.14.0+git20200603.5cbdbf0d-2) as well as the distribution/suite (unstable)--in other words, it's just about ready to sponsor. As an aside, I seem to remember that native-comp-never-optimize-functions is supposed to be renamed sooner or later, which is good, because at that time Someone™ will need to refresh the patch and test that core functionality is still working. Regards, Nicholas signature.asc Description: PGP signature
Re: yasnippet commits review
Hi Aymeric, tldr: We only have about week to upload the fix, so I'd prefer to merge what I reviewed (where you used a patch) right now and upload ASAP. Aymeric Agon-Rambosson writes: > Le dimanche 22 janvier 2023 à 17:31, Nicholas D Steeves > a écrit : > >> It would be nice to see some of the above text in the patch >> header >> and/or Debian changelog (it's not relevant for the upstream PR >> as far as >> I can tell) > > I don't think it is relevant to this specific patch either, and it > could change in the future. I think this a generic piece of > knowledge that we have to keep in mind for all our packages. I > remember enquiring about it and later explaining it a couple of > times on #debian-emacsen, for instance. Maybe the wiki would be > the good place to store that kind of information ? > I agree, the wiki is a good place to centralise information. Linking to that article can then be used to avoid needing to reexplaining things; it also prevents gating when you link to it from package that needs a workaround--this is especially important for a package that needs an active human maintainer! Another possibility might be to eventually provide additional documentation in dh-elpa. [snip] > I sincerely hope that in a real-world yasnippet usage, our users > do not override a primitive as important as `buffer-list' so > recklessly. > Fair point haha! > The bug lies most definitely in the interaction of the native > compiler and the override of the primitive `buffer-list' > implemented by the macro `yas-with-overriden-buffer-list' used by > the three failing tests. This macro is used only for testing, and > is not shipped to our users. > > Advising primitives was frowned upon even before native > compilation, but now it should be avoided at all costs. As far as > I know, the main valid use case for doing it anyway are tests that > aim to give themselves a reproducible environment, so mostly > package maintainers are concerned by this. > It sounds like you're proposing a policy such as this: If an upstream package has advised primitives, in the test file (or in test functions) *for the purposes of testing*, and the package FTBFS, then the Debian package should add these advised primitives to 'native-comp-never-optimize-functions' to prevent FTBFS. Any other instanced of advised of primitives is an upstream bug. Of course it's also worth considering that if the test environment has been advised to such an extent that it no longer represents the package-as-used-by-a-user on a Debian system, then tests run in such an environment have poor functional (and qualitative) value. > According to me, these tests do in fact trigger a difficult to > reproduce bug in emacs related to native compilation and primitive > redefinition. Our users should be fine as long as they do not override > this primitive, or if they do, they also include it to > `native-comp-never-optimize-functions'. > A reliable way to reproduce a difficult to reproduce bug is valuable! :) >> Go ahead and finalise the changelog >> with a commit message that mentions the version >> (0.14.0+git20200603.5cbdbf0d-2) as well as the >> distribution/suite >> (unstable)--in other words, it's just about ready to sponsor. > > If you still think this fix is valid, I can go ahead. However, I > will not implement this fix with a patch, I'll use either d/rules > (like I did with projectile) or more probably d/elpa-test (that > allows arbitrary elisp evaluation before the running of the test). > The "not with a patch" alternative is valid but I worry it may be insufficient, so I would need to see what you're proposing...and we're short on time...for the record, here's my criteria: 1. Don't make Debian-specific fixes (make them upstream, and make the same changes in the Debian package), except for Debian-specific issues 2. Provide the URL where fix was forwarded 3. It's better if no further action needs to be taken when rebasing the Debian package on a future (fixed) upstream version 4. Optionally provide a link to upstream bug (in this case, it sounds like that would be an Emacs bug). In the absence of this, it would be nice to see it as a TODO item, because we're supposed to be helping upstream work towards a more robust future. 5. Don't normalise the bug or take on technical debt--I feel like a simple use of d/elpa-test would probably do this, because this file is usually used for permanent Debian-specific CI integration type problems...also, if it's truly an Emacs then I think that dh-elpa is the place to implement the workaround. >> Also, please forward that patch. > > I'll op
Re: yasnippet commits review
Hi Aymeric, Aymeric Agon-Rambosson writes: > Hi Nicholas, > > Le dimanche 29 janvier 2023 à 13:51, Nicholas D Steeves > a écrit : > >> I agree, the wiki is a good place to centralise information. >> Linking to >> that article can then be used to avoid needing to reexplaining >> things; >> it also prevents gating when you link to it from package that >> needs a >> workaround--this is especially important for a package that >> needs >> an active human maintainer! >> >> Another possibility might be to eventually provide additional >> documentation in dh-elpa. > > Feel free to use any part of my previous mails verbatim if you > edit the wiki (I don't have write access). If you want me to > review it first, just tell me. > Have you already created an account, or are you waiting for approval? https://wiki.debian.org/FrontPage?action=newaccount Failing that, feel free to ping me around mid-April (or so) when I hope to have more free time. [snip] >>>> Go ahead and finalise the changelog >>>> with a commit message that mentions the version >>>> (0.14.0+git20200603.5cbdbf0d-2) as well as the >>>> distribution/suite >>>> (unstable)--in other words, it's just about ready to sponsor. > > Done, the package should be ready to upload. > Uploaded! Thank you for your contributions and a good discussion :) Cheers, Nicholas P.S. Are you subscribed to this list, and in the future may I follow the usual Debian convention of not including individuals in CC?
Bug#1030831: Please resolve issues related to the doc/ subdir
Package: kotlin-mode Version: 0.0~git20230123.fddd747-1 Severity: normal X-Debbugs-Cc: s...@debian.org Hi Josh, Towards the end of packaging this snapshot, I found several issues: 1. Lintian warned about "doc/indentation_logic/.gitignore". When reenabling installation of docs, please ensure that this file does not end up in the elpa-kotlin-mode package. 2. "pages.pdf" should be regenerated at build time. 2a. Also related to this a probable upstream bug: the doc's Makefile's clean target removes pages.pdf; however, upstream's git repo includes pages.pdf, which means the development repo is in an unclean state. This means you'll need to do something clever when regenerating pages.pdf, to avoid an FTBFS due to "unrepresentable changes to source". Considering the fourth objective, noted below, will provide a hint about how to solve this in an elegant way. 3. It appears that the rest of this subdir tree exists to build "pages.pdf". If this is the case, then only the PDF should be installed. Consult Policy §12 for where to install it. Don't worry about §12.4 4. Pages.pdf should have a more useful name. Best, Nicholas
Bug#1033697: flycheck: autopkgtest fails: trampoline file does not exists
Paul Gevers writes:
> Source: flycheck
> Version: 32~git.20200527.9c435db3-3
> Severity: serious
[snip]
> Traceback (most recent call last):
>spy-on(buffer-file-name :and-return-value "test-buffer-name")
>buttercup--spy-on-and-call-replacement(buffer-file-name (lambda
> (&rest arg...
>comp-subr-trampoline-install(buffer-file-name)
>comp-trampoline-search(buffer-file-name)
>
> native-elisp-load("/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--tram...
> error: (native-lisp-load-failed "file does not exists"
> "/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--trampoline-627565722d66696c652d6e616d65_buffer_file_name_0.eln")
>
>
> [31mUtilities flycheck-buffer-saved-p considers a modified buffer with
> backing file unsaved[0m
>
> Traceback (most recent call last):
>spy-on(buffer-file-name :and-return-value "test-buffer-name")
>buttercup--spy-on-and-call-replacement(buffer-file-name (lambda
> (&rest arg...
>comp-subr-trampoline-install(buffer-file-name)
>comp-trampoline-search(buffer-file-name)
>
> native-elisp-load("/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--tram...
> error: (native-lisp-load-failed "file does not exists"
> "/home/debci/.emacs.d/eln-cache/28.2-ffd0c654/subr--trampoline-627565722d66696c652d6e616d65_buffer_file_name_0.eln")
>
> Ran 109 out of 110 specs, 2 failed, in 389.98ms.
I wonder if the following upstream Emacs bug (tldr: given two
primitives, the necessary trampoline and eln file is not generated for
the second primitive) is the cause of this behaviour?:
https://mail.gnu.org/archive/html/bug-gnu-emacs/2023-02/msg02464.html
Rob, Sean, and Aymeric, what do you think? To my eyes that upstream
Emacs bug looks like it's probably RC buggy, and flycheck+buttercup is a
reproducer.
Regards,
Nicholas
signature.asc
Description: PGP signature
Re: RFP: company-irony -- C, C++ and Objective-C completion tooltips for emacs.
unarchive 892377 reopen 892377 retitle 892377 RFP: company-irony -- C, C++ and Objective-C completion tooltips for emacs. submitter 892377 ! thanks Dear Alberto and anyone else reading this, It appears that Bart's stale-bot closed this bug, which is a shame because this package makes our Emacs and irony-mode packages more useful. Since the last update to this bug I've been granted DD privileges, so, Alberto, I'd like to sponsor your work now that I'm able to. TODO notes from my last review are at https://bugs.debian.org/890878, but I haven't verified if they're still current. The only reason that I've set myself as submitter is to make it easier to remain appraised of this bug's status. Alberto, please set yourself as owner and retitle if you'd like to resume the work. Current state of the progress on this RFP (from when it was an ITP) can be found here: https://salsa.debian.org/aluaces-guest/company-irony and I've created a backup copy in my personal namespace here: https://salsa.debian.org/sten/company-irony If Alberto or someone else doesn't want to carry the baton for this RFP then I ought to be able to eventually get around to it. Regards, Nicholas signature.asc Description: PGP signature
Bug#1035650: elpa-org version older than built-in Org in bookworm
David Bremner writes: > Note that by filing this bug with severity serious, you are proposing to > remove elpa-org from bullseye. This might be the right course of action, > I'm not sure. > At this time, this would mean that at least elpa-org-contrib will also be dropped. I don't know if there are others. IIRC elpa-org-drill doesn't depend on elpa-org at the dpkg level, so maybe that Depends (or Recommends) could be dropped from elpa-org-contrib and others? > I guess one downside is that people will just keep the old version of > elpa-org when upgrading, but at least it will show up as an obsolete > package in some package management interfaces. > Is there a practical argument against adding versioned Provides to either emacs-common or emacs-el (as appropriate)? Something like Provides: elpa-org (= 9.5.5) The idea is that emacs-common (or -el) would replace elpa-org 9.4.0+dfsg-1 from bullseye during the upgrade to bookworm, but that a future bookworm-backport (or the future trixie package) of standalone org-mode would replace the versioned semivirtual "elpa-org" package. I haven't taken the time to test to see if this would also need Breaks and replaces, because #1033400 makes it sound like the release team would necessarily stonewall any possible fix. > This bug is also duplicate of #1033400, but that bug (for now) has > different severity. Both look probably RC to me, and org-mode is a killer feature that motivates people to adopt Emacs, so imho we need to get this right. I think we need to discuss the versioned Provides approach, or some other approach, inform the release team of the situation and let them know the options we've considered, and then ask them what they'd like to see. After all, it's unlikely they'll ack a standalone elpa-org update. Regards, Nicholas signature.asc Description: PGP signature
Bug#1035650: elpa-org version older than built-in Org in bookworm
tldr: Dear team, are there any objections to making a team upload using
the dummy package approach? It's what at least two users want, and it
guards against harming relations with upstream Emacs. The existing
state of things is between useless, embarrassing, and harmful, so let's
fix this.
Sean Whitton writes:
> Hello,
>
> On Sun 07 May 2023 at 04:42PM -04, Nicholas D Steeves wrote:
>
>> Is there a practical argument against adding versioned Provides to
>> either emacs-common or emacs-el (as appropriate)? Something like
>>
> I believe that changes of this nature are not appropriate at this stage
> of the freeze. I wish we had done something about this sooner, but
> elpa-org is undermaintained.
>
With a potential harm argument ("not appropriate"), shouldn't one also
consider the social cost of doing nothing? With users, as well as to
our rapport with upstream? See below.
> I don't think we should kick it out, because having a slightly older Org
> seems less bad than also kicking out the rdeps, on balance.
>
Another way of articulating the problem:
(without elpa-org installed) M-x org-version
Org mode version 9.5.5 (release_9.5.5 @ /usr/share/emacs/28.2/lisp/org/)
(with elpa-org installed) M-x org-version
Org mode version 9.5.2 (9.5.2 @ /usr/share/emacs/site-lisp/elpa/org-9.5.2/)
Elpa-org shadows the built-in copy. 9.5.3's bug fixes appear to
indicate that 9.5.2 may be unusable for users of Org's
bibliography-related functions, and of course there are a number of
other bug fixes between 9.5.2 and 9.5.5. Is it really conscionable to
/disable/ bug fixes that Emacs 25 provides in built-in Org-mode? Is it
really conscionable to do this to upstream? When we ask them to
accommodate us for native-comp-related things, shouldn't we also
demonstrate that we support their work in other areas of Emacs?
All users who have elpa-org installed in bullseye will be affected when
upgrading, as well as all elpa-org-contrib users. Release notes can
advise the former to remove elpa-org, but we shouldn't advise
elpa-org-contrib users to use 'equivs' to make emacs Provide a virtual
elpa-org.
Maxim Nikulin writes:
> On 07/05/2023 20:34, David Bremner wrote:
>> Maxim Nikulin writes:
>
> I am against *removing* elpa-org from bookworm. I have a hope that it is
> possible to submit *empty* elpa-org package and it still can be accepted
> to bookworm. No dependencies will be broken, users will get a few more
> fixes from built-in Org shipped in emacs-el. If a newer Org appear later
> in next Debian releases (or in backports) users will get it.
>
You're describing the "dummy package" approach. I was advocating for
the "virtual package" approach (with version-qualified Provides <- this
is key), but yes, either approach works :) Some people find empty
packages ugly/cruft so I prefer to avoid them when possible, but it
sounds like this isn't consensus for this approach at this time. Thus,
yes, now I agree with you!
> Almost unrelated to bookworm (and so having less priority) issue: coming
> Emacs-29 will have built-in Org-9.6 and difference between versions will
> be substantial. Benefits of empty elpa-org in comparison to outdated Org
> will be more important.
>
Agreed!
Regards,
Nicholas
signature.asc
Description: PGP signature
Bug#1036359: crashes with (wrong-type-argument consp nil)
Control: tag -1 confirmed upstream fixed-upstream pending Antoine Beaupre writes: > Package: elpa-markdown-toc > Version: 0.1.5-2 > Severity: grave > markdown-toc-generate-toc crashes with: > > Debugger entered--Lisp error: (wrong-type-argument consp nil) Thanks for reporting; fix pending! signature.asc Description: PGP signature
Bug#1036359: crashes with (wrong-type-argument consp nil)
David Bremner writes: > Antoine Beaupre writes: > >> Package: elpa-markdown-toc >> Version: 0.1.5-2 >> Severity: grave >> >> In Debian bookworm, markdown-toc is currently unusable. >> >> Given the following markdown buffer: >> > > Hi Antoine; > > I agree that markdown file looks innocuous, but do you know if it is > just this file or any markdown file? This bug appears to be native-comp related. After cherry picking three commits from upstream, I was able to generate a toc for the md snippet in the initial but report. In the time it took to reply to this bug, native-comp occurred, and generate-toc began to fail again. I purged the eln cache and tried again, and it succeeded... signature.asc Description: PGP signature
Bug#1036359: crashes with (wrong-type-argument consp nil)
Antoine Beaupré writes: > On 2023-05-19 14:39:14, Nicholas D Steeves wrote: >> Control: tag -1 confirmed upstream fixed-upstream pending >> Antoine Beaupre writes: >> >>> Package: elpa-markdown-toc >>> Version: 0.1.5-2 >>> Severity: grave >> >>> markdown-toc-generate-toc crashes with: >>> >>> Debugger entered--Lisp error: (wrong-type-argument consp nil) >> >> Thanks for reporting; fix pending! > > Oh interesting! Where can I see it? is there a patch? > git clone g...@salsa.debian.org:emacsen-team/markdown-toc-el.git git checkout for-testing-before-upload > -- > Je n'ai fait celle-ci plus longue que parce que je n'ai pas eu le > loisir de la faire plus courte. > - Blaise Pascal
Bug#1036359: crashes with (wrong-type-argument consp nil)
Control: tag -1 -pending Nicholas D Steeves writes: > David Bremner writes: >> >> I agree that markdown file looks innocuous, but do you know if it is >> just this file or any markdown file? > > This bug appears to be native-comp related. After cherry picking three > commits from upstream, I was able to generate a toc for the md snippet > in the initial but report. In the time it took to reply to this bug, > native-comp occurred, and generate-toc began to fail again. I purged > the eln cache and tried again, and it succeeded... I also confirmed that both the patched version (in the staging branch) and unpatched version (in bookworm) work correctly with https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-36-gitolite-gitweb-retirement.md when one loads markdown-toc and generates the toc before native comp kicks in. signature.asc Description: PGP signature
Bug#1036359: crashes with (wrong-type-argument consp nil)
Nicholas D Steeves writes: > I also confirmed that both the patched version (in the staging branch) > and unpatched version (in bookworm) work correctly with > > > https://gitlab.torproject.org/tpo/tpa/team/-/wikis/policy/tpa-rfc-36-gitolite-gitweb-retirement.md > > when one loads markdown-toc and generates the toc before native comp > kicks in. Sorry for not being clear. What I mean is that I believe that this bug is triggered by native compilation, and that it's unlikely that I'll find enough time figure out what the upstream issue is before the autoremoval. Also, upstream hasn't seen any activity since 2021... Feel free to forward this bug and/or adopt this package (I don't use it). Cheers, Nicholas signature.asc Description: PGP signature
Bug#1033341: org-mode: CVE-2023-28617
fixed 1033341 org/mode/9.5.2+dfsh-5 fixed 1033341 org-mode/9.6.6+dfsg-1~exp1 thanks Dear Salvatore and Security Team, Salvatore Bonaccorso writes: > Source: org-mode > Version: 9.5.2+dfsh-4 > Severity: important > Tags: security upstream > X-Debbugs-Cc: car...@debian.org, Debian Security Team > > Control: clone -1 -2 > Control: reassign -2 src:emacs 1:28.2+1-13 > Control: retitle -2 emacs: CVE-2023-28617 > > Hi, > > The following vulnerability was published for org-mode (and emacs, > will close tis bug). > > CVE-2023-28617[0]: > | org-babel-execute:latex in ob-latex.el in Org Mode through 9.6.1 for > | GNU Emacs allows attackers to execute arbitrary commands via a file > | name or directory name that contains shell metacharacters. All lisp files were dropped in org-mode/9.5.2+dfsh-5, and so this CVE is fixed there; however, unfortunately this bug was not closed from that changelog entry. This CVE is also not present in the 9.6.6+dfsg-1~exp1 that I just uploaded to experimental, but be honest I forgot about this bug when uploading, and so I forgot to close this bug from the changelog as instructed. Sorry. What is the correct way to proceed now? Regards, Nicholas signature.asc Description: PGP signature
Bug#907495: please ship the x11idle binary
Control: tag -1 pending Sébastien Delafond writes: > On 27/03 09:26, Michal Politowski wrote: >> Actually I think there is no need to compile x11idle. As the footnote >> https://orgmode.org/manual/Resolving-idle-time.html#DOCF82 says, >> Debian already provides xprintidle, which seems to work for me. >> >> Maybe elpa-org could just suggest that package and change the default >> for org-clock-x11idle-program-name? > > Hi Michal, > > that's a good point, and sounds like an elegant way to solve this in > Debian. I'm pretty busy these days, so I won't have time to work on that > right now, but I'd happily accept a patch in the meantime :) > Pending upload to experimental: https://salsa.debian.org/emacsen-team/org-mode/-/commit/67d33aa4f2a26b8449f0f2ecb4404cdb2ad969a1 Cheers, Nicholas signature.asc Description: PGP signature
Bug#1037135: please update to latest upstream version and confirm intent to maintain package
Source: modus-themes Version: 1.0.2-1 Severity: normal X-Debbugs-Cc: Dhavan Vaidya Hi Dhavan, I hope this email finds you in good health. Are you still interested in maintaining modus-themes? The repository hasn't seen any activity since 2021, the current stable upstream version is now 4.2.0, and this makes it look like the package is effectively unmaintained. Regards, Nicholas
RFAU (an uploader) for thk's remaining packages
Last September the MIA team filed bugs requesting that thk be dropped from the Uploaders of various packages. Some packages have already been adopted, and some have already been orphaned. The following are those that remain in limbo: bui-el company-lsp dap-mode emacs-lsp-ui emacs-posframe git-auto-commit-mode haskell-mode lsp-java lsp-treemacs org-drill web-mode Raúl and Dhavan, I have CCed you because you maintain themes, which indicates you may have an interest in UI/UX. Maybe you would like to adopt emacs-posframe? I can take care of git-auto-commit-mode and org-drill if no one else wants to. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
Antoine Beaupré writes: > You seem to have pasted a link to the TPA GitLab wiki here... Did you > mean to paste some other bug report or link there? That's confirmation that I tested with the link to the file that you were noted (in an earlier post) that you were testing with. > I think I'm okay with the package being removed from bookworm if we > can't find a quick fix here. The release date is just too close. We can > always fix this in a point release or get a backport going. > > Interestingly, it's not marked as autoremoval here though: > > https://tracker.debian.org/pkg/markdown-toc-el Interesting, maybe someone has faith that we'll fix this in a point release! > Alternatively, I wonder if there's a way to make a simpler module that > would defer the TOC generation to an external command... > > Is there something out there that takes a markdown doc as input and > outputs a TOC? I saw your note on python3-md-doc, and it made me think about more generic TOC and endnotes functions that call an external parser. This one might be a viable alternative, with a slightly more active upstream than markdown-toc: https://github.com/snosov1/toc-org#markdown-support Cheers, Nicholas signature.asc Description: PGP signature
Re: RFAU (an uploader) for thk's remaining packages
Raúl Benencia writes: > Nicholas D Steeves writes: >> Raúl and Dhavan, I have CCed you because you maintain themes, which >> indicates you may have an interest in UI/UX. Maybe you would like to >> adopt emacs-posframe? > > Yes, I'll gladly adopt it. I'll prepare an upload in the upcoming days. > Thank you Raúl! Here's the relevant bug #1019019 Take care, Nicholas signature.asc Description: PGP signature
Re: RFAU (an uploader) for thk's remaining packages
Nicholas D Steeves writes: > Raúl Benencia writes: > >> Nicholas D Steeves writes: >>> Raúl and Dhavan, I have CCed you because you maintain themes, which >>> indicates you may have an interest in UI/UX. Maybe you would like to >>> adopt emacs-posframe? >> >> Yes, I'll gladly adopt it. I'll prepare an upload in the upcoming days. >> P.S. If you're interested, you're also welcome to comaintain emacs-theme-gruvbox and autothemer-el (currently in NEW); They're respectively at the 94th and 93rd percentile on MELPA.
Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
Hi,
Here is a way to work around this bug (whether in Emacs or in markdown-toc).
To test:
emacs --eval="(setq native-comp-deferred-compilation-deny-list
'(\"markdown-toc\"))"
To make permanent:
(setq native-comp-deferred-compilation-deny-list '("markdown-toc"))
That said, I'm not convinced that a workaround like this should be
inserted into Debian's markdown-toc (or any package)...
Cheers,
Nicholas
signature.asc
Description: PGP signature
Bug#1036359: elpa-markdown-toc -- crashes with (wrong-type-argument consp nil)
Antoine Beaupré writes: > On 2023-06-11 14:45:19, Nicholas D. Steeves wrote: >> >> Here is a way to work around this bug (whether in Emacs or in markdown-toc). [snip] > > Oh wow, thanks! You're welcome! > That said it doesn't actually work! I have tried both the `--eval` and > the `setq` and neither fix the crash. > > I'm not sure this is related to native compilation, is it really? When I 'rm -rf ~/.emacs.d/eln-cache, and restart Emacs, markdown-toc-generate-toc works correctly, but will eventually break again once various things are compiled again (sooner than later on a fast machine!). I'm not sure why the deny list hack works with an empty eln-cache, but not after a 'rm ~/.emacs.d/eln-cache/*/markdown-toc*'. > I thought it was some imenu thing, maybe it doesn't get autoloaded properly? Based on your hunch, I tested removing each rdep from the eln-cache, and I found that the (wrong-type-argument consp nil) bug occurs in markdown-mode-toc when markdown-mode is native compiled. markdown-toc-generate-toc succeeds for me when ~/.emacs.d/eln-cache/*/markdown-mode-*.eln and ~/.emacs.d/eln-cache/*/markdown-toc-*.eln and ~/.emacs.d/eln-cache/*/imenu-*.eln are removed, and emacs is started with this minimal workaround: emacs --eval="(setq native-comp-deferred-compilation-deny-list '(\"markdown-mode\"))" Yes, markdown-mode, no "toc". For this hack to work long-term for most users, it seems like imenu would probably need to be added to that list...but here's the strange thing: Logically, markdown-toc-generate-toc uses imenu, so it seems like it should trigger native-comp of imenu at L261. Neither markdown-mode, nor markdown-mode-toc explicitly (require 'imenu), so yes, I think you're right that one or both of them is depending on autoloads. Markdown-toc ends up native-compiled using this method, markdown-mode and imenu don't, and for reasons that aren't yet clear, this allows markdown-toc to function correctly. I also wonder if there may be a dash.el+native comp bug in play. 'hope this band-aid does the trick until the root of the problem can be identified. Nicholas signature.asc Description: PGP signature
Bug#1033341: org-mode: CVE-2023-28617
David Bremner writes: > Nicholas D Steeves writes: > >> fixed 1033341 org/mode/9.5.2+dfsh-5 >> fixed 1033341 org-mode/9.6.6+dfsg-1~exp1 >> thanks > > Are you sure about that? It depends on emacs 28.2, which afaik has the > vulnerable org-mode embedded. I guess it's a question of interpretation, > but the vulnerability is still there after installing the package. Wasn't the fix in emacs 1:28.2+1-14 two months ago? Meanwhile the new empty org-mode 9.5.2+dfsh-5 won't be able to shadow the (fixed) bundled copy. Thanks again for that work! This was also in bullseye in emacs 26.1+1-3.2+deb10u4 After uploading to bullseye-updates I'll upload 9.6.6 to unstable. I'd rather let someone else take care of buster, if we're still supporting it. Regards, Nicholas signature.asc Description: PGP signature
Bug#923908: new upstream version available (9.2)
Hi, Sebastien Delafond writes: > On 15/03 22:45, Nicholas D Steeves wrote: >> While triaging bugs I just noticed this one is marked fixed but is >> still open. Was it left open as a reminder to backport bullseye's >> org-mode? > > I believe that was the rationale at the time. > >> Does arch:all elpa-org-mode need a formal bpo, or will adding testing >> or sid apt source in combination with pinning work well enough? > > Package pinning should work fine, but if enough users request a proper > stable backport I guess it could also be maintained. Bookworm has been released, which means bullseye-backports will probably be winding down in a year. Meanwhile, no one requested an org-mode formal backport in three years, so I think it's safe to close this bug. Regards, Nicholas signature.asc Description: PGP signature
Bug#923908: new upstream version available (9.2)
Hi Bastien, Reply follows inline. Bastien writes: > Hi all, > > I'm not sure if this is the right place to announce this, but here it > goes: Org 9.4 is out. That's a good question! Yes, I believe that filing a "new upstream version" bug is likely to reduce the latency between when you release, and when this release is imported into Debian. With a Debian system, this is achieved with the following command: reportbug org-mode > We plan to remove the contrib/ directory from org-mode.git for either > Org 9.5 or Org 9.6. > > We will provide another way to install contribs, surely as a Org ELPA > package. I will let you know the details. Thank you for the notification, and sorry for the unfortunate state of Org mode in Debian 12 (bookworm). A variety of factors intersected to generate this outcome, and I wish we, as a team, had been able to do better. As for dependency packages that ensure a smooth transition: For Debian 12 (bookworm), unfortunately neither org-drill nor org-contrib are installed by default when org-mode is installed. I believe org-drill should have been, but I'm not sure sure about org-contrib, given its status as a kind of unmaintained orphanage area. Do you think that org-contrib should be installed alongside Org by default? I believe in "better late than never", so would like to fix these issues for Debian 13 (trixie), as well as for users who will manually install the latest available Debian org-mode package onto older releases. Also, is there something we should consider automatically parsing for notice of these kinds of changes? Regards, Nicholas
Bug#1037135: please update to latest upstream version and confirm intent to maintain package
Nicholas D Steeves writes: > Source: modus-themes > Version: 1.0.2-1 > Severity: normal > X-Debbugs-Cc: Dhavan Vaidya > > Hi Dhavan, > > I hope this email finds you in good health. Are you still interested > in maintaining modus-themes? The repository hasn't seen any activity > since 2021, the current stable upstream version is now 4.2.0, and this > makes it look like the package is effectively unmaintained. > > Regards, > Nicholas
Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package
Hi Dhavan, I'm forwarding this to your new email address, so there will be a record about how to contact you: Nicholas D Steeves writes: > Source: modus-themes > Version: 1.0.2-1 > Severity: normal > X-Debbugs-Cc: Dhavan Vaidya > > Hi Dhavan, > > I hope this email finds you in good health. Are you still interested > in maintaining modus-themes? The repository hasn't seen any activity > since 2021, the current stable upstream version is now 4.2.0, and this > makes it look like the package is effectively unmaintained. Please note that modus-themes is currently a salvaging candidate: https://wiki.debian.org/PackageSalvaging Regards, Nicholas signature.asc Description: PGP signature
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here.
Hi H.-Dirk, and anyone else reading this, I just found this draft from 3 June, and am sending it now: "H.-Dirk Schmitt" writes: > For myself I have deinstalled elpa-org for the moment. That makes sense. There's a parallel discussion at #1035650, btw, and the current package in both sid and testing [now bookworm/stable] has no lisp files. > But this mitigation – or the suggested changing of the load-path – > introducing unnecessary modifications, which will – Murphy's Law – become > persistent. > > A „clean solution“ should avoid duplicated distribution of the same > functionality – especially if one „shadows“ the other. Can upstream be convinced of this „clean solution“? If so, then Debian would inherit it; however, I suspect they'll reply with something like the following: -- Why? Emacs with bundled org-mode works fine with org-mode installed from GNU ELPA. Also, Emacs is, by-design a distribution of various useful libraries. > I suggest strongly to drop the duplicated parts from the main emacs-el and > either only distribute as 'elpa' or move to distinct packages setting > conflicts against the elpa version (and vice versa!) . Sorry, I don't understand what you mean by "or move to distinct packages". I'll discuss the Breaks Provides case below. > The problem of the duplicated 'elpa-org' distribution applies also to – on my > system – to 'elpa-seq' and 'elpa-let-alist'. Duplication is arguably an aesthetic concern; however, I agree with you 100% that it's a serious problem when an older version of elpa-foo functionally shadows the Emacs built-in version. That said, aesthetic concerns have value--sometimes great value. Is this an important enough issue to you that you're willing to invest a significant amount of time into continuously unbundling (within a Debian context) anything that is added to Emacs, for the foreseeable future? You'd also need to convince the other Debian Emacs maintainers of why this is important. There are a couple of alternative solutions that I think ought to be discussed. For example a script that parses our Emacs' built-in version, and that files release critical bugs against an elpa-foo package when it's older than the Emacs built-in version. If a package hasn't been updated between the point when Emacs is uploaded to Debian (before the freeze) and the point in the freeze that "no rentry into testing" becomes enforced, then I think it's fair to say that the package may be so insufficiently maintained that it shouldn't be part of the upcoming release. It's also worth considering whether this can be solved using Debian dependencies, without making disruptive unbundling changes. Ie emacs-el would declare breaks against things like elpa-org (<< x.y.z). In this case, it would need a "Provides: elpa-org (x.y.z)" to not break packages that have a hard dependency on elpa-org. I don't think it would be safe to use unversioned Provides. A script to maintain these would need to be written and integrated into src:emacs's build process, and the parser for this would necessarily be similar to the RC bug filing one; It seems like there is an opportunity for code reuse here. I wonder if having a package with a huge list of Breaks and Provides would reveal corner-case bugs in things like aptitude? Best, Nicholas signature.asc Description: PGP signature
Bug#1033400: elpa-org: Bookworm emacs 28 has org-mode included in newer version as provided here
Hi Max, Max Nikulin writes: > Thank you for fixing of the https://bugs.debian.org/1035650 bug that was > a duplicate of this one. I am glad to see that a dummy elpa-org package > has been landed to bookworm. > > Have you decided to keep this issue open to package Org-9.6 and to > implement emacs-pkg-* provides or it was just forgotten in the changelog > message and it should be closed? Fixed in experimental, and the bug will be closed when an updated version of org-mode is uploaded to unstable. At this time, "and to implement emacs-pkg-* provides" is not part of importing a new upstream release of Org. As for all the other ideas about how things can be done better? Debian is a do-ocracy. Anyone who cares enough to invest their time to maintain a solution in the long-term is welcome to upgrade the status quo :) "long-term" is key, because a drive-by set of changes that makes things maintenance more labour-intensive is unlikely to be seen in a favourable light. Regards, Nicholas signature.asc Description: PGP signature
Bug#907495: please ship the x11idle binary
Michal Politowski writes: > Dnia Sat, 3 Jun 2023 23:06:00 -0400, Nicholas D Steeves napisał(a): >> >> Pending upload to experimental: >> >> https://salsa.debian.org/emacsen-team/org-mode/-/commit/67d33aa4f2a26b8449f0f2ecb4404cdb2ad969a1 > > Nice. The relevant commit is actually > https://salsa.debian.org/emacsen-team/org-mode/-/commit/f484de742a55280a2e92e17f93fd21057e6b0705 Thank you for pointing this out, yes, that's what I meant! Primary X11 clipboard behaviour seems to have recently changed under KDE Plasma, and I haven't figured out how to make it behave in classic mode...or else it's no longer reliable. Either way, it makes me grumpy that highlight -> middle click to paste doesn't work 100% reliably the way it always has. Regards, Nicholas
Bug#907495: please ship the x11idle binary
Max Nikulin writes: > Next Org mode release will discover xprintidle out of the box: > > https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=1810c625d That's great news :)
Re: Bug#1040690: emacs-el: Warnings resulting from org-mode source files not found
Control: tag -1 confirmed Control: tag -1 affects dh-elpa Control: tag -1 severity important # Justification: Causes packages to not upgrade cleanly Hello, Balbir Thomas writes: > Package: emacs-el > Version: 1:28.2+1-15 > Severity: normal > > Dear Maintainer, > > On starting emacs 28 in bookworm various warnings are displayed because > elisp source files (mostly for) org-mode are not found. [snip] Thank you for filing this bug Balbir! I wonder if you reported this against emacs-el, because your hypothesis is that this is an Emacs28-related bug? Two things that stand out in your list to me are esxml, and markdown-mode, because these are elpa-only packages that don't overlap with files provided by emacs-el. Consequently, I wonder if this bug is on the dh-elpa side rather than the emacs-el side. I have the following list, with the notable omission of org mode, because I had uninstalled elpa-org before upgrading from bullseye to bookworm: /usr/share/emacs/site-lisp/elpa/seq-2.22/seq.elc /usr/share/emacs/site-lisp/elpa/seq-2.22/seq-25.elc /usr/share/emacs/site-lisp/elpa/git-commit-2.99.0/git-commit.elc /usr/share/emacs/site-lisp/elpa/dash-2.17.0/dash.elc /usr/share/emacs/site-lisp/elpa/transient-0.2.0.30/transient.elc /usr/share/emacs/site-lisp/elpa/async-1.9.3/async-bytecomp.elc /usr/share/emacs/site-lisp/elpa/async-1.9.3/async.elc /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc /usr/share/emacs/site-lisp/elpa/hl-todo-3.1.2/hl-todo.elc > There are broken symlinks to source files in the directory > /usr/share/emacs/site-lisp/elpa/org-9.4/ > The symlinks point to files in the directory > /usr/share/emacs/site-lisp/elpa-src/org-9.4/ which > does not exist. I suspect bullseye2bookworm is a trigger condition, and here an example of where things get weird: Given /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc # dpkg -S /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc dpkg-query: no path found matching pattern /usr/share/emacs/site-lisp/elpa/with-editor-3.0.2/with-editor.elc # cruft /usr/share/emacs/site-lisp/ returns no matches Cruft should find matches, but doesn't ! Yes, I've also done a full cruft run, and have grepped for with-editor, for example. One final bit of data: Your list has /usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode.elc but mine doesn't. I remember that I had manually upgraded to elpa-markdown 2.5 long ago, so this was the version that was present during the bullseye2bookworm upgrade. Consequently, it seems that the version of the elpa-foo package needs to change during bullseye2bookworm process in order to trigger this bug. 'hope this helps identify what's going on! Regards, Nicholas signature.asc Description: PGP signature
Bug#1040676: elpa-debian-el: Documentation fixes.
manp...@gmail.com writes: > I have a merge request on salsa[1] for documentation fixes for the > package elpa-debian-el. The first commit has typo fixes only, the > second one has some proposed wording fixes. Please review. Thanks! > > [1] https://salsa.debian.org/emacsen-team/debian-el/-/merge_requests/10 Thank you for these fixes! I've started a review. If for some reason I seem to take too long to notice that you've resolved all issues (when you've resolved them), please ping me at this bug. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1037135: please update to latest upstream version (>> 4.2.0) and confirm intent to maintain package
Hi Dhavan, Dhavan writes: > Thanks for dropping the email to this address, and apologies for causing > trouble by letting the previous address go dead. You're welcome. > I stopped updating the package because the docs of modus-themes are licensed > such that they cannot be added to Debian repos anymore. They'll have to be > split and moved to debian-contrib. I do not know how to do this, and haven't > looked into it since I last tried. I shall try to get it done soon(TM). > Bremner had suggested we can let go of the docs for now. If I cannot figure > things out in time, perhaps we can explore this path as well. > Minor correction: The docs would need to go into non-free, not contrib; however, If you wanted to make modus-themes depend on non-free docs, then elpa-modus-themes would need to be moved to contrib. Please note that the docs will also need their on source package. So in addition to src:modus-themes (in Debian main), you would also have src:modus-themes-docs (in non-free). I recommend using a "Suggests" from elpa-modus-themes, or a "Enhances" from the future non-free modus-themes docs. I agree with Bremner, and will add that the harm of shadowing the copy of modus-themes that is bundled in Emacs is greater than the usefulness of the docs. Elpa-modus-themes doesn't have a "-docs" package, so won't need to go through the NEW queue again. > In any case, I shall be attempting to upgrade soon. > You've got this! :) You're already using a gbp (git-buildpackage) style git repository so this is *very easy*. Just use the Files-Excluded feature of debian/control, and run "gbp import-orig --uscan". Regards, Nicholas signature.asc Description: PGP signature
Bug#1040787: dh-elpa: Lots of missing eln files
Sean Whitton writes: > async 1.9.3 is from buster. You have > /usr/share/emacs/site-lisp/elpa-async-1.9.7 on your system, right? > That's interesting, because that means that this is an old bug! See #1040690, which also appears to be this issue. So far the trigger condition appears to be a dist-upgrade (or full-upgrade). I wonder if the issue is on the emacs-el or dh-elpa side, or both? Cheers, Nicholas
Bug#1030394: reassign bug to correct package
reassign 1030394 dh-elpa retitle 1030394 dh-elpa: elpa-csv-mode 1.20 not cleaned up tags 1030394 - moreinfo - unreproducible thanks These bugs are the same type as #1040787. Thus far, the only trigger that we've been able to identify is a dist-upgrade (or full-upgrade) from bullseye to bookworm. I ran these in a 'su -' environment on real machines. It may be that the actual trigger condition is buster2bullseye2bookworm. #1040690, which is currently filed against emacs-el (with an "affects dh-elpa") appears to have the most activity as well as user-confirmed reproducibility. Note that this is a disruptive bug to users, who are having to resort to heavy-handed methods. To all affected users: Do you remember if you ever manually installed an affected elpa-package from sid/unstable or from testing? I'm curious if this might be part of the trigger condition. Likewise, do you remember if you installed dh-elpa from backports? While I think both of these cases are unlikely to have caused problems, one might as well be thorough! Regards, Nicholas signature.asc Description: PGP signature
Bug#1041824: src:volume-el: Enable merge request on salsa
Xiyue Deng writes: > Source: volume-el > Severity: wishlist > X-Debbugs-Cc: none, Xiyue Deng > > Dear maintainers, > > I have been trying to fix uscan error of Emacs addon packages. When > working on volume-el, I found that the repo on salsa didn't accept merge > requests while most other packages did. If it can open up merge request > access it would be great and I have some pending d/watch fixes. Thanks > in advance! This may indicate that the Uploader wants patches rather than MRs, and at the very least may indicate the Uploader doesn't want to monitor Salsa for MRs. You can use git-format-patch to prepare a patch series from your git history, and can attach those to a bug report here. To retitle this bug, but this as the first line in your reply (won't work with HTML email, of course): Control: retitle -1 src:volume-el: Useful subject of choice Control: tag -1 patch If you attach a patch, I recommend updating the metadata with that second line. Cheers, Nicholas signature.asc Description: PGP signature
Bug#1041824: src:volume-el: disable d/watch and sync to latest head version
Manphiz writes: >>> I have been trying to fix uscan error of Emacs addon packages. When >>> working on volume-el, I found that the repo on salsa didn't accept merge >>> requests while most other packages did. If it can open up merge request >>> access it would be great and I have some pending d/watch fixes. Thanks >>> in advance! >> >> This may indicate that the Uploader wants patches rather than MRs, and >> at the very least may indicate the Uploader doesn't want to monitor >> Salsa for MRs. >> > > Thanks for the explanation, Nicolas! Totally make sense. You're welcome! > Done. A little bit of explanation for the changes: > > * Upstream never had any tags, so uscan will always fail, so disable > d/watch for now. This will result in an empty uscan results. Why is breaking notification of any future upstream tags better than using uscan's git mode? Uscan's git mode will notify when upstream pushes any commit, with or without a tag. Help is available in #debian-mentors if writing an output format line that is suitable for volume-el's existing version scheme is too challenging. Regards, Nicholas
Bug#1042450: elpa-org: #+LANGUAGE: de-de is not working in LaTeX export
Control: tag -1 moreinfo Hello, H.-Dirk Schmitt writes: > Package: elpa-org > Version: 9.6.7+dfsg-1-c42-bpo-1 > Severity: normal > X-Debbugs-Cc: none, H.-Dirk Schmitt > > I use a backport from sid/trixie below bookworm. > In difference to the 9.5 version the setting `#+LANGUAGE: de-de` is not > working any more. > The option of the babel LaTeX package is in this case now empty. > > An easy mitigation is to use instead `de-de` the `de` language code. Have you eliminated issues pertaining to the new org-latex-language-alist? https://orgmode.org/Changes.html https://orgmode.org/manual/LaTeX-specific-export-settings.html https://orgmode.org/worg/org-irc.html > May somebody please check if this is a backport problem or reproducible in a > „clean“ trixie setup. $ rmadison elpa-org elpa-org | 9.1.14+dfsg-3 | oldoldstable | all elpa-org | 9.4.0+dfsg-1 | oldstable| all elpa-org | 9.5.2+dfsh-5 | stable | all elpa-org | 9.6.7+dfsg-1 | testing | all elpa-org | 9.6.7+dfsg-1 | unstable | all There are no other supported elpa-org versions in Debian. Please provide steps to reproduce (and/or an example file). Regards, Nicholas signature.asc Description: PGP signature
Bug#1042559: src:dash-el: Fix d/watch
Sean Whitton writes: > Thanks, applied. Just a quick note: please don't end commit messages > with periods, in the future. I've removed them. I'm wondering how to be supportive of your preferred style. If this… reply was a commit message, and this commit message ended at the following "mark" (minus end punctuation), then would you omit this question mark? And if the commit message didn't end at mark… This last sentence has no end punctuation, while other sentences do Kindly share your rationale, or at least steps to comply with your preferred style :) Cheers, Nicholas
Bug#815402: org-mode: * [[shell:cat ~/tmp | grep "asdf :: "]] does not work.
Control: tag -1 + upstream wontfix Control: forwarded -1 https://list.orgmode.org/20160222085952.GA32746@garlic/ Hello Max, Max Nikulin writes: > On Sun, 21 Feb 2016 11:37:01 +0100 Sébastien Delafond wrote: >> >> thanks for your report. As this seems to be a pure upstream problem, >> could you please follow up on it using the org-mode mailing list[0] ? >> Once that's done, feel free to add a link to your post in the Debian >> BTS. > > I think, this issue can be closed as not a bug: > > Nicolas Goaziou to emacs-orgmode. Re: * [[shell:cat ~/tmp | grep "asdf > :: "]] does not work. Wed, 24 Feb 2016 18:38:09 +0100 > https://list.orgmode.org/878u2a57r2@nicolasgoaziou.fr/T/#u > >> This is not a bug. - :: *is* description list syntax, no matter how >> you look at it. You can easily work around this, e.g., by starting the >> link on the next line. I read the thread upstream, and see what you mean, and upstream's perspective makes sense. How do you feel about keeping this bug open, because this "gotcha" should be documented somewhere. I'm not sure if org-mode's documentation would be the best place, because it's non-free. For future readers of this bug, Brian G Powell wrote some nice style suggestions for avoiding this pitfall, so here is the link: https://list.orgmode.org/CAFm0skF=3JNXQQPFYutEvM8y+FRZJziE+QngVX=gocx3rkq...@mail.gmail.com/#t > And a related issue: try to export text where /italics breaks the link > [[https://lists.debian.org/msgid-search/?m=zitsdg4dp0wxd...@powdarrmonkey.net][Bits > > from the Release Team: a trixie customer]] due to adjacent slash and > question mark./ Thank you for documenting this one too. > It is a price for lightweight markup and it is how org-element parser works. Indeed! Please go ahead and give this bug a more useful title. Regards, Nicholas signature.asc Description: PGP signature
Re: debhelper-compat 13 now have a writable "$HOME"
Manphiz writes: > Sean Whitton writes: >> On Wed 09 Aug 2023 at 02:23pm -07, Manphiz wrote: >> >>> While practicing some Emacsen packaging and getting assistance from >>> #debian-mentors, I noticed that with "debhelper-compat (=13)" it now >>> sets up a writable $HOME[1]. With this, Emacs with native compilation >>> doesn't need any specially handling during build or test anymore, at >>> least in dh_auto_*. However, currently dh-elpa doesn't use the same set >>> up as dh_auto_*[2] yet, so currently it will still cause failure in >>> targets like dh_elpa_test. Will the team consider to follow the same >>> convention so that $HOME becomes writable? I assume this will also make >>> it possible to drop the EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION >>> related patches. >> >> Debian Policy requires that package builds don't attempt to write into HOME. > > Indeed, found the item in section 4.9[1]. Though I do wonder what is > the reason that compat 13 starts to provide a writeable $HOME? > > [1] > https://www.debian.org/doc/debian-policy/ch-source.html#error-trapping-in-makefiles > https://bugs.debian.org/942111 https://bugs.debian.org/933799 Please note several pitfalls. One question I have after reading these is: Shouldn't Emacs itself gracefully handle an unset, nonexistent, or read-only $HOME gracefully? Cheers, Nicholas signature.asc Description: PGP signature
Re: debhelper-compat 13 now have a writable "$HOME"
Sean Whitton writes: > Hello, > > On Thu 10 Aug 2023 at 01:11pm -07, Manphiz wrote: > >> Thanks for the pointers! I think the reasons given in the bugs are >> essentially the same as the scenarios I gave in my other mail, >> especially when it is not Emacs itself but the client code that accesses >> $HOME. Would the team consider enabling it in dh-elpa given that no >> write is done to $HOME/$XDG_* so that no Policy violation happens? > > There's the risk of bugs here. Setting HOME to /nonexistent ensures > that unknown writing to HOME doesn't slip in in a future upload. +1 And as far as I know sbuild (which is used on buildds) always does this by default, and every build log will have this line near the top: HOME=/sbuild-nonexistent I wonder if it's always set up this way, or only when the 'sbuild-debian-developer-setup' package is used? Cheers, Nicholas signature.asc Description: PGP signature
Re: debhelper-compat 13 now have a writable "$HOME"
Manphiz writes: > Sean Whitton writes: > >> >> Debian Policy requires that package builds don't attempt to write into HOME. > > Indeed, found the item in section 4.9[1]. Though I do wonder what is > the reason that compat 13 starts to provide a writeable $HOME? > My guess would be for experiments/debugging; although, this compat 13 feature you've mentioned sounds a lot like a Policy footgun. signature.asc Description: PGP signature
Bug#809931: org-mode: Correction to report
Hello Reuben, Reuben Thomas writes: > Package: org-mode > Version: 8.3.2-1 > Followup-For: Bug #809931 > > The correct value for org-odt-data-dir is actually > > /usr/share/emacs/site-lisp/org-mode/etc > > (not …/styles as I previously said). Wow, it seems no one saw this bug for quite some time... I recently did some Debian Emacsen Team uploads for org-mode, and I noticed that the following are not currently installed in the elpa-org package: etc/csl/locales-en-US.xml etc/styles/OrgOdtContentTemplate.xml etc/styles/OrgOdtStyles.xml however, emacs-common installs this: /usr/share/emacs/28.2/etc/org/OrgOdtStyles.xml Do you know if the copy bundled with Emacs is sufficient, or if we should be setting org-odt-data-dir to a value specific to elpa-org? Regards, Nicholas signature.asc Description: PGP signature
Bug#1050350: flycheck: keep flycheck out of testing until it finds an uploader
Manphiz writes: > control: merge 1050404 -1 > control: block -1 by 1050459 > control: tags -1 patch > > Hi, > > I've prepared an MR[1] to handle this, which requires a newer > emacs-buttercup which is being prepared at [2]. PTAL. > > [1] https://salsa.debian.org/emacsen-team/flycheck/-/merge_requests/3 > [2] https://salsa.debian.org/emacsen-team/emacs-buttercup/-/merge_requests/1 Belated thank you! I think it's completely just that a package whose popularity is at the 99.86th percentile on MELPA and the 96.41th on MELPA stable blocks a transition, and that your work enabled a more ideal resolution of this situation. Cheers, Nicholas signature.asc Description: PGP signature
Re: Packages marked as testing auto-removel due to bug#999962
Manphiz writes:
>>
>> 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 '/<>'
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 -l wgrep-test.el --eval
\(ert-run-tests-batch-and-exit\)
Error: error ("Test ‘wgrep-normal’ redefined")
mapbacktrace(#f(compiled-function (evald func args flags) #))
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 (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 fn-122
#'signal) (list (car err) (cdr err))) (let ((value-124
'ert-form-evaluation-aborted-125)) (let (form-description-126) (if
(unwind-protect (setq value-124 (apply fn-122 args-123)) (setq
form-description-126 (nconc (list '(should (re-search-forward "^grep" nil t)))
(list :form (cons fn-122 args-123)) (if (eql value-124
'ert-form-evaluation-aborted-125) nil (list :value value-124)) (if (eql
value-124 'ert-form-evaluation-aborted-125) nil (let* ((-explainer- (and t
(ert--get-explainer 're-search-forward (if -explainer- (list :explanation
(apply -explainer- args-123)) nil) (ert--signal-should-execution
form-description-126)) nil (ert-fail form-description-126))) value-124)) (let*
((fn-127 #'delete-char) (args-128 (condition-case err (let
((signal-hook-function #'ert--should-signal-hook)) (list 1)) (error (progn
(setq fn-127 #'signal) (list (car err) (cdr err))) (let ((value-129
'ert-form-evaluation-aborted-130)) (let (form-description-131) (let ((errorp132
nil) (form-description-fn-133 #'(lambda nil form-description-131)))
(condition-case -condition- (unwind-protect (setq value-129 (apply fn-127
args-128)) (setq form-description-131 (nconc (list '(should-error (delete-char
1) :type 'text-read-only)) (list :form (cons fn-127 args-128)) (if (eql
value-129 'ert-form-evaluation-aborted-130) nil (list :value value-129)) (if
(eql value-129 'ert-form-evaluation-aborted-130) nil (let* ((-explainer- (and t
(ert--get-explainer 'delete-char (if -explainer- (list :explanation (apply
-explainer- args-128)) nil) (ert--signal-should-execution
form-description-131)) (error (setq errorp132 t)
(ert--should-error-handle-error form-description-fn-133 -condition-
'text-read-only nil) (setq value-129 -condition-))) (if errorp132 nil (ert-fail
(append (funcall form-description-fn-133) (list :fail-reason "did not signal an
error")) value-129)) (let* ((fn-134 #'re-search-forward) (args-135
(condition-case err (let ((signal-hook-function #'ert--should-signal-hook))
(list "HOGE" nil t)) (error (progn (setq fn-134 #'signal) (list (car err) (cdr
err))) (let ((value-136 'ert-form-evaluation-aborted-137)) (let
(form-description-138) (if (unwind-protect (setq value-136 (apply fn-134
args-135)) (setq form-description-138 (nconc (list '(should (re-search-forward
"HOGE" nil t))) (list :form (cons fn-134 args-135)) (if (eql value-136
'ert-form-evaluation-aborted-137) nil (list :value value-136)) (if (eql
value-136 'ert-form-evaluation-aborted-137) nil (let* ((-explainer- (and t
(ert--get-explainer 're-search-forward (if -explainer- (list :explanation
(apply -explainer- args-135)) nil) (ert--signal-should-execution
form-description-138)) nil (ert-fail form-description-138))) value-136))
(wgrep-mark-deletion) (let* ((fn-139 #'re-search-forward) (args-140
(condition-case err (let ((signal-hook-function #'ert--should-signal-hook))
(list "FOO" nil t)) (error (progn (setq fn-139 #'signal) (list (car err) (cdr
err))) (let ((value-141 'ert-form-evaluation-aborted-142)) (let
(form-description-143) (if (unwind-protect (setq value-141 (apply fn-139
args-140)) (setq form-description-143 (nconc (list '(should (re-search-forward
"FOO" nil t))) (list :form (cons fn-139 args-140)) (if (eql
Re: Packages marked as testing auto-removel due to bug#999962
Manphiz writes: > Nicholas D Steeves writes: > >> Manphiz writes: >> >> To be fair, the following issue wasn't introduced by this MR, but was [snip] >> 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 >> wgrep-subtest.el -l wgrep-test.el --eval \(ert-run-tests-batch-and-exit\) >> returned exit code 255 >> 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 :) This looks probably native-comp/trampoline-related to me, so I'm guessing wgrep advises something. No idea why why the issues presents in emacs29 but not in emacs28. > 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 signature.asc Description: PGP signature
Re: RFS to solve bug#999962 (silversearcher-ag: depends on obsolete pcre3 library)
Manphiz writes: > Manphiz writes: >> Manphiz 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=62#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 signature.asc Description: PGP signature
