Re: [rt-users] Debian package status / Full text indexing failure (invalid byte sequence for encoding UTF8)
* Dominic Hargreaves dominic.hargrea...@it.ox.ac.uk [20130202 08:13]: On Fri, Feb 01, 2013 at 08:36:22PM -0500, Alex Vandiver wrote: On Fri, 2013-02-01 at 17:03 -0800, Ben Poliakoff wrote: We're currently running RT 4.0.5-3~bpo60+1 (from Debian backports) with Postgresql 8.4.12-0squeeze1. This is fixed in RT 4.0.9 and above, wich resolve this issue by skipping the attachment with bad data. RT 4.0.7 and above are better about not trusting emails which claim to be utf-8, which prevents the bad data from getting in in the first place, which is the likely cause here, and which older Pg allowed. The good news is that Debian backports now has 4.0.7 (I've just uploaded 4.0.7-4~bpo60+1 which has a few extra fixes compared to 4.0.7-2~bpo60+1). The bad news is that since Debian is in freeze, 4.0.9 or above won't be hitting Debian any time soon (except possibly experimental, if someone asks nicely :) However, I do encourage people who are using the Debian packages to report bugs that affect them to the BTS even if they are fixed in newer upstream releases; if they seem serious enough, it's still possible to fix important bugs in Debian before the release. Thanks for the replies Alex and Dominic. I'll plan on updating to 4.07-4 soon, looking forward to 4.0.9! Ben -- pub 4096R/318B6A97 2009-05-11 Ben Poliakoff b...@reed.edu Primary key fingerprint: 3F23 EBC8 B73E 92B7 0A67 705A 8219 DCF0 318B 6A97 signature.asc Description: Digital signature
[rt-users] Full text indexing failure (invalid byte sequence for encoding UTF8)
We're currently running RT 4.0.5-3~bpo60+1 (from Debian backports) with Postgresql 8.4.12-0squeeze1. Recently I tried to enable full text search following the instructions here: http://blog.bestpractical.com/2011/06/full-text-searching.html ...but ran into this error an hour into the initial rt-fulltext-indexer --all: [crit]: error: ERROR: invalid byte sequence for encoding UTF8: 0xfc HINT: This error can also happen if the byte sequence does not match the encoding expected by the server, which is controlled by client_encoding. at /usr/sbin/rt-fulltext-indexer-4 line 375. (/usr/share/request-tracker4/lib/RT.pm:351) Subsequent runs of the same command end with the same error. The encoding for the rt4 db has been set to utf8 for as long as I can recall. I assume this relates to some data inserted into the db ages ago when client_encoding was something other than utf8, or in a previous version of postgresql which might have been less stringent about input. There is a FAQ about 'invalid byte sequence for encoding' but I'm not sure that this is the same issue. Anyone else been through this sort of issue? Would it be better to take the question to a postgresql list? Ben -- pub 4096R/318B6A97 2009-05-11 Ben Poliakoff b...@reed.edu Primary key fingerprint: 3F23 EBC8 B73E 92B7 0A67 705A 8219 DCF0 318B 6A97 signature.asc Description: Digital signature
[rt-users] wiki update request: QuickResolveandQuickReject (for rt4)
Hi All, We had a flawless upgrade from 3.8.8 to 4.0.1 this week (thanks to BestPractial and the Debian package maintainers). Some of our users have requested the QuickResolveandQuickReject addition: http://requesttracker.wikia.com/wiki/QuickResolveandQuickReject Has anyone sorted out what needs to change to make this work with rt4? Ben -- PGP (318B6A97): 3F23 EBC8 B73E 92B7 0A67 705A 8219 DCF0 318B 6A97 signature.asc Description: Digital signature 2011 Training: http://bestpractical.com/services/training.html
Re: [rt-users] wiki update request: QuickResolveandQuickReject (for rt4)
* Kevin Falcone falc...@bestpractical.com [20110805 11:47]:
On Fri, Aug 05, 2011 at 11:33:12AM -0700, Ben Poliakoff wrote:
Hi All,
We had a flawless upgrade from 3.8.8 to 4.0.1 this week (thanks to
BestPractial and the Debian package maintainers).
Some of our users have requested the QuickResolveandQuickReject
addition:
http://requesttracker.wikia.com/wiki/QuickResolveandQuickReject
Has anyone sorted out what needs to change to make this work with rt4?
You can do both of those with the included Lifecycles functionality.
Read about it in RT_Config.pm and copy your lifecycles over to
RT_SiteConfig.pm to add the new transitions
Hmm. I've read about it, and I've copied over the default %Lifecycles
into RT_SiteConfig.pm, adding this action to default:
'open - resolved' = { label = 'Quick Resolve' },
...right below the default Resolve action, and restarted apache (using
mod_perl), but I don't see a new Quick Resolve item in the action menu
in the web ui.
Obviously I'm missing something.
Ben
--
PGP (318B6A97): 3F23 EBC8 B73E 92B7 0A67 705A 8219 DCF0 318B 6A97
signature.asc
Description: Digital signature
2011 Training: http://bestpractical.com/services/training.html
Re: [rt-users] wiki update request: QuickResolveandQuickReject (for rt4)
* Kevin Falcone falc...@bestpractical.com [20110805 12:41]:
On Fri, Aug 05, 2011 at 12:30:49PM -0700, Ben Poliakoff wrote:
* Kevin Falcone falc...@bestpractical.com [20110805 11:47]:
On Fri, Aug 05, 2011 at 11:33:12AM -0700, Ben Poliakoff wrote:
Hi All,
We had a flawless upgrade from 3.8.8 to 4.0.1 this week (thanks to
BestPractial and the Debian package maintainers).
Some of our users have requested the QuickResolveandQuickReject
addition:
http://requesttracker.wikia.com/wiki/QuickResolveandQuickReject
Has anyone sorted out what needs to change to make this work with rt4?
You can do both of those with the included Lifecycles functionality.
Read about it in RT_Config.pm and copy your lifecycles over to
RT_SiteConfig.pm to add the new transitions
Hmm. I've read about it, and I've copied over the default %Lifecycles
into RT_SiteConfig.pm, adding this action to default:
'open - resolved' = { label = 'Quick Resolve' },
...right below the default Resolve action, and restarted apache (using
mod_perl), but I don't see a new Quick Resolve item in the action menu
in the web ui.
Obviously I'm missing something.
Is the ticket you're testing new or open?
I appreciate your spotting what should have been obvious to me: the
ticket status was new, so consequently the Quick Resolve action wasn't
in the menu. Once the status was set to open Quick Resolve was
available and worked as it should. I'll update the wiki page to reflect
this.
Thanks much for your help,
Ben
--
PGP (318B6A97): 3F23 EBC8 B73E 92B7 0A67 705A 8219 DCF0 318B 6A97
signature.asc
Description: Digital signature
2011 Training: http://bestpractical.com/services/training.html
