Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

[Rocky Bernstein]

That link is the correct one. I was comparing to
https://sources.debian.org/patches/libcdio/2.1.0-2/ncursesw.diff/  which is
different so I may have this wrong.

On Tue, Nov 2, 2021 at 5:47 PM Gabriel F. T. Gomes <
gabr...@inconstante.net.br> wrote:

> Hi, Rocky,
>
> On Tue, 2 Nov 2021 13:11:07 -0400
> Rocky Bernstein  wrote:
> >
> > Hmm - as best as I can tell this patches things a little differently than
> > what was done in the git codebase.
>
> That was not my intention.
>
> Actually, I don't understand why you say that.
>
> The patch that I backported to Debian is the one you mentioned in a
> previous message, i.e.:
>
> https://savannah.gnu.org/patch/index.php?10130
>
> What did I get wrong?
>
> Cheers,
> Gabriel
>

Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

[Rocky Bernstein]

Hmm - as best as I can tell this patches things a little differently than
what was done in the git codebase.

It looks like this changes to use library ncursesw whereas change in git
changes the source code and adjusts the source code so that  the previous
curses library is okay to use.

I don't have an opinion on which is preferable, but I note that the
mismatch might cause a problem down the line.


On Tue, Nov 2, 2021 at 12:49 PM Gabriel F. T. Gomes <
gabr...@inconstante.net.br> wrote:

> Hi, Rocky, Lucas,
>
> Thanks for doing all the hard work of reporting and fixing the bug.
> I have just uploaded a new version o libcdio with the fix.
>
> Cheers,
> Gabriel
>

Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

[Rocky Bernstein]

A patch was offered in https://savannah.gnu.org/patch/index.php?10130 and
applied in commit 2adb43c6 .

On Sat, Oct 23, 2021 at 3:12 PM Lucas Nussbaum  wrote:

> Source: libcdio
> Version: 2.1.0-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):
> > gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../lib/driver -I../include
> -I../include/   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings -c -o mmc-tool.o
> mmc-tool.c
> > cdda-player.c: In function ‘action’:
> > cdda-player.c:301:28: error: format not a string literal and no format
> arguments [-Werror=format-security]
> >   301 |   mvprintw(LINE_ACTION, 0, psz_action_line);
> >   |^~~
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings  -Wl,-z,relro
> -Wl,-z,now -o cd-drive cd-drive.o util.o getopt.o getopt1.o ../lib/iso9660/
> libiso9660.la ../lib/driver/libcdio.la  -lm
> > cdda-player.c: In function ‘display_tracks’:
> > cdda-player.c:1032:31: error: format not a string literal and no format
> arguments [-Werror=format-security]
> >  1032 | mvprintw(i_line++, 0, line);
> >   |   ^~~~
> > cdda-player.c:1035:31: error: format not a string literal and no format
> arguments [-Werror=format-security]
> >  1035 | mvprintw(i_line++, 0, line);
> >   |   ^~~~
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings  -Wl,-z,relro
> -Wl,-z,now -o cd-read cd-read.o util.o getopt.o getopt1.o ../lib/iso9660/
> libiso9660.la ../lib/driver/libcdio.la  -lm
> > libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wbad-function-cast -Wcast-align -Wchar-subscripts
> -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels
> -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wno-sign-compare -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef
> -Wunused -Wwrite-strings -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/cd-drive
> cd-drive.o util.o getopt.o getopt1.o  ../lib/iso9660/.libs/libiso9660.so
> ../lib/driver/.libs/libcdio.so -lm
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings  -Wl,-z,relro
> -Wl,-z,now -o iso-info iso-info.o util.o getopt.o getopt1.o ../lib/udf/
> libudf.la ../lib/iso9660/libiso9660.la ../lib/driver/libcdio.la  -lm
> > libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wbad-function-cast -Wcast-align -Wchar-subscripts
> -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels
> -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wno-sign-compare -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef
> -Wunused -Wwrite-strings -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/cd-read
> cd-read.o util.o getopt.o getopt1.o  ../lib/iso9660/.libs/libiso9660.so
> ../lib/driver/.libs/libcdio.so -lm
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> 

Bug#997166: libcdio: FTBFS: cdda-player.c:301:28: error: format not a string literal and no format arguments [-Werror=format-security]

[Rocky Bernstein]

The simplest thing to do would be to remove cdda-player. It is a standalone
utility program and one that probably is no longer useful since most
computers do not have CD drives that work as an independent analog CD
player which is what this program controls. (In the olden days CD drives
had an audio output jack on them that you could attach RCA-type headphones.)

Also if I recall correctly, standalone programs like this are packaged
separately, e.g libcdio-utils
.

On Sat, Oct 23, 2021 at 3:12 PM Lucas Nussbaum  wrote:

> Source: libcdio
> Version: 2.1.0-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):
> > gcc -DHAVE_CONFIG_H -I. -I..  -I.. -I../lib/driver -I../include
> -I../include/   -Wdate-time -D_FORTIFY_SOURCE=2  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings -c -o mmc-tool.o
> mmc-tool.c
> > cdda-player.c: In function ‘action’:
> > cdda-player.c:301:28: error: format not a string literal and no format
> arguments [-Werror=format-security]
> >   301 |   mvprintw(LINE_ACTION, 0, psz_action_line);
> >   |^~~
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings  -Wl,-z,relro
> -Wl,-z,now -o cd-drive cd-drive.o util.o getopt.o getopt1.o ../lib/iso9660/
> libiso9660.la ../lib/driver/libcdio.la  -lm
> > cdda-player.c: In function ‘display_tracks’:
> > cdda-player.c:1032:31: error: format not a string literal and no format
> arguments [-Werror=format-security]
> >  1032 | mvprintw(i_line++, 0, line);
> >   |   ^~~~
> > cdda-player.c:1035:31: error: format not a string literal and no format
> arguments [-Werror=format-security]
> >  1035 | mvprintw(i_line++, 0, line);
> >   |   ^~~~
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings  -Wl,-z,relro
> -Wl,-z,now -o cd-read cd-read.o util.o getopt.o getopt1.o ../lib/iso9660/
> libiso9660.la ../lib/driver/libcdio.la  -lm
> > libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wbad-function-cast -Wcast-align -Wchar-subscripts
> -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels
> -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wno-sign-compare -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef
> -Wunused -Wwrite-strings -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/cd-drive
> cd-drive.o util.o getopt.o getopt1.o  ../lib/iso9660/.libs/libiso9660.so
> ../lib/driver/.libs/libcdio.so -lm
> > /bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2
> -ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat
> -Werror=format-security  -Wall -Wbad-function-cast -Wcast-align
> -Wchar-subscripts -Wdeclaration-after-statement -Wdisabled-optimization
> -Wendif-labels -Winline -Wmissing-declarations -Wmissing-prototypes
> -Wnested-externs -Wno-sign-compare -Wpointer-arith -Wshadow
> -Wstrict-prototypes -Wundef -Wunused -Wwrite-strings  -Wl,-z,relro
> -Wl,-z,now -o iso-info iso-info.o util.o getopt.o getopt1.o ../lib/udf/
> libudf.la ../lib/iso9660/libiso9660.la ../lib/driver/libcdio.la  -lm
> > libtool: link: gcc -g -O2 -ffile-prefix-map=/<>=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wall
> -Wbad-function-cast -Wcast-align -Wchar-subscripts
> -Wdeclaration-after-statement -Wdisabled-optimization -Wendif-labels
> -Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs
> -Wno-sign-compare -Wpointer-arith -Wshadow -Wstrict-prototypes -Wundef
> -Wunused -Wwrite-strings -Wl,-z -Wl,relro -Wl,-z -Wl,now -o .libs/cd-read
> cd-read.o util.o getopt.o getopt1.o  ../lib/iso9660/.libs/libiso9660.so
> 

Bug#951020: zshdb: build-depends on emacs25

[Rocky Bernstein]

Hi -

I was tracking the progress of zshdb on Debian (which of course I use).

Some things to note. zshdb no longer uses GNU emacs. The GNU emacs
interface which includes things other than zshdb is now its own thing in
ELPA . (And likewise for MELPA
if you prefer that).

Also, I see there is a Python3 dependency, but that is optional to support
syntax highlighting via Pygments. So if Python3 is a dependency, then so
should Python Pygments.

Thanks for all the work done here.

On Sun, Feb 9, 2020 at 4:15 PM Ralf Treinen  wrote:

> Source: zshdb
> Version: 0.92-3
> User: trei...@debian.org
> Usertags: edos-uninstallable
> Severity: serious
>
> Hi,
>
> zshdb build-depends on emacs25, which was removed from sid.
>
> -Ralf
>
>

Bug#951020: zshdb: build-depends on emacs25

[Rocky Bernstein]

And while updating the package. zshdb 1.1.0 was released a while ago. It
should be seamless update.

On Sun, Feb 9, 2020 at 4:15 PM Ralf Treinen  wrote:

> Source: zshdb
> Version: 0.92-3
> User: trei...@debian.org
> Usertags: edos-uninstallable
> Severity: serious
>
> Hi,
>
> zshdb build-depends on emacs25, which was removed from sid.
>
> -Ralf
>
>

Bug#883673: fix build with libcdio 1.0

[Rocky Bernstein]

Dominic - I see you have forked the Perl libcdio code. I have just updated
it with something that provisionally works with
http://rocky.github.io/libcdio-1.1.0rc1.tar.bz2  the current 1.1.0 release
candidate.  That Perl code still needs fixups for (not recent) CD-Text API
changes.

In the last libcdio release, I removed the rather old CD-Text API but we
were stull using that in the Perl bindings.

In general what has to happen is 1.1.0 needs to get out there. Then another
Device::Cdio will be released which uses that and will depend on 1.1.0 (not
1.0.0).

Sorry everyone for all of the hassle. With luck, perhaps this will be the
last set of libcdio stuff I do.


On Wed, Dec 6, 2017 at 7:59 AM, Dominic Hargreaves  wrote:

> On Wed, Dec 06, 2017 at 11:46:31AM +0100, Matthias Klose wrote:
> > Package: src:libdevice-cdio-perl
> > Version: 0.4.0-2
> > Severity: serious
> > Tags: sid buster patch
> >
> > One driver is gone upstream.
> >
> > patch at
> > http://launchpadlibrarian.net/348274120/libdevice-cdio-perl_
> 0.4.0-2build1_0.4.0-2ubuntu1.diff.gz
>
> Hi Matthew,
>
> I tried applying this patch (both to the Debian package and to upstream
> git ready for forwarding) but I get the following build failures on sid:
>
> ./perlcdio_wrap.c: In function 'get_cdtext':
> ./perlcdio_wrap.c:2439:14: error: too many arguments to function
> 'cdio_get_cdtex
> t'
>  cdtext = cdio_get_cdtext (p_cdio, (track_t) track);
>   ^~~
> In file included from /usr/include/cdio/cdio.h:62:0,
>  from ./perlcdio_wrap.c:1562:
> /usr/include/cdio/disc.h:77:13: note: declared here
>cdtext_t *cdio_get_cdtext (CdIo_t *p_cdio);
>  ^~~
> ./perlcdio_wrap.c:2448:29: warning: passing argument 1 of
> 'cdtext_get_const' makes pointer from integer without a cast
> [-Wint-conversion]
>  if(cdtext_get_const(num,cdtext)) {
>  ^~~
> In file included from /usr/include/cdio/cdio.h:59:0,
>  from ./perlcdio_wrap.c:1562:
> /usr/include/cdio/cdtext.h:262:13: note: expected 'const cdtext_t * {aka
> const struct cdtext_s *}' but argument is of type 'int'
>  const char *cdtext_get_const (const cdtext_t *p_cdtext, cdtext_field_t
> field,
>  ^~~~
> ./perlcdio_wrap.c:2448:33: error: incompatible type for argument 2 of
> 'cdtext_get_const'
>  if(cdtext_get_const(num,cdtext)) {
>  ^~
>
> [...]
>
> (full log attached).
>
> Do you have any suggestions about how to resolve this?
>
> Cheers,
> Dominic.
>

Bug#883673: fix build with libcdio 1.0

[Rocky Bernstein]

 Oops --

#define LIBCDIO_VERSION_NUM 10100

is the current version number that will be in the next release. in the
1.0.0 release it was erroneously 1.

On Wed, Dec 6, 2017 at 8:30 AM, Rocky Bernstein <ro...@gnu.org> wrote:

> Don't know how this solves things, but  compiling locally there is another
> problem with the *unpatched sources. *In the the 1.0.0 release I
>
> *have*#define LIBCDIO_VERSION_NUM 10100
>
> but this should be a number greater than 100. I am working on a
> libcdio-1.1.0 release which will be out probably within a week or two that
> addresses this problem.
> It also addresses all of remaining memory leaks that I have been able to
> find in the library code (and example programs and tests). So I kind of
> consider it to be important.
>
> I am also working on an update to Device::Cdio which removes long obsolete
> code, and removes the no-longer-supported drivers (there are two, OS/2 and
> BSDI, not one) and whatever else has changed in the last 5 or so years.
>
>
> On Wed, Dec 6, 2017 at 8:06 AM, Matthias Klose <d...@debian.org> wrote:
>
>> On 06.12.2017 13:59, Dominic Hargreaves wrote:
>> > On Wed, Dec 06, 2017 at 11:46:31AM +0100, Matthias Klose wrote:
>> >> Package: src:libdevice-cdio-perl
>> >> Version: 0.4.0-2
>> >> Severity: serious
>> >> Tags: sid buster patch
>> >>
>> >> One driver is gone upstream.
>> >>
>> >> patch at
>> >> http://launchpadlibrarian.net/348274120/libdevice-cdio-perl_
>> 0.4.0-2build1_0.4.0-2ubuntu1.diff.gz
>> >
>> > Hi Matthew,
>> >
>> > I tried applying this patch (both to the Debian package and to upstream
>> > git ready for forwarding) but I get the following build failures on sid:
>> >
>> > ./perlcdio_wrap.c: In function 'get_cdtext':
>> > ./perlcdio_wrap.c:2439:14: error: too many arguments to function
>> 'cdio_get_cdtex
>> > t'
>> >  cdtext = cdio_get_cdtext (p_cdio, (track_t) track);
>> >   ^~~
>> > In file included from /usr/include/cdio/cdio.h:62:0,
>> >  from ./perlcdio_wrap.c:1562:
>> > /usr/include/cdio/disc.h:77:13: note: declared here
>> >cdtext_t *cdio_get_cdtext (CdIo_t *p_cdio);
>> >  ^~~
>> > ./perlcdio_wrap.c:2448:29: warning: passing argument 1 of
>> 'cdtext_get_const' makes pointer from integer without a cast
>> [-Wint-conversion]
>> >  if(cdtext_get_const(num,cdtext)) {
>> >  ^~~
>> > In file included from /usr/include/cdio/cdio.h:59:0,
>> >  from ./perlcdio_wrap.c:1562:
>> > /usr/include/cdio/cdtext.h:262:13: note: expected 'const cdtext_t *
>> {aka const struct cdtext_s *}' but argument is of type 'int'
>> >  const char *cdtext_get_const (const cdtext_t *p_cdtext, cdtext_field_t
>> field,
>> >  ^~~~
>> > ./perlcdio_wrap.c:2448:33: error: incompatible type for argument 2 of
>> 'cdtext_get_const'
>> >  if(cdtext_get_const(num,cdtext)) {
>> >  ^~
>> >
>> > [...]
>> >
>> > (full log attached).
>> >
>> > Do you have any suggestions about how to resolve this?
>>
>> yes, fixed in libcdio-1.0.0-2
>>
>>
>

Bug#883673: fix build with libcdio 1.0

[Rocky Bernstein]

Don't know how this solves things, but  compiling locally there is another
problem with the *unpatched sources. *In the the 1.0.0 release I

*have*#define LIBCDIO_VERSION_NUM 10100

but this should be a number greater than 100. I am working on a
libcdio-1.1.0 release which will be out probably within a week or two that
addresses this problem.
It also addresses all of remaining memory leaks that I have been able to
find in the library code (and example programs and tests). So I kind of
consider it to be important.

I am also working on an update to Device::Cdio which removes long obsolete
code, and removes the no-longer-supported drivers (there are two, OS/2 and
BSDI, not one) and whatever else has changed in the last 5 or so years.


On Wed, Dec 6, 2017 at 8:06 AM, Matthias Klose  wrote:

> On 06.12.2017 13:59, Dominic Hargreaves wrote:
> > On Wed, Dec 06, 2017 at 11:46:31AM +0100, Matthias Klose wrote:
> >> Package: src:libdevice-cdio-perl
> >> Version: 0.4.0-2
> >> Severity: serious
> >> Tags: sid buster patch
> >>
> >> One driver is gone upstream.
> >>
> >> patch at
> >> http://launchpadlibrarian.net/348274120/libdevice-cdio-perl_
> 0.4.0-2build1_0.4.0-2ubuntu1.diff.gz
> >
> > Hi Matthew,
> >
> > I tried applying this patch (both to the Debian package and to upstream
> > git ready for forwarding) but I get the following build failures on sid:
> >
> > ./perlcdio_wrap.c: In function 'get_cdtext':
> > ./perlcdio_wrap.c:2439:14: error: too many arguments to function
> 'cdio_get_cdtex
> > t'
> >  cdtext = cdio_get_cdtext (p_cdio, (track_t) track);
> >   ^~~
> > In file included from /usr/include/cdio/cdio.h:62:0,
> >  from ./perlcdio_wrap.c:1562:
> > /usr/include/cdio/disc.h:77:13: note: declared here
> >cdtext_t *cdio_get_cdtext (CdIo_t *p_cdio);
> >  ^~~
> > ./perlcdio_wrap.c:2448:29: warning: passing argument 1 of
> 'cdtext_get_const' makes pointer from integer without a cast
> [-Wint-conversion]
> >  if(cdtext_get_const(num,cdtext)) {
> >  ^~~
> > In file included from /usr/include/cdio/cdio.h:59:0,
> >  from ./perlcdio_wrap.c:1562:
> > /usr/include/cdio/cdtext.h:262:13: note: expected 'const cdtext_t *
> {aka const struct cdtext_s *}' but argument is of type 'int'
> >  const char *cdtext_get_const (const cdtext_t *p_cdtext, cdtext_field_t
> field,
> >  ^~~~
> > ./perlcdio_wrap.c:2448:33: error: incompatible type for argument 2 of
> 'cdtext_get_const'
> >  if(cdtext_get_const(num,cdtext)) {
> >  ^~
> >
> > [...]
> >
> > (full log attached).
> >
> > Do you have any suggestions about how to resolve this?
>
> yes, fixed in libcdio-1.0.0-2
>
>

Bug#878775: remake doublecolon feature test failure on s390x

[Rocky Bernstein]

I don't think this failure is significant. I have seen failures in the
double colon test in other OSs and on  scenarios where there are mounted
filesystems so timing is an issue or where the locking of files causes
slowdown. I think the test itself is fragile and might simply be skipped or
ignored here.

Also, I note that GNU make
http://http.debian.net/debian/pool/main/m/make-dfsg/make-dfsg_4.1-9.1.diff.gz
has some diffs that you might apply here as well since the code bases are
largely the same.

See also the comments about double colon weirdness logged against GNU make
which are probably relevant here.

Bug#560665: zshdb: FTBFS: tests failed

[Rocky Bernstein]

First and foremost, thanks everyone for such diligent and detailed work;
also thanks for the interest in zshdb and contacting me about this.

In theory, I suppose it is possible to make this work, but in practice I
don't see much of a point of it here.

Some debuggers do support the notion of remote debugging -- in that
situation there need not be an interactive tty. zsh has the primitives to
support remote debugging (I think). But it's not something I want to
undertake; if someone else were interested in this enough to work on it I'd
help them out.

Also it is possible to segregate tests into those that require tty's and
those don't. For example test/unit/test-columnized.sh just tests the ability
to sort an array and display it in column order. It doesn't pull in the full
debugger or need an interactive tty (I think). However, segregating tests is
a bit of work for what strikes me as somewhat limited benefit.

I generally test everything before a release. And mosts system that want to
run zshdb have interactive tty's. So in the end I wonder what the overall
benefit of this would be to make the tests work for a scenario that is a bit
odd and out of the mainstream intended use.

Therefore what I suggest is do some sort of test to see if there's an
interactive tty and if not skip all of the tests. Or unconditionally skip
all tests when building on Debian for packaging.

2010/2/12 Clint Adams sch...@debian.org

 On Fri, Feb 12, 2010 at 12:16:16PM +0100, Loďc Minier wrote:
  On Fri, Dec 11, 2009, Lucas Nussbaum wrote:
   Relevant part:
 
   Actually that's not the whole relevant part; there's also:
  checking whether make sets $(MAKE)... yes
  get_processor:3: command not found: ps
  ./ok4zshdb.sh:43: command not found: -if
  checking Checking whether /bin/zsh is compatible with zshdb... Your zsh
 doesn't have the fc -l patches.
  yes!
  checking for diff... /usr/bin/diff
  adding -w to diff in regression tests
 
   This particular problem is due to a missing build-dep on procps which
   provides ps, used in test/zsh/ok4zshdb.sh:get_processor().
   (debootstrap --variant=buildd wont pull procps)
 
   
 /build/user-zshdb_0.03+git20090920-1-amd64-hSCnaM/zshdb-0.03+git20090920/lib/processor.sh:37:
 no such file or directory:
 
   That's the meat of the problem: lib/processor.sh:37 breaks the build
   because it uses $TTY:
  # For zsh, using this builtin parameter $TTY seems preferred over 0
  # because it will find/fake a terminal when 0 might not be one.
  exec {_Dbg_fdi}$TTY
 
  TTY isn't set
 
   I managed to reproduce the problem in my build environment with:
  sudo mv /dev/tty /dev/tty.bak
  env -i dpkg-buildpackage -b /dev/null log 21
   (obviously this might break your system)
 
   So I believe the buildd environment has a partial /dev without
   /dev/tty.
 
   I tried replacing $TTY with 0, and a real file, but that didn't work
   (hit the same test failures), and with a fifo, but that hanged the
   build waiting for the fifo to fill in.
 
   I'm not familiar with zshdb, but I suspect it might need a TTY during
   debug sessions which might be why the testsuite would use one as well.
   Someone more familiar with zshdb could perhaps check whether we can use
   coproc here, or a pair of fifos (adding code to properly close them as
   well), to replace the use of $TTY.  Perhaps another way would be to
   pass a script (list of commands to run) to zshdb.
 
   As a last resort, I tried running make check under expect, but oddly
   that failed in the same way.  While expect correctly sets up stdin,
   stdout, stderr on a pty,
   test/integration/check-common.sh:run_test_check() ruins that effort by
   using redirections:
  (cd $srcdir  run_debugger $debugged_script 21 $TEST_FILE
 /dev/null)
   so zsh sees that stdin, stdout, and stderr aren't ttys and falls back
   to /dev/tty (which doesn't exist apparently).
 
   So I tried working around that with:
  expect -c 'spawn zsh -c ZSH_TTY=\$$TTY $(MAKE) check; expect'
   and changing lib/processor.sh to use ZSH_TTY.  I don't know why *that*
   still fails.
 
   So it seems the only way is to rework the testsuite to not rely on
   using a real tty...

 Rocky, any thoughts?  I guess at the worst case we could simply disable
 the tests if no tty is available.