]> sipb.mit.edu Git - ikiwiki.git/blob - doc/bugs/yaml_setup_file_does_not_support_UTF-8_if_XS_is_installed.mdwn
349464844b798bf280100aa1a53d0331316dbaf0
[ikiwiki.git] / doc / bugs / yaml_setup_file_does_not_support_UTF-8_if_XS_is_installed.mdwn
1 I converted an ikiwiki setup file to YAML as
2 [[documented|tips/yaml_setup_files]].
3
4 On my Debian Squeeze system, attempting to build the wiki using the
5 YAML setup file triggers the following error message:
6
7         YAML::XS::Load Error: The problem:
8
9             Invalid trailing UTF-8 octet
10
11         was found at document: 0
12         usage: ikiwiki [options] source dest
13                ikiwiki --setup configfile
14
15 Indeed, my setup file contains UTF-8 characters.
16
17 Deinstalling YAML::XS ([[!debpkg libyaml-libyaml-perl]]) resolves this
18 issue. According to YAML::Any's POD, YAML::Syck is used instead of
19 YAML::XS in this case since it's the best YAML implementaion available
20 on my system.
21
22 No encoding-related setting is mentionned in YAML::XS' POD. We may
23 consider there is a bug in there. I'll see if it's known / fixed
24 somewhere as soon as I get online.
25
26 Joey, as a (hopefully) temporary workaround, what do you think of
27 explicitely using YAML::Syck (or whatever other YAML implementation
28 that does not expose this bug) rather than letting YAML::Any pick its
29 preferred one?
30
31 --[[intrigeri]]
32
33 > Upgrading YAML::XS ([[!debpkg libyaml-libyaml-perl]]) to current sid
34 > version (0.34-1) fixes this bug for me. --[[intrigeri]]
35
36 >> libyaml-syck-perl's description mentions that the module is now
37 >> deprecated. (I had to do some ugly workaround to make unicode work with
38 >> Syck earlier.) So it appears the new YAML::Xs is the
39 >> way to go longterm, and presumably YAML::Any will start depending on it
40 >> in due course? --[[Joey]]
41
42 >>> Right. Since this bug is fixed in current testing/sid, only
43 >>> Squeeze needs to be taken care of. As far as Debian Squeeze is
44 >>> concerned, I see two ways out of the current buggy situation:
45 >>>
46 >>> 1. Add `Conflicts: libyaml-libyaml-perl (< 0.34-1~)` to the
47 >>>    ikiwiki packages uploaded to stable and squeeze-backports.
48 >>>    Additionally uploading the newer, fixed `libyaml-libyaml-perl`
49 >>>    to squeeze-backports would make the resulting situation a bit
50 >>>    easier to deal with from the Debian stable user point of view.
51 >>> 2. Patch the ikiwiki packages uploaded to stable and
52 >>>    squeeze-backports:
53 >>>    - either to workaround the bug by explicitly using YAML::Syck
54 >>>      (yeah, it's deprecated, but it's Debian stable)
55 >>>    - or to make the bug easier to workaround by the user, e.g. by
56 >>>      warning her of possible problems in case YAML::Any has chosen
57 >>>      YAML::XS as its preferred implementation (the
58 >>>      `YAML::Any->implementation` module method can come in handy
59 >>>      in this case).
60 >>>
61 >>> I tend to prefer the first aforementioned solution, but any of
62 >>> these will anyway be kinda ugly, so...
63
64 >>>> I was wrong: I just experienced that bug with YAML::XS 0.34-1
65 >>>> too. Seems like [[!cpanrt 54683]]. --[[intrigeri]]