git.oblomov.eu Git - ikiwiki/blob - 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]]
  66
  67 >>>>> Yes, [[!debbug 625713]] reports this also affects debian unstable.
  68 >>>>> So, I will add a conflict I guess. [[done]] --[[Joey]]
  69
  70 >>>>>> With the additional info and test cases I provided on the
  71 >>>>>> Debian bug (Message #22), I now doubt this is a YAML::XS bug
  72 >>>>>> very much. Also, the RT bug I linked to happens with `use
  73 >>>>>> utf8`, which is not the case in ikiwiki AFAIK => I think you
  74 >>>>>> shall reconsider whether this bug really is YAML::XS' fault, or
  75 >>>>>> YAML::Any's fault, or Perl's fault, or... the way ikiwiki
  76 >>>>>> slurps and untaints UTF-8 YAML setup files. Sorry for providing
  77 >>>>>> information that may have been misguided. --[[intrigeri]]
  78
  79 >>>>>>> `use utf8` is completely irrelevant; that only tells
  80 >>>>>>> perl to support utf8 in its source code.
  81 >>>>>>>
  82 >>>>>>> I don't know what `Path::Class::File` is, but if it
  83 >>>>>>> provides non-decoded bytes to the module than it would likely
  84 >>>>>>> avoid this failure, while resulting in parsed yaml where every
  85 >>>>>>> string was likewise not decoded unicode, which is not very useful.
  86 >>>>>>> --[[Joey]]
  87
  88 >>>>>>>> You guessed right about the non-decoded bytes being passed to
  89 >>>>>>>> YAML::XS, except this is the way it shall be done. YAML::XS
  90 >>>>>>>> POD reads: "YAML::XS only deals with streams of utf8 octets".
  91 >>>>>>>> Feed it with non-decoded UTF-8 bytes and it gives you
  92 >>>>>>>> properly encoded UTF-8 Perl strings in exchange.
  93 >>>>>>>>
  94 >>>>>>>> Once this has been made clear, since 1. this module indeed
  95 >>>>>>>> seems to be the future of YAML in Perl, and 2. is depended on
  96 >>>>>>>> by other popular software such as dh-make-perl (on the 2nd
  97 >>>>>>>> degree), I suggest using it explicitly instead of the current
  98 >>>>>>>> "try to support every single YAML Perl module and end up
  99 >>>>>>>> conflicting with the now recommended one" nightmare.
 100 >>>>>>>> --[[intrigeri]]
 101
 102 >>>>>>>>> Ok, [[done]] (although YAML::Syck does also still work.) --[[Joey]]
 103
 104 >>>>>>>>>> Thanks a lot. --[[intrigeri]]