gnome2.zenity: Add docbook_xml_dtd_412 to prevent build failure

[coreyoconnor]

Adds docbook_xml_dtd_412 to build dependencies.

Motivation for this change

1. ensure a rebuild of gnome2.zenity (EG: change version number to 2.32.2 as done below)
2. build with nix build -f default.nix pkgs.gnome2.zenity

expectation is gnome2.zenity succeeds. Actual is build of gnome2.zenity fails with:

builder for '/nix/store/c64dr3z107aklgf0rzw9gka4wc6zxvl2-zenity-2.32.2.drv' failed with exit code 2; last 10 log lines:
  xsltproc -o zenity-C.omf --stringparam db2omf.basename zenity --stringparam db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.1.2//EN" --stringparam db2omf.lang C --stringparam db2omf.omf_dir "/nix/s
tore/zsp439gygfhxwzzvhqj9x3ck60sq0agb-zenity-2.32.2/share/omf" --stringparam db2omf.help_dir "/nix/store/zsp439gygfhxwzzvhqj9x3ck60sq0agb-zenity-2.32.2/share/gnome/help" --stringparam db2omf.omf_in "/tmp/nix-build-zenity-2.32.2.dr
v-0/zenity-2.32.1/help/zenity.omf.in"  `/nix/store/340wmknqs4by554nwpg3hcr52lshqdj2-pkg-config-0.29.2/bin/pkg-config --variable db2omf gnome-doc-utils` C/zenity.xml || { rm -f "zenity-C.omf"; exit 1; }
  http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd:22: parser error : Comment not terminated

   ^
  unable to parse C/zenity.xml
  make[2]: *** [Makefile:596: zenity-C.omf] Error 1
  make[2]: Leaving directory '/tmp/nix-build-zenity-2.32.2.drv-0/zenity-2.32.1/help'
  make[1]: *** [Makefile:322: all-recursive] Error 1
  make[1]: Leaving directory '/tmp/nix-build-zenity-2.32.2.drv-0/zenity-2.32.1'
  make: *** [Makefile:260: all] Error 2

Which means the DTD cannot be accessed.

The following patch adds the DTD to the build depends.

Strange this succeeded before. Difference in nix builder sandbox WRT network DTD references?

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
• Fits CONTRIBUTING.md.

---

[7c6f434c]

Hm a Hydra build has recently succeeded…

[coreyoconnor]

This is one of several packages I've had to do the same transform to. All appear to be attempting to download the stylesheet over the network. Which, on my CI, is mostly blocked. ( That does cause, on purpose, the CI to rebuild most from scratch. ) Could this be impacted by sandboxing? I'm not convinced that given hydra succeeded there is not an issue.

…

On Sun, Mar 25, 2018, 05:10 Michael Raskin ***@***.***> wrote: Hm a Hydra build has recently succeeded… — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#37005 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACGDWV3B3q-KR3tkrpQbg2Xo-CNAtbCks5th4lJgaJpZM4Sq-Uo> .

[7c6f434c]

I would expect this to be a snadboxing issue, but Hydra runs with sandboxing.

We had a recent example of nondeterminism during patching that makes it random which files are fresher. In this case it shouldn't be an issue, but maybe there is some corner case about tarballs.

[coreyoconnor]

Makes sense that hydra runs with sandboxing. I was unaware of the nondeterminism during patching issue. Is there a ticket for that?

I wonder if these other CI build failures I'm looking at are from that issue. The whole goal behind this this non-hydra, nearly from scratch, CI is to uncover different issues than hydra. Which is nice idea, but chasing these down is complicated by non-determinism in some builds.

[7c6f434c]

@coreyoconnor I meant #34387 as the recent example. I think even #1424 can still be triggered in some exotic cases…