I experienced the same problem about two weeks ago and gave up,
This has been fixed as of 28 March.
% patch/list applied/9660srv-leapyear
I have the same problem, but i haven't got an internet connection, so
i would like to know how you resolved itif you did itthanks
Armando
On Mar 24, 6:42 pm, [EMAIL PROTECTED] (Rodolfo kix Garcia) wrote:
I don't run pull in this default installation, then the install CD do
not write this value.
I got the same problem with two different CD images, three days ago and
one week ago, installing them in vmware and qemu virtual
I experienced the same problem about two weeks ago and gave up,
This has been fixed as of 28 March.
% patch/list applied/9660srv-leapyear
I said:
I don't understand this, because as
far as I can see the mtime should be taken from the actual mtime of
the file being copied from the CD (install) ...
I've now traced the problem to a leap-year bug in the Plan 9 ISO9660
file server.
Several files in the distribution (including
I'm assuming /386/bin/fossil/fossil does not, in fact, exist.
The file exists:
term% ls -l /386/bin/fossil/fossil
--rwxrwxr-x M 8 sys sys 366315 Dec 31 1969 /386/bin/fossil/fossil
term%
The fact that the last file completed changes is just a distraction
in this case; I suspect you have
term% ls -l /386/bin/fossil/fossil
--rwxrwxr-x M 8 sys sys 366315 Dec 31 1969 /386/bin/fossil/fossil
December 1969? I think not.
Ah yes, the day before time began :)
I don't run pull in this default installation, then the install CD do
not write this value.
I got the same problem with two different CD images, three days ago and
one week ago, installing them in vmware and qemu virtual machines.
Thanks Richard
Richard Miller escribió:
grep
