…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?
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.
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.
Dominic Hargreaves, Systems Development and Support Section
IT Services, University of Oxford
Dominic Hargreaves dominic.hargreaves@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!
But what I am missing is the possibility to have multiple instances (prod/test)
and multiple versions, e.g. I am now very much interested in 4.0.10 but of course if first want to test it.
Is there perhaps an unofficial 4.0.10 dep repository somewhere ?
Is it complicated to build a new deb if there is a new upstream version ?
About the multiple version and instances, the Open Monitoring Distribution http://omdistro.org/ solved this very nice for nagios and friends,
i wish something like that would exist for rt as well.
I am planning to upload 4.0.10 to experimental in the next week or
so. As for multiple concurrent versions, this isn’t something the
Debian packages are suited to. If you have a need for multiple concurrent
versions, you will need to look at other options. On other hand,
as long as you aren’t using mod_perl in the same apache instance, you
can quite happily run multiple instances of the same version;
just make sure the configurations point to different databases
and cache locations.On Thu, Mar 21, 2013 at 01:32:56PM +0100, linux@muellers.ms wrote:
Hello Dominic,
Thanks a lot for your work!
I am running 4.0.7-4 fine on Debian 7.0 wheezy.
But what I am missing is the possibility to have multiple instances (prod/test)
and multiple versions, e.g. I am now very much interested in 4.0.10 but of course if first want to test it.
Is there perhaps an unofficial 4.0.10 dep repository somewhere ?
Is it complicated to build a new deb if there is a new upstream version ?
About the multiple version and instances, the Open Monitoring Distribution http://omdistro.org/ solved this very nice for nagios and friends,
i wish something like that would exist for rt as well.
jo
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.
Dominic Hargreaves, Systems Development and Support Section
IT Services, University of Oxford
As for multiple concurrent versions, this isn’t something the
Debian packages are suited to.
Agreed; it can work, but it’s a pain. You can see this in the PostgreSQL
packages for example - they handle concurrent versions reasonably well
via the alternatives system and versioned config and data directories,
but it does cause some confusion for users and admins. In the case of
PostgreSQL it’s absolutely necessary to enable low-pain upgrades so it’s
worth the price in complexity, but this probably isn’t true for RT.
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
As for multiple concurrent versions, this isn’t something the
Debian packages are suited to.
Agreed; it can work, but it’s a pain. You can see this in the PostgreSQL
packages for example - they handle concurrent versions reasonably well
via the alternatives system and versioned config and data directories,
but it does cause some confusion for users and admins. In the case of
PostgreSQL it’s absolutely necessary to enable low-pain upgrades so it’s
worth the price in complexity, but this probably isn’t true for RT.
Yes, between major releases, but that doesn’t let run any arbitrary
combinations of versions. We’re doing much the same in Debian,
(request-tracker3.6, request-tracker3.8, request-tracker4) which I
should have mentioned, although I think we’re hoping that the 4.x
series will be maintained all in one package namespace to make things
easier for users.
Cheers,
Dominic.
Dominic Hargreaves, Systems Development and Support Section
IT Services, University of Oxford
Yes, between major releases, but that doesn’t let run any arbitrary
combinations of versions.
Ah, good point. I misunderstood. Yes, the only good way to allow
arbitrary combinations of versions is with a second install in a VM.
Since that handily prevents all sorts of other nasty problems with
combining test and live systems that’s the approach I favour anyway.
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
I am planning to upload 4.0.10 to experimental in the next week or
so. As for multiple concurrent versions, this isn’t something the
Debian packages are suited to. If you have a need for multiple concurrent
versions, you will need to look at other options. On other hand,
as long as you aren’t using mod_perl in the same apache instance, you
can quite happily run multiple instances of the same version;
just make sure the configurations point to different databases
and cache locations.
4.0.10 packages have been uploaded to Debian, but because they include
a new binary package (for the HTML documentation - BPS, thanks for the
handy devel script for generating this!) is sitting in a queue for
manual processing.
If you’re impatient and happy with building your own package, have a look
at the debian/4.0.10-1 tag in the repository at
4.0.10 packages have been uploaded to Debian, but because they include
a new binary package (for the HTML documentation - BPS, thanks for the
handy devel script for generating this!) is sitting in a queue for
manual processing.
A side note: the HTML doc is customized for being displayed as part of a
larger HTML context (http://docs.bestpractical.com), so it’s just HTML
fragments and no styling. It’s somewhat readable on it’s own though.
