In message <07ad160c53...@hobbes.bass-software.com>
          John Tytgat <john.tyt...@aaug.net> wrote:

> In message <70fbce0b53.b...@ron1954.woosh.co.nz>
>           Ron <b...@woosh.co.nz> wrote:
> 
> > In message <89c5080b53...@hobbes.bass-software.com>
> >           John Tytgat <john.tyt...@aaug.net> wrote:
> > 
> > > In message <177cd20a53.b...@ron1954.woosh.co.nz>
> > >           Ron <b...@woosh.co.nz> wrote:
> > > 
> > > > The only autobuilder build I have done is zip which has failed in the
> > > > later stage with
> > > > 
> > > > mv: cannot stat '../zip30-joty/acorn/swiven.c': No such file or 
> > > > directory
> > > > 
> > > > There is a ../zip30 directory there, but not the above.
> > > 
> > > I could reproduce this.  This is because of r5221 by Chris Gransden which
> > > I fail to understand why there was a 'mv' added as part of that change.
> > > Chris, any idea why that was needed ?
> > > 
> > > After removing that 'mv' (in r6249) and fixing a couple of other
> > > Autobuilder bugs (r6248 and r6250), I got a zip RiscPkg package built.
> > > 
> > > John.
> > 
> > I'm now 'At revision 6250' and still get the error,
> 
> Which error do you mean with "the error", the original
> "mv: cannot stat '../zip30-joty/acorn/swiven.c': No such file or directory"
> one ?
>
Yes, no change. I deleted everything in the build(s) directory before
re-running build zip, I think that is clean enough.
 
> > but looking back up
> > the terminal, there is an error trying to open *.orig.tar.bz2
> > 
> > 2013-01-10 22:21:18 
> > URL:http://ftp.uk.debian.org/debian/pool/main/z/zip/zip_3.0-6.debian.tar.gz 
> > [7132/7132] -> "zip_3.0-6.debian.tar.gz" [1]
> > tar (child): *.orig.tar.bz2: Cannot open: No such file or directory
> > tar (child): Error is not recoverable: exiting now
> 
> I see the same think in my last-success log file for 'zip'.  It looks
> like this error gets ignored as the build continues and succeeds making
> the final package (not that I fully understand why this can happen).
> 
> John.

Yes, I noticed later in the failure file, that it does this (incase of?)
for a .xz and .bz2 instance.
As you say, that looks like that is always done, so shouldn't be a problem.
Could it be something related to the CWD? 



Digressing here:
'Cant stat' is usually a missing file or a file name misunderstanding.
I have just found that parsing a directory name with slashes to my
RISC OS tar gives this error.
I have now modified my directory leafname extraction routine to swap
"." and "/" around also. 
Chris's tesseract port works well with full RISC OS paths if I run them
through my swap routine and is probably the case for most ports
unless the argument parsing is modified in the source.
Modifying may be easy sometimes, but other times the source might
want to detect particular extensions so it can get complicated.

Generally we always feed the unix ports unix names and the unix port
outputs RISC OS names which is a simple rule to remember anyway.

Ron M.


_______________________________________________
GCCSDK mailing list gcc@gccsdk.riscos.info
Bugzilla: http://www.riscos.info/bugzilla/index.cgi
List Info: http://www.riscos.info/mailman/listinfo/gcc
Main Page: http://www.riscos.info/index.php/GCCSDK

Reply via email to