2011-04-15 03:04:52 +02:00
|
|
|
I converted an ikiwiki setup file to YAML as
|
|
|
|
|
[[documented|tips/yaml_setup_files]].
|
|
|
|
|
|
|
|
|
|
On my Debian Squeeze system, attempting to build the wiki using the
|
|
|
|
|
YAML setup file triggers the following error message:
|
|
|
|
|
|
|
|
|
|
YAML::XS::Load Error: The problem:
|
|
|
|
|
|
|
|
|
|
Invalid trailing UTF-8 octet
|
|
|
|
|
|
|
|
|
|
was found at document: 0
|
|
|
|
|
usage: ikiwiki [options] source dest
|
|
|
|
|
ikiwiki --setup configfile
|
|
|
|
|
|
|
|
|
|
Indeed, my setup file contains UTF-8 characters.
|
|
|
|
|
|
|
|
|
|
Deinstalling YAML::XS ([[!debpkg libyaml-libyaml-perl]]) resolves this
|
|
|
|
|
issue. According to YAML::Any's POD, YAML::Syck is used instead of
|
|
|
|
|
YAML::XS in this case since it's the best YAML implementaion available
|
|
|
|
|
on my system.
|
|
|
|
|
|
|
|
|
|
No encoding-related setting is mentionned in YAML::XS' POD. We may
|
|
|
|
|
consider there is a bug in there. I'll see if it's known / fixed
|
|
|
|
|
somewhere as soon as I get online.
|
|
|
|
|
|
|
|
|
|
Joey, as a (hopefully) temporary workaround, what do you think of
|
|
|
|
|
explicitely using YAML::Syck (or whatever other YAML implementation
|
|
|
|
|
that does not expose this bug) rather than letting YAML::Any pick its
|
|
|
|
|
preferred one?
|
2011-04-15 15:17:48 +02:00
|
|
|
|
|
|
|
|
--[[intrigeri]]
|
|
|
|
|
|
|
|
|
|
> Upgrading YAML::XS ([[!debpkg libyaml-libyaml-perl]]) to current sid
|
|
|
|
|
> version (0.34-1) fixes this bug for me. --[[intrigeri]]
|
2011-04-15 20:03:10 +02:00
|
|
|
|
|
|
|
|
>> libyaml-syck-perl's description mentions that the module is now
|
|
|
|
|
>> deprecated. (I had to do some ugly workaround to make unicode work with
|
|
|
|
|
>> Syck earlier.) So it appears the new YAML::Xs is the
|
|
|
|
|
>> way to go longterm, and presumably YAML::Any will start depending on it
|
|
|
|
|
>> in due course? --[[Joey]]
|
2011-04-16 18:56:28 +02:00
|
|
|
|
|
|
|
|
>>> Right. Since this bug is fixed in current testing/sid, only
|
|
|
|
|
>>> Squeeze needs to be taken care of. As far as Debian Squeeze is
|
|
|
|
|
>>> concerned, I see two ways out of the current buggy situation:
|
|
|
|
|
>>>
|
|
|
|
|
>>> 1. Add `Conflicts: libyaml-libyaml-perl (< 0.34-1~)` to the
|
|
|
|
|
>>> ikiwiki packages uploaded to stable and squeeze-backports.
|
|
|
|
|
>>> Additionally uploading the newer, fixed `libyaml-libyaml-perl`
|
|
|
|
|
>>> to squeeze-backports would make the resulting situation a bit
|
|
|
|
|
>>> easier to deal with from the Debian stable user point of view.
|
|
|
|
|
>>> 2. Patch the ikiwiki packages uploaded to stable and
|
|
|
|
|
>>> squeeze-backports:
|
|
|
|
|
>>> - either to workaround the bug by explicitly using YAML::Syck
|
|
|
|
|
>>> (yeah, it's deprecated, but it's Debian stable)
|
|
|
|
|
>>> - or to make the bug easier to workaround by the user, e.g. by
|
|
|
|
|
>>> warning her of possible problems in case YAML::Any has chosen
|
|
|
|
|
>>> YAML::XS as its preferred implementation (the
|
|
|
|
|
>>> `YAML::Any->implementation` module method can come in handy
|
|
|
|
|
>>> in this case).
|
|
|
|
|
>>>
|
|
|
|
|
>>> I tend to prefer the first aforementioned solution, but any of
|
|
|
|
|
>>> these will anyway be kinda ugly, so...
|
