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

v 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 patc

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

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

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

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

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

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

Bug#951020: zshdb: build-depends on emacs25

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

Bug#951020: zshdb: build-depends on emacs25

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

Bug#883673: fix build with libcdio 1.0

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

Bug#883673: fix build with libcdio 1.0

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 compilin

Bug#883673: fix build with libcdio 1.0

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

Bug#878775: remake doublecolon feature test failure on s390x

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

Bug#560665: zshdb: FTBFS: tests failed

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