Today

• 4 hours ago

  issue 181 (DragonFly BSD support) commented on by fgudin   -   extrudedaluminiu: could you please upload your diff here ? www.grex.org never answers these days… TIA, -- Francis

  extrudedaluminiu: could you please upload your diff here ? www.grex.org never answers these days… TIA, -- Francis
• 20 hours ago

  Revision 9861189ffc (20091215-2149) pushed by Charles.Forsyth   -   20091215-2149

  20091215-2149
• 20 hours ago

  issue 217 (/appl/cmd/mount.b:96 factotum.mount() args swapped in call) Status changed by Charles.Forsyth   -   the args aren't the wrong way round: it really should be spec, nil in mount.b, because the [spec] in bind(1) is the mount specifier (aname in the protocol) not a key specification. but factotum(2) should include the keyspec parameter in the signature. i've also changed mount and mount(1) to say that the -k value is passed on to factotum, so now it's factotum->mount(..., spec, keyfile). unfortunately that doesn't do a great deal of good because the current p9any implementation in factotum doesn't do much with the key spec. this change at least gets a bit closer, and is consistent with future changes to mount where -k is always a keyspec and mount always uses factotum.

  Status: Fixed

  the args aren't the wrong way round: it really should be spec, nil in mount.b, because the [spec] in bind(1) is the mount specifier (aname in the protocol) not a key specification. but factotum(2) should include the keyspec parameter in the signature. i've also changed mount and mount(1) to say that the -k value is passed on to factotum, so now it's factotum->mount(..., spec, keyfile). unfortunately that doesn't do a great deal of good because the current p9any implementation in factotum doesn't do much with the key spec. this change at least gets a bit closer, and is consistent with future changes to mount where -k is always a keyspec and mount always uses factotum.

  Status: Fixed
• 20 hours ago

  Revision de99e70f57 (20091215-2140) pushed by Charles.Forsyth   -   20091215-2140

  20091215-2140
• 22 hours ago

  issue 217 (/appl/cmd/mount.b:96 factotum.mount() args swapped in call) reported by r...@coraid.com   -   is: ok = factotum->mount(fd, mountpoint, flags, spec, nil).t0; should be: ok = factotum->mount(fd, mountpoint, flags, nil, spec).t0; /module/factotum.m correctly matches /appl/lib/factotum.mount(). also, man 2 factotum is missing the last arg for the mount command (keyspec: string): is: mount: fn(fd: ref Sys->FD, mnt: string, flags: int, aname: string): (int, ref Authinfo); should be: mount: fn(fd: ref Sys->FD, mnt: string, flags: int, aname: string, keyspec: string): (int, ref Authinfo); all the best, r

  is: ok = factotum->mount(fd, mountpoint, flags, spec, nil).t0; should be: ok = factotum->mount(fd, mountpoint, flags, nil, spec).t0; /module/factotum.m correctly matches /appl/lib/factotum.mount(). also, man 2 factotum is missing the last arg for the mount command (keyspec: string): is: mount: fn(fd: ref Sys->FD, mnt: string, flags: int, aname: string): (int, ref Authinfo); should be: mount: fn(fd: ref Sys->FD, mnt: string, flags: int, aname: string, keyspec: string): (int, ref Authinfo); all the best, r

Yesterday

• 33 hours ago

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by zobnin   -   You can use Debian Etch (http://people.debian.org/~aurel32/qemu/mipsel/) and Qemu to run Inferno on Linux-mipsel.

  You can use Debian Etch (http://people.debian.org/~aurel32/qemu/mipsel/) and Qemu to run Inferno on Linux-mipsel.
• 42 hours ago

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by Charles.Forsyth   -   another idea: i'm not sure how it could cause quite this effect, but i wonder whether on your platform pread is being declared as the 32-bit version, not the 64-bit pread64. (there shouldn't be two versions anywhere, but that's a rant for another day.) if you look at the code compiled for fsread in devfs-posix.c it might give a clue. similarly, you could try capturing the .s for sysfile.c above. unfortunately i haven't got a mipsel environment on which i can test any of this myself, otherwise it would usually be quicker to debug. if it doesn't involve x11, of course.

  another idea: i'm not sure how it could cause quite this effect, but i wonder whether on your platform pread is being declared as the 32-bit version, not the 64-bit pread64. (there shouldn't be two versions anywhere, but that's a rant for another day.) if you look at the code compiled for fsread in devfs-posix.c it might give a clue. similarly, you could try capturing the .s for sysfile.c above. unfortunately i haven't got a mipsel environment on which i can test any of this myself, otherwise it would usually be quicker to debug. if it doesn't involve x11, of course.
• 46 hours ago

  issue 126 (emu doesn't compile/work without X) commented on by Charles.Forsyth   -   odd. i've made that change.

  odd. i've made that change.
• 46 hours ago

  Revision 557159f133 (20091214-1943) pushed by Charles.Forsyth   -   20091214-1943

  20091214-1943
• 46 hours ago

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by Charles.Forsyth   -   it looks as though this addition in rread in emu/port/sysfile.c is not being done correctly: lock(cl); c.c->offset += n; unlock(cl); or the value is damaged (somehow) later. you might try adding a print after that point to check the (unsigned long long) %llux value of c.c->offset, and the value of long n. if the value is fine there, it is (apparently) being cleared later.

  it looks as though this addition in rread in emu/port/sysfile.c is not being done correctly: lock(cl); c.c->offset += n; unlock(cl); or the value is damaged (somehow) later. you might try adding a print after that point to check the (unsigned long long) %llux value of c.c->offset, and the value of long n. if the value is fine there, it is (apparently) being cleared later.

Last 7 days

• Dec 14, 2009

  issue 126 (emu doesn't compile/work without X) commented on by powerman.asdf   -   Looks like some fixes related to this issue was lost some time ago. Currently it's again fail to compile on server without X11 libs. This can be fixed by adding these lines to emu/Linux/emu-g: ---cut--- env X11LIBS= ---cut---

  Looks like some fixes related to this issue was lost some time ago. Currently it's again fail to compile on server without X11 libs. This can be fixed by adding these lines to emu/Linux/emu-g: ---cut--- env X11LIBS= ---cut---
• Dec 14, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by zobnin   -   Ooops, corrupted file. This is new one. After line 2791.

  Ooops, corrupted file. This is new one. After line 2791.
• Dec 14, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by zobnin   -   Strace dump after executing "cat /NOTICE" (from line 2690). I killed the emu after dozens of repetitions of the file content.

  Strace dump after executing "cat /NOTICE" (from line 2690). I killed the emu after dozens of repetitions of the file content.
• Dec 13, 2009

  Revision 696e16828c (20091213-1625) pushed by Charles.Forsyth   -   20091213-1625

  20091213-1625
• Dec 10, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by Charles.Forsyth   -   "infinite loop as you can see in dump" i thought that looked like another matter that i was going to check separately, but perhaps they are the same.

  "infinite loop as you can see in dump" i thought that looked like another matter that i was going to check separately, but perhaps they are the same.
• Dec 09, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by zobnin   -   As I said at the beginning, emuinit.dis fail. If i just run "emu -r/path" (without /dis/sh.dis) it freezes and eat 100% cpu (infinite loop as you can see in dump). Strace output of other failed commands looks very similar to this output. Anyway I try to give you other strace dumps.

  As I said at the beginning, emuinit.dis fail. If i just run "emu -r/path" (without /dis/sh.dis) it freezes and eat 100% cpu (infinite loop as you can see in dump). Strace output of other failed commands looks very similar to this output. Anyway I try to give you other strace dumps.
• Dec 09, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by Charles.Forsyth   -   oh. could you please try some of the commands that seemed to fail, so i can see the system calls they issued (if strace can show them)? thanks.

  oh. could you please try some of the commands that seemed to fail, so i can see the system calls they issued (if strace can show them)? thanks.
• Dec 09, 2009

  issue 216 (libtk/coval.c spills) reported by Michaelian.Ennis   -   What steps will reproduce the problem? Compile with 8c that has the quanstro vlong bug patch What is the expected output? What do you see instead? Compilation What version of the product are you using? On what operating system? 362:d6d6cf406377 on Plan9 Please provide any additional information below. Changing return of tkcvsovalhit allows it to compile with out throwing the error. The comment before the return makes me think using vlogs complicate things in some way so I'm not sure if this is the best solution but it seems to work.

  What steps will reproduce the problem? Compile with 8c that has the quanstro vlong bug patch What is the expected output? What do you see instead? Compilation What version of the product are you using? On what operating system? 362:d6d6cf406377 on Plan9 Please provide any additional information below. Changing return of tkcvsovalhit allows it to compile with out throwing the error. The comment before the return makes me think using vlogs complicate things in some way so I'm not sure if this is the best solution but it seems to work.

Last 30 days

• Dec 09, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by zobnin   -   No, just run "strace -f ./emu -r/path"

  No, just run "strace -f ./emu -r/path"
• Dec 09, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by Charles.Forsyth   -   did you type any commands to that?

  did you type any commands to that?
• Dec 09, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) commented on by zobnin   -   strace -f ./emu -r/path: http://pastie.org/735523

  strace -f ./emu -r/path: http://pastie.org/735523
• Dec 09, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) Status changed by Charles.Forsyth   -   Reading these in reverse order: i read 215 first. having now read this one, there seems to be a deeper problem with this port. As with cmd.c, devfs-posix.c is invariant (even across posix systems, allowing for the 64-bit configuration), and uses ordinary system calls. the examples above suggest that internal operations are generally fine, but touching anything outside can be troublesome. having said that, it can load .dis files (and that uses the same file system driver). you might try an strace. (strace -f might trace all emu's children properly.)

  Status: Checking

  Reading these in reverse order: i read 215 first. having now read this one, there seems to be a deeper problem with this port. As with cmd.c, devfs-posix.c is invariant (even across posix systems, allowing for the 64-bit configuration), and uses ordinary system calls. the examples above suggest that internal operations are generally fine, but touching anything outside can be troublesome. having said that, it can load .dis files (and that uses the same file system driver). you might try an strace. (strace -f might trace all emu's children properly.)

  Status: Checking
• Dec 09, 2009

  issue 215 (Segmentation violation when call 'os' command on Linux-spim) Status changed by Charles.Forsyth   -  

  Status: Checking

  Status: Checking
• Dec 09, 2009

  issue 215 (Segmentation violation when call 'os' command on Linux-spim) commented on by Charles.Forsyth   -   emu -s will stop it catching the segmentation fault and allow either gdb on the faulting process or a core dump (if ulimit set to allow one). emu/Linux/cmd.c is invariant across architectures and i can't see any obvious pointers that might be nil. (but there must be something like that!)

  emu -s will stop it catching the segmentation fault and allow either gdb on the faulting process or a core dump (if ulimit set to allow one). emu/Linux/cmd.c is invariant across architectures and i can't see any obvious pointers that might be nil. (but there must be something like that!)
• Dec 09, 2009

  issue 215 (Segmentation violation when call 'os' command on Linux-spim) reported by zobnin   -   Host OS: Linux 2.4.20 Architecture: spim Inferno OS version: Latest, from hg Tested on: qemu + debian etch (http://people.debian.org/~aurel32/qemu/mipsel/) alpha400 mips-based netbook (http://en.wikipedia.org/wiki/Skytone_Alpha- 400) ; os uname SYS: process faults: Segmentation violation Killed

  Host OS: Linux 2.4.20 Architecture: spim Inferno OS version: Latest, from hg Tested on: qemu + debian etch (http://people.debian.org/~aurel32/qemu/mipsel/) alpha400 mips-based netbook (http://en.wikipedia.org/wiki/Skytone_Alpha- 400) ; os uname SYS: process faults: Segmentation violation Killed
• Dec 09, 2009

  issue 214 (Many bugs related to file read operation on Linux-spim) reported by zobnin   -   Host OS: Linux 2.4.20 Architecture: spim Inferno OS version: Latest, from hg Tested on: qemu + debian etch (http://people.debian.org/~aurel32/qemu/mipsel/) alpha400 mips-based netbook (http://en.wikipedia.org/wiki/Skytone_Alpha- 400) Problem: Many bugs related to file read operation Examples: ; emu -r/path No response. ; emu -r/path /dis/sh.dis All ok. ; cat /README.gcode File contens repeated many times, infinitely. ; cat /dev/memory All ok. ; lc Directory contents repeated many times, infinitely. ; ls -p $* | mc All ok. ; svc/registry No response. ; mount -A -c {ndb/registry} /mnt/registry All ok. ; echo aaa > /file ; echo bbb >> /file Contents of the /file: bbb

  Host OS: Linux 2.4.20 Architecture: spim Inferno OS version: Latest, from hg Tested on: qemu + debian etch (http://people.debian.org/~aurel32/qemu/mipsel/) alpha400 mips-based netbook (http://en.wikipedia.org/wiki/Skytone_Alpha- 400) Problem: Many bugs related to file read operation Examples: ; emu -r/path No response. ; emu -r/path /dis/sh.dis All ok. ; cat /README.gcode File contens repeated many times, infinitely. ; cat /dev/memory All ok. ; lc Directory contents repeated many times, infinitely. ; ls -p $* | mc All ok. ; svc/registry No response. ; mount -A -c {ndb/registry} /mnt/registry All ok. ; echo aaa > /file ; echo bbb >> /file Contents of the /file: bbb
• Dec 08, 2009

  issue 213 (problem with makemk.sh when installing inferno on linux) Status changed by Charles.Forsyth   -   i've followed the first suggestion for makemk.sh committed changeset 365:d6aeaecd7cbb making some of the other directories equivalent to $PLAT should be done in the relevant os/ and emu/ portmkfiles, but i need to extend utils/mkdir first. for most of the other directories, it seems better to me at the moment to use the .tgz file (containing the relevant directories) to prime the hg system once, rather than have special mkfile targets or rules. (that view might turn out to be wrong.)

  Status: Fixed

  i've followed the first suggestion for makemk.sh committed changeset 365:d6aeaecd7cbb making some of the other directories equivalent to $PLAT should be done in the relevant os/ and emu/ portmkfiles, but i need to extend utils/mkdir first. for most of the other directories, it seems better to me at the moment to use the .tgz file (containing the relevant directories) to prime the hg system once, rather than have special mkfile targets or rules. (that view might turn out to be wrong.)

  Status: Fixed
• Dec 08, 2009

  Revision d6aeaecd7c (20091208-1407) pushed by Charles.Forsyth   -   20091208-1407

  20091208-1407
• Dec 08, 2009

  issue 213 (problem with makemk.sh when installing inferno on linux) commented on by ankarakulov   -   I just have read another guide about installing inferno on linux, there is mentioned command: xargs mkdir -p <lib/emptydirs Maybe, it should be included in makemk.sh .

  I just have read another guide about installing inferno on linux, there is mentioned command: xargs mkdir -p <lib/emptydirs Maybe, it should be included in makemk.sh .
• Dec 08, 2009

  issue 213 (problem with makemk.sh when installing inferno on linux) reported by ankarakulov   -   I got the latest build with command hg clone https://inferno-os.googlecode.com/hg/ inferno I followed the INSTALL instructions: changed mkconfig file and tried to execute makemk.sh but got following error: ar crvs /home/alex/src/inferno/Linux/386/lib/libregexp.a regaux.o regcomp.o regerror.o regexec.o regsub.o rregexec.o rregsub.o ar: /home/alex/src/inferno/Linux/386/lib/libregexp.a: No such file or directory libregexp ar failed I looked through the makemk.sh and found the cause. In the line 52: $AR $PLAT/lib/libregexp.a `ofiles $CFILES` || error libregexp ar failed The problem is that there is not such directory $PLAT/lib. So, the solution will be to place the string: mkdir -p $PLAT/lib somewhere before.

  I got the latest build with command hg clone https://inferno-os.googlecode.com/hg/ inferno I followed the INSTALL instructions: changed mkconfig file and tried to execute makemk.sh but got following error: ar crvs /home/alex/src/inferno/Linux/386/lib/libregexp.a regaux.o regcomp.o regerror.o regexec.o regsub.o rregexec.o rregsub.o ar: /home/alex/src/inferno/Linux/386/lib/libregexp.a: No such file or directory libregexp ar failed I looked through the makemk.sh and found the cause. In the line 52: $AR $PLAT/lib/libregexp.a `ofiles $CFILES` || error libregexp ar failed The problem is that there is not such directory $PLAT/lib. So, the solution will be to place the string: mkdir -p $PLAT/lib somewhere before.
• Dec 07, 2009

  issue 98 (Immediate crash when setting -C option for emu) commented on by lost.goblin   -   Sorry, but I decommissioned the box where this was happening a while ago, and I no longer have any linux systems running X, please feel free to close this issue, if I get around reproducing this again I will post a new comment here.

  Sorry, but I decommissioned the box where this was happening a while ago, and I no longer have any linux systems running X, please feel free to close this issue, if I get around reproducing this again I will post a new comment here.
• Dec 07, 2009

  issue 68 (copy-paste and scrollwheel don't work on linux (ubuntu feist...) commented on by sor...@gmail.com   -   This seems to have been fixed: Thanks, i think it'S safe to close it now.

  This seems to have been fixed: Thanks, i think it'S safe to close it now.
• Dec 04, 2009

  Revision f69437f5b3 (20091204-2046) pushed by Charles.Forsyth   -   20091204-2046

  20091204-2046
• Dec 04, 2009

  Revision da943c4fa5 (20091204) pushed by Charles.Forsyth   -   20091204

  20091204
• Dec 03, 2009

  issue 182 (few missing directories in inferno snapshots.) commented on by r...@coraid.com   -   lib in Inferno/386 is also missing ... don't know if that one was specifically included in "a few other[s]"

  lib in Inferno/386 is also missing ... don't know if that one was specifically included in "a few other[s]"
• Dec 03, 2009

  issue 212 (false limbo errors for pick coverage ) reported by mechiel@ueber.net   -   limbo does not correctly check whether a pick statement covers all tags of the pick adt. when all the tags have their own body, it works correctly. when tags share a body because of an "or", it does not anymore. the attached program testpickcover.b shows the problem. function "bad" should be fine (all pick tags are covered), but limbo complains with "no return at end of function bad". the attached patch makes the problem go away. the error originates from reach() which checks for reachability of instructions. it seems casecom() generates an instruction (or does other magic) when it thinks a "*" case is needed. this then causes reach() to think a return is missing. i have only tested it on testpickcover.b, not the entire inferno tree. (now that i think of it, nlabels() is probably not the right name for the function...) to get an idea of the left/right's in nlabels(), here is a pick with a case for Elem0 or Elem1, and one for *. pick case int labels 0 0 := nothing 0 0 name t ref T 0 0 name tt ref T 0 0 seq nothing 0 0 label nothing 0 0 seq nothing 0 0 const Elem0 (0) int 0 0 seq nothing 0 0 const Elem1 (1) int 0 0 scope nothing 0 0 return nothing 0 0 const elem0 or elem1 string 0 0 seq nothing 0 0 label nothing 0 0 seq nothing 0 0 * T 0 0 scope nothing 0 0 return nothing 0 0 const other string 0 0

  limbo does not correctly check whether a pick statement covers all tags of the pick adt. when all the tags have their own body, it works correctly. when tags share a body because of an "or", it does not anymore. the attached program testpickcover.b shows the problem. function "bad" should be fine (all pick tags are covered), but limbo complains with "no return at end of function bad". the attached patch makes the problem go away. the error originates from reach() which checks for reachability of instructions. it seems casecom() generates an instruction (or does other magic) when it thinks a "*" case is needed. this then causes reach() to think a return is missing. i have only tested it on testpickcover.b, not the entire inferno tree. (now that i think of it, nlabels() is probably not the right name for the function...) to get an idea of the left/right's in nlabels(), here is a pick with a case for Elem0 or Elem1, and one for *. pick case int labels 0 0 := nothing 0 0 name t ref T 0 0 name tt ref T 0 0 seq nothing 0 0 label nothing 0 0 seq nothing 0 0 const Elem0 (0) int 0 0 seq nothing 0 0 const Elem1 (1) int 0 0 scope nothing 0 0 return nothing 0 0 const elem0 or elem1 string 0 0 seq nothing 0 0 label nothing 0 0 seq nothing 0 0 * T 0 0 scope nothing 0 0 return nothing 0 0 const other string 0 0
• Dec 03, 2009

  issue 36 (window corruption, and image pool limits.) commented on by Charles.Forsyth   -   i think the medium-term plan is to move the X11 code to a separate program or service. X11 doesn't seem to work well in a concurrent program, at least the way kprocs are used.

  i think the medium-term plan is to move the X11 code to a separate program or service. X11 doesn't seem to work well in a concurrent program, at least the way kprocs are used.
• Dec 02, 2009

  issue 36 (window corruption, and image pool limits.) commented on by sor...@gmail.com   -   i'm sorry, but my plan9 dedicated machine broke just then (phew it was a long time ago..), and now i have just inferno. The reason why i didn't bug much is because since some big updates to the X code from a while back, for xcb compatibility, reduced the occurence of such freezes largely! I do get the inferno window to completely freeze sometimes, I blame xcb though, especially since this is a gentoo machine with all the latest gnu *, and i'm sure it's hard to keep up :D. emu-g is rather stable so it's just my client that crashes all the time; a good wmsetup script can help tons in these cases If anyone is still interested, i can try getting some useful information out of the xcb lockups and whatever i get on the console..

  i'm sorry, but my plan9 dedicated machine broke just then (phew it was a long time ago..), and now i have just inferno. The reason why i didn't bug much is because since some big updates to the X code from a while back, for xcb compatibility, reduced the occurence of such freezes largely! I do get the inferno window to completely freeze sometimes, I blame xcb though, especially since this is a gentoo machine with all the latest gnu *, and i'm sure it's hard to keep up :D. emu-g is rather stable so it's just my client that crashes all the time; a good wmsetup script can help tons in these cases If anyone is still interested, i can try getting some useful information out of the xcb lockups and whatever i get on the console..
• Dec 02, 2009

  issue 195 (/tmp & /usr/$user/tmp directories missing in recent hg clone...) commented on by sor...@gmail.com   -   Er, bump! :) I see there were improvements in the mkfile in this regard, here attached is a diff that makes the needed directories for me, it's basically all that's missing from a smooth mk install.

  Er, bump! :) I see there were improvements in the mkfile in this regard, here attached is a diff that makes the needed directories for me, it's basically all that's missing from a smooth mk install.
• Nov 29, 2009

  issue 211 (snarf device not binded) reported by 23hiro   -   What version of the product are you using? On what operating system? vitanuova site binary windows xp snarfed from snarf(3): Emu(1) automatically binds the device to both /dev and /chan when it starts up, if a window system is configured. I have to bind it manually.

  What version of the product are you using? On what operating system? vitanuova site binary windows xp snarfed from snarf(3): Emu(1) automatically binds the device to both /dev and /chan when it starts up, if a window system is configured. I have to bind it manually.
• Nov 19, 2009

  issue 210 (Unable to list directory from host) Status changed by Charles.Forsyth   -   i've stopped the second ls from blocking. the first problem might be a little trickier to mend. apparently the target files are on many devices (more than 16 different ones).

  Status: Started

  i've stopped the second ls from blocking. the first problem might be a little trickier to mend. apparently the target files are on many devices (more than 16 different ones).

  Status: Started
• Nov 19, 2009

  Revision d6d6cf4063 (CHANGES) pushed by Charles.Forsyth   -   CHANGES

  CHANGES
• Nov 19, 2009

  issue 210 (Unable to list directory from host) reported by extrudedaluminiu   -   Hi, ; cd '#U*/home/snapshots' ; ls ls: Readdir: .: too many devices ; ls <emu lockup> The directory /home/snapshots contains a number of symlinks to files with funny names (such as @@0x0000000236cf0b40) on the host.

  Hi, ; cd '#U*/home/snapshots' ; ls ls: Readdir: .: too many devices ; ls <emu lockup> The directory /home/snapshots contains a number of symlinks to files with funny names (such as @@0x0000000236cf0b40) on the host.
• Nov 16, 2009

  issue 209 (appl/spree/mkfile broken) reported by powerman.asdf   -   What steps will reproduce the problem? 1. fetch and try to build latest revision 2. 3. What is the expected output? What do you see instead? build failed with: ... (cd spree; mk install) limbo -gw -I lib -o engines/afghan.dis engines/afghan.b engines/afghan.b:3: near ` ; ` : can't include sys.m: No such file or directory engines/afghan.b:5: near ` ; ` : can't include draw.m: No such file or directory engines/afghan.b:6: near ` ; ` : can't include sets.m: No such file or directory mk: limbo -gw -I ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) What version of the product are you using? On what operating system? current on Linux Please provide any additional information below. I've build it early today without problems, but that's probably because I had another inferno installed and it somehow used .m-files from installed inferno while building new one. When I've tried to build inferno on system without already installed inferno I got that error. This can be quickly fixed in appl/spree/mkfile using attached patch, but I think right fix should be rewriting mkfile to use $ROOT/mkfiles/mkdis.

  What steps will reproduce the problem? 1. fetch and try to build latest revision 2. 3. What is the expected output? What do you see instead? build failed with: ... (cd spree; mk install) limbo -gw -I lib -o engines/afghan.dis engines/afghan.b engines/afghan.b:3: near ` ; ` : can't include sys.m: No such file or directory engines/afghan.b:5: near ` ; ` : can't include draw.m: No such file or directory engines/afghan.b:6: near ` ; ` : can't include sets.m: No such file or directory mk: limbo -gw -I ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) mk: for j in ... : exit status=exit(1) What version of the product are you using? On what operating system? current on Linux Please provide any additional information below. I've build it early today without problems, but that's probably because I had another inferno installed and it somehow used .m-files from installed inferno while building new one. When I've tried to build inferno on system without already installed inferno I got that error. This can be quickly fixed in appl/spree/mkfile using attached patch, but I think right fix should be rewriting mkfile to use $ROOT/mkfiles/mkdis.
• Nov 16, 2009

  issue 208 (conflict while hg update on fonts/LICENCE) Status changed by Charles.Forsyth   -   just delete any existing LICENCE file and do another update. had i realised in time that it wasn't in the original set, i could have pushed the original version, then the updated version, and it would not moan. unfortunately, i saw that too late. sorry. i don't think there's a way of putting it right now.

  Status: Explained

  just delete any existing LICENCE file and do another update. had i realised in time that it wasn't in the original set, i could have pushed the original version, then the updated version, and it would not moan. unfortunately, i saw that too late. sorry. i don't think there's a way of putting it right now.

  Status: Explained
• Nov 16, 2009

  issue 208 (conflict while hg update on fonts/LICENCE) commented on by powerman.asdf   -   btw, amount of small headaches here and there because of using these non-free fonts are funny :)

  btw, amount of small headaches here and there because of using these non-free fonts are funny :)
• Nov 16, 2009

  issue 208 (conflict while hg update on fonts/LICENCE) reported by powerman.asdf   -   What steps will reproduce the problem? 1. download and unpack http://www.vitanuova.com/dist/4e/ inferno-20090730.tgz 2. hg pull 3. hg update What is the expected output? What do you see instead? Expect to see no merge conflicts. :) But: $ hg update merging fonts/LICENCE warning: conflicts during merge. merging fonts/LICENCE failed! 47 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges $ hg diff fonts/LICENCE diff -r 7717b1cd5b20 fonts/LICENCE --- a/fonts/LICENCE Sun Nov 01 21:50:21 2009 +0000 +++ b/fonts/LICENCE Mon Nov 16 22:35:47 2009 +0200 @@ -4,7 +4,12 @@ You MAY NOT: +<<<<<<< local +- make an ADAPTATION of files that are copyright Bigelow & Holmes found in the directory +``/font'' and its various subdirectories (``FONT SOFTWARE''). +======= - make an ADAPTATION of files that are copyright Bigelow & Holmes found in the Inferno distribution (``FONT SOFTWARE''). +>>>>>>> other - distribute FONT SOFTWARE except as part of a larger software distribution incorporating the Inferno system software (and any adaptations of it YOU may make) provided that the distribution includes minimum sub-licence terms as specified below. What version of the product are you using? On what operating system? Please provide any additional information below.

  What steps will reproduce the problem? 1. download and unpack http://www.vitanuova.com/dist/4e/ inferno-20090730.tgz 2. hg pull 3. hg update What is the expected output? What do you see instead? Expect to see no merge conflicts. :) But: $ hg update merging fonts/LICENCE warning: conflicts during merge. merging fonts/LICENCE failed! 47 files updated, 0 files merged, 0 files removed, 1 files unresolved use 'hg resolve' to retry unresolved file merges $ hg diff fonts/LICENCE diff -r 7717b1cd5b20 fonts/LICENCE --- a/fonts/LICENCE Sun Nov 01 21:50:21 2009 +0000 +++ b/fonts/LICENCE Mon Nov 16 22:35:47 2009 +0200 @@ -4,7 +4,12 @@ You MAY NOT: +<<<<<<< local +- make an ADAPTATION of files that are copyright Bigelow & Holmes found in the directory +``/font'' and its various subdirectories (``FONT SOFTWARE''). +======= - make an ADAPTATION of files that are copyright Bigelow & Holmes found in the Inferno distribution (``FONT SOFTWARE''). +>>>>>>> other - distribute FONT SOFTWARE except as part of a larger software distribution incorporating the Inferno system software (and any adaptations of it YOU may make) provided that the distribution includes minimum sub-licence terms as specified below. What version of the product are you using? On what operating system? Please provide any additional information below.

Earlier this year

• Nov 05, 2009

  issue 181 (DragonFly BSD support) commented on by extrudedaluminiu   -   Slightly updated version of this patch, with directory information in the diff and updated to match ip changes in Inferno: http://www.grex.org/~vsrinivas/src/inferno-dragonflybsd.diff.bz2

  Slightly updated version of this patch, with directory information in the diff and updated to match ip changes in Inferno: http://www.grex.org/~vsrinivas/src/inferno-dragonflybsd.diff.bz2
• Nov 02, 2009

  issue 204 (vacfs changing directory listings with vac -a archives) commented on by mechiel@ueber.net   -   attached a diff and new version. it stores dir qid+entry name and seems to solve the problem for me. i think the whole approach may be using a bit too much memory: the entries are never removed. that's not new with this patch. but with patch it does use a more memory. perhaps inactive subtrees (no fids) of the vac file tree can have its cached qids cleared. walking to those files again gives different qids then though...

  attached a diff and new version. it stores dir qid+entry name and seems to solve the problem for me. i think the whole approach may be using a bit too much memory: the entries are never removed. that's not new with this patch. but with patch it does use a more memory. perhaps inactive subtrees (no fids) of the vac file tree can have its cached qids cleared. walking to those files again gives different qids then though...
• Nov 01, 2009

  issue 204 (vacfs changing directory listings with vac -a archives) commented on by mechiel@ueber.net   -   this seems to be caused by a directory having directory entries with the same qid. vacfs maps directory qid+entry qid to a file, so these clash. plan 9 (ports) seems to use an additional field "qidspace" (in the direntry) to keep the qids unique. the limbo vac code ignores it... the simplest fix might be to map directory qid+entry _name_ to a file. at least names should be unique in a directory, and we calculate our own qids anyway (so using the qidspace won't win a lot; vacfs needs to have its own qids to keep qids unique over multiple vac archives it can serve). i'll try to send in a patch tomorrow.

  this seems to be caused by a directory having directory entries with the same qid. vacfs maps directory qid+entry qid to a file, so these clash. plan 9 (ports) seems to use an additional field "qidspace" (in the direntry) to keep the qids unique. the limbo vac code ignores it... the simplest fix might be to map directory qid+entry _name_ to a file. at least names should be unique in a directory, and we calculate our own qids anyway (so using the qidspace won't win a lot; vacfs needs to have its own qids to keep qids unique over multiple vac archives it can serve). i'll try to send in a patch tomorrow.