Requesting help from Fedora (or other Linux) users! PR 2057 contains a bug fix which has been tested to work on Windows, and I’m asking the bug reporter to test it on their Fedora system. Where would the fixed source file be placed?
The bug reporter has tried replacing /usr/lib/python3.13/site-packages/gramps/plugins/webreport/narrativeweb.py but it didn’t seem to fix the problem. Is that the correct location? Is there a trick to updating the Python cache?
If they are editing the file instead of overwriting, the OS tends to object about needing Admin rights repeatedly. Overwriting tends to only need 1 admin confirmation
I’ve pointed the bug reporter to this thread, and from their comment in the bug, they said they started Gramps after replacing the file so I believe the answer to your question is, yes.
Could you confirm whether the file location is correct?
I’m the bug reporter. Yes, I tested a few times and restarted gramps each time. I’m running on Fedora 42, fully updated. Here is what I added to the bug report:
-=-=-=-=-=-=-=-=
I found the changed file on github, /gramps/plugins/webreport/narrativeweb.py. I found that file on my system and saved it. I downloaded your updated file to my system at /usr/lib/python3.13/site-packages/gramps/plugins/webreport/narrativeweb.py. I checked that the downloaded file contained the changes you made. I ran gramps and regenerated my web site using the Basic-Blue style sheet. I then checked the css/narrative-screen.css file on my web site. It did not change. It remained at Basic-Lilac.
Wondering if perhaps there was a cached version of the python file I found:
/usr/lib/python3.13/site-packages/gramps/plugins/webreport/pycache/narrativeweb.cpython-313.opt-1.pyc
and
/usr/lib/python3.13/site-packages/gramps/plugins/webreport/pycache/narrativeweb.cpython-313.pyc
I renamed those file to move them out of the way and retested generating my web site. It did not changed anything. My tests still failed as before.
-=-=-=-=-=-=-=-=
I will also note that the .pyc file in the cache area was not regenerated after removing it and starting gramps and generating the web site a few times. Of course, all the cache files and the directory itself are owned by root and I’m running gramps under my own user id.
More on the cache files. They are included in the rpm file that is downloaded trom the Fedora repositories when gramps is first installed or later updated. Makes sense as they are owned by root.
There may be cached files in /usr/lib/python3.13/site-packages/__pycache__ and in ~/.local/lib/python3.1?/site_packages/ as well.
Which version of Fedora is this? F42? Would it help if someone built a replacement RPM for gramps? I might be able to fit that in over the next couple of days …
No other related cached files found in the areas you suggested. Besides checking manually I also used the locate command to search. The system runs a cron job (updatedb) every night and that maintains a searchable database of the names of all files and directories on the system. I note that since I deleted the cache version of narrativeweb it was not recreated after running gramps several times. I don’t know if that should happen automatically or if I would need to run a special command to do so.
I also checked again to make sure the file I downloaded matched the gramps python one:
charlie@redwood:~$ diff /home/charlie/Downloads/narrativeweb.py /usr/lib/python3.13/site-packages/gramps/plugins/webreport/narrativeweb.py
charlie@redwood:~$ (no output mrans they are the same,)
I looked at the changed and noticed a variable called clobber was added so I checked for that:
charlie@redwood:~$ grep clobber /usr/lib/python3.13/site-packages/gramps/plugins/webreport/narrativeweb.py
def copy_file(self, from_fname, to_fname, to_dir="", clobber=False):
if clobber or not os.path.exists(dest):
I also ran “lsof | grep narr” to see if there were any open files. Nothing.
Yes, it is a Fedora 42 system.
If I get a chance later today I will try a reboot to see if that fixes anything.
Hold on!!! Pilot error. I feel so stupid. Image of me doing a face-palm here.
For testing I had changed the target for generating the website and forgotten I had done so. I was looking on the wrong place for the results. I just regenerated the web site to the correct location a few times, each with a different CSS and it worked as expected each time. The bug has been squashed.