[9fans] mk bug(s?) in plan9ports


    Sponsored Links


  • 1. [9fans] !@#$!@#$@ sshd
    I have a new laptop, so very little is working right :-) can someone remind me why the ssh FROM plan 9 TO Linux would get me to a TIS identification prompt? did SSH2 ever get done on Plan 9? thanks ron
  • 2. [9fans] did the mapping for the up arrow change?
    After weeks, I pulled the new sources/binaries. After that I had a problem with the down arrow button within 'page'. 'page' didn't know this keycode. stepping back to yesterdays 'page' ... and scrolling up in page worked. I concluded that the keyboard map has changed and presumed this was an incompatibility of my old kernel and the new userland (at least page). I rebuilt the kernel and page now understands the down arrow button correctly. But know 'vt' doesn't understand it correctly. Was there such a change to the keycodes in the kernel (and some of the userland binaries)? Regards, Heiko
  • 3. [9fans] Plan9 port man pages
    System is Linux Mandrake-9.1 Just adding /usr/local/plan9/man to MANPATH only works for man page entries that are unique to plan9 but all others have matches in linux man pages or ones that start with a digit (9c etc.) man command treats it as a section #. So, what os the correct way to handle it? -ishwar

[9fans] mk bug(s?) in plan9ports

Postby a » Sat, 05 Jun 2004 03:39:18 GMT

i've found at least one bug in the plan9ports mk. it (mk, not the bug) claims
to have come from Inferno, and russ wants packaging bug reports, and it's in
the plan9ports tree, so i don't know who should really get the bug, but here
you go.

first, the one i'm pretty sure of: when using a regular-expression rule as a
target, you need to do \\1 for the () substitution in the prereq, rather than \1,
as in plan 9 and sam.

second, and a bigger deal, mk seems to just get things wrong given nested
virtual rules. i have a target "push" which does "nuke export upload". nuke
is just one rm, upload is just one scp; export is a virtual target for "foo.export
bar.export baz.export". each of those do some queries and then post-process
the results. foo.export has a foo.txt target. %.txt relies on %.pre, and does
sed -e 'something' < $prereq > $target. %.pre has no prerequisites and just
does a DB query and puts the results in %target. doing "mk export" gets all
this right; doing "mk push" does the nuke, generates all the %.pre files, then
immediatly tries to do the upload (which fails). what's (perhaps) interesting
is that doing "mk -n push" claims it'll do the right thing. this seems like a
pretty substantial bug, unless i'm missing something.

neither of these two bugs exhibit themselves using mk on plan9.

third, and i'm less confident this is a bug, mk seems to get stuck on the
existance of files at invocation, rather than when a rule is run. that is, in
the above example, if the prerequisites for export are up to date before the
nuke is run (which removes them), it believes they still are when it gets to
the export. i wasn't able to compare the behavior here to my plan9 box.

any pointers or assistence will be very much appreciated.

(oh, this is all on OS X using a copy with May 14 as the most recent date in
the CHANGES file - is there a more accurate way to version them?)

Return to plan9


Who is online

Users browsing this forum: No registered users and 9 guest