Summary: |
'intltool-merge -k' fails to handle absolute paths Edit |
Product: |
Gentoo Linux
|
Reporter: |
Christian Faulhammer (RETIRED) <fauli> |
Component: |
Current packages | Assignee: |
Freedesktop bugs <freedesktop-bugs> |
Status: |
RESOLVED
FIXED
|
|
|
Severity: |
normal
|
CC: |
mgorny
|
Priority: |
Normal
|
Keywords: |
PATCH |
Version: |
unspecified | |
|
Hardware: |
All | |
|
OS: |
Linux | |
|
URL: |
https://bugs.launchpad.net/intltool/+bug/1168941
|
Whiteboard: |
|
Package list:
|
|
Runtime testing required:
|
---
|
Bug Depends on: |
|
|
|
Bug Blocks: |
464954
|
|
|
Attachments: |
Patch
|
Created attachment 348440 [details, diff] Patch From upstream bug report (by mgorny): "$ LC_ALL=C intltool-merge -k -u -c po/.intltool-merge-cache po data/gramps.keys.in /tmp/test/data/gramps.keys Found cached translation database Merging translations into /tmp/test/data/gramps.keys. Cannot open .//tmp/test/data/gramps.keys: No such file or directory This is the command that is run by gramps setup.py in an out-of-source build, when the build-dir is passed as an absolute path. The cause of the failure is that intltool implicitly prepends language-based subdirectory to the destination path. I have no idea about multiple file output, so I can't tell if it can be fixed there or not. But I believe the non-multiple-output mode shall be able to handle absolute paths similarly to how options other than '-k' handle it. I believe that the issue can be fixed quite easily, through prepending $lang only if multiple-output mode is requested, instead of using './' as a dirty hack-around. I'm attaching a patch made on top of 0.50.2, as I don't see a snapshot download link anywhere. Looking at the online viewer, the code should match on HEAD anyway." Upstream has not reacted in any way, but maybe we can incorporate this fix into Gentoo as it will stop the upcoming app-misc/gramps update to 4.0.0.