Re: [Trac] Re: Help: trac.* components appear as individual plugins on admin page
On Tuesday, November 19, 2019 at 10:44:15 AM UTC-6, RjOllos wrote: > > > I tend to push users towards creating a virtualenv and pip install'ing all > of their packages, so as to have more control and not depend on the OS > package maintainer in addition to the plugin maintainer. > > However, some users do like having the packages maintained by a Debian > package maintainer, so I'll be interested to hear what others have to say. > > - Ryan > I generally agree with the suggestion of using virtualenv, and that's what we use for build environments. In this case we are trying to create a lightweight Docker container, so it would be nice if the Debian package just worked. For the most part, they do. Only on the Plugin Admin page is there a "glitch". I've diff'd the Debian and pip-install Trac==1.2.3 packages and have identified a few differences: - Debian installs symlinks to jquery content because it is installed by a separate package. The pip-install package has them embedded. - jquery versions are different. Debian: 3.3.1, pip-install: 1.11.3 - jquery-ui versions are different. Debian: 1.12.1, pip-install: 1.11.4 - jquery time picker versions are also different. - Several png files are different, and several of the jquery-ui/images files are missing on Debian. - jquery-ui-addons.css is different. I don't know if jquery is responsible for "unorganized content" on the Plugin page. Regarding "apt-get install python-pip" I can reduce its overhead by adding "--no-install-recommends", which eliminates the dev tools that aren't needed to (re)install Trac. The relevant part of my Dockerfile is now: RUN apt-get update; apt-get install -y \ apache2 \ libapache2-mod-wsgi \ libapache2-mod-svn \ subversion \ python \ python-requests \ trac \ rsync \ ; \ *apt**-get install -y --no-install-recommends python-**pip* ; \ rm -rf /var/lib/apt/lists/* ; \ *pip install --ignore-installed --no-deps --no-cache-dir Trac==1.2.3* I still install trac via apt-get because it brings in several other required and recommended dependencies, some of which require compiling. It's only the trac and tracopt python packages that need to be "refreshed". The root cause of the problem still eludes me. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/f12549df-8afc-4838-9258-fea0cef94c2f%40googlegroups.com.
Re: [Trac] Vanilla Trac Slow
On Tue, Nov 19, 2019 at 12:17 PM Gabriel Alves wrote: > Hello guys. > > From a few weeks ago to now days, I'm doing some tests with Trac(from > 0.12x to trunk) and I see it can't handle multiple requests. Is that true > or I'm doing something very wrong? > > I have some environments using apache and others using standalone. In both > cases, I faced the same results. > > I have logged only one method(_process_ticket_request) and methods inside > it(pictures are filtered). Look some pictures and I'll explain it: > > [image: 3.PNG] > > (state, id, local_hour, method, timestamp) > > > When the server is ready, the first few requests(open some tickets in this > example) are handled all at the same time after a long delay(something > about 5~20 seconds). > > After that, requests take somehow uniform time: > > [image: 2.PNG] > > (state, id, local_hour, method, timestamp) > > How I said, trac vanilla (without plugins). > > I'm alredy done some tests using Locust to open some aleatory tickets and > the results are very bad(simulation with 50 persons, 5 per second): > > [image: rps.png] > > [image: rt.png] > > I can do something about 2,5 requests per second. (I'm sure apache cand do > much more and I guess standalone can do it too) > > Conditions: > Trac 1.0.17~19 > Windows 10 > Standalone/Apache 2.4 with mod_wsgi > You may want to use PostgreSQL or MySQL, rather than SQLite: https://trac.edgewall.org/wiki/TracPerformance#Database Trac 1.4 with Jinja2 should give the best performance. I don't have experience with Apache on Windows, but I've read there can be performance problems. https://groups.google.com/d/msg/trac-users/EmesGAcdtrE/kTSdh1N9BAAJ Concurrent request performance is pretty good on Linux with Apache and PostgreSQL or MySQL, in my experience. - Ryan -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/CA%2BBGpn8dgMMwfRqxqnFWTshOOd6BiThFj9LXLfTF5tUq8LVpVQ%40mail.gmail.com.
[Trac] Vanilla Trac Slow
Hello guys. >From a few weeks ago to now days, I'm doing some tests with Trac(from 0.12x to trunk) and I see it can't handle multiple requests. Is that true or I'm doing something very wrong? I have some environments using apache and others using standalone. In both cases, I faced the same results. I have logged only one method(_process_ticket_request) and methods inside it(pictures are filtered). Look some pictures and I'll explain it: [image: 3.PNG] (state, id, local_hour, method, timestamp) When the server is ready, the first few requests(open some tickets in this example) are handled all at the same time after a long delay(something about 5~20 seconds). After that, requests take somehow uniform time: [image: 2.PNG] (state, id, local_hour, method, timestamp) How I said, trac vanilla (without plugins). I'm alredy done some tests using Locust to open some aleatory tickets and the results are very bad(simulation with 50 persons, 5 per second): [image: rps.png] [image: rt.png] I can do something about 2,5 requests per second. (I'm sure apache cand do much more and I guess standalone can do it too) Conditions: Trac 1.0.17~19 Windows 10 Standalone/Apache 2.4 with mod_wsgi -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/161997cf-6da0-4d8f-9fae-8272a81e16d1%40googlegroups.com.
Re: [Trac] Re: Help: trac.* components appear as individual plugins on admin page
On Tuesday, November 19, 2019 at 1:16:46 AM UTC-8, hasienda wrote: > > Just to throw in a thought: > > Would providing Trac DEB-packages be useful? > I've been a couple of times before near doing some serious Debian > developer work but never did the final step. > > Recently I've moved to a rather powerful private cluster computing > structure, that would benefit from useful tasks like building packages. > So how do your, Ryan, and others feel about a repository, that could > provide more recent Trac and even development versions via apt rather then > pip & Co.? > > Steffen > > Mit freundlichem Gruß > > Steffen Hoffmann Hi Steffen, Good to hear from you. I tend to push users towards creating a virtualenv and pip install'ing all of their packages, so as to have more control and not depend on the OS package maintainer in addition to the plugin maintainer. However, some users do like having the packages maintained by a Debian package maintainer, so I'll be interested to hear what others have to say. - Ryan -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/0fc182c2-1a03-4da2-9cff-0ec41ac8a88b%40googlegroups.com.
Re: [Trac] Migration from 1.2.3 to 1.4
Am Dienstag, 19. November 2019 17:27:09 UTC+1 schrieb Mo: > > > But the https://github.com/trac-hacks/trac-NewTicketLikeThisPlugin has a > better documentation about it. > -> https://github.com/trac-hacks/trac-NewTicketLikeThisPlugin/issues/1 -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/104ebb7f-3053-4e7b-a20d-2974ff0b8df0%40googlegroups.com.
Re: [Trac] Migration from 1.2.3 to 1.4
Am Dienstag, 19. November 2019 17:14:46 UTC+1 schrieb RjOllos: > > > What features does the NewTicketLikeThisPlugin provide that aren't > available in Trac 1.4? > Good question. I hoped I can configure which fields to clone and which not. And to configure a template for adding the #parent_ticket id somewhere, preferably to "Parent ticket" field from SubTicketsPlugin, making the cloned ticket a child. But even the DerivedFieldsTicketCloner that I used is not documented in the wiki at all. But the https://github.com/trac-hacks/trac-NewTicketLikeThisPlugin has a better documentation about it. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/b5190d47-1dd1-4a90-8278-3a6d65367801%40googlegroups.com.
Re: [Trac] Git repository not receiving changes after migration to Trac-1.4
On Tuesday, November 19, 2019 at 6:17:32 AM UTC-8, Mo wrote: > > Am Montag, 18. November 2019 15:47:27 UTC+1 schrieb Jun Omae: >> >> >> I guess that explicit synchronization via post-receive hook in your >> Git repository doesn't work. >> Please try to execute `trac-admin $ENV repository sync mt6` and make >> sure your hook scripts work well. >> > > Now the changes are there. > Did something change here from Trac-1.2.3 to 1.4? I did not need the > explicit repository sync before. > > I have > [git] > cached_repository = enabled > persistent_cache = enabled > > The process looks like this: A 5-minutly cronjob calls a script doing '*git > p4 sync*' into a repo that was initially created like '*git p4 clone > --bare //DEPOT@all*'. > Then the script parses the last changes and calls '*trac-admin $ENV > changeset added $repo $revision*' for every revision in order to make > Trac check the changes for mentioned ticket numbers adding a comment about > the submission to every ticket. > That was working like this with Trac-1.2.3. > Do I need to call '*repository sync*' now additionally? > > Best regards, > - Mo > Nothing has changed, you still just need to call "changeset added". Sync is used to "catch up" when the Trac is not yet sync'ed. Possibly there is something wrong with your Cron script. I would check logged info for that script, or try to run it manually and inspect the output. Based on previous things you've described, you may need to use the full path to trac-admin, as it sounds like python2.7 is not the default on your server. - Ryan -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/a21403e3-ab6f-4599-b01d-4cb0cf9e7745%40googlegroups.com.
Re: [Trac] Migration from 1.2.3 to 1.4
On Tuesday, November 19, 2019 at 8:00:45 AM UTC-8, Mo wrote: > > Am Dienstag, 19. November 2019 15:58:07 UTC+1 schrieb RjOllos: >> >> >> Please make sure the plugin is enabled in trac.ini for through the >> General > Plugin webadmin page. >> > > I got to the root of the issue and found some old residuals: I was using > trac_NewTicketLikeThisPlugin-0.2-py2.7.egg with > > [newticketlikethis] > derived_fields = $ticket.summary (cloned)->summary > > > excluded_fields = reporter > ticket_clone_permission = TICKET_CREATE > ticket_cloner = DerivedFieldsTicketCloner > > Reading that the used DerivedFieldsTicketCloner is based on Genshi I > disabled that plugin and re-enabled tracopt.ticket.clone.ticketclonebutton. > Some time before I tried to have some custom cloning the adds the cloned > ticket number somewhere in the clone. Now I see the default already adds > some "Cloned from #..." to the description. > At least a basic clone is possible now. Is NewTicketLikeThisPlugin > maintained for > You'd have to ask the plugin maintainer whether it will be maintained for Trac 1.4+. What features does the NewTicketLikeThisPlugin provide that aren't available in Trac 1.4? -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/0cfba721-189b-4774-b505-b13dba362fad%40googlegroups.com.
Re: [Trac] Migration from 1.2.3 to 1.4
Am Dienstag, 19. November 2019 15:58:07 UTC+1 schrieb RjOllos: > > > Please make sure the plugin is enabled in trac.ini for through the > General > Plugin webadmin page. > I got to the root of the issue and found some old residuals: I was using trac_NewTicketLikeThisPlugin-0.2-py2.7.egg with [newticketlikethis] derived_fields = $ticket.summary (cloned)->summary excluded_fields = reporter ticket_clone_permission = TICKET_CREATE ticket_cloner = DerivedFieldsTicketCloner Reading that the used DerivedFieldsTicketCloner is based on Genshi I disabled that plugin and re-enabled tracopt.ticket.clone.ticketclonebutton. Some time before I tried to have some custom cloning the adds the cloned ticket number somewhere in the clone. Now I see the default already adds some "Cloned from #..." to the description. At least a basic clone is possible now. Is NewTicketLikeThisPlugin maintained for -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/0a032ea8-536c-4e4f-a66a-e1ee7ea83241%40googlegroups.com.
Re: [Trac] Migration from 1.2.3 to 1.4
On Tue, Nov 19, 2019 at 5:33 AM Mo wrote: > Am Montag, 18. November 2019 16:42:41 UTC+1 schrieb RjOllos: > >> >> Ticket clone is an optional component. Please make sure it is enabled and >> loading: >> DEBUG: Loading plugin "tracopt.ticket.clone" >> > > 2019-11-19 14:25:49,510 Trac[loader] DEBUG: Loading plugin > "tracopt.ticket.clone" from > "/mnt/data/trac/.local/lib64/python2.7/site-packages" > Please make sure the plugin is enabled in trac.ini for through the General > Plugin webadmin page. - Ryan -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/CA%2BBGpn_Pez2gFg_Bn89z_hLM-yqDxR36_o%2B81REC%2B0Zzoqb%3D1g%40mail.gmail.com.
Re: [Trac] Git repository not receiving changes after migration to Trac-1.4
Am Montag, 18. November 2019 15:47:27 UTC+1 schrieb Jun Omae: > > > I guess that explicit synchronization via post-receive hook in your > Git repository doesn't work. > Please try to execute `trac-admin $ENV repository sync mt6` and make > sure your hook scripts work well. > Now the changes are there. Did something change here from Trac-1.2.3 to 1.4? I did not need the explicit repository sync before. I have [git] cached_repository = enabled persistent_cache = enabled The process looks like this: A 5-minutly cronjob calls a script doing '*git p4 sync*' into a repo that was initially created like '*git p4 clone --bare //DEPOT@all*'. Then the script parses the last changes and calls '*trac-admin $ENV changeset added $repo $revision*' for every revision in order to make Trac check the changes for mentioned ticket numbers adding a comment about the submission to every ticket. That was working like this with Trac-1.2.3. Do I need to call '*repository sync*' now additionally? Best regards, - Mo -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/4afd3b7d-4489-4497-b124-415d01dceff7%40googlegroups.com.
[Trac] Future of TracTicketFieldsLayoutPlugin
Hello everybody, the Trac-1.4 and Jinja2 migration has so many drawbacks, here is the next: We have been using TracTicketFieldsLayoutPlugin for arranging a lot of custom fields, creating groups and collapsing some groups by default. Sorting the fields by .order = is not that comfortable. Hiding or collapsing single fields is not possible anymore. I understand the note on the wiki page, that there will be no port to Jinja2 or Javascript. Isn't there any change to get something similar? This is a substantial loss. Best regards, Mo -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/0d16cf61-44b1-4493-9bdb-fe1cdc7904c8%40googlegroups.com.
Re: [Trac] Migration from 1.2.3 to 1.4
Am Montag, 18. November 2019 16:42:41 UTC+1 schrieb RjOllos: > > Ticket clone is an optional component. Please make sure it is enabled and > loading: > DEBUG: Loading plugin "tracopt.ticket.clone" > 2019-11-19 14:25:49,510 Trac[loader] DEBUG: Loading plugin "tracopt.ticket.clone" from "/mnt/data/trac/.local/lib64/python2.7/site-packages" Second, please check the browser console for errors, and check the page > source to determine if '/chrome/ticketopt/ticketclone.js' is added to the > page. > The page source does not have any "ticketclone" string. Web developer -> Web console, I can't see any errors when reloading the ticket page. In the debugger I see some .js files but no ticketclone.js. - Mo -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/bac48fea-b9f7-445c-b57b-c8071fb24443%40googlegroups.com.
Re: [Trac] Re: Help: trac.* components appear as individual plugins on admin page
Am 19. November 2019 00:09:25 MEZ schrieb thos : >Ryan, > >I am a long-time Trac user, but new to this group. I appreciate your >attentiveness. > >We are trying to create lightweight containers for multiple Trac/SVN >instances, and having all of the development binaries pulled in by pip >is >undesirable. We also need control over when we upgrade resources. > >One difference is that apt-get puts the python packages in >/usr/lib/python2.7/dist-packages, while pip puts them in >/usr/local/lib/python2.7/dist-packages. (This is from memory so may be >off >a bit.) Also, the --force-reinstall doesn't actually remove the >system-installed packages. > >I will continue to explore what might be different. Could you point me >to >where in Trac the "Plugin" page is generated? That might give clues as >to >why the grouping is wrong. Of course the problem could be elsewhere >(e.g. >plugin registration) and I'm willing to do a little digging. It's just >odd >that no errors are produced. > >Thanks. > >-Tom > >On Monday, November 18, 2019 at 9:37:50 AM UTC-6, RjOllos wrote: >> >> >> >> On Sunday, November 17, 2019 at 10:24:24 PM UTC-8, thos wrote: >>> >>> I have some additional information to provide. In my Dockerfile: >>> >>> FROM debian:buster-slim >>> >>> ENV SITE_DIR /var/www/repos >>> ENV LANG C.UTF-8 >>> >>> RUN apt-get update; apt-get install -y \ >>> apache2 \ >>> libapache2-mod-wsgi \ >>> libapache2-mod-svn \ >>> subversion \ >>> python \ >>> trac \ >>> rsync \ >>> ; \ >>> rm -rf /var/lib/apt/lists/* >>> >>> There seems to be an issue with the package distribution. If I add >pip to >>> the installed packages and use it to force a reinstall of Trac, then >the >>> problem goes away: >>> >>> RUN apt-get update; apt-get install -y \ >>> apache2 \ >>> libapache2-mod-wsgi \ >>> libapache2-mod-svn \ >>> subversion \ >>> python \ >>> * python**-pip \* >>> trac \ >>> rsync \ >>> ; \ >>> rm -rf /var/lib/apt/lists/* ; \ >>> >>> * pip install --force-reinstall Trac==1.2.3* >>> >>> The problem with this solution is that python-pip carries a lot of >>> baggage with it (compilers, developer libraries, etc.) >>> >>> Perhaps there is a missing dependency in the trac.deb package? >>> >> >> I've seen the behavior during development and reinstall has always >fixed >> the issue, as you've noted. I'm unsure about the cause. >> >> Maybe a diff of the files installed by apt-get vs pip would provide a >clue? >> >> Another advantage of installing with pip is that you can get the >latest >> Trac, 1.2.5 or 1.4.0, rather than relying on the Debian package >managers to >> update the distribution. >> >> - Ryan >> > >-- >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+unsubscr...@googlegroups.com. >To view this discussion on the web visit >https://groups.google.com/d/msgid/trac-users/e702bc84-b634-4459-af0d-94c954ae066d%40googlegroups.com. Just to throw in a thought: Would providing Trac DEB-packages be useful? I've been a couple of times before near doing some serious Debian developer work but never did the final step. Recently I've moved to a rather powerful private cluster computing structure, that would benefit from useful tasks like building packages. So how do your, Ryan, and others feel about a repository, that could provide more recent Trac and even development versions via apt rather then pip & Co.? Steffen Mit freundlichem Gruß Steffen Hoffmann -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/trac-users/003E17EE-5D0A-4772-8206-A96E10190591%40web.de.
