GNU bug report logs - #74613
fortunes-jkirchartz is missing python input

Previous Next

Full log

Message #8 received at 74613 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: "Dr. Arne Babenhauserheide" <arne_bab <at> web.de>, 74613 <at> debbugs.gnu.org
Subject: Re: fortunes-jkirchartz is missing python input
Date: Sat, 30 Nov 2024 10:04:42 +0100

Hi Arne

Am Samstag, dem 30.11.2024 um 02:09 +0100 schrieb Dr. Arne
Babenhauserheide:
> Hi,
> 
> the build for fortunes-jkirchartz fails:
> 
> `/gnu/store/hax39blb0f62cnax7n92hcxkw5k4jymq-fortunes-jkirchartz-0-
> 0.2e32ba0-checkout/bin/goodreadsquotes.py' ->
> `./bin/goodreadsquotes.py'
> phase `unpack' succeeded after 0.0 seconds
> starting phase `patch-source'
> phase `patch-source' succeeded after 0.1 seconds
> starting phase `patch-usr-bin-file'
> phase `patch-usr-bin-file' succeeded after 0.0 seconds
> starting phase `patch-source-shebangs'
> patch-shebang: ./bin/azquotes.py: warning: no binary for interpreter
> `python' found in $PATH
> patch-shebang: ./bin/goodreadsquotes.py: warning: no binary for
> interpreter `python' found in $PATH
> phase `patch-source-shebangs' succeeded after 0.0 seconds
> starting phase `patch-generated-file-shebangs'
> patch-shebang: ./bin/azquotes.py: warning: no binary for interpreter
> `python' found in $PATH
> patch-shebang: ./bin/goodreadsquotes.py: warning: no binary for
> interpreter `python' found in $PATH
These patch-shebang failures are unrelated to the build, as these are
scripts to download more quotes from the web, which are never invoked.

> phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
> starting phase `build'
> egrep: warning: egrep is obsolescent; using grep -E
> make: *** [Makefile:10: AClaude.dat] Aborted
> make: *** Deleting file 'AClaude.dat'
As embarrassing as this is to say, this appears to be an out-of-bounds
read in daikichi (if you check out the source and invoke the actual
command, it will print "Assertion '__pos <= size()' failed." with a
long type qualifier), which is raised somewhere from 
   std::ostream &operator<< (std::ostream &o, const header& header)
in daikichi-io.cc.

As nothing whatsoever is written, this may be already on the first
line, but with the ostream likely being buffered could be any of those
writes.  I'll dig deeper once I have some more time.

Cheers

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.