Chavdar Ivanov <ci4ic4%gmail.com@localhost> writes: >> Are you really sure your tree has no local changes? If there is a >> conflict and conflict markers, various tools behave badly. > > I ran pkg_chk, there were very few problems. One package had mixed-up > Makefile, perhaps due to an early local change; I reloaded all files > for it. There are a number of packages installed from wip, some of > them with dependencies from wip, which later have been moved to the > main pkgsrc or even removed; I dealt with these manually. There were > also a bunch of obsolete packages installed, which were only leaf, I > removed them (two from x11, related to printing, and about 10-12 tex- > packages). So if you do "cvs up" in /usr/pkgsrc, and save the output, then: 1) there are no lines starting with "C" 2) For every line starting with "M", you have run diff and you are sure it's ok? or do you mean something else? >> Run "pkg_chk -uq" manually. llvm should be in it, but it seems it is >> not. llvm should show up in MISMATCH_TODO. You did not answer this. This is a critical point. > This is what comes from the pkg_rr log: Sure, but the problem is that llvm is not in MISMATCH_TODO, not what happens when clang is built. What happens when clang is built is a symptom of not having replaced llvm first. You need to figure out why llvm was not in MISMATCH_TODO, which means pkg_chk -uq and seeing if it is there. And perhaps "make show-downlevel" in lang/llvm. > pkg_rr somehow has failed to notice that llvm also needs an update and > it needs to be done ahead of the clang update - as a result of the > sort. Yes, and I have been asking you to figure out why and how. >> >> Can you find out from the output (that I hope you saved) whether llvm >> >> was on the MISMATCH list? > > That is. llvm was not listed in any of the lists. That is very wrong, and we need to find out why it is not. >> You said "queued before"; do you mean "python37 is in MISMATCH but >> things are misordered" or "python37 is not in MISMATCH"? > > The lists above do not show python3.7. The presently installed version > is 3.7.8. py37-sqlite3 shows dependency on python3.7.9 and builds it, > but the installation fails again, as python3.7.8 is installed. There is something very wrong, and others do not report this. Please run "pkg_chk -uq" and see if python37 and llvm are reported as mismatched. If they are not, this is not a pkg_rr problem. > Basically the same as with clang/llvm. I then manually replaced python > and reran pkg_rr, which then caught all other py37 packages for > replacement. No real surprise there! >> Also, pkg_rr, pkg_chk, and tools in general, do not deal well with >> multiversion things like pyNN-foo, but they are msotly ok for the >> default version. > > They also do not deal well with packages having the same name. but > different underlying versions - e.g. pkg_chk showed > > archivers/py-zipp1 - py37-zipp-3.1.0nb1 > py37-zipp-1.2.0 - ignoring > > (it sees that py-zipp1 package should be also called 'py37-zipp' and > as the installed version is higher, it ignores it - but it will miss a > new version of py-zipp this way, or so I think). Yes, that's also tricky. Perhaps also a bug in pkg_chk, perhaps not.
Attachment:
signature.asc
Description: PGP signature