Bug#494547: munin cron job complains about pango invalid utf-8 string

Joey Hess

unread,

Aug 10, 2008, 11:30:33 AM8/10/08

to

Package: munin
Version: 1.2.6-4

Getting this every 5 minutes after upgrading to current unstable.

----- Forwarded message from Cron Daemon <ro...@kitenet.net> -----

From: Cron Daemon <ro...@kitenet.net>
Date: Sun, 10 Aug 2008 10:03:25 -0400 (EDT)
To: ro...@kitenet.net
Subject: Cron <munin@bluebird> if [ -x /usr/bin/munin-cron ]; then
/usr/bin/munin-cron; fi

(process:27862): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text()

----- End forwarded message -----

--
see shy jo

signature.asc

Matthias Schmitz

unread,

Aug 13, 2008, 1:30:16 AM8/13/08

to

Hi Joey,

Am Sun, 10 Aug 2008 10:54:08 -0400
schrieb Joey Hess <jo...@debian.org>:

> Package: munin
> Version: 1.2.6-4
>
> Getting this every 5 minutes after upgrading to current unstable.
>

> ...

>
> (process:27862): Pango-WARNING **: Invalid UTF-8 string passed to
> pango_layout_set_text()

this sounds like this bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493553

I reassign this bug to the rrdtool package.

best regards,
Matthias Schmitz

signature.asc

Joey Hess

unread,

Aug 13, 2008, 3:30:16 PM8/13/08

to

> This bug has been fixed in rrdtool-1.3.1-3.
> See http://bugs.debian.org/493553 for details.

This bug is still present.

The system on which I originally filed the bug had just upgraded to
librrd4 1.3.1-3 when the bug showed up. AFAICS, your fix for 493553
could have caused 494547.

--
see shy jo

signature.asc

Sebastian Harl

unread,

Aug 13, 2008, 8:00:22 PM8/13/08

to

Hi,

Just to make sure, I'm not doing any wrong assumptions here: Which
version did you use before? That one was working fine for you, right?

What are your environment settings when calling rrdgraph (from munin)?
How is the script (i.e. the text being passed to rrdgraph) being
encoded?

For some more detailed explanations about what's going on here and the
problems involved with that, please see my follow-up to #493553 [1].

Cheers,
Sebastian

[1] http://bugs.debian.org/493553#10

--
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin

signature.asc

Joey Hess

unread,

Aug 14, 2008, 1:30:06 PM8/14/08

to

Sebastian Harl wrote:
> Just to make sure, I'm not doing any wrong assumptions here: Which
> version did you use before? That one was working fine for you, right?
>
> What are your environment settings when calling rrdgraph (from munin)?
> How is the script (i.e. the text being passed to rrdgraph) being
> encoded?
>
> For some more detailed explanations about what's going on here and the
> problems involved with that, please see my follow-up to #493553 [1].

Based on the dpkg.log, munin was using librrd2 until recently when it
switched to librrd4. No problem until switching to librrd4.

The system did not have any locale configured in /etc/environment or
enabled in /etc/locale.gen, and was just using the C locale. I've turned
on en_US.UTF-8, but am still getting the same messages.

Reverting bts493553-pango-utf-8 does not fix the problem.

--
see shy jo

signature.asc

Sebastian Harl

unread,

Aug 28, 2008, 12:50:07 PM8/28/08

to

Hi Joey,

On Thu, Aug 14, 2008 at 01:17:49PM -0400, Joey Hess wrote:
> Sebastian Harl wrote:
> > Just to make sure, I'm not doing any wrong assumptions here: Which
> > version did you use before? That one was working fine for you, right?
> >
> > What are your environment settings when calling rrdgraph (from munin)?
> > How is the script (i.e. the text being passed to rrdgraph) being
> > encoded?
> >
> > For some more detailed explanations about what's going on here and the
> > problems involved with that, please see my follow-up to #493553 [1].
>
> Based on the dpkg.log, munin was using librrd2 until recently when it
> switched to librrd4. No problem until switching to librrd4.

rrdtool did not use libpango before version 1.3 (librrd4).

> The system did not have any locale configured in /etc/environment or
> enabled in /etc/locale.gen, and was just using the C locale. I've turned
> on en_US.UTF-8, but am still getting the same messages.

The current version should work in any of the following two cases:

- the script's encoding matches the locale settings
- the script is encoded in UTF-8

I would be nice if you could verify either one or both claims.

> Reverting bts493553-pango-utf-8 does not fix the problem.

Which would make sense if the script's encoding is not UTF-8 _and_ does
not match the locale settings.

TIA,
Sebastian

signature.asc