saj%yipeia@Sun.COM (Scott A. Jordahl) (12/16/89)
Well, I have dusted off my 1.1 floppies, booted Minix up on my new 20Mhz 286 clone, and started the upgrade process to 1.3 (getting ready for 1.5.0!!!). I got all the upgrade kits off of the N. Dakota State archive server (Thanks Glen!!!) and started plugging away. The thing that most suprised me is that I had no problem getting Minix installed on the second partition of my "D:" RLL drive (hd7) (ST251-1 with the DTC 7287 1:1 RLL Controller). I actually was "amazed" that Minix right from the 1.1 box came right up on the disk (I used a special version of "fdisk", but everything else was stock). I figured with such a strange configuration of hardware that getting my hard disk going would be my big problem. Not so. Now to the REAL problem: I installed all the new compiler stuff including the 1.3libc.a and the "/usr/include" files from 1.3. I got everything else in place from the 11-12kit including creating new directories and shuffling files. All I had left was to run the patch program (from the archive server) on the "diff.patch" file. Well, as soon as patch got to cc.c (Third patch in) it got to hunk #6 saying it was a strange context diff, applied the patch anyway, and then came to the next hunk and asked which file it was for. I told cc.c again and it continued on its way, but it starting acting funny on subsequent files to the point I decided to quite and give up. I thought that maybe the version of "patch" I had was buggy, so I down loaded the source to patch 2.0 Level 12 and compiled that. Same results. When I removed the offending hunk from the diff file (#6), patch worked fine for the rest of the cc.c diffs. It did stop again, however, in a later patch. I looked at the part of the diff that caused the problem and can't find anything obvious wrong with it. Has anyone else experienced this problem? Any clues or suggestions? Thanks all! -- Scott /########################################################\ | Scott A. Jordahl | | UUCP: saj@sun.COM | | PHONE: WK: [415] 336-5463 | | HM: [408] 270-5619 | \########################################################/
EPRF%SNYCENVM.BITNET@cornellc.cit.cornell.edu (Peter Flass) (12/19/89)
On Fri, 15 Dec 89 22:02:50 GMT Scott A. Jordahl said: >... > >Now to the REAL problem: > >I installed all the new compiler stuff including the 1.3libc.a and the >"/usr/include" files from 1.3. I got everything else in place from the >11-12kit including creating new directories and shuffling files. All I >had left was to run the patch program (from the archive server) on the >"diff.patch" file. Well, as soon as patch got to cc.c (Third patch in) >it got to hunk #6 saying it was a strange context diff, applied the >patch anyway, and then came to the next hunk and asked which file it >was for. I told cc.c again and it continued on its way, but it >starting acting funny on subsequent files to the point I decided to >quite and give up. I thought that maybe the version of "patch" I had >was buggy, so I down loaded the source to patch 2.0 Level 12 and >compiled that. Same results. When I removed the offending hunk from >the diff file (#6), patch worked fine for the rest of the cc.c diffs. >It did stop again, however, in a later patch. > >I looked at the part of the diff that caused the problem and can't find >anything obvious wrong with it. Has anyone else experienced this >problem? Any clues or suggestions? > Sorry...no suggestions. I had the same problem with the 1.2->1.3 upgrade. In fact, I believe Patch went into a loop on CC.C and bailed out on several other programs, even with PATCH -L. I finally had to hand-apply a number of patches. This is with patch 2.0.1.5 level 11. - Pete (P.S. Glad to see the list is fixed - I had several postings go into the bit-bucket and finally gave up for a while) +---------------------------------------------------------------------------+ | | | Peter Flass BITNET: EPRF@SNYCENVM (preferred) | | Director of Computing Services INTERNET: ESCFLASS@UBVM.CC.BUFFALO.EDU | | SUNY Empire State College AT&TNET: (518)587-2100 X350 | | 2 Union Avenue "After three days without programming, | | Saratoga Springs NY 12866 Life becomes meaningless" | | - The Tao of Programming | +---------------------------------------------------------------------------+
overby@plains.UUCP (Glen Overby) (12/20/89)
In article <6465@nigel.udel.EDU> EPRF%SNYCENVM.BITNET@cornellc.cit.cornell.edu (Peter Flass) writes: >On Fri, 15 Dec 89 22:02:50 GMT Scott A. Jordahl said: Summary: patch goes into a loop on the 1.1-1.2 upgrade kit from vm1.nodak.edu and starts acting weird. Patch -l doesn't help, either. This is the first I've heard of the problem. I believe I the full upgrade with the kits (just to check them out), and I don't recall any problems. If anybody can track down exactly what is wrong, I'd like to hear about it so I can fix it. Has anybody had a similar problem with a kit FTPed directly from bugs? -- Glen Overby <overby@plains.nodak.edu> uunet!plains!overby (UUCP) ncoverby@ndsuvax, overby@plains (Bitnet)
wongda@ecf.toronto.edu (WONG DANIEL Y H) (12/20/89)
SIGN-OFF
paula@bcsaic.UUCP (Paul Allen) (12/21/89)
In article <3013@plains.UUCP> overby@plains.UUCP (Glen Overby) writes: >In article <6465@nigel.udel.EDU> EPRF%SNYCENVM.BITNET@cornellc.cit.cornell.edu (Peter Flass) writes: >>On Fri, 15 Dec 89 22:02:50 GMT Scott A. Jordahl said: > >Summary: patch goes into a loop on the 1.1-1.2 upgrade kit from > vm1.nodak.edu and starts acting weird. Patch -l doesn't help, > either. > >Has anybody had a similar problem with a kit FTPed directly from bugs? I upgraded using the 1.2 and 1.3 upgrade kits on bugs, but I did all my un-sharing and patching on a Sun. (My Minix machine at the time was the two-floppy IPC card in my Sun.) I don't remember having any particular trouble with the patches. Could this be a stack-size problem? Perhaps the original poster could do a chmem =64000 patch and report back on what happens? Paul Allen -- ------------------------------------------------------------------------ Paul L. Allen | pallen@atc.boeing.com Boeing Advanced Technology Center | ...!uw-beaver!bcsaic!pallen
EPRF%SNYCENVM.BITNET@cornellc.cit.cornell.edu (Peter Flass) (01/04/90)
On Thu, 21 Dec 89 07:30:00 GMT Paul Allen said: >In article <3013@plains.UUCP> overby@plains.UUCP (Glen Overby) writes: >>In article <6465@nigel.udel.EDU> EPRF%SNYCENVM.BITNET@cornellc.cit.cornell.edu > (Peter Flass) writes: >>>On Fri, 15 Dec 89 22:02:50 GMT Scott A. Jordahl said: >> >>Summary: patch goes into a loop on the 1.1-1.2 upgrade kit from >> vm1.nodak.edu and starts acting weird. Patch -l doesn't help, >> either. >> >>Has anybody had a similar problem with a kit FTPed directly from bugs? > >I upgraded using the 1.2 and 1.3 upgrade kits on bugs, but I did all my >un-sharing and patching on a Sun. (My Minix machine at the time was the >two-floppy IPC card in my Sun.) I don't remember having any particular >trouble with the patches. > >Could this be a stack-size problem? Perhaps the original poster could >do a > > chmem =64000 patch > >and report back on what happens? > Here is a log and some relevant information on my problem patching CC.C from 1.2 -> 1.3. Another possibility is that there is a problem with my copy of cc. - Pete -------------- stuff follows -------------------------------------- >> Status of "Patch" text data bss stack memory 25840 5894 4842 54800 91376 /usr/bin/patch $Header: patch.c,v 2.0.1.5 88/06/03 15:09:37 lwall Locked $ Patch level: 11 >> Log from patch of 1.2 cc.c using patches from VM1.NODAK.EDU >> Command "patch -l<patches.cc 2>&1 | tee patch.log Hmm... Looks like a context diff to me... The text leading up to this was: -------------------------- |diff -rc2 v1.2base/minix/commands/cc.c v1.3d/minix/commands/cc.c |*** v1.2base/minix/commands/cc.c Thu Sep 29 10:04:16 1988 |--- v1.3d/minix/commands/cc.c Thu Sep 29 21:47:47 1988 -------------------------- Patching file cc.c using Plan A... Hunk #1 succeeded at 1. Hunk #2 succeeded at 1. Hunk #3 succeeded at 25. (Fascinating--this is really a new-style context diff but without the telltale extra asterisks on the *** line that usually indicate the new style...) Hunk #4 succeeded at 37. Hmm... The next patch looks like a context diff to me... The text leading up to this was: -------------------------- | }; | | | #ifdef MEM640K -------------------------- <Patch asks "File to patch:"> <Response: cc.c> Patching file cc.c using Plan A... (Fascinating--this is really a new-style context diff but without the telltale extra asterisks on the *** line that usually indicate the new style...) Hunk #1 succeeded at 35 with fuzz 1 (offset -3 lines). Hmm... The next patch looks like a context diff to me... The text leading up to this was: -------------------------- | | | #ifdef MEM640K | /* MINIX paths for 640K PC (not 512K AT) */ -------------------------- <Patch asks: "File to patch:"> <Response: cc.c> Patching file cc.c using Plan A... Hunk #1 succeeded at 50 (offset 5 lines). Hunk #2 succeeded at 46 (offset -11 lines). Hunk #3 succeeded at 67 (offset 5 lines). Hunk #4 succeeded at 63 (offset -11 lines). Hunk #5 succeeded at 90 (offset 5 lines). <At this point Patch loops> +---------------------------------------------------------------------------+ | | | Peter Flass BITNET: EPRF@SNYCENVM (preferred) | | Director of Computing Services INTERNET: ESCFLASS@UBVM.CC.BUFFALO.EDU | | SUNY Empire State College AT&TNET: (518)587-2100 X350 | | 2 Union Avenue "After three days without programming, | | Saratoga Springs NY 12866 Life becomes meaningless" | | - The Tao of Programming | +---------------------------------------------------------------------------+