Debian Bug report logs - #868609
le FTBFS with latest ncurses

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: le FTBFS with latest ncurses

Date: Mon, 17 Jul 2017 02:48:27 +0300

Source: le
Version: 1.16.3-1
Severity: serious
Tags: buster sid

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html

...
gcc -DHAVE_CONFIG_H -I. -I../lib  -I../lib -I../lib -I/usr/include/ncursesw -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc
color.cc: In function 'int find_pair(int, int)':
color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and later 'static' [-fpermissive]
 static int find_pair(int fg,int bg)
            ^~~~~~~~~
In file included from edit.h:36:0,
                 from color.cc:27:
/usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int find_pair(int, int)'
 extern NCURSES_EXPORT(int) find_pair (int, int);
                            ^~~~~~~~~
Makefile:1299: recipe for target 'color.o' failed
make[3]: *** [color.o] Error 1

Message #10 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Alexander V. Lukyanov" <lav@netis.ru>

To: Adrian Bunk <bunk@debian.org>, 868609@bugs.debian.org

Cc: Debian Bug Tracking System <submit@bugs.debian.org>, bug-ncurses@gnu.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Mon, 17 Jul 2017 11:43:35 +0300

On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote:
> Source: le
> Version: 1.16.3-1
> Severity: serious
> Tags: buster sid
>
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html
>
> ...
> gcc -DHAVE_CONFIG_H -I. -I../lib  -I../lib -I../lib -I/usr/include/ncursesw -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc
> color.cc: In function 'int find_pair(int, int)':
> color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and later 'static' [-fpermissive]
>  static int find_pair(int fg,int bg)
>             ^~~~~~~~~
> In file included from edit.h:36:0,
>                  from color.cc:27:
> /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int find_pair(int, int)'
>  extern NCURSES_EXPORT(int) find_pair (int, int);
>                             ^~~~~~~~~
> Makefile:1299: recipe for target 'color.o' failed
> make[3]: *** [color.o] Error 1

ncurses was extended with new symbols, some of which conflict with "le"
internal names. So either ncurses should be fixed not to export these
symbols by default or le should be fixed to rename its identifiers.

--
   Alexander.

Message #20 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Thomas Dickey <dickey@his.com>

To: 868609@bugs.debian.org

Cc: 868609-submitter@bugs.debian.org, bug-ncurses@gnu.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Mon, 17 Jul 2017 05:28:09 -0400

[Message part 1 (text/plain, inline)]

On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote:
> On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote:
> > Source: le
> > Version: 1.16.3-1
> > Severity: serious
> > Tags: buster sid
> >
> > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html
> >
> > ...
> > gcc -DHAVE_CONFIG_H -I. -I../lib  -I../lib -I../lib -I/usr/include/ncursesw -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc
> > color.cc: In function 'int find_pair(int, int)':
> > color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and later 'static' [-fpermissive]
> >  static int find_pair(int fg,int bg)
> >             ^~~~~~~~~
> > In file included from edit.h:36:0,
> >                  from color.cc:27:
> > /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int find_pair(int, int)'
> >  extern NCURSES_EXPORT(int) find_pair (int, int);
> >                             ^~~~~~~~~
> > Makefile:1299: recipe for target 'color.o' failed
> > make[3]: *** [color.o] Error 1
> 
> ncurses was extended with new symbols, some of which conflict with "le"
> internal names. So either ncurses should be fixed not to export these
> symbols by default or le should be fixed to rename its identifiers.

hmm - not that I'm oblivious to the problem, but (for example) a quick
check on an alternate name "find_color_pair" finds existing usage too.
This problem will come up since there's no namespaces in C (not that
C++ is free from the problem).

So... I could look for a rarely-used name (which still gives the same
connotations), or the couple of applications using ncurses could be
modified.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[signature.asc (application/pgp-signature, inline)]

Message #28 received at 868609@bugs.debian.org (full text, mbox, reply):

From: "Alexander V. Lukyanov" <lav@netis.ru>

To: dickey@his.com, 868609@bugs.debian.org

Cc: 868609-submitter@bugs.debian.org, bug-ncurses@gnu.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Mon, 17 Jul 2017 14:51:22 +0300

On Mon, Jul 17, 2017 at 05:28:09AM -0400, Thomas Dickey wrote:
> On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote:
> > On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote:
> > > Source: le
> > > Version: 1.16.3-1
> > > Severity: serious
> > > Tags: buster sid
> > >
> > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html
> > >
> > > ...
> > > gcc -DHAVE_CONFIG_H -I. -I../lib  -I../lib -I../lib -I/usr/include/ncursesw -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wwrite-strings -Woverloaded-virtual -fno-exceptions -fno-rtti -fno-implement-inlines -c -o color.o color.cc
> > > color.cc: In function 'int find_pair(int, int)':
> > > color.cc:36:12: error: 'int find_pair(int, int)' was declared 'extern' and later 'static' [-fpermissive]
> > >  static int find_pair(int fg,int bg)
> > >             ^~~~~~~~~
> > > In file included from edit.h:36:0,
> > >                  from color.cc:27:
> > > /usr/include/ncursesw/curses.h:924:28: note: previous declaration of 'int find_pair(int, int)'
> > >  extern NCURSES_EXPORT(int) find_pair (int, int);
> > >                             ^~~~~~~~~
> > > Makefile:1299: recipe for target 'color.o' failed
> > > make[3]: *** [color.o] Error 1
> >
> > ncurses was extended with new symbols, some of which conflict with "le"
> > internal names. So either ncurses should be fixed not to export these
> > symbols by default or le should be fixed to rename its identifiers.
>
> hmm - not that I'm oblivious to the problem, but (for example) a quick
> check on an alternate name "find_color_pair" finds existing usage too.
> This problem will come up since there's no namespaces in C (not that
> C++ is free from the problem).
>
> So... I could look for a rarely-used name (which still gives the same
> connotations), or the couple of applications using ncurses could be
> modified.

What about a separate include file for curses extensions, somthing like
ncurses_ext.h? This way any new identifiers won't conflict with legacy code.

Other common way to avoid conflicts is prefixing the identifiers.
nc_find_pair is much less likely to conflict.

--
   Alexander.

Message #36 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Thomas Dickey <dickey@his.com>

To: "Alexander V. Lukyanov" <lav@netis.ru>

Cc: 868609@bugs.debian.org, 868609-submitter@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Sat, 22 Jul 2017 10:43:07 -0400

[Message part 1 (text/plain, inline)]

On Mon, Jul 17, 2017 at 02:51:22PM +0300, Alexander V. Lukyanov wrote:
> On Mon, Jul 17, 2017 at 05:28:09AM -0400, Thomas Dickey wrote:
> > On Mon, Jul 17, 2017 at 11:43:35AM +0300, Alexander V. Lukyanov wrote:
> > > On Mon, Jul 17, 2017 at 02:48:27AM +0300, Adrian Bunk wrote:
> > > > Source: le
> > > > Version: 1.16.3-1
> > > > Severity: serious
> > > > Tags: buster sid
> > > >
> > > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/le.html

This is a problem with "le".  I'm reassigning to that program, along with
a patch to fix the issues I found.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[signature.asc (application/pgp-signature, inline)]

Message #48 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Thomas Dickey <dickey@his.com>

To: 868609@bugs.debian.org

Cc: 868609-submitter@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Sat, 22 Jul 2017 10:52:19 -0400

[Message part 1 (text/plain, inline)]

To ensure that I made a correct fix, I test-compiled le-1.16.3 and ran it.
Doing that, I noticed some additional issues (partly because I did not
override the makefile's C++ variables, but that was just as well, since
it prompted me to do the extra fixes):

a) renamed the private symbol find_pair to find_or_init_pair
b) include unistd.h to get prototype for write()
c) add a cast to fix a signed/unsigned compiler warning
d) add (to help with running valgrind) the ExitProgram macro
e) fix a different fail-to-build with the opaque TERMTYPE

Having done that, in a quick check the menus came up, and valgrind
had only reported an issue with linux_process_key() which I suppose
Alexander is familiar with.

There are still more than a hundred compiler warnings.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[le-1.16.3-fix.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #60 received at 868609@bugs.debian.org (full text, mbox, reply):

From: "Alexander V. Lukyanov" <lav@netis.ru>

To: dickey@his.com

Cc: 868609@bugs.debian.org, 868609-submitter@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Tue, 25 Jul 2017 10:04:02 +0300

On Sat, Jul 22, 2017 at 10:52:19AM -0400, Thomas Dickey wrote:
> c) add a cast to fix a signed/unsigned compiler warning

I will check if a newer/better version of regex.c if available in emacs (it was taken from there).

> d) add (to help with running valgrind) the ExitProgram macro

Where is HAVE__NC_FREE_AND_EXIT defined?

> e) fix a different fail-to-build with the opaque TERMTYPE

I don't see how these lines are equivalent:

-   TERMTYPE *tp = &cur_term->type;
+   TERMTYPE *tp = (TERMTYPE *)(&cur_term);

Can you elaborate?

--
   Alexander.

Message #68 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Thomas Dickey <dickey@his.com>

To: 868609@bugs.debian.org

Cc: 868609-submitter@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Tue, 25 Jul 2017 04:55:54 -0400

[Message part 1 (text/plain, inline)]

On Tue, Jul 25, 2017 at 10:04:02AM +0300, Alexander V. Lukyanov wrote:
> On Sat, Jul 22, 2017 at 10:52:19AM -0400, Thomas Dickey wrote:
> > c) add a cast to fix a signed/unsigned compiler warning
> 
> I will check if a newer/better version of regex.c if available in emacs (it was taken from there).
> 
> > d) add (to help with running valgrind) the ExitProgram macro
> 
> Where is HAVE__NC_FREE_AND_EXIT defined?

It would be defined if you had (an optional) configure check for
_nc_free_and_exit.

I do this for example when debugging ncurses applications and want to check
for memory leaks.  But see

http://invisible-island.net/ncurses/ncurses.faq.html#config_leaks

> > e) fix a different fail-to-build with the opaque TERMTYPE
> 
> I don't see how these lines are equivalent:
> 
> -   TERMTYPE *tp = &cur_term->type;
> +   TERMTYPE *tp = (TERMTYPE *)(&cur_term);

They're the same because the first member of TERMINAL happens to be
a TERMTYPE, and since TERMINAL is opaque in current code (so you
cannot refer to the "type" member any longer).

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[signature.asc (application/pgp-signature, inline)]

Message #76 received at 868609@bugs.debian.org (full text, mbox, reply):

From: "Alexander V. Lukyanov" <lav@netis.ru>

To: dickey@his.com, 868609-quiet@bugs.debian.org

Cc: 868609@bugs.debian.org, 868609-submitter@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Tue, 25 Jul 2017 13:19:16 +0300

On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote:
> > > e) fix a different fail-to-build with the opaque TERMTYPE
> >
> > I don't see how these lines are equivalent:
> >
> > -   TERMTYPE *tp = &cur_term->type;
> > +   TERMTYPE *tp = (TERMTYPE *)(&cur_term);
>
> They're the same because the first member of TERMINAL happens to be
> a TERMTYPE, and since TERMINAL is opaque in current code (so you
> cannot refer to the "type" member any longer).

But shouln't it be (TERMTYPE *)(cur_term) ?

Is there a new function or macro to get current TERMTYPE, so that I could
use it if available?

--
   Alexander.

Message #89 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Thomas Dickey <dickey@his.com>

To: 868609@bugs.debian.org

Cc: 868609-submitter@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Wed, 26 Jul 2017 05:18:57 -0400

[Message part 1 (text/plain, inline)]

On Tue, Jul 25, 2017 at 01:19:16PM +0300, Alexander V. Lukyanov wrote:
> On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote:
> > > > e) fix a different fail-to-build with the opaque TERMTYPE
> > >
> > > I don't see how these lines are equivalent:
> > >
> > > -   TERMTYPE *tp = &cur_term->type;
> > > +   TERMTYPE *tp = (TERMTYPE *)(&cur_term);
> >
> > They're the same because the first member of TERMINAL happens to be
> > a TERMTYPE, and since TERMINAL is opaque in current code (so you
> > cannot refer to the "type" member any longer).
> 
> But shouln't it be (TERMTYPE *)(cur_term) ?

hmm - I agree that doesn't look right (the problem with casts).
I'm surprised it worked.
 
> Is there a new function or macro to get current TERMTYPE, so that I could
> use it if available?

Not syntactically the same.  This is what I use in term.h:

/* The cast works because TERMTYPE is the first data in TERMINAL */
#define CUR ((TERMTYPE *)(cur_term))->

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[signature.asc (application/pgp-signature, inline)]

Message #97 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Thomas Dickey <dickey@his.com>

To: 868609@bugs.debian.org

Cc: 868609-submitter@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Sun, 30 Jul 2017 17:53:21 -0400

[Message part 1 (text/plain, inline)]

On Wed, Jul 26, 2017 at 05:18:57AM -0400, Thomas Dickey wrote:
> On Tue, Jul 25, 2017 at 01:19:16PM +0300, Alexander V. Lukyanov wrote:
> > On Tue, Jul 25, 2017 at 04:55:54AM -0400, Thomas Dickey wrote:
> > > > > e) fix a different fail-to-build with the opaque TERMTYPE
> > > >
> > > > I don't see how these lines are equivalent:
> > > >
> > > > -   TERMTYPE *tp = &cur_term->type;
> > > > +   TERMTYPE *tp = (TERMTYPE *)(&cur_term);
> > >
> > > They're the same because the first member of TERMINAL happens to be
> > > a TERMTYPE, and since TERMINAL is opaque in current code (so you
> > > cannot refer to the "type" member any longer).
> > 
> > But shouln't it be (TERMTYPE *)(cur_term) ?
> 
> hmm - I agree that doesn't look right (the problem with casts).
> I'm surprised it worked.

attaching an improved patch (with some additional compiler-warning fixes)

sadly enough, either way the cast gives no warnings, and the program
appears to run.

also attaching a copy of valgrind log from running the program with
the _nc_free_and_exit function turned on (just from opening a file,
looking at some menus and quitting - ymmv).

> > Is there a new function or macro to get current TERMTYPE, so that I could
> > use it if available?
> 
> Not syntactically the same.  This is what I use in term.h:
> 
> /* The cast works because TERMTYPE is the first data in TERMINAL */
> #define CUR ((TERMTYPE *)(cur_term))->

I'm reluctant to add a new function for accessing things that "should"
just work: the definitions in term.h are the defined interface, and
providing a function to access those in a different way doesn't seem
a good solution.

Of course, if that structure hadn't happened to be first in TERMINAL,
I'd have had to provide a function, just to keep TERMINAL opaque.

Since I'm keeping binary compatibility (aside from preventing applications
from knowing how large TERMINAL is), it's good enough for now.

-- 
Thomas E. Dickey <dickey@invisible-island.net>
http://invisible-island.net
ftp://invisible-island.net

[le-1.16.3-fix2.patch (text/x-diff, attachment)]

[valgrind.log (text/plain, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #105 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: "Alexander V. Lukyanov" <lav@netis.ru>

Cc: 868609@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Fri, 18 Aug 2017 12:39:00 +0200

Alexander,

Do you plan to make a new release with the fixes? or should I grab the
patches from github?

I'd like to fix this some time soon to get le back in testing.

Thanks in advance.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #110 received at 868609@bugs.debian.org (full text, mbox, reply):

From: "Alexander V. Lukyanov" <lav@netis.ru>

To: Raphael Geissert <geissert@debian.org>

Cc: 868609@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Mon, 21 Aug 2017 10:06:14 +0300

On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote:
> Do you plan to make a new release with the fixes? or should I grab the
> patches from github?

I'm going to release next version soon. I'm only waiting for a feedback
from a NetBSD user (compilation problem).

--
   Alexander.

Message #115 received at 868609@bugs.debian.org (full text, mbox, reply):

From: "Alexander V. Lukyanov" <lav@netis.ru>

To: Raphael Geissert <geissert@debian.org>

Cc: 868609@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Wed, 23 Aug 2017 15:56:31 +0300

On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote:
> Do you plan to make a new release with the fixes? or should I grab the
> patches from github?

1.16.5 has been released.

--
   Alexander.

Message #120 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Raphael Geissert <geissert@debian.org>

To: "Alexander V. Lukyanov" <lav@netis.ru>

Cc: 868609@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Wed, 23 Aug 2017 16:27:46 +0200

On 23 August 2017 at 14:56, Alexander V. Lukyanov <lav@netis.ru> wrote:
> On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote:
>> Do you plan to make a new release with the fixes? or should I grab the
>> patches from github?
>
> 1.16.5 has been released.

Awesome, thanks. I'll take care of the upload.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net

Message #125 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Boyuan Yang <073plan@gmail.com>

To: Raphael Geissert <geissert@debian.org>

Cc: 868609@bugs.debian.org

Subject: Re: Bug#868609: le FTBFS with latest ncurses

Date: Tue, 24 Apr 2018 23:53:05 +0800

[Message part 1 (text/plain, inline)]

X-Debbugs-CC: lav@netis.ru

在 2017年8月23日星期三 CST 下午10:27:46，您写道：
> On 23 August 2017 at 14:56, Alexander V. Lukyanov <lav@netis.ru> wrote:
> > On Fri, Aug 18, 2017 at 12:39:00PM +0200, Raphael Geissert wrote:
> >> Do you plan to make a new release with the fixes? or should I grab the
> >> patches from github?
> > 
> > 1.16.5 has been released.
> 
> Awesome, thanks. I'll take care of the upload.
> 
> Cheers,

Hi Raphael,

I noticed that the new version of le with fix has been released for a while 
but no uploads have been made yet. Do you have spare time to fix this bug and 
upload a new version recently?

Thanks,
Boyuan Yang

[signature.asc (application/pgp-signature, inline)]

Message #132 received at 868609@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: 868609@bugs.debian.org

Subject: le: diff for NMU version 1.16.5-0.1

Date: Mon, 20 Aug 2018 06:19:16 +0300

[Message part 1 (text/plain, inline)]

Control: tags 868609 + pending

[Replace 15 with correct value]

Dear maintainer,

I've prepared an NMU for le (versioned as 1.16.5-0.1) and uploaded
it to DELAYED/15. Please feel free to tell me if I should cancel it.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

[le-1.16.5-0.1-nmu.diff (text/x-diff, attachment)]

Message #139 received at 868609-close@bugs.debian.org (full text, mbox, reply):

From: Adrian Bunk <bunk@debian.org>

To: 868609-close@bugs.debian.org

Subject: Bug#868609: fixed in le 1.16.5-0.1

Date: Tue, 04 Sep 2018 04:18:58 +0000

Source: le
Source-Version: 1.16.5-0.1

We believe that the bug you reported is fixed in the latest version of
le, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 868609@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Adrian Bunk <bunk@debian.org> (supplier of updated le package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Mon, 20 Aug 2018 05:37:52 +0300
Source: le
Binary: le
Architecture: source
Version: 1.16.5-0.1
Distribution: unstable
Urgency: medium
Maintainer: Raphael Geissert <geissert@debian.org>
Changed-By: Adrian Bunk <bunk@debian.org>
Description:
 le         - Text editor with block and binary operations
Closes: 868609
Changes:
 le (1.16.5-0.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * New upstream release.
     - Fixes FTBFS with ncurses 6. (Closes: #868609)
   * Upstream ships a .dektop entry, remove the Debian menu entry.
Checksums-Sha1:
 ffd5ddacbacd834d9c0811ff2f35b5fb6d57055c 1983 le_1.16.5-0.1.dsc
 882ab2026cb138481405fa8588d77a376d4f8a70 678920 le_1.16.5.orig.tar.xz
 a8c4c2acdb4511c8a4e0376ba8901f156f3807b7 155 le_1.16.5.orig.tar.xz.asc
 3a4a70d9cde10c76a47014b94adabd04cc4e6719 8300 le_1.16.5-0.1.debian.tar.xz
Checksums-Sha256:
 ba02b1f4b26216d445c91913aa0e424c870c4501619d5a4b4331c597f8bcfbae 1983 le_1.16.5-0.1.dsc
 258d586f83e8abd55144dc3f09d9ddaf6ef55e8a90543fdb0932fb77d089dd78 678920 le_1.16.5.orig.tar.xz
 15f88d3dc0ea733053abe5226e817abb8f987ddf4c71266bdca72ea18fe2b954 155 le_1.16.5.orig.tar.xz.asc
 7bf1bfa5856eed21e8dacc7c62d8146fbcd2b8614443df6692385cefe6e0bd76 8300 le_1.16.5-0.1.debian.tar.xz
Files:
 d00582d3eba2483aa1b85081b1b2ecb0 1983 editors optional le_1.16.5-0.1.dsc
 ff3841f35feafcb6249f322cc3e232ce 678920 editors optional le_1.16.5.orig.tar.xz
 dd54f91c19d961db85fe0cc67fcd5c53 155 editors optional le_1.16.5.orig.tar.xz.asc
 21e0a6e28ce368a1380bbf3b74dba223 8300 editors optional le_1.16.5-0.1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEOvp1f6xuoR0v9F3wiNJCh6LYmLEFAlt6MpQACgkQiNJCh6LY
mLE6Dw//ZZ/yXZ9zvqfyzFQWsJWWpkfXvAXDJKZTJ90S5n3TH3sR16/wd9QHjgIc
+AKNdsC8jGyFnekvQPNG92S1JL+Z1rTFWC+I8RkWb0EgzmCPF0L2raqFS/TRKAvp
E1rhrdDrHECK2idQQabC6HDTDVhBbhfyiZ/Fw7P4r5Qry9a8mxZcaYZIWYEfZ5AT
ozWLpOjzHIJ0+yAoJsiFDa2pqFwo6vazavun7+LMYOwlp2qaf4TlXcFh97O7hzyq
Y/zadzp6TncEe4nxfRJ0FdGDgPb2RHj20oTueh4bWU3nYYJa/Kyr34zhb7jm4wMg
imoviTap/r2aYnOmH1pMBl3K3hlDIWjUHThVkTohc50t4WHQgX4+dk1vlmDm1J7E
jkjU/zt1w/VjSqZYLtUWu5ksAWJBPP5vPJ0aB5Mo+sqGGszLqnoFTq32wGbkMeIc
XIk6Cqlsue9zARltTWkqmOk1DTjG5M12prj8cj10U5j9ceJk6C/1g8xiq2ncApLo
FDAGw+Dtc5VsvYTMU3yknjJPSxmq+vVH+zu6mbWI4CO4FRhby+CF2WBs7RC/bIE4
bzZ+fE97+/T5pVtGaXwkcjPdgJsKlqSXDDbVEJ9mHbIYRWMbGzsPQzKbOc0p+aBF
u1G/oQsfJUZXn5O+ovO77A5hluTpdIV/tuxfT3Js0yIh0qzNjfY=
=GTi4
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.