On 2024-01-05 at 21:45:25 +0000, pete <petegn@xxxxxxxx> wrote: > Hi folks . > > > I am still getting plagued by these Python warnings > > warning: could not get file information for > usr/lib/python3.11/site-packages/pyr???????????????????? > ate_limiter-3.1.0.dist-info/ > ??????? warning: could not get file information for > usr/lib/python3.11/site-packages/pyr???????????????????? > ate_limiter-3.1.0.dist-info/LICENSE > ????????? warning: could not get file information for > usr/lib/python3.11/site-packages/pyr???????????????????? > ate_limiter-3.1.0.dist-info/METADATA > ????????? warning: could not get file information for > usr/lib/python3.11/site-packages/pyr???????????????????? > ate_limiter-3.1.0.dist-info/RECORD > ????????? warning: could not get file information for > usr/lib/python3.11/site-packages/pyr???????????????????? > ate_limiter-3.1.0.dist-info/WHEEL > > > > it seems every time there is something Python related i get around 150 lines of > these warnings any help anyone before i loose it and rebuild the system > that is a nightmare thought > > > Pete > On 2024-01-06 at 07:06:06 -0600, Doug Newgard <dnewgard@xxxxxxxxxxx> wrote: > On Sat, 6 Jan 2024 12:55:24 +0000 > pete <petegn@xxxxxxxx> wrote: > > > the problem is if you manually go into the directorys the files are there and > > are not zero length > > > > i checked that > > And yet both pacman and python say they are not there. What does > `ls -lR /usr/lib/python3.11/site-packages/gpg/` show? I know that pete said that the question marks in the original post are artifacts, but I'm still hung up on the fact that in that original post, the filenames appear to be relative rather than absolute, as if some environment variable is unset, or perhaps mistakenly set to an empty string instead of being unset. I admit that I haven't read every post in excruciating detail, but if something in pete's system is looking in usr/lib, but all the people helping are looking in /usr/lib, that might explain some of the apparently contradictory results. Can pete please verify that the warnings name files in /usr/lib/... (an absolute path) and not usr/lib/... (a relative path)? Or perhaps capture the output from commands that generate the warnnings in a file and post/attach that instead of (presubably) copying and pasing from a terminal program (which is evidently not a lossless copy)?
