[Trac] Re: Trac + fcgi = [Errno 22] Invalid argument
Thanks for the link. I was a bit unclear; I did follow the link to set it up and the link I provided was purely for generating the .cgi, .fcgi and .wsgi-files. Is there a way to check the python-version of fcgi? I installed it through IPKG. I suppose I could compile fcgi, but I rather avoid that hassle as I'm not to confident in this stuff. Cheers, On Wednesday, March 19, 2014 1:38:11 AM UTC+1, RjOllos wrote: On Friday, March 14, 2014 3:29:43 PM UTC-7, Oscar Edvardsson wrote: Hi all, I recently decided to try to switch from tracd to an apache-powered fast-cgi solution to try to get https-support. I started with an attempt at wsgi but left when I ran into a problem that I think was related to a Python-version mis-match between wsgi and Trac. My setup is a Synology NAS (basically unix). I created a new project at /trac/, which I can successfully host with tracd. I generated the steps to create the necessary .cgi, .fcgi and .wsgi-files as described herehttp://www.google.com/url?q=http%3A%2F%2Ftrac.edgewall.org%2Fwiki%2FTracCgisa=Dsntz=1usg=AFQjCNFhOtmkdH5ziH4L-UbFEX4QmSphlw . I'm not sure what is going wrong with your configuration, but this should be a better documentation reference at least: http://trac.edgewall.org/wiki/TracFastCgi#SimpleApacheconfiguration -- 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 post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Re: TracTicketTemplatePlugIn
On Tuesday, March 18, 2014 8:58:27 PM UTC-5, RjOllos wrote:
On Monday, March 17, 2014 2:10:22 PM UTC-7, ONeal Freeman wrote:
On Monday, March 17, 2014 2:34:23 PM UTC-5, hasienda wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 17.03.2014 17:06, ONeal Freeman wrote:
I did take Trac live today on my server and trying to work through the
bugs as they appear. We depend on it so heavily.
Dependency can push things - good, unless you start to act too hastily.
If you recall I have a test machine I work on before making changes to
the actual server. I have a couple of issues on my server instance
that
are not present on my test machine. One is that my tickets on the
server
show last modified 44 years ago where the test machine shows 8 weeks.
You're looking at time column content, that has not been upgrades from
POSIX seconds to microseconds correctly. This could quite easily fixed
manually, if needed, but I fear there could be more than that.
I.e. Trac 1.x totally changed the attachment file storage organization.
Did you check, that you can still open/view your old attachments?
Also in the tickets from trac 0.10.4 we used the {{{ }}} around emails
pasted into the comments. In trac 1.0.1 those same {{{ }}} in the
comments are showing up. Again, they look fine on the test machine but
not the server.
{{{ }}} is still a special character constellation. If it does not work,
there is a) something broken regarding WikiFormatting or b) content
malformed, similar to what you reported for the description ticket field
before.
I have spent a lot of the morning comparing the plugins and the
trac.ini
between the test machine and server to make sure it is entirely
duplicated but I am obviously missing something.
Well, it might be worth following Ryan's advice, if it is possible for
you to roll-over to that alternative import db.
Steffen Hoffmann
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iEYEARECAAYFAlMnTjwACgkQ31DJeiZFuHeyxwCfY8Im+sl3LS+B0IdTaQ+rg6ii
qMoAoOgNOj+upt/PUGsecSqVJy+gvcHq
=snVr
-END PGP SIGNATURE-
I fixed the special characters {{{ }}} being displayed by upgrading
Docutils.
The loss of the time and timechange in the db is the biggest issue. I
depend on those fields to display ticket closed in last 30-, 60- and
90-days.
I have even entertained the thought of trying to install the original
version (0.10.4) on windows that way at least I would have my data.
Regarding the templates, it seems that all you need to do is delete the
layout.html in your environment's templates directory.
Customizations should go in site.html, or files included from site.html,
as you've done with ComplianceWarning.html. You almost certainly will never
need to do anything with layout.html.
Let us know if you have any other issues. Hopefully all the issues are
fixed now, possibly with the exception of some reports that need to be
rewritten to account for the change in timestamp format.
I will delete the layout.html from my environment.
I appreciate all of the help you and Steffen provided. You have taught me
so much and I appreciate it. I put trac online yesterday and it seems to be
functioning fine. I know it will need some tweaking as we get into it but
that's okay.
I will admit that I am struggling with the queries trying to get tickets
close during a period like the last 30-days. I am quite confused as to why
the developers would chose to use seconds and milliseconds but who am I...
Thanks again for all that you did.
Regards,
O'Neal
--
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 post to this group, send email to trac-users@googlegroups.com.
Visit this group at http://groups.google.com/group/trac-users.
For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Re: TracTicketTemplatePlugIn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.03.2014 14:54, ONeal Freeman wrote: I will admit that I am struggling with the queries trying to get tickets close during a period like the last 30-days. I am quite confused as to why the developers would chose to use seconds and milliseconds but who am I... As you've not been involved into related issues and development, this is a valid question. In short, we've got reports of issues with timestamps when doing automated changes within some milliseconds while the time resolution has been only seconds. I.e. it was no longer guaranteed, that composite keys in ticket_change db table consisting of timestamp + ticket ID were unique for each change. Accounting for future improvements of IT equipment and making a step into safe water it was consequent to boost time resolution by a factor of 6 - up to microseconds, you see? You'll make your way with adapting queries to that time stamps too. For issues browse the mailing list first, and ask detailed questions, if required. Steffen Hoffmann -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlMp4GUACgkQ31DJeiZFuHcMOACcDAL6Odew9K/u5OA0c3E46e9r gsIAn3NBN5rADFIUsVvasPV3/Kam30qu =vkrY -END PGP SIGNATURE- -- 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 post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Reporter/Owners who have left
Sorry to open up such an old can of worms, but given that this discussion addresses the issue we're having, it seems like the right place to start. Running Trac 1.0, installed 13 months ago. HTTP server version: Apache/2.4.3 (Unix) /usr/lib/python2.7/ /usr/libexec/mysqld Ver 5.5.27-log for Linux on i686 (MySQL Community Server (GPL)) On Wednesday, January 12, 2011 11:13:50 PM UTC-8, Cooke, Mark wrote: From: Matthew Caron matt@sixnet.com Date: 01/11/2011 01:26 PM Subject: Re: [Trac] Reporter/Owners who have left On 01/11/2011 01:23 PM, Marjory L. Mackes wrote: I have a person who left the project and they were originally a reporter on several tickets that are still open. I have taken them out from the permissions and removed them from the Password file, but when the tickets are updated they are still getting notified. We reparent them, changing the reporter to someone else (typically their manager). [snipped discussion of using bulk change, irrelevant to our issue --rma] I may be barking up the wrong tree but where is trac getting the email address from? If it is from the user's session data (you are not deriving from the username or using LDAP for example) then you could just remove the user's email from their session record. That should stop them getting the emails. We have a single Trac ticket, recently (re)assigned to a new employee, which was originally owned by someone no longer with the company. The reporter on the ticket is the engineering manager (never changed), the owner is the newbie, and there is a CC to yet another person otherwise not involved. (I'm the Trac administrator.) Updates to the ticket are still being mailed to the original owner (bouncing since he is no longer here). One oddity is that his forwarding entry in /etc/mail/aliases was removed the day he left, so there should not be any way for the mail to leave the system on which Trac is running (company mail is handled by Exchange/Outlook, user authentication is AD). I can't see any trace(s) of the original owner anywhere in Trac. I'm not really fond of the idea that I need to run a SQL session to manipulate the Trac database directly, for obvious reasons. Suggestions on what is going on here? Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 http://www.LivingComputerMuseum.org/ -- 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 post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Reporter/Owners who have left
On 03/19/2014 02:57 PM, Rich Alderson wrote: Updates to the ticket are still being mailed to the original owner (bouncing since he is no longer here). One oddity is that his forwarding entry in /etc/mail/aliases was removed the day he left, so there should not be any way for the mail to leave the system on which Trac is running (company mail is handled by Exchange/Outlook, user authentication is AD). If his email address is explicitly set to user@domain, then it is going to look up the MX record for @domain, and will not use the local alias, since there is no alias for user@domain (and there likely was only one for user to begin with). You can always look at the local mail log file, and update the ticket. My guess is that you'll see 3 pieces of mail go out - one to you, one to the ticket owner, one to the original reporter. I can't see any trace(s) of the original owner anywhere in Trac. I'm not really fond of the idea that I need to run a SQL session to manipulate the Trac database directly, for obvious reasons. Please elucidate what reasons you feel are obvious. I would think that a simple: select * from session_attribute where name = 'email' and sid = 'user'; would be pretty harmless. -- Matthew Caron, Software Build Engineer Red Lion Controls | www.redlion.net +1 (518) 877-5173 x138 office -- 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 post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
[Trac] Re: Trac + fcgi = [Errno 22] Invalid argument
On Wednesday, March 19, 2014 12:09:33 AM UTC-7, Oscar Edvardsson wrote: Thanks for the link. I was a bit unclear; I did follow the link to set it up and the link I provided was purely for generating the .cgi, .fcgi and .wsgi-files. Is there a way to check the python-version of fcgi? I installed it through IPKG. I suppose I could compile fcgi, but I rather avoid that hassle as I'm not to confident in this stuff. I'm not sure about verifying the dependencies. Usually Python version is part of the egg filename though. It might be worthwhile to try and get this running in a VM on your desktop and then move the configuration onto your NAS after you've verified the configuration is functioning correctly. -- 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 post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Reporter/Owners who have left
On Wednesday, March 19, 2014 12:22:00 PM UTC-7, Matthew Caron wrote: On 03/19/2014 02:57 PM, Rich Alderson wrote: Updates to the ticket are still being mailed to the original owner (bouncing since he is no longer here). One oddity is that his forwarding entry in /etc/mail/aliases was removed the day he left, so there should not be any way for the mail to leave the system on which Trac is running (company mail is handled by Exchange/Outlook, user authentication is AD). If his email address is explicitly set to user@domain, then it is going to look up the MX record for @domain, and will not use the local alias, since there is no alias for user@domain (and there likely was only one for user to begin with). You can always look at the local mail log file, and update the ticket. My guess is that you'll see 3 pieces of mail go out - one to you, one to the ticket owner, one to the original reporter. I can't see any trace(s) of the original owner anywhere in Trac. I'm not really fond of the idea that I need to run a SQL session to manipulate the Trac database directly, for obvious reasons. Please elucidate what reasons you feel are obvious. I would think that a simple: select * from session_attribute where name = 'email' and sid = 'user'; would be pretty harmless. If you're looking for a web interface to the session data, I believe that AccountManagerPlugin will delete the session data when a user is deleted. -- 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 post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
Re: [Trac] Reporter/Owners who have left
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19.03.2014 21:25, RjOllos wrote: If you're looking for a web interface to the session data, I believe that AccountManagerPlugin will delete the session data when a user is deleted. Yes, at least recent versions do that reliably. A special case are valid email addresses as usernames, what might still drive notification from existing reporter/commenter entries. Steffen Hoffman -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iEYEARECAAYFAlMqA0UACgkQ31DJeiZFuHfqKwCcCPzMrKouFF29eG1wDymo2ANc qQoAn1NpNWWktHWZ/GQK5yYlayAvu15d =XqPP -END PGP SIGNATURE- -- 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 post to this group, send email to trac-users@googlegroups.com. Visit this group at http://groups.google.com/group/trac-users. For more options, visit https://groups.google.com/d/optout.
