Created attachment 211064 [details] inkscape1.0b2.patch - GTK 3 - Python 3 - GraphicsMagick by default (bug 242588)
Thanks, I had a 1.0-b2 patch myself. I'm not really that hot on already committing this to ports yet, since it is a beta version. Is there are urgency to getting this in ports (apart from python3 support)?
(In reply to Koop Mast from comment #1) Well, I guess you could wait for the release if it comes before the python 2 deadline..
inkscape 0.92.4 build fine with default python 3.7. inkscape 0.92.5 just released: https://inkscape.org/news/2020/04/12/inkscape-0925-released-and-testers-needed-inkscape/ And release candidate 1.0: https://inkscape.org/release/inkscape-1.0/?latest=1
Any progress on this? It would be fine to upgrade at least to 0.92.5 in order to get rid of python-2.7.
This port should really use the graphicsmagick port instead of imagemagick6. About everything else in ports is using imagemagick7, but if you decide to install inkscape then pkg wants to uninstall a bunch of software so inkscape can use imagemagick6. They are not likely to get InkScape updated to use ImageMagick7 anytime soon, as it's been an open issue for awhile. But they did add in optional support for GraphicsMagick, which solves the problem.
Created attachment 213604 [details] patch graphics/inkscape from 0.92.4 to 0.92.5, Python 3 and GraphicsMagick As a step towards version 1.0, here is a patch to version 0.92.5, with changes to Python 3 and from ImageMagick6 to GraphicsMagick. Perhaps this helps waiting on 1.0. If older Inkscape is installed, one need to do something like portmaster -o textproc/scour@py37 py27-scour-0.37 because of a confict of both versions. The patch is tested on Poudriere (11.3a/i, 12.0a/i, and HEADa/i). 'portlint -AC' seems happy.
(In reply to Rainer Hurling from comment #6) Thank you very much for the patch. It works on my FreeBSD 12.1.RELEASE (amd64). I do not have any trace of Python 2.7 anymore.
This was just released today \o/ https://inkscape.org/news/2020/05/04/introducing-inkscape-10/
[Now, since incskape 1.0 is released, we can skip version 0.92.5] It seems openMP works as expected and should be enabled for inskape 1.0. Beside that, shouldn't cmake >= 3.12 set CMP0075 policy to NEW for this port? CMAKE_ARGS+= -DCMAKE_POLICY_DEFAULT_CMP0075:STRING=NEW \ -DWITH_OPENMP:BOOL=true
Rename PR from "beta" to "release" and update patch, plz.
*** Bug 242588 has been marked as a duplicate of this bug. ***
aand their server is borked: Connecting to media.inkscape.org (media.inkscape.org)|199.232.18.217|:443... connected. HTTP request sent, awaiting response... 503 between bytes timeout 2020-05-05 01:59:26 ERROR 503: between bytes timeout. Connecting to media.inkscape.org (media.inkscape.org)|199.232.18.217|:443... connected. HTTP request sent, awaiting response... 503 Backend unavailable, connection timeout 2020-05-05 02:02:05 ERROR 503: Backend unavailable, connection timeout. I'll work on this tomorrow, hopefully it will be up :) (In reply to Rainer Hurling from comment #9) Upstream already sets this: https://gitlab.com/inkscape/inkscape/-/blob/INKSCAPE_1_0/CMakeLists.txt#L8-10
(In reply to Greg V from comment #12) Ah, sorry, I must have overlooked it for 1.0. In version 0.92.5 it was needed. Many thanks for the hint.
Created attachment 214183 [details] inkscape1.0final.patch Here's 1.0, please test.
(In reply to Greg V from comment #14) Many thanks for the patch. Unfortunately, it does not apply for me: #patch < ./patch-graphics_inkscape_1.0.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -------------------------- |--- w/graphics/inkscape/Makefile |+++ w/graphics/inkscape/Makefile -------------------------- Patching file Makefile using Plan A... Hunk #1 succeeded at 1 with fuzz 2. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- w/graphics/inkscape/distinfo |+++ w/graphics/inkscape/distinfo -------------------------- Patching file distinfo using Plan A... Hunk #1 succeeded at 1. Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -------------------------- |--- w/graphics/inkscape/files/patch-CMakeScripts_Pod2man.cmake |+++ w/graphics/inkscape/files/patch-CMakeScripts_Pod2man.cmake -------------------------- File to patch: This is with a fresh downloaded port graphics/inkscape. Am I doing something wrong?
(In reply to Rainer Hurling from comment #15) You should use `patch -p1 < ...` in the root of the ports tree. (Better yet, use `git apply`, with the ports tree cloned from git of course)
(In reply to Greg V from comment #16) *or* better yet; you could use svn(lite) diff(1) as indicated in the porters handbook. B-} eg; svn diff --ignore-properties > graphics_inkscape.diff
(In reply to Greg V from comment #16) (In reply to Chris Hutchinson from comment #17) Many thanks for the hints with 'git apply' and 'svn diff'. Because I am not familiar enough with both, I tried it with 'patch -p1' for now. It applies fine :) As a first issue, I did #portlint -AC WARN: Makefile: for new port, make $FreeBSD$ tag in comment section empty, to make SVN happy. WARN: Makefile: "LIB_DEPENDS" has to appear earlier. WARN: Makefile: "RUN_DEPENDS" has to appear earlier. WARN: Makefile: "USES" has to appear earlier. WARN: /usr/ports/graphics/inkscape/files/patch-CMakeScripts_Pod2man.cmake: patch was not generated using ``make makepatch''. It is recommended to use ``make makepatch'' when you need to [re-]generate a patch to ensure proper patch format. 0 fatal errors and 5 warnings found.
(In reply to Greg V from comment #14) On a real life 13.0-CURRENT amd64 box, 1.0 builds and installs fine. Some quick tests with drawing, texturing, and pdf export also seem fine :)
On mine FreeBSD 12.1-RELEASE-p3 (amd64) inkscape1.0final.patch doesn't wokk. I had the same problem as are in comment 15. I am using portsnap. I run: patch - p1 < inkscape1.0final.patch Thank you.
(In reply to lumiwa from comment #20) Eventually just a typo (no space between minus and p1)? patch -p1 < inkscape1.0final.patch ^^^
(In reply to Rainer Hurling from comment #21) Yes, it is.
It doesn't want to patch /files/* Is it possible to download files from the /files from somewhere? Github? I search to find something but not success. Thank you.
(In reply to lumiwa from comment #23) Hi lumiwa, As far as I can say, it does work. These are the steps I did: - Download 'inkscape1.0final.patch' as 'raw unified' diff file[1] - cd /usr/ports - patch -p1 < /path.to.patch/inkscape1.0final.patch - cd graphics/inkscape - rm -R *.orig - cd files - Remove all file with length '0' (= files deleted by the patch) Now this port version should be buildable. HTH, Rainer [1] https://bz-attachments.freebsd.org/attachment.cgi?id=214183&action=diff&format=raw&headers=1
(In reply to Rainer Hurling from comment #24) A look at the diff seems to indicate the Index is wrong. Is the patch against a private/local repo? The first line is: --- w/graphics/inkscape/Makefile +++ w/graphics/inkscape/Makefile Shouldn't that be: --- ports/graphics/inkscape/Makefile +++ ports/graphics/inkscape/Makefile ^^^^^ Also there's alot of trailing garbage hanging on the lines (spaces/tabs/...) Just thought it worth a mention
(In reply to Chris Hutchinson from comment #25) > Shouldn't that be: > --- ports/graphics/inkscape/Makefile The prefix literally does not matter, you just use -p1 option to cut the first part. Git uses 'w' for working copy diffs, e.g. `git diff --cached -U9999 origin/master .`. For diffs across branches, it would write '--- a/' and '+++ b/'. > Is the patch against a private/local repo? It's against origin/master, which was at: https://github.com/freebsd/freebsd-ports/commit/7150489a5c61516fd366f1339cb44e98846ea487
>> Shouldn't that be: >> --- ports/graphics/inkscape/Makefile > The prefix literally does not matter, you just use -p1 option to cut the first part. Ugh. Of _course_. I knew that (but forgot). Sorry for the noise. :( > Git uses 'w' for working copy diffs, e.g. `git diff --cached -U9999 origin/master .`. For diffs across branches, it would write '--- a/' and '+++ b/'. Right. > Is the patch against a private/local repo? It's against origin/master, which was at: https://github.com/freebsd/freebsd-ports/commit/7150489a5c61516fd366f1339cb44e98846ea487 Thanks, and again, sorry. :)
(In reply to Rainer Hurling from comment #24) It doesn't work for me: ===> Patching for inkscape-1.0 ===> Applying FreeBSD patches for inkscape-1.0 I can't seem to find a patch in there anywhere. ====> FAILED Applying FreeBSD patch patch-CMakeScripts_Pod2man.cmake ====> IGNORING patchfile patch-CMakeScripts_Pod2man.cmake.orig ====> IGNORING patchfile patch-CMakeScripts_Pod2man.cmake.rej ====> IGNORING patchfile patch-src_extension_internal_pdfinput_pdf-input.cpp.orig ====> IGNORING patchfile patch-src_extension_internal_pdfinput_pdf-parser.cpp.orig ====> IGNORING patchfile patch-src_extension_internal_pdfinput_pdf-parser.h.orig ====> IGNORING patchfile patch-src_extension_internal_pdfinput_poppler-transition-api.h.orig ====> IGNORING patchfile patch-src_extension_internal_pdfinput_svg-builder.cpp.orig ====> IGNORING patchfile patch-src_libavoid_connector.cpp.orig ====> IGNORING patchfile patch-src_libnrtype_FontFactory.cpp.orig ===> FAILED to apply cleanly FreeBSD patch(es) patch-CMakeScripts_Pod2man.cmake ==> SOME PATCHES FAILED TO APPLY CLEANLY. ==> Look for FAILED messages above. *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/inkscape Thank you.
(In reply to lumiwa from comment #28) In comment #24, I showed my way to get a 'clean' port, patched from 0.92.4 to 1.0 with Gregs patch. I mentioned to use '-p1' for the patch command. There you find also the needed steps to get rid of *.orig files (after patching) and to delete files in the 'files' dir with length '0' (zero). HTH, Rainer
I did dlete *,orig but the problem are files in the files directory where the patch didn't work as before. I didn't have problem to patch to version 0.92.5. Thank you.
(In reply to lumiwa from comment #30) And just file patch-CMakeScripts_Pod2man.cmake is patched other no.
(In reply to lumiwa from comment #30 and comment #31) To be successfull with the patch towards 0.92.5 sounds like a port, that is not on version 0.92.4 any more? Perhaps it would be better to delete and reimport all files within graphics/inkscape, before you patch it to 1.0? Only having files/patch-CMakeScripts_Pod2man.cmake patched is correct. All other files in 'files' are deleted by the patch.
(In reply to Rainer Hurling from comment #32) Thank you very much for your patience... It works and for now there are no problem with Inkscape 1.0 :).
(In reply to lumiwa from comment #33) Nice to hear. And thanks for the feedback. I am glad I could help.
I did little work on this .I missed this PR and I feel I walk into something that's already kind of decided. BTW, one can find here my own patches for the 1.0 release port. https://gitlab.com/TurtleCrazy/inkscape-1.0-freebsd I only kept the Pod2man patch. It sounds that the inkscape devs globally switched to python3. So I do not used python flavor macros. They already use compliant (/bin/env python) shebangs for python scripts at first glance and the extension script defines both python2 and python3 commands. Finally, with my own Makefile, I doubt that ImageMagick and/or GraphicsMagick are well detected by CMake, despite the libraries are installed: -- Package 'ImageMagick++', required by 'virtual:world', not found -- Checking for module 'GraphicsMagick++' -- Package 'GraphicsMagick++', required by 'virtual:world', not found HTH.
Ok, I see. Unlike ImageMagick6, ImageMagick7 does not provide 'Magick++' for pkg-config, only 'ImageMagick++'. So that the pkg_check_modules(MAGICK Magick++<=7) Failed.
I just took a peek at your source on GitLab, and you have a dangling double quote on line 106 ( GRAPHICSMAGICK_LIB_DEPENDS= ) easy to miss. So thought I should mention it. :-)
(In reply to Chris Hutchinson from comment #37) Good catch, thanks. It needs more work actually, to make poudriere really happy and to improve The ImageMagick vs GraphicsMagick choice.
I think it's ok now. https://gitlab.com/TurtleCrazy/inkscape-1.0-freebsd I checked few differents option sets, that pass testport from a poudriere. http://poudriere.lapinbilly.eu/jail.html?mastername=test-dev while GTKSPELL is not a straight option, CMake will ask pkgconfig to find it out. So that I prefer activating this one by default.
I tried inkscape1.0final.patch and it works for me. As someone mentioned before, portlint -C : WARN: Makefile: "LIB_DEPENDS" has to appear earlier. WARN: Makefile: "RUN_DEPENDS" has to appear earlier. WARN: Makefile: "USES" has to appear earlier. I think this is caused by extra blank lines between these items.
I notice two missing dependencies. /usr/local/share/inkscape/extensions/ps_input.py calls 'ps2pdf' (use ghostscript macro) /usr/local/share/inkscape/extensions/fig_input.py calls 'fig2dev' from print/transfig
testbuilds@work
Committed, thanks!
A commit references this bug: Author: pi Date: Fri May 15 12:05:35 UTC 2020 New revision: 535285 URL: https://svnweb.freebsd.org/changeset/ports/535285 Log: graphics/inkscape: update 0.92.4 -> 1.0 - Smoother performance, HiDPI support, new & improved Live Path Effects - supports python3 - option to use ImageMagick6 PR: 243615 Submitted by: Greg V <greg@unrelenting.technology>, rhurlin@gwdg.de Reviewed by: kwm, vvd@unislabs.com, thierry, waitman@waitman.net, portmaster@bsdforge.com, lumiwa@gmail.com, david@lapinbilly.eu, contact@evilham.com Relnotes: https://inkscape.org/news/2020/05/04/introducing-inkscape-10/ https://wiki.inkscape.org/wiki/index.php?title=Release_notes/1.0#Inkscape_1.0 Changes: head/graphics/inkscape/Makefile head/graphics/inkscape/distinfo head/graphics/inkscape/files/patch-CMakeScripts_Pod2man.cmake head/graphics/inkscape/files/patch-src_extension_internal_pdfinput_pdf-input.cpp head/graphics/inkscape/files/patch-src_extension_internal_pdfinput_pdf-parser.cpp head/graphics/inkscape/files/patch-src_extension_internal_pdfinput_pdf-parser.h head/graphics/inkscape/files/patch-src_extension_internal_pdfinput_poppler-transition-api.h head/graphics/inkscape/files/patch-src_extension_internal_pdfinput_svg-builder.cpp head/graphics/inkscape/files/patch-src_libavoid_connector.cpp head/graphics/inkscape/files/patch-src_libnrtype_FontFactory.cpp head/graphics/inkscape/pkg-plist
(In reply to commit-hook from comment #44) Why gvfs is mandatory?!
(In reply to VVD from comment #45) ===> Installing for inkscape-1.0 ===> Checking if inkscape is already installed ===> Registering installation for inkscape-1.0 pkg-static: Unable to access file /tmp/work/usr/ports/graphics/inkscape/work/stage/usr/local/share/inkscape/templates/default.es_MX.svg:No such file or directory *** Error code 74
(In reply to VVD from comment #45) To be honest, the wide range of config options led me to not test each and every one on it's necessity. If gvfs is not needed or only needed in certain circumstances, please provide some patch and we'll fix it.
(In reply to VVD from comment #46) In my poudriere environment, the file templates/default.es_MX.svg was available, that's why I put it into the pkg-plist. Can you provide more details for the environment you built this ?
(In reply to Kurt Jaeger from comment #48) CDR : on DBUS : off GM : on IMAGICK6 : off OPENMP : off POPPLER : on VISIO : on WPG : on 12.1 amd64.
(In reply to waitman from comment #5) > About everything else in ports is using imagemagick7, but if you decide to install inkscape then pkg wants to uninstall a bunch of software so inkscape can use imagemagick6. multimedia/lives require ImageMagick6 too.
Created attachment 214529 [details] Make optional GVFS (In reply to Kurt Jaeger from comment #47) Already did.
A commit references this bug: Author: pi Date: Fri May 15 15:06:22 UTC 2020 New revision: 535292 URL: https://svnweb.freebsd.org/changeset/ports/535292 Log: graphics/inkscape: make gvfs an OPTION PR: 243615 Submitted by: VVD <vvd@unislabs.com> Changes: head/graphics/inkscape/Makefile
(In reply to VVD from comment #49) Thanks, testbuilding.
(In reply to VVD from comment #49) Testbuild on poudriere looks fine with your options: https://people.freebsd.org/~pi/logs/inkscape-121.txt(In reply to VVD from comment #50) Any ideas where the discrepancy comes from for that one file ?
(In reply to VVD from comment #50) We have multimedia/lives 2.10.2 in the ports tree. Upstream has 3.0.2. Would 3.0.2 work with ImageMagick7 or GraphicsMagick ?
(In reply to Kurt Jaeger from comment #55) > We have multimedia/lives 2.10.2 in the ports tree. > Upstream has 3.0.2. Would 3.0.2 work with ImageMagick7 or GraphicsMagick ? Probably yes - fast search show that it use convert command line utility only, but not libMagick*: RUN_DEPENDS= convert:graphics/ImageMagick6 I think we can make optional deps for IM6, 7 or GM. More ports with IM6 only dependency: print/cups-filters - convert:graphics/ImageMagick6 (same easy optional 6/7/GM) multimedia/dvdauthor - libMagick++-6.so:graphics/ImageMagick6 multimedia/libxine - libMagickWand-6.so:graphics/ImageMagick6 multimedia/transcode - libMagickWand-6.so:graphics/ImageMagick6
(In reply to Kurt Jaeger from comment #54) > Any ideas where the discrepancy comes from for that one file? Will upload build log file in ~30 mins.
Created attachment 214532 [details] inkscape full build log with error "default.es_MX.svg:No such file or directory"
(In reply to Kurt Jaeger from comment #55) https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246491 has a patch for multimedia/lives to 3.0.2 - it needs users that can run-test the software.
(In reply to VVD from comment #58) you build with portmaster, that might be the cause of the problem.
(In reply to Kurt Jaeger from comment #60) Can you tell me the result of pkg which /usr/local/bin/msgfmt ?
(In reply to Kurt Jaeger from comment #61) $ pkg which /usr/local/bin/msgfmt /usr/local/bin/msgfmt was installed by package gettext-tools-0.20.2
Created attachment 214536 [details] inkscape full build (make install) log with error "default.es_MX.svg:No such file or directory" Same error with make install.
(In reply to Kurt Jaeger from comment #54) I am sorry I have no idea why on poudriere "default.es_MX.svg" is build. Outside of poudriere it seems this does not happen. I tried with several combinations of options disabled/enabled and always got the "default.es_MX.svg" error outside of poudriere (with make install or with portmaster). On the other hand, poudriere seems happy without having "default.es_MX.svg" in pkg-plist. So wouldn't it be ok to remove this file from pkg-plist?
(In reply to Rainer Hurling from comment #64) I test-build using poudriere and it would fail without %%DATADIR%%/templates/default.es_MX.svg so...
I just tried updating via a manual port build and have the same issue, default.es_MX.svg:No such file. I'm baffled as to where those Template/default.XX.svg files come from. None exist in the work tree but "make stage" installs them in the stage tree. No idea where they come from. I assume that they are generated from the "po" files, but there is an es_MX.po in the o directory and the build uses the po files elsewhere. In any case, removing the file from the packing list allowed a successful install.
Created attachment 214570 [details] /usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49/share/templates/create_default_templates.py with debug output This file make svg files: /usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49/share/templates/create_default_templates.py cd /tmp/work/usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49/share/templates && python3.7 ./create_default_templates.py /tmp/work/usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49 /tmp/work/usr/ports/graphics/inkscape/work/.build I did: # cd /usr/ports/graphics/inkscape/ # make configure Then replace edited with a lot of debug output file create_default_templates.py: # cp /backup/create_default_templates.py /tmp/work/usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49/share/templates/ # make This is the normal output with create file default.sl.svg: [VVD] 0. language = sl [VVD] 1. destination_dir [VVD] 2. shutil.copy [VVD] 3.0. translation [VVD] 3.1. translation [VVD] 3.2. translated_string = Plast [VVD] 3.3. LAYER_STRING = Layer [VVD] 3.5. translated_string = Plast [VVD] 4. output_file = /tmp/work/usr/ports/graphics/inkscape/work/.build/share/templates/default.sl.svg [VVD] 5.1. os.path.isfile [VVD] 5.2. translated_string != LAYER_STRING [VVD] 5.3. file.read [VVD] 5.4. filedata.replace [VVD] 6. open This is output for es_MX [VVD] 0. language = es_MX [VVD] 1. destination_dir [VVD] 2. shutil.copy [VVD] 3.0. translation [VVD] 3.1. translation [VVD] 3.2. translated_string = Layer [VVD] 3.3. LAYER_STRING = Layer [VVD] 3.5. translated_string = Layer [VVD] 4. output_file = /tmp/work/usr/ports/graphics/inkscape/work/.build/share/templates/default.es_MX.svg [VVD] 5.1. os.path.isfile [VVD] 6. open Check attache file, no strings in output: [VVD] 5.2. translated_string != LAYER_STRING [VVD] 5.3. file.read [VVD] 5.4. filedata.replace "translated_string == LAYER_STRING" for es_MX. But if I do manual steps: [1078/1079] cd /tmp/work/usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49/share/templates && python3.7 ./create_default_templates.py /tmp/work/usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49 /tmp/work/usr/ports/graphics/inkscape/work/.build I got: [VVD] 0. language = es_MX [VVD] 1. destination_dir [VVD] 2. shutil.copy [VVD] 3.0. translation [VVD] 3.1. translation [VVD] 3.2. translated_string = Capa [VVD] 3.3. LAYER_STRING = Layer [VVD] 3.5. translated_string = Capa [VVD] 4. output_file = /tmp/work/usr/ports/graphics/inkscape/work/.build/share/templates/default.es_MX.svg [VVD] 5.1. os.path.isfile [VVD] 5.2. translated_string != LAYER_STRING [VVD] 5.3. file.read [VVD] 5.4. filedata.replace [VVD] 6. open And file default.es_MX.svg was created!!! I'm not python programmer - who can say WTF? Why 1st time after: > translation = gettext.translation('inkscape', localedir=binary_dir + '/po/locale', languages=[language]) > translated_string = translation.gettext(LAYER_STRING) translated_string == 'Layer', but during manual run translated_string == 'Capa' ???
(In reply to VVD from comment #67) I can exactly confirm the behaviour on my boxes (HEAD amd64), described by VVD. In the first build (automatic one from make) 'default.es_MX.svg' is not created. Running 'python3.7 ./create_default_templates.py /usr/ports/graphics/inkscape/work/inkscape-1.0_2020-05-01_4035a4fb49 /usr/ports/graphics/inkscape/work/.build' afterwards in the share/template directory does the job, 'default.es_MX.svg' is created now. (In reply to Kurt Jaeger from comment #65) I have no clue, why this is different on my poudriere. Here, graphics/inkscape builds fine on poudriere w/o 'default.es_MX.svg' in pkg-plist. I tried with HEADamd64, 11.3i386 and 12.1amd64, host system is HEADamd64.
(In reply to Rainer Hurling from comment #68) Maybe somebody can ask upstream?
[17.05.2020][20:06:54] <@Mc> it's "just" running a python script, so that might come from different python versions of different versions of python-getttext or something similar [17.05.2020][20:07:37] <@Mc> if it finds "Capa" it's probably not looking at es_MX.po but at es.po [17.05.2020][20:08:38] <VVD> es.po have Capa [17.05.2020][20:08:53] <VVD> <g inkscape:label="Capa 1" inkscape:groupmode="layer" id="layer1" /> [17.05.2020][20:09:28] <@Mc> so probably in one case it does not find it in es_MX (and concludes that the word is not translated in mexican, so there is no reason to produce a mexican version of the default.svg file); and in another case it defaults back from es_MX to es instead of giving up, and finds a translation (which is a sensible thing to do for gettext as es_MX is a derivate of es) [17.05.2020][20:10:06] <@Mc> => My guess is a difference in gettext "fallback" behavior So we can explore more, or just remove line "if translated_string != LAYER_STRING:" from create_default_templates.py.
(In reply to VVD from comment #70) If there's a patch, please submit it in a new PR.
Fixed error "default.es_MX.svg:No such file or directory" during build: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246588 Add NLS option: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=246589