possible 1.8.3 / 1.9.1 intertalk issue #1668
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#1668
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I have system which was running 1.8.3+I2P patches(from Killyourtv.i2p)
later it was updated to 1.9.1
CentOS 5
I also have this from deep-check on
and
/root/tahoe is path to old tahoe install(1.8.3 i2p one needed to be installed with python 2.6 for some reason)
1.8.3/i2p is no longer in $PATH/PYTHONPATH(but this folder is still present on machine).
tahoe --version from this machine
I don't exactly knew how this happen. how they become intermingled.as I said - old one is not in PATH/PYTHONPATH.
Moving /root/tahoe away resulted in
so this looks like 1.9.1's setup.py somehow got it's hands on parts of old install?
FWIW, the I2P installer script will use whatever "python" points to, it doesn't depend on python2.6.
At the end of the installation you're advised to set the
PATH
andPYTHONPATH
accordingly. I'd guess that you may have left the old installation defined in thePATH
.Make sure the old path is not defined in PATH and PYTHONPATH then try to reinstall.
Possibly related to #1669 (notice the "ValueError (need more than 8 values to unpack)"), but the mixture of 1.8.3 and 1.9.1 code means that we can't conclude anything concrete from this traceback.
How was the installation updated to 1.9.1? Using
tahoe setup.py install
? It seems as though it is using the 1.9.1 Tahoe code with the dependencies (Twisted, foolscap, etc.) that were installed for 1.8.3+I2P. That could result in using a wrong version of a dependency if its requirement changed, although it is not as bad as mixing files within the same Python package.After moving /root/tahoe back, please do
tahoe --version-and-path
how?
I don't use install.
just python setup.py build / python setup.py test on new one
I moved /root/tahoe back
Replying to vikarti:
Oh, ok. I was confused by the /root paths and the fact that you're using
tahoe
to run. You should be usingbin/tahoe
(in this case/root/tahoe-new/bin/tahoe
) to run an instance of Tahoe that has been built rather than installed.What does
say?
BTW, I don't recommend running Tahoe as root.
Replying to killyourtv:
Oh, that could confuse things no end. It shouldn't be necessary to set
PYTHONPATH
; as long as you're running thetahoe
script that is in thebin/
directory of the build you want, that should be sufficient. If you setPYTHONPATH
as well, then you're explicitly asking for a mixture of the code pointed to byPYTHONPATH
and the code from that build.at this time
which is correct.
I can't reproduce this one(with 1.8.3 paths) anymore
[notice with incorrect ref deleted]commit
Replying to [davidsarah]comment:8:
That was a holdover from when duck was handling it. I'll test without PYTHONPATH being set and report back if it is required. If it is not needed (of course) I'll advise people to not set it any longer.
Replying to [killyourtv]comment:13:
OK, thanks.