"Barak A. Pearlmutter" writes:
> Upstream is moving the bbdb project repo from nongnu.org to ELPA-gnu
> which makes it official gnu.org. Or something like that. And so it
> seems like a good time to move the debian packaging repo from
> https://salsa.debian.org/debian/bbdb3.git to
> https://salsa
Xiyue Deng writes:
>
> +# Disable adding sub-directories to `load-path'
> +for DIR in ${el_dir}/*; do [ -d ${DIR} ] && touch ${DIR}/.nosearch; done
I wonder about quoting here. I tend to overquote in shell scripts, but
what if some subdirectory has whitespace in the name?
> +# Remove entries
Xiyue Deng writes:
> Source: racket-mode
> Version: 20240129git0
> Severity: important
>
> When working on updating the racket-mode package, I noticed that the
> Debian packaging work under "debian/" does not have a separate copyright
> clause. This is probably fine. However, upstream has updat
Xiyue Deng writes:
>> Friendly ping. Would really like to get this in before Trixie so that
>> dh-elpa is compatible with upstream ELPA.
>>
>
> Friendly ping. Would really like to make it in before Trixie freeze.
Is this an RC bug? because that's about all I have time for at the moment.
IOhannes m zmölnig (Debian/GNU) writes:
> Package: elpa-org
> Version: 9.7.11+dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> since i've upgraded elpa-org to 9.7.11+dfsg-1, I can no longer export my
> presentations to LaTeX/beamer.
>
> With the current version, when I try to export my slides (
Xiyue Deng writes:
> Package: emacs-goodies-el
> Version: 42.5
> Severity: wishlist
>
> Hi,
>
> emacs-goodies-el depends on a list of useful Emacs addons. While most
> of them are useful, it is less flexible that a user would have to
> install all of them even if some of the packages are not of
Xiyue Deng writes:
>
> So, I'd like to gather some feedback from folks: how do you think of
> enabling Salsa CI for all? Or maybe selective enable it for core
> packages or on demand as a start?
>
I guess I'm generally fine if you (or somebody) are committed to debugging any
salsaci
specific i
Xiyue Deng writes:
>
> Make sense. AIUI rebuild is not necessary for enabling this because
> currently there is no package depending on this feature, and before and
> after this patch existing package will behave the same. It is only
> making a difference when a package has source code in a sub
Xiyue Deng writes:
>
> I have tested running the previously failed tests, e.g. clojure-mode
> which uses buttercup and flycheck which uses both buttercup and ERT, and
> they are now passing using the new implementation.
>
Build failures are (relatively) fine. What I really want to avoid is
havin
Helmut Grohne writes:
> Source: cycle-quotes
> Severity: serious
> Justification: grab attention of maintainer
For the record, this "justification" is pretty infuriating, no matter
how well thought the rest of the message (which I am now not going to
read) might be.
Xiyue Deng writes:
> Xiyue Deng writes:
>
>> [[PGP Signed Part:Undecided]]
>> Sean Whitton writes:
>>
>>> Hello Xiyue,
>>>
>>> On Thu 25 Jul 2024 at 11:54pm -07, Xiyue Deng wrote:
>>>
I have prepared a patch at [3] and also attached. Please help review
and comment. I'll merge it onc
Xiyue Deng writes:
>
> Will re-evaluate if XEmacs compatibility would be dropped.
>
> [1]
> https://salsa.debian.org/emacsen-team/dpkg-dev-el/-/commit/132669ed6d6ee19a440234b943625da9cd6e2d9b
>
Does the package currently work (somehow?) with XEmacs? At least dh-elpa
byte compilation does not su
Package: org-mode
Version: 9.6.10+dfsg-1
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: debian-emacsen@lists.debian.org, Debian Security Team
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
In https://list.orgmode.org/87o7b3eczr@bzg.fr/T/#t, Ihor Rad
Source: emacs
Version: 29.2+1-2
Severity: grave
Tags: security upstream
Justification: user security hole
X-Debbugs-Cc: Debian Security Team ,
debian-emacsen@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
According to the 29.3 release notes
* Changes in Emacs 29.3
Emacs 29.3
Paul Gevers writes:
> Source: racket-mode
> Version: 20231222git0-1
> Severity: serious
> Control: close -1 20240129git0-1
> Tags: sid trixie
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
>
In principle the autopkgtest failure should be fixed with 20240129git0-2
just upl
"Debian Bug Tracking System" writes:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 1055860:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1055860.
>
The offending file is "org-secretary.el", which rebinds several keys
reserved for users
Package: elpa-org-contrib
Version: 0.4.2-1
Severity: normal
Tags: upstream
According to (info "(elisp) Key Binding Conventions")
Don’t define ‘C-c LETTER’ as a key in Lisp programs. Sequences
consisting of ‘C-c’ and a letter (either upper or lower case; ASCII
or non-ASCII) are res
d...@debian.org writes:
>
> He does not have his time, so I do it for him acked by him.
> But I do not have access right for Salsa emacsen-team.
>
> There are 2 ways:
>
> A. Can anyone grant my access to Salsa emacsen-team?
>If someone does that, I will replace him with QA group,
>orphan an
Nicholas D Steeves writes:
>
> David, do you think you'll be able to find time for this or do you want me
> to come back to it in a week or so?
I'm not likely to look at it soon, go ahead.
d
Lev Lamberov writes:
>> elpa-hl-todo has a versioned depends which is wrong.
>
> It is not wrong. It is as it is stated in the code, and as it is
> detected by dh-elpa.
>
> Personally, I don't see any problem here. The hl-todo-el package is just
> waiting for the latest upstream version of compla
Control: severity -1 important
David Bremner writes:
> Andreas Beckmann writes:
>
>> Package: compat-el
>> Version: 29.1.4.1-2
>> Severity: serious
>>
>> elpa-hl-todo/sid is currently uninstallable since it depends on
>> elpa-compat (>= 29.1.4.2).
Andreas Beckmann writes:
> Package: compat-el
> Version: 29.1.4.1-2
> Severity: serious
>
> elpa-hl-todo/sid is currently uninstallable since it depends on
> elpa-compat (>= 29.1.4.2).
>
>
> Andreas
Maybe it doesn't matter, but I don't think this is a serious bug in
compat.el. It's not like a it
Manphiz writes:
>
> Hi sten,
>
> When trying to pick a new upstream to rebase, I found that pulling
> either upstream repo will result in an incompatible git history versus
> the current debian/master branch on salsa. I wonder how I should handle
> this? Is it OK to force push to master? Will
There were a few bugs upgrading emacs-addon packages to bookworm
(e.g. #1040690). The symptom is that the elpa/foo-$version directory
created by the installation was not removed correctly on package
removal.
I have uploaded to experimental a new version of dh-elpa (last is 2.1.1)
meant to addres
>From an IRC discussion Helmut asked me to mention our use case for
dynamic file registration. In emacs addon packages we currently generate
byte-compiled .elc files and some symlinks at install time. It would be
very useful not to have to track and clean those up in an ad-hoc way.
Manphiz writes:
> Hmm, indeed I cannot reproduce this with "emacs -Q" either. Will see
> what could have caused this. Any tips on debugging?
The only thing I can think of is to bisect the packages you have enabled/loaded.
Control: tag -1 unreproducible
Xiyue Deng writes:
> Package: elpa-debian-el
> Version: 37.10
> Severity: normal
> X-Debbugs-Cc: none, Xiyue Deng
>
> I've encountered an error when using "M-x debian-bug" on certain binary
> package, such as linux-image-6.4.0-3-amd64. The error backtrace look
Source: flycheck
Severity: serious
Justification: Team decision
X-Debbugs-Cc: debian-emacsen@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Nobody has stepped up to take care of flycheck, and it currently
blocks the transition of emacs 29 to testing.
- -- System Information:
D
Aymeric Agon-Rambosson writes:
> For this reason, I have in my fork
> (https://salsa.debian.org/ricorambo/deb-emacs) a branch
> (rico-without-lars-patch) that simply drops patches 12 and 13.
>
> The experiment is the following : for every package maintained by
> the debian-emacsen team, a buil
Dan Jacobson writes:
> ⛔ Warning (comp): debian-el.el:90:26: Warning: reference to free variable
> ‘dired-mode-map’
> ⛔ Warning (comp): debian-el.el:95:35: Warning: docstring has wrong usage of
> unescaped single quotes (use \= or different quoting)
> ⛔ Warning (comp): debian-ispell.el:420:16:
Richard Lewis writes:
> I suspect a plain chroot isnt 'enough', i had success with systemd-nspawn:
>
> ln -s /tmp/bullseye/ /var/lib/machines
>
> # im sure there is a better way than these two lines
> cp /etc/passwd bullseye/etc/passwd
> cp /etc/shadow bullseye/etc/shadow
>
> systemd-nspawn --eph
David Bremner writes:
>>
>> chroot . apt install emacs elpa-helpful
Try the same set of steps without elpa-helpful, and the upgrade still
fails with
Install emacsen-common for emacs
emacsen-common: Handling install of emacsen flavor emacs
>>Error occurred pro
Richard Lewis writes:
> An attempt to reproduce - partially successful, maybe reveals deeper issues!
>
> su -
> mkdir /tmp/bullseye
> cd /tmp/bullseye
> debootstrap bullseye . https://deb.debian.org/debian
>
> chroot . apt install emacs elpa-helpful
>
> sed -i s/bullseye/bookworm/ ./etc/apt/sourc
Jeremy Sowden writes:
>
> Now that Bookworm is out and the freeze is over, I should be grateful
> for help with mutt-alias-el and muttrc-mode-el.
>
> Thanks,
>
> J.
I don't know if it hurts anything, but changing the section of a package
is (unfortunately) not as simple as editing debian/control.
Manphiz writes:
> Dear Emacsen Maintainers,
>
> It looks like a few Emacsen packages are marked as testing auto-removal
> due to bug#62[1]. It looks like this pcre to pcre2 migration is
> non-trivial, and the upstream of silversearcher-ag[2] seems to be silent
> since Dec. 2020. The list of
Bastien writes:
> Hi Nicholas,
>
> thanks for your answer.
>
> Nicholas D Steeves writes:
>
>> 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
Aymeric Agon-Rambosson writes:
> I would say that any directory in /usr/share/emacs/site-lisp/elpa
> that has no namesake in /usr/share/emacs/site-lisp/elpa-src, AND
> that is not provided itself by a package, should not be
> there. Sean, does that seem right to you, or is that too violent a
Package: maildir-utils
Version: 1.8.14-2
Severity: serious
Justification: violates policy 8.1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I think that libguile-mu.* need to be either moved to a private
directory or to their own packages. I don't know enough about guile to
say which is better.
Matthias Klose writes:
> Package: src:maildir-utils
> Version: 1.8.14-1
> Severity: normal
> Tags: sid trixie
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-13
>
> [This bug is targeted to the upcoming trixie release]
>
> Please keep this issue open in the bug tracker for the package i
Balbir Thomas writes:
> Thanks to bremner on IRC it was found that
> launching emacs disabling the init and site lisp file
> ("emacs -Q") seems to fix the issue i.e. org-export-dispatch
> does work and and exported file is generated.
I was thinking about this a bit more, and I wonder if the two
Balbir Thomas writes:
> As requested I am listing below all Emacs related
> packages installed. These list was generated using
> "dpkg --get-selections" and grepping for "emacs" and
> "elpa".
On IRC you later mentioned you duplicated the problem with a smaller set
of packages installed. It would
Control: reopen -1
Control: found -1 racket-mode/20230425git0-1
> The release team has announced [1] that failing autopkgtest on amd64 and
> arm64 are considered RC in testing. [Release Team member hat on] Because
> we're currently in the hard freeze for bookworm, I have marked this bug
> as
Paul Gevers writes:
> Source: racket-mode
> Version: 20210916git0-2
> Severity: serious
> Control: tags -1 bookworm-ignore
> User: debian...@lists.debian.org
> Usertags: regression
This bug should be fixed in testing as soon as the just-uploaded
20230425git0-2 migrates to testing (a few days?).
Salvatore Bonaccorso writes:
>
> Looking at https://security-tracker.debian.org/tracker/CVE-2023-28617
> I think we should be fine for bookworm already, correct?
Yes, I think what is there makes sense, given the constraints of
expressing a weird situation.
d
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 ther
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
Maxim Nikulin writes:
> Package: elpa-org
> Version: 9.5.2+dfsh-4
> Severity: serious
>
> Installing elpa-org package to current Debian testing (bookworm) results
> in older Org version than Org shipped with Emacs. I consider it as a
> really bad surprise for people who will upgrade from bullse
Control: tag -1 unreproducible
Control: severity -1 important
H.-Dirk Schmitt writes:
> Package: elpa-flycheck
> Version: 32~git.20200527.9c435db3-3
> Severity: grave
> X-Debbugs-Cc: none, H.-Dirk Schmitt
>
>
> The combination of Emacs28 + elpa-flycheck + shellcheck in *bookworm*
> spawn neve
Sven Joachim writes:
Control: severity -1 wishlist
> Package: elpa-debian-el
> Version: 37.10
> Severity: normal
>
> Visiting zstd compressed .deb files in deb-view mode-fails with a tar
> error, here is a backtrace after toggling debug-on-error.
Hi Sven;
At least until Debian is using zstd th
David Bremner writes:
> Adrian Bunk writes:
>
>>> FTR, the dates when epl started to FTBFS in sid and bookworm are
>>> a good match for when emacs 1:28.2+1-9 entered sid and bookworm:
>>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.
Adrian Bunk writes:
>> FTR, the dates when epl started to FTBFS in sid and bookworm are
>> a good match for when emacs 1:28.2+1-9 entered sid and bookworm:
>> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/epl.html
>
> Correct link:
> https://tests.reproducible-builds.org/debi
Sergio Durigan Junior writes:
> On Monday, February 27 2023, David Bremner wrote:
>
>> Sergio Durigan Junior writes:
>>>
>>> I was testing with an upstream build. For Debian's Emacs, we should
>>> use:
>>>
>>> buttercup --eval &q
Sergio Durigan Junior writes:
>
> I was testing with an upstream build. For Debian's Emacs, we should
> use:
>
> buttercup --eval "(setq comp-enable-subr-trampolines nil)" -L .
>
Did you get that working with the upstream version currently in master
or with a new upstream snapshot? I tried che
Sergio Durigan Junior writes:
> Agreed. I'm thinking about filing an RM bug against cycle-quotes; its
> last release happened 4 years ago (although there are some non-useful
> new commits on https://github.com/emacsmirror/cycle-quotes), it fails to
> build with Emacs 28, has been blocked for 790
David Bremner writes:
> I don't think these are the same as previously encountered
> native-compilation related failures. I get the same / similar failures
> when running
>
> EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l
> buttercup -f buttercup-ru
Package: wnpp
Severity: wishlist
Owner: David Bremner
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emacsen@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: elpa-gap-mode
Version : 2.1.0
Upstream Contact: Ivan Andrus
* URL
Sven Joachim writes:
>
> I have attached a patch which drops the extra second slash.
>
> Cheers,
>Sven
Thanks Sven, I'll most likely wait until after the freeze to apply that.
d
Dan Jacobson writes:
> Package: elpa-csv-mode
> Version: 1.21-1
>
> When I open a .csv file, I see:
>
> Warning (comp): Cannot look-up eln file as no source file was found
> for /usr/share/emacs/site-lisp/elpa/csv-mode-1.20/csv-mode.elc Disable
> showing Disable logging
That file is not present
Dan Jacobson writes:
> Package: dh-elpa-helper
> Version: 2.0.16
> Severity: minor
>
> I saw this:
> Warning (comp): Cannot look-up eln file as no source file was found for
> /usr/share/emacs/site-lisp/elpa/csv-mode-1.20/csv-mode.elc
Why do you think this is a bug in dh-elpa-helper?
Aymeric Agon-Rambosson writes:
> Hello David,
>
> Le dimanche 15 janvier 2023 à 07:05, David Bremner
> a écrit :
>
>> Apologies, I haven't had time to follow this discussion very
>> well, but I
>> should note setting EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPI
I don't think these are the same as previously encountered
native-compilation related failures. I get the same / similar failures
when running
EMACS_INHIBIT_AUTOMATIC_NATIVE_COMPILATION=t emacs -q -batch -L . -l buttercup
-f buttercup-run-discover
as a non-root user with a defined home director
Aymeric Agon-Rambosson writes:
>
> I have a patch for the remaining three failures. It was the
> trampoline compilation of the primitive buffer-list that made the
> three tests fail. This is similar to what I got in projectile. I
> am not exactly sure *how* the trampoline compilation makes the
Daniel Kahn Gillmor writes:
> Package: elpa-dpkg-dev-el
> Version: 37.9
>
> I'm using emacs 1:28.2+1-9 with the aforementioned elpa-dpkg-dev-el.
>
> I see the following entries in my *Warnings* buffer when editing debian
> packaging.
Yes, the new native compilation generates a log of warnings. S
Thorsten Alteholz writes:
> Hi David,
>
> one "The Org Contributors" is fine as well.
>
> Thorsten
Oh! Fixed in git, thanks.
d
Lucas Nussbaum writes:
> Source: epl
> Version: 0.9-5
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20230101 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
This seem
Jeremy Sowden writes:
> Nicholas Steeves has orphaned two Emacs add-ons:
>
> * muttrc-mode-el: https://bugs.debian.org/1005709
> * mutt-alias-el: https://bugs.debian.org/1005853
>
> I have been working on the Window Maker and Netfilter teams since 2019,
> and I became a DM twelve months ago.
Package: wnpp
Severity: wishlist
Owner: David Bremner
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emacsen@lists.debian.org
* Package name: elpa-ol-notmuch
Version : 2.0.0
Upstream Author (Maintainer) : Jonas Bernoulli
* URL : https://git.sr.ht/~tarsius/ol
Package: emacs
Version: 1:28.2+1-1
Severity: important
X-Debbugs-Cc: debian-emacsen@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Here's the reproducer (tested on a couple of different debian testing
/ unstable machines). This is with Debian's build of emacs 28.2. I
cannot repl
Lucas Nussbaum writes:
> Source: helpful-el
> Version: 0.19-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
thi
Lucas Nussbaum writes:
> Source: cycle-quotes
> Version: 0.1-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
Lucas Nussbaum writes:
> Source: yasnippet
> Version: 0.14.0+git20200603.5cbdbf0d-1
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
This seems unrelated to native compilation. At a guess, it is because
ema
Lucas Nussbaum writes:
> Source: pcre2el
> Version: 1.8-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
>
This
Lucas Nussbaum writes:
> Source: elisp-bug-hunter
> Version: 1.3.1+repack-5
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
>
Lucas Nussbaum writes:
> Source: emacs-deferred
> Version: 0.5.1-4
> Severity: serious
> Justification: FTBFS
> Tags: bookworm sid ftbfs
> User: lu...@debian.org
> Usertags: ftbfs-20220917 ftbfs-bookworm
>
> Hi,
>
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
This looks like a real bug though, unrelated to native compilation
Searched 1/1 files
passed 19/87 helpful--display-implementations (0.122235 sec)
passed 20/87 helpful--docstring (0.44 sec)
Test helpful--docstring-advice backtrace:
signal(ert-test-failed (((should (equal (helpful
here's the failed build with dh-elpa 2.0.12
dh_elpa_test
emacs -batch -Q -l package --eval "(setq
native-compile-target-directory \"/tmp/NpGLjk7chP\")" --eval "(add-to-list
'package-directory-list \"/usr/share/emacs/site-lisp/elpa\")" --eval
"(add-to-list 'package-directory-list \"/
Lev Lamberov writes:
> 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
Yavor Doganov writes:
> Package: elpa-jabber
> Version: 0.8.92+git98dc8e-7
> Severity: serious
>
> The upgrade from Emacs 27 to 28 aborts because byte-compilation of
> elpa-jabber fails with the following error(s):
>
> | In toplevel form:
> | jabber-vcard.el:67:1: Error: Wrong number of arguments
Package: wnpp
Severity: wishlist
Owner: David Bremner
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-emacsen@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
* Package name: elpa-srv
Version : 0.2
Upstream Author : Magnus Henoch
* URL : https
Package: dh-make-elpa
Version: 0.19.1
Severity: important
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
% git clone -o upstream https://github.com/legoscia/srv.el
% dh-make-elpa --pkg-emacsen
Can't locate object method "gecos" via package "bremner" (perhaps you forgot to
load "bremner"?) at /u
Package: emacs-nox
Version: 1:28.1+1-2
Severity: serious
Justification: does not install
X-Debbugs-Cc: debian-emacsen@lists.debian.org
Recipe to duplicate
===
(assuming schroot is set up in a more or less
standard way with a chroot called sid, and session support).
% schroot -c s
Diane Trout writes:
>
> Though debian-el might be a better example to follow where the info file
> and its dir file are added to the elpa-src directory.
>
Although that's my doing (I think) I have to note that it makes the info
files inaccessible to /usr/bin/info, so might not be an ideal soluti
Package: elpa-jabber
Version: 0.8.92+git98dc8e-7
Severity: wishlist
X-Debbugs-Cc: debian-emacsen@lists.debian.org
The fork at
https://codeberg.org/emacs-jabber/emacs-jabber
seems to be under active(-ish) development (it is now the repo melpa
points to).
-- System Information:
Debian Relea
Source: emacs-pdf-tools
Version: 1.0~20200512-2
Severity: wishlist
X-Debbugs-Cc: debian-emacsen@lists.debian.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
According to the current upstream,
PDF Tools is dead, long live PDF Tools. Development
continues with this fork:
Diane Trout writes:
> Package: elpa-geiser
> Version: 0.10-1
> Severity: normal
> X-Debbugs-Cc: none, Diane Trout
>
> Dear Maintainer,
>
> Hello I was trying to experiment with emacs-guix, but it failed looking
> for a geiser symbol.
>
> I looked the versions of geisers available in guix and fou
Package: wnpp
Severity: normal
X-Debbugs-Cc: debian-emacsen@lists.debian.org
Control: affects -1 src:geiser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I request an adopter for the geiser package.
I am not using the package any more, and consequently doing a bad job
of maintaining it. The pa
l.bonn...@laposte.net writes:
> Setting up elpa-f (0.20.0-3) ...
> tsort: -: input contains a loop:
> tsort: elpa-dash
> tsort: emacsen-common
> tsort: -: input contains a loop:
> tsort: emacsen-common
> tsort: elpa-s
Is there a user-visible problem other than these messages?
Nicholas D Steeves writes:
> 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. T
Package: elpa-message-templ
Version: 0.3.20161104-3
Severity: wishlist
Tags: upstream newcomer
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I've (finally) fixed the git hosting for message-templ and it should be stable
at
https://git.tethera.net/message-templ.git/
- -- System Information:
D
Lukas Märdian writes:
> Package: dh-elpa
> Version: 2.0.10
> Followup-For: Bug #1001452
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
> X-Debbugs-Cc: sl...@ubuntu.com
> Control: tags -1 patch
>
> Hello David,
>
> thank you for your comments, I've updated the p
Lukas Märdian writes:
> Package: dh-elpa
> Version: 2.0.10
> Severity: wishlist
> Tags: patch
> User: ubuntu-de...@lists.ubuntu.com
> Usertags: origin-ubuntu jammy ubuntu-patch
> X-Debbugs-Cc: sl...@ubuntu.com
>
> Hello David,
>
> the testing situation of dh-elpa isn't very good.
> I added a simp
Nicholas D Steeves writes:
> 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--i
"Paul W. Rankin" writes:
>
> Hello,
>
> There does not appear to be much enthusiasm to keep the Debian
> elpa-fountain-mode package at all up-to-date. As the upstream author I would
> appreciate if you would please remove it from Debian.
>
> Thank you.
Version 3.5.1 is now available in Debian u
Matthias Klose writes:
>
> dh-elpa doesn't work on package versions with buildN or ubuntuN suffixes,
> errors
> out with:
>
> Invalid version syntax: ‘0.49build1’
>
>
> patch at
> http://launchpadlibrarian.net/562638722/dh-elpa_2.0.8_2.0.8ubuntu1.diff.gz
>
> however the patch doesn't work yet, pa
Sean Whitton writes:
> On Tue 21 Sep 2021 at 01:26PM -03, David Bremner wrote:
>>
>> As long as Testsuite: autopkgtest-pkg-elpa is present in debian/control,
>> the binary packages are installed and hence byte compiled. Until the
>> upload 20210916git0-2, racket-mode
Sean Whitton writes:
> Hello,
>
> On Mon 20 Sep 2021 at 11:24AM -03, David Bremner wrote:
>
>> By the way, I realized that autopkgtest is already testing byte
>> compilation, even for tests disabled via debian/elpa-test. Maybe that's
>> enough, what do you
Control: retitle 994748 "disabled dh_elpa_test should mark autopkgtest
superficial"
So it turns out overriding "dh_elpa_test" works fine as way of disabling
build time tests while still running the tests as autopkgtests.
I still think it would be useful to mark tests where dh_elpa_test is
disabl
Sean Whitton writes:
> Package: dh-elpa
> Version: 1.15
> Severity: wishlist
>
> Hello,
>
> In addition to running upstream test suites, dh_elpa_test could test
> whether the package's elisp can be bytecompiled against the version of
> Emacs in sid -- Emacs is already a hard dependency of dh-elpa
Thanks to smcv on #debian-qa, I now understand a bit more what would be
involved in auto-marking tests as superficial.
1) (the easy part) Instead of exiting 0 when disabled, dh_elpa_test
should exit 77
2) support/elpa/generate in autodep8 would need to be updated to check
d/elpa-test (or
Package: dh-elpa
Version: 2.0.9
Severity: wishlist
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
As far as I can tell, overriding dh_auto_test does not stop running
the tests at build time; presumably that's why we support the
"disable" key in d/elpa-test. On the other hand setting that key
dis
1 - 100 of 333 matches
Mail list logo
