Re: [9front] 7c: compile error after sysupdate

Re: [9front] 7c: compile error after sysupdate

[cinap_lenrek]

yes. this is not a mistake. you need to create these directories manually
or use /sys/lib/rootstub.

if you have mail history, you might find the 9front announcement for arm64
with build instructions.

--
cinap

Re: [9front] 7c: compile error after sysupdate

[Stanley Lieber]

[-- Attachment #1: Type: text/plain, Size: 43 bytes --]

http://fqa.9front.org/fqa8.html#8.9.3

sl


[-- Attachment #2: Type: text/html, Size: 321 bytes --]

Re: [9front] 7c: compile error after sysupdate

[Ethan Gardener]

On Mon, Jun 24, 2019, at 10:36 AM, cinap_lenrek@felloff.net wrote:
> yes. this is not a mistake. you need to create these directories manually
> or use /sys/lib/rootstub.

okay.  /arm64/include is missing from rootstub, resulting in:

7.c:10 6c: '/arm64/include' does not exist: /arm64/include/ureg.h
mk: 6c -FTVw -I/sys/src/cmd 7.c  : exit status=rc 18153: 6c 18158: error
mk: date for (i ...  : exit status=rc 15951: rc 18100: mk 18101: error
term% lc /arm64
bin/	lib/

it doesn't make any include dirs.

ah-ha!:

term% lc /dist/plan9front/
.hg/		.hgignore	arm64/

remove; bind; hg up -C; unmount; lc /arm64/include
ape/	u.h		ureg.h

good!  userspace and kernel builds now complete without error.  



> 
> if you have mail history, you might find the 9front announcement for arm64
> with build instructions.

just checking, you know all this is happening when i'm not trying to do 
anything with arm64?  

term% whatis cputype objtype
cputype=amd64
objtype=amd64

would it be a good idea to have sysupdate source rootstub?



don't sleep-sysadmin, kids.  i've got to clean up after running rootstub in $home .

Re: [9front] 7c: compile error after sysupdate

[hiro]

> got to clean up
just time travel back to before you made the mess.
that's what we have fs dumps for :)

Re: [9front] 7c: compile error after sysupdate

[Ethan Gardener]

On Mon, Jun 24, 2019, at 8:01 PM, hiro wrote:
> > got to clean up
> just time travel back to before you made the mess.
> that's what we have fs dumps for :)
>

it certainly crossed my mind! :)

Re: [9front] 7c: compile error after sysupdate

[Ethan Gardener]

On Mon, Jun 24, 2019, at 8:05 PM, cinap_lenrek@felloff.net wrote:
> > would it be a good idea to have sysupdate source rootstub?
> 
> i worked on this for a day and then gave up. its too hard and
> too complicated.
> 
> sysupdate would need some check to update itself in case
> there needs to be stuff like this. but how do you deploy
> THAT change? the only way is to fork everything. have
> a thumbstone commit with the sysupdate change. and then
> the next sysupdate goes to a new repository.

hmm...  i've got an idea.  as you say below, it won't help with
adding dirs to /, but just for fun:

i don't think you'd need a new repository, but you would need a way
for sysupdate to check and update itself first.  the first update
would be trouble, you're right there.  after that, it wouldn't be
complex with one or two helper scripts.  sysupdate could have just 2
lines (plus #!), the first running sysupdate-updater, the second execs
sysupdate-doit.  sysupdate-updater updates sysupdate-doit, but
sysupdate and sysupdate-updater would be updated by hg as normal,
because they're not running when hg is.  not that the 2-line sysupdate
would ever need updating.

i could code this, if you'd like it.

> on the other hand, its not so easy to automate creating
> stuff in the root. initially, the root of the fileserver
> was readonly and the only way to create directories there
> was console command. what if you don't run sysupdate on
> the fileserver but from a cpu server? then you can't
> access the fileserver console.

oh yes, of course.  

Re: [9front] 7c: compile error after sysupdate

[cinap_lenrek]

> would it be a good idea to have sysupdate source rootstub?

i worked on this for a day and then gave up. its too hard and
too complicated.

sysupdate would need some check to update itself in case
there needs to be stuff like this. but how do you deploy
THAT change? the only way is to fork everything. have
a thumbstone commit with the sysupdate change. and then
the next sysupdate goes to a new repository.

on the other hand, its not so easy to automate creating
stuff in the root. initially, the root of the fileserver
was readonly and the only way to create directories there
was console command. what if you don't run sysupdate on
the fileserver but from a cpu server? then you can't
access the fileserver console.

--
cinap