trac fails when upgrading to Fedora 37

25 views
Skip to first unread message

Ard Vilken

unread,
Nov 29, 2022, 4:29:37 PM11/29/22
to Trac Users
Been running flawlessly for a while until upgrading to Fedora 37.  I'm getting the error messages listed below.  I looked online and some places with similar errors (but different programs) said to do:  pip install markupsafe==2.0.1

After doing that, I get no error messages but when trying to load the trac login page, get an error.  Is there another package or version of jinja that needs to be loaded?

I've looked in the log/ directory and log.txt and see nothing.  I see that log.txt is getting a new time stamp to show it's at least getting touched but there is no text in log.txt.  Is there another location where errors might be going?

initial error
--------------------------------------------

  File "/usr/sbin/tracd", line 33, in <module>
    sys.exit(load_entry_point('Trac==1.5.3', 'console_scripts', 'tracd')())
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/sbin/tracd", line 25, in importlib_load_entry_point
    return next(matches).load()
           ^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/importlib/metadata/__init__.py", line 198, in load
    module = import_module(match.group('module'))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.11/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1206, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1178, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1149, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/usr/lib/python3.11/site-packages/trac/web/standalone.py", line 35, in <module>
    from trac.web.auth import BasicAuthentication, DigestAuthentication
  File "/usr/lib/python3.11/site-packages/trac/web/auth.py", line 29, in <module>
    from trac.web.chrome import Chrome, INavigationContributor
  File "/usr/lib/python3.11/site-packages/trac/web/chrome.py", line 40, in <module>
    from trac.mimeview.api import RenderingContext, get_mimetype
  File "/usr/lib/python3.11/site-packages/trac/mimeview/__init__.py", line 14, in <module>
    from trac.mimeview.api import *
  File "/usr/lib/python3.11/site-packages/trac/mimeview/api.py", line 70, in <module>
    from trac.resource import Resource
  File "/usr/lib/python3.11/site-packages/trac/resource.py", line 21, in <module>
    from trac.util.presentation import classes
  File "/usr/lib/python3.11/site-packages/trac/util/presentation.py", line 26, in <module>
    from markupsafe import soft_unicode
ImportError: cannot import name 'soft_unicode' from 'markupsafe' (/usr/lib64/python3.11/site-packages/markupsafe/__init__.py)

Jun Omae

unread,
Nov 29, 2022, 5:18:36 PM11/29/22
to trac-...@googlegroups.com
On Wed, Nov 30, 2022 at 6:29 AM Ard Vilken <ardv...@gmail.com> wrote:
> File "/usr/lib/python3.11/site-packages/trac/resource.py", line 21, in <module>
> from trac.util.presentation import classes
> File "/usr/lib/python3.11/site-packages/trac/util/presentation.py", line 26, in <module>
> from markupsafe import soft_unicode
> ImportError: cannot import name 'soft_unicode' from 'markupsafe' (/usr/lib64/python3.11/site-packages/markupsafe/__init__.py)

The error has been reported [1] and fixed in trunk.
Try to upgrade to trunk [2].

[1] https://trac.edgewall.org/ticket/13404
[2] https://svn.edgewall.org/repos/trac/trunk/

--
Jun Omae <jun...@gmail.com> (大前 潤)

Bill Buklis

unread,
Dec 2, 2022, 3:51:32 PM12/2/22
to trac-...@googlegroups.com

I'm trying to upgrade a local trac system on Windows (using tracd) to 1.4 from 1.2.2. I've upgraded the plugins as much as possible. Everything seemed to go relatively smoothly.

I ran pip install --upgrade Trac. This seems to work properly. Displaying "pip list" shows the trac version as 1.4.3.

I ran trac-admin <tracfolder> upgrade. Everything seems fine.

I ran trac-admin <tracfolder> wiki upgrade. Wiki files seem to be updated properly.

I then restarted the trac service.

However, the main page now displays:

Warning:
  • Error with navigation contributor "AdminModule"
  • Error with navigation contributor "SearchModule"
  • Error with navigation contributor "RoadmapModule"
  • Error with navigation contributor "QueryModule"
  • Error with navigation contributor "ReportModule"
  • Error with navigation contributor "TicketModule"
  • Error with navigation contributor "TimelineModule"
  • Error with navigation contributor "WikiModule"

Configuration Error

Cannot find implementation(s) of the IPermissionPolicy interface named DefaultTicketPolicy, DefaultWikiPolicy. Please check that the Component is enabled or update the option [trac] permission_policies in trac.ini.


In addition the "Powered by Trac" version still shows 1.2.2, which I think may be the crux of the problem. However, I can't see why.

Python version is 2.7. It is the only version installed.

I turned on INFO logging and the log also shows that it is starting version 1.2.2. The traceback is odd in that it shows a path to .py files located in a folder that does not exist. For example:

File "c:\users\<unknownuser>\appdata\local\temp\easy_install-jdu2wl\Trac-1.2.2-py2.7-win-amd64.egg.tmp\trac\env.py", line 942, in open_environment
    needs_upgrade = env.needs_upgrade()

where <unknownuser> is similar to an actual user folder, but different. Regardless, the mentioned egg or py file can't be found anywhere as near I can tell.

If I restore the original trac folder (copied before upgrade), everything is happy again, but, of course in version 1.2.2.

Did I miss a step somewhere?


Thanks,


-- Bill



Bill Buklis

unread,
Dec 2, 2022, 4:43:09 PM12/2/22
to trac-...@googlegroups.com

I figured it out. It was the script loading tracd that specifically required trac version 1.2.2. I'm not sure why it needs that. Perhaps it doesn't. I updated the version in the script and now it seems to load as expected. I may have a couple more questions as I make sure nothing is missing, but for now it seems OK.

--
You received this message because you are subscribed to the Google Groups "Trac Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to trac-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/74bd5d94-5af9-ad5f-3aaf-0ee684ba4f35%40pbjzone.com.

RjOllos

unread,
Dec 5, 2022, 2:02:23 PM12/5/22
to Trac Users
Was the server still running? It appears the code may have loaded to memory.

RjOllos

unread,
Dec 5, 2022, 2:03:00 PM12/5/22
to Trac Users
On Friday, December 2, 2022 at 4:43:09 PM UTC-5 Bill Buklis wrote:

I figured it out. It was the script loading tracd that specifically required trac version 1.2.2. I'm not sure why it needs that. Perhaps it doesn't. I updated the version in the script and now it seems to load as expected. I may have a couple more questions as I make sure nothing is missing, but for now it seems OK.


What is the name and contents of the script loading tracd? Something you or the previous admin wrote?

Missing this step is often the cause of trouble:

 

OSP Hathaway

unread,
Dec 15, 2022, 3:17:27 PM12/15/22
to trac-...@googlegroups.com
I have not tried installing Trac on Windows.  I use Trac on Linux RHEL7 - but turn SELinux policy to disabled. Instead of using "tracd" we use Apache httpd. It has been years since we upgraded to version 1.4. You might get some insights reviewing the Trac Upgrade page:


About your screen footer: Some of the older web pages are not overwritten - therefore you probably see powered by 1.2.2.  I am in the process of prototyping an install of 1.5.x on RHEL9 // bypassing RHEL8.
Good Luck!
Steven J. Hathaway

Ard Vilken

unread,
Dec 26, 2022, 7:17:59 AM12/26/22
to Trac Users
Yesterday, I did an update and the problem fixed itself in Fedora 37.  Just to be sure, I did a complete upgrade from Fedora 36 and it went cleanly.  So. some package under DNF was updated and problem solved.
Reply all
Reply to author
Forward
0 new messages