cvs update: move away any file; it is in the way
Hi there, I am puzzled with a strange behaviour of CVS. In my .profile I have PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/ CVSROOT=anon...@ftp.hostserver.de:/cvs export PKG_PATH CVSROOT Now when updating e.g. /usr/src I get the following: /usr/src $ sudo cvs -q up -Pd cvs update: move away bin/ln/Makefile; it is in the way C bin/ln/Makefile cvs update: move away bin/ln/ln.1; it is in the way C bin/ln/ln.1 cvs update: move away bin/ln/ln.c; it is in the way C bin/ln/ln.c cvs update: move away bin/ln/symlink.7; it is in the way C bin/ln/symlink.7 This goes on like this for any file in /usr/src. Is this expected behaviour??? I doubt it ... dmesg and sysctl -all below. Any other input needed to investigate further? Anybody any ideas? (Beside deleting the sources and GETing a fresh checkout?) TIA. Cheers, STEFAN OpenBSD 5.6-current (GENERIC.MP) #415: Mon Oct 13 16:19:37 MDT 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 3203203072 (3054MB) avail mem = 3109289984 (2965MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.4 @ 0xe0010 (68 entries) bios0: vendor LENOVO version 79ETC9WW (2.09 ) date 12/22/2006 bios0: LENOVO 2007VG2 acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT ECDT TCPA APIC MCFG HPET SLIC BOOT SSDT SSDT SSDT SSDT acpi0: wakeup devices LID_(S3) SLPB(S3) LURT(S3) DURT(S3) EXP0(S4) EXP1(S4) EXP2(S4) EXP3(S4) PCI1(S4) USB0(S3) USB1(S3) USB2(S3) USB7(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpiec0 at acpi0 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.60 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu0: 4MB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 166MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM)2 CPU T7200 @ 2.00GHz, 1994.33 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,NXE,LONG,LAHF,PERF cpu1: 4MB 64b/line 16-way L2 cache cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 1 pa 0xfec0, version 20, 24 pins ioapic0: misconfigured as apic 2, remapped to apid 1 acpimcfg0 at acpi0 addr 0xf000, bus 0-63 acpihpet0 at acpi0: 14318179 Hz acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus 1 (AGP_) acpiprt2 at acpi0: bus 2 (EXP0) acpiprt3 at acpi0: bus 3 (EXP1) acpiprt4 at acpi0: bus 4 (EXP2) acpiprt5 at acpi0: bus 12 (EXP3) acpiprt6 at acpi0: bus 21 (PCI1) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS, resource for USB0, USB2, USB7 acpitz0 at acpi0: critical temperature is 127 degC acpitz1 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 92P1139 serial 2887 type LION oem Panasonic acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit online acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 1994 MHz: speeds: 2000, 1667, 1333, 1000 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel 82945GM Host rev 0x03 ppb0 at pci0 dev 1 function 0 Intel 82945GM PCIE rev 0x03: msi pci1 at ppb0 bus 1 radeondrm0 at pci1 dev 0 function 0 ATI Radeon Mobility X1300 M52-64 rev 0x00 drm0 at radeondrm0 radeondrm0: apic 1 int 16 azalia0 at pci0 dev 27 function 0 Intel 82801GB HD Audio rev 0x02: msi azalia0: codecs: Analog Devices AD1981HD, Conexant/0x2bfa, using Analog Devices AD1981HD audio0 at azalia0 ppb1 at pci0 dev 28 function 0 Intel 82801GB PCIE rev 0x02: msi pci2 at ppb1 bus 2 em0 at pci2 dev 0 function 0 Intel 82573L rev 0x00: msi, address 00:15:58:81:15:fb ppb2 at pci0 dev 28 function 1 Intel 82801GB PCIE rev 0x02: msi pci3 at ppb2 bus 3 wpi0 at pci3 dev 0 function 0 Intel PRO/Wireless 3945ABG rev 0x02: msi, MoW2, address 00:19:d2:85:6f:4d ppb3 at pci0 dev 28 function 2 Intel 82801GB PCIE rev 0x02: msi pci4 at ppb3 bus 4 ppb4 at pci0 dev 28 function 3 Intel 82801GB PCIE rev 0x02: msi pci5 at ppb4 bus 12 uhci0 at pci0 dev 29 function 0 Intel 82801GB USB rev 0x02: apic 1 int 16 uhci1 at pci0 dev 29 function 1 Intel 82801GB USB rev 0x02: apic 1 int 17 uhci2 at pci0 dev 29 function 2 Intel 82801GB USB rev 0x02: apic 1 int 18 uhci3 at pci0 dev 29 function 3 Intel 82801GB USB rev 0x02: apic 1 int 19 ehci0 at pci0 dev 29 function 7 Intel 82801GB USB rev 0x02: apic 1 int 19 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb5 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0xe2 pci6 at ppb5
Re: cvs update: move away any file; it is in the way
Hi Stefan,
Stefan Wollny wrote on Tue, Oct 14, 2014 at 02:25:04PM +0200:
I am puzzled with a strange behaviour of CVS.
In my .profile I have
PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/
CVSROOT=anon...@ftp.hostserver.de:/cvs
export PKG_PATH CVSROOT
When updating a tree, there are two places where cvs(1) looks for
the CVSROOT that applies to each directory: (1) In the CVS/Root
file of the directory, if any and (2) in the CVSROOT environment
variable or the cvs -d command line option. If (1) and (2) mismatch,
you get conflicts for all affected files. Note that your .profile
shown above may or may not have influenced what was put into some
CVS/Root files in the past and may or may not have influenced your
current CVSROOT setting in the environment: .profile is somewhat
unrelated to your problem.
Now when updating e.g. /usr/src I get the following:
/usr/src $ sudo cvs -q up -Pd
cvs update: move away bin/ln/Makefile; it is in the way
C bin/ln/Makefile
cvs update: move away bin/ln/ln.1; it is in the way
C bin/ln/ln.1
cvs update: move away bin/ln/ln.c; it is in the way
C bin/ln/ln.c
cvs update: move away bin/ln/symlink.7; it is in the way
C bin/ln/symlink.7
This goes on like this for any file in /usr/src.
Is this expected behaviour??? I doubt it ...
It really depends on what your are actually doing.
Your first step should be to figure out the state of your tree:
$ find /usr/src -path \*/CVS/Root -print -exec cat {} \;
Do not post the result because it is likely very long.
If all those files have identical content, you can fix your problem
by simply running against that server again (set CVSROOT in your
*current* environment - not .profile - or run cvs with -d).
If those files have *different* content, you need to figure out
whether you did that on purpose or accidentally. If you did that
on purpose and have a CVS/Root file in each directory, simply
using these files by unsetting the CVSROOT environment variable
may be enough - but note that will update different parts of the
tree against different servers.
I doubt you did it on purpose or you wouldn't be asking this question.
If you did *not* do this on purpose, removing the CVS/Root files
is likely to solve your problem:
$ find /usr/src -path \*/CVS/Root -print -exec rm {} \;
Obviously, do *NOT* do that in a tree where you intentionally
mixed content from different servers, or where you might forget
which servers parts of it came from. Also, note that short of
manually recreating CVS/Root files in all directories, you will
never again be able to use a tree where you did that without
having CVSROOT set or specifying cvs -d.
After running the removal, simply set CVSROOT to the server you
want and cvs up -dP away. Note that some CVS/Root files will
reappear in the future, but only in newly created directories.
Beside deleting the sources and GETing a fresh checkout?
In case you are unsure about the state of your tree, for example
if you think you ran various commands of unknown effect without
knowing what you were doing, and in case it is important that the
tree be reliable, for example because you want to build releases
from it that you want to run in production, that might be advisable.
In case you are sure that the only bad thing you did was running
cvs up against varying (as opposed to untrusted!) servers and nothing
except CVS/Root files is corrupt, that is not needed. It is your
call to decide whether you still trust your tree. Only you know
what you did to it, or if you do not, well, that's a data point,
too...
Yours,
Ingo
Re: cvs update: move away any file; it is in the way
Hi Ingo!
Thank you very, very much for your valuable, in-depth answer and advice!
I have issues with the system loosing it's routes. Because of this I had
tried several mirror sites and must have caught the divergent entries
doing so. Your advice solved the problem. Thanks again! Cheers,STEFAN
Gesendet: Dienstag, 14. Oktober 2014 um 15:24 Uhr
Von: Ingo Schwarze schwa...@usta.de
An: Stefan Wollny stefan.wol...@web.de
Cc: openbsd-misc misc@openbsd.org
Betreff: Re: cvs update: move away any file; it is in the wayHi Stefan,
Stefan Wollny wrote on Tue, Oct 14, 2014 at 02:25:04PM +0200:
I am puzzled with a strange behaviour of CVS.
In my .profile I have
PKG_PATH=http://ftp.hostserver.de/pub/OpenBSD/snapshots/packages/amd64/
CVSROOT=anon...@ftp.hostserver.de:/cvs
export PKG_PATH CVSROOT
When updating a tree, there are two places where cvs(1) looks for
the CVSROOT that applies to each directory: (1) In the CVS/Root
file of the directory, if any and (2) in the CVSROOT environment
variable or the cvs -d command line option. If (1) and (2) mismatch,
you get conflicts for all affected files. Note that your .profile
shown above may or may not have influenced what was put into some
CVS/Root files in the past and may or may not have influenced your
current CVSROOT setting in the environment: .profile is somewhat
unrelated to your problem.
Now when updating e.g. /usr/src I get the following:
/usr/src $ sudo cvs -q up -Pd
cvs update: move away bin/ln/Makefile; it is in the way
C bin/ln/Makefile
cvs update: move away bin/ln/ln.1; it is in the way
C bin/ln/ln.1
cvs update: move away bin/ln/ln.c; it is in the way
C bin/ln/ln.c
cvs update: move away bin/ln/symlink.7; it is in the way
C bin/ln/symlink.7
This goes on like this for any file in /usr/src.
Is this expected behaviour??? I doubt it ...
It really depends on what your are actually doing.
Your first step should be to figure out the state of your tree:
$ find /usr/src -path \*/CVS/Root -print -exec cat {} \;
Do not post the result because it is likely very long.
If all those files have identical content, you can fix your problem
by simply running against that server again (set CVSROOT in your
*current* environment - not .profile - or run cvs with -d).
If those files have *different* content, you need to figure out
whether you did that on purpose or accidentally. If you did that
on purpose and have a CVS/Root file in each directory, simply
using these files by unsetting the CVSROOT environment variable
may be enough - but note that will update different parts of the
tree against different servers.
I doubt you did it on purpose or you wouldn't be asking this question.
If you did *not* do this on purpose, removing the CVS/Root files
is likely to solve your problem:
$ find /usr/src -path \*/CVS/Root -print -exec rm {} \;
Obviously, do *NOT* do that in a tree where you intentionally
mixed content from different servers, or where you might forget
which servers parts of it came from. Also, note that short of
manually recreating CVS/Root files in all directories, you will
never again be able to use a tree where you did that without
having CVSROOT set or specifying cvs -d.
After running the removal, simply set CVSROOT to the server you
want and cvs up -dP away. Note that some CVS/Root files will
reappear in the future, but only in newly created directories.
Beside deleting the sources and GETing a fresh checkout?
In case you are unsure about the state of your tree, for example
if you think you ran various commands of unknown effect without
knowing what you were doing, and in case it is important that the
tree be reliable, for example because you want to build releases
from it that you want to run in production, that might be advisable.
In case you are sure that the only bad thing you did was running
cvs up against varying (as opposed to untrusted!) servers and nothing
except CVS/Root files is corrupt, that is not needed. It is your
call to decide whether you still trust your tree. Only you know
what you did to it, or if you do not, well, that's a data point,
too...
Yours,
Ingo
