Bug 246588 - graphics/inkscape: fix build "default.es_MX.svg:No such file or directory"
Summary: graphics/inkscape: fix build "default.es_MX.svg:No such file or directory"
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Kurt Jaeger
URL: https://bugs.freebsd.org/bugzilla/sho...
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-20 00:16 UTC by VVD
Modified: 2020-05-21 19:35 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (gnome)


Attachments
fix build "default.es_MX.svg:No such file or directory" (879 bytes, patch)
2020-05-20 00:16 UTC, VVD
vvd: maintainer-approval? (pi)
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description VVD 2020-05-20 00:16:56 UTC
Created attachment 214670 [details]
fix build "default.es_MX.svg:No such file or directory"

Upstream patch: https://gitlab.com/inkscape/inkscape/-/merge_requests/2020/diffs?commit_id=affcaa7cd39a182e506096bb4f566839065935fd

Explanation from: https://gitlab.com/inkscape/inkscape/-/merge_requests/2020

The translation file es_MX.po has a fuzzy attribute for the msgid "Label", so when evaluating this translation, gettext will fall through to language 'es' for the translation. If po/locale/es/LC_MESSAGES/inkscape.mo does not exist at the time of the call, the translation will fail, and "Label" will be returned, causing the check to fail, preventing writing es_MX.svg.
The order in which languages are processed is determined by the results of glob.glob, which may vary with filesystem type. In some build environments, 'es' is processed before 'es_MX', and no problem occurs. This is not guaranteed, however. In other build environments, 'es_MX' occurs first, and lacking 'es', the translation fails, and es_MX.svg is not generated.
To remove reliance on a particular ordering of gmofiles, and ensure build reproducibility, process the translations in two complete passes -- one to copy the gmo files, and when complete, the second to actually use the translations to generate the svg files.
Comment 1 VVD 2020-05-20 01:42:54 UTC
Tested on 12.1 amd64.
Comment 2 Kurt Jaeger freebsd_committer 2020-05-21 19:34:55 UTC
Thanks, a very cool find!
Comment 3 commit-hook freebsd_committer 2020-05-21 19:35:23 UTC
A commit references this bug:

Author: pi
Date: Thu May 21 19:34:27 UTC 2020
New revision: 536144
URL: https://svnweb.freebsd.org/changeset/ports/536144

Log:
  graphics/inkscape: fix build error "default.es_MX.svg:No such file or directory"

  The translation file es_MX.po has a fuzzy attribute for the msgid
  "Label", so when evaluating this translation, gettext will fall
  through to language 'es' for the translation. If
  po/locale/es/LC_MESSAGES/inkscape.mo does not exist at the time of
  the call, the translation will fail, and "Label" will be returned,
  causing the check to fail, preventing writing es_MX.svg.

  The order in which languages are processed is determined by the
  results of glob.glob, which may vary with filesystem type. In some
  build environments, 'es' is processed before 'es_MX', and no problem
  occurs. This is not guaranteed, however. In other build environments,
  'es_MX' occurs first, and lacking 'es', the translation fails, and
  es_MX.svg is not generated.

  To remove reliance on a particular ordering of gmofiles, and ensure
  build reproducibility, process the translations in two complete
  passes -- one to copy the gmo files, and when complete, the second
  to actually use the translations to generate the svg files.

  PR:		246588
  Submitted by:	vvd@unislabs.com
  Obtained from:	https://gitlab.com/inkscape/inkscape/-/merge_requests/2020

Changes:
  head/graphics/inkscape/files/patch-share_templates_create__default__templates.py