Chavdar Ivanov <ci4ic4%gmail.com@localhost> writes: > The package being replaced at the moment was clang-10.0.1 > (clang-10.0.0 was installed at the moment). This obviously requires > the latest llvm, which had to be built, but was not in any of the > three lists (MISMATCH_TODO, REBUILD_TODO and UNSAFE_TODO). So > llvm-10.0.1 got successfully built, but as llvm-10.0.0nb1 was > installed, it didn't replace it. Are you really sure your tree has no local changes? If there is a conflict and conflict markers, various tools behave badly. Run "pkg_chk -uq" manually. llvm should be in it, but it seems it is not. llvm should show up in MISMATCH_TODO. Another bug is that llvm didn't show up as a dependency. read the pkg_rr code, around line 463. Run those commands in clang, and see if llvm is listed as a dependency. >> Can you find out from the output (that I hope you saved) whether llvm >> was on the MISMATCH list? > > I can post the three lists, but they are rather long. For whatever > reason pkg_rr hadn't recognized llvm as a package in need of an > upgrade. AS above, llvm was not in any of the lists. That's what I needed to know. It should have gotten into MISMATCH. > I used to do this as well; now I prefer using only '-uv'. With '-k' > one can let it go over as many as packages it can, but it may leave > the packages in inconsistent state, if I ca say this - I use this > build host as a pkgin server and if I use '-uvk', then get the list > with the '-' at the end and go over each of them, thinking that > everything would be ok, there are still unresolved upgrades from > packages depending on these last ones. So at the moment I run only > '-uv', sorting out each failure as it goes, then cleaning the work > directories and carrying on. Perhaps it is not the right thing, but it > seems better then the previous. What you are doing is perfectly reasonable. I use -k because my computer makes more progress when I am not paying attention. In theory, and I think mostly in practivce, anything replaced later after fixing will result in further replaces in order, so things should end up ok. > Anyway, this seems to happen more often now, I have several similar > logs (I keep the pkg_rr logs, if they are of interest), e.g. with > python3.7 as well ( some python package using the default 3.7 gets > queued for rebuild before python3.7, which leads to python3.7 being > rebuilt and its installation fail, as the previous version is > obviously installed). You said "queued before"; do you mean "python37 is in MISMATCH but things are misordered" or "python37 is not in MISMATCH"? 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.
Attachment:
signature.asc
Description: PGP signature