Your message dated Tue, 20 Sep 2022 23:25:37 +
with message-id
and subject line Bug#1020038: fixed in dash-el
2.19.1+git20220608.1.0ac1ecf+dfsg-1
has caused the Debian Bug report #1020038,
regarding dash-el: FTBFS: dash.el:615:8: Error: docstring wider than 80
characters
to be marked as
Source: dash-el
Version: 2.19.1+dfsg-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.
Relevant part (hopefully):
> mak
dash-el 2.19.1+dfsg-1 is marked for autoremoval from testing on 2022-06-30
It (build-)depends on packages with these RC bugs:
1011146: nvidia-graphics-drivers-tesla-470: CVE-2022-28181, CVE-2022-28183,
CVE-2022-28184, CVE-2022-28185, CVE-2022-28191, CVE-2022-28192
https://bugs.debian.org
Hello,
On Wed 23 Jan 2019 at 09:28AM +0100, Thomas Koch wrote:
> https://github.com/magnars/dash.el/releases
>
> I want to update lsp-mode to 6.0 but it relies on dash-el >= 2.15.0 which was
> released only yesterday.
>
> Do you think it's feasible to update dash-el (a
https://github.com/magnars/dash.el/releases
I want to update lsp-mode to 6.0 but it relies on dash-el >= 2.15.0 which was
released only yesterday.
Do you think it's feasible to update dash-el (and dash-functional) in the next
days? Would you like me to do it? Do you think it's
Hi List,
as discussed on IRC, I've made available a dh-elpa version of dash-el:
dget http://lot-of-stuff.info/debian/dash-el_2.12.1-2.dsc
Hoping it will help convince its maintainer to use dh-elpa.
--
Rémi Vanicat
David Bremner writes:
> Rémi Vanicat writes:
>
>> By the way, I converted magit to dh-elpa, but I didn't move its Debian
>> git repository (it still in collab-maint). Should I move it? Otherwise
>> we should add a wiki page on package not in the team git's repository.
>
> If we want to be able t
Rémi Vanicat writes:
> By the way, I converted magit to dh-elpa, but I didn't move its Debian
> git repository (it still in collab-maint). Should I move it? Otherwise
> we should add a wiki page on package not in the team git's repository.
If we want to be able to do global changes (including, b
David Bremner writes:
> Rémi Vanicat writes:
>>
>> I was wondering if it would not be the moment to ask the dash-el debian
>> package maintainer to switch to an elpa style package. We will have more
>> and more package depending on dash-el, and the sooner dash-el
David Bremner writes:
[...]
> There have been a few bugs in the maintainer scripts (postinst, prerm)
> generated by dh_elpa, and currently the only way to fix those bugs is to
> rebuild the package using a fixed dh_elpa. We could also optimistically
> assume that the rate of bugs in dh_elpa will
Sean Whitton writes:
>> 4) Another thing that has been suggested at some point is
>> auto-rebuilding team packages on a new dh-elpa upload. Because of the
>> generated maintainer scripts, this rebuilding is likely to continue to
>> be required, and it's not very nice for uploaders.
>
> Could you
Hello,
On Thu, Dec 17, 2015 at 11:19:09AM +0100, Rémi Vanicat wrote:
> I was wondering if it would not be the moment to ask the dash-el debian
> package maintainer to switch to an elpa style package. We will have more
> and more package depending on dash-el, and the sooner dash-el
Rémi Vanicat writes:
>
> I was wondering if it would not be the moment to ask the dash-el debian
> package maintainer to switch to an elpa style package. We will have more
> and more package depending on dash-el, and the sooner dash-el integrate
> into the elpa infrastructure, the
Sean Whitton writes:
> Hello,
>
Sorry, I'm not actually responding to your question
[...]
>
> After:
> ,
> | EMACSFLAGS = -L /usr/share/emacs/site-lisp/dash-el \
I was wondering if it would not be the moment to ask the dash-el debian
package maintainer to switch t
14 matches
Mail list logo
