I'm assuming /386/bin/fossil/fossil does not, in fact, exist.

The fact that the last file completed changes is just a distraction
in this case; I suspect you have $NPROC>1 and mk is parallelizing
its work. I think if you set NPROC=1 before running mk you'll stop
seeing that last file change.

The problem is simply that the kernel mkfiles don't know how to
build things in /sys/src/cmd. The trivial work-around is to build
fossil yourself (cd /sys/src/cmd/fossil && mk install). There's
likely to be other similar binaries needed, so I'd recommend you
'mk install' all of /sys/src/cmd.
Anthony

> 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 $NPROC>1 and mk is parallelizing
> its work. I think if you set NPROC=1 before running mk you'll stop
> seeing that last file change.

I am getting the same problem with or without setting NPROC=1

> The problem is simply that the kernel mkfiles don't know how to
> build things in /sys/src/cmd. The trivial work-around is to build
> fossil yourself (cd /sys/src/cmd/fossil && mk install). There's
> likely to be other similar binaries needed, so I'd recommend you
> 'mk install' all of /sys/src/cmd.

Yes!? Here is the problem:

If I compiled fossil and now, doing the mk with pccpuf, show me an error
with libip.a :-?
Then, I compiled libip.a and now the kernel is compiling ok.

The real problem is this is the official plan9.iso CD, with the default
installation, then other people will have the same problem.

> Anthony

Thank you Anthony,

>
>


--
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)

> 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.

What does the date command on your system say?

What is the date on this file on your installation ISO image?

Hi,

yes, December 1969 is the date of this file. The file _fossil has the same
time.

In the plan9.iso the date for /386/bin/fossil/fossil is Feb 29 2008.

The size is equal in the plan9 installation and the plan9.iso, 336315 bytes


>> 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.
>
> What does the date command on your system say?
>
> What is the date on this file on your installation ISO image?
>
>
>


--
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)

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

As others have noted, the date on your fossil is suspect. It looks like
you've got other issues going on. Beyond, that, however, you say the
fossil exists, but then "If I compiled fossil and now...", with some
changed behavior. What happened here? You also skipped over the
question of what 'date' on your system returns.

// The real problem is this is the official plan9.iso CD, with the default
// installation, then other people will have the same problem.

True as far as it goes, but we don't know what the problem is yet. I
suspect the issue is simply that you're trying to build the kernels
without the prerequisites in place, which (if anything) would make
this mostly a documentation bug (although I don't offhand have a
good idea where to document this).

Anthony

> yes, December 1969 is the date of this file. The file _fossil has the same
> time.

It seems that replica/applylog (which is used for both install
and pull) isn't setting the correct date on your files.

Please try the following commands:

date
ls -l /dist/replica/didplan9 /dist/replica/client
cat /dist/replica/client/plan9.time
grep 386/bin/fossil/fossil /dist/replica/client/plan9.db

Hi,

thanks for your reply

>> yes, December 1969 is the date of this file. The file _fossil has the
>> same
>> time.
>
> It seems that replica/applylog (which is used for both install
> and pull) isn't setting the correct date on your files.
>
> Please try the following commands:
>
> date

Mon Mar 24 18:22:08 EST 2008 (now :-) )

> ls -l /dist/replica/didplan9 /dist/replica/client

--rw-rw-r-- M 8 glenda sys 0 Mar 22 20:17 /dist/replica/didplan9

> cat /dist/replica/client/plan9.time

1206163804 0

> grep 386/bin/fossil/fossil /dist/replica/client/plan9.db

386/bin/fossil/fossil - 755 sys sys 0 366315
386/bin/fossil/fossil - 755 sys sys 0 366315
386/bin/fossil/fossil - 755 sys sys 0 366315

>
>
>


--
Rodolfo García AKA kix
http://www.kix.es/
EA4ERH (@IN80ER)

>> grep 386/bin/fossil/fossil /dist/replica/client/plan9.db
>
> 386/bin/fossil/fossil - 755 sys sys 0 366315
> 386/bin/fossil/fossil - 755 sys sys 0 366315
> 386/bin/fossil/fossil - 755 sys sys 0 366315

The '0' is what replica/applylog wrote as the file modification time -
clearly the wrong thing to do. 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) or sources (pull).

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 386/bin/fossil/fossil /dist/replica/client/plan9.db
>>>
>> 386/bin/fossil/fossil - 755 sys sys 0 366315
>> 386/bin/fossil/fossil - 755 sys sys 0 366315
>> 386/bin/fossil/fossil - 755 sys sys 0 366315
>>
>
> The '0' is what replica/applylog wrote as the file modification time -
> clearly the wrong thing to do. 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) or sources (pull).
>
>
>

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 /386/bin/fossil/fossil)
were made on 29 February this year. A logic error in 9660srv rejects
this as an impossible date, so it sets mtime for those files to zero.

Patch 9660srv-leapyear should fix the error.

On Mar 24, 6:42 pm, k...@kix.es (Rodolfo kix Garci*a) 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 machines.
>
> Thanks Richard
>
> Richard Miller escribió:
>
> >>> grep 386/bin/fossil/fossil /dist/replica/client/plan9.db
>
> >> 386/bin/fossil/fossil - 755 sys sys 0 366315
> >> 386/bin/fossil/fossil - 755 sys sys 0 366315
> >> 386/bin/fossil/fossil - 755 sys sys 0 366315
>
> > The '0' is what replica/applylog wrote as the file modification time -
> > clearly the wrong thing to do. 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) or sources (pull).

I experienced the same problem about two weeks ago and gave up,
thinking it was oddly related to the VMWARE installation. I used the
lated release of VMWARE workstation and everything seemed fine with
exception to building the kernel and the screen acting quirky (mouse
cursor, snarf acting inconsistent etc.) I plan to install on a PC this
weekend and slowly build a network of machines for research. Will
report my findings if relevant. Thanks
david

> 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 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 it....if you did it....thanks

Armando

ps: i downloaded the iso file from the bell site last week.

>> > 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 it....if you did it....thanks
>
> Armando
>
> ps: i downloaded the iso file from the bell site last week.

then reinstall from that cd.

- erik