Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-13 Thread Martin Quinson

On Wed, Nov 12, 2014 at 03:35:50PM +0100, Lucas Nussbaum wrote:
> 
> couldn't you build with javac -encoding "UTF-8"?
> See
> http://stackoverflow.com/questions/1726174/how-to-compile-a-java-source-file-which-is-encoded-as-utf-8

Thanks for the hint. I would have expected jh_build to do the right
thing for me, but apparently it is not the case. I just asked jh_build
to pass that flags to javac, and it seems all good now. 

> Regarding the msggrep warnings, I'm not sure if they are really
> harmless.

Thinking again, that should be harmless. I cannot see any after
rebuilding the package in a chroot similar to yours.


Many thanks for your assistance, and sorry, I'm really fuzzy in my
head these days. The fixed package was just uploaded.

Bye, Mt.

-- 
Les chats, c'est vraiment des branleurs.  -- Alain Chabat


signature.asc
Description: Digital signature


Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-12 Thread Lucas Nussbaum
On 12/11/14 at 15:06 +0100, Martin Quinson wrote:
> retitle 768732 plm: FTBFS in non-UTF-8 settings
> thanks
> 
> Hello, 
> 
> thanks for this additional information, that's indeed the source of
> the problem. The PLM package builds correctly if I set LC_ALL=C.UTF-8
> in addition to your settings and fails without it.
> 
> But, it seems to me that the package built with non-utf locale
> settings will not be functionnal for non-english speakers. At least
> that's what I understand from the msggrep warnings.
> 
> Could you please point me to the part of the policy that is relevant
> to the locale settings of the builder? I fail to find anything
> relevant by myself, sorry.

I'm not sure if this is specified. my chroot is generated by
sbuild-createchroot, without any further customization.
One could argue that sbuild could default to C.UTF-8, but OTOH,
all other packages build fine (or fail for unrelated reasons).

> In the meanwhile, I will patch most of the java files to not use the
> UTF encoding. I'm just reluctant do so in some cases where it would
> not be an improvement. For example, it would request to write the name
> of "Gérald Oster" as "Gerald Oster". Not a big deal, but not nice.

couldn't you build with javac -encoding "UTF-8"?
See
http://stackoverflow.com/questions/1726174/how-to-compile-a-java-source-file-which-is-encoded-as-utf-8

Regarding the msggrep warnings, I'm not sure if they are really
harmless.

> I guess that it would not be ok to set LC_ALL=C.UTF-8 in the rules
> file, right?

That would probably work, yes.
 
Lucas


signature.asc
Description: Digital signature


Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-12 Thread Martin Quinson
retitle 768732 plm: FTBFS in non-UTF-8 settings
thanks

Hello, 

thanks for this additional information, that's indeed the source of
the problem. The PLM package builds correctly if I set LC_ALL=C.UTF-8
in addition to your settings and fails without it.

But, it seems to me that the package built with non-utf locale
settings will not be functionnal for non-english speakers. At least
that's what I understand from the msggrep warnings.

Could you please point me to the part of the policy that is relevant
to the locale settings of the builder? I fail to find anything
relevant by myself, sorry.

In the meanwhile, I will patch most of the java files to not use the
UTF encoding. I'm just reluctant do so in some cases where it would
not be an improvement. For example, it would request to write the name
of "Gérald Oster" as "Gerald Oster". Not a big deal, but not nice.

I guess that it would not be ok to set LC_ALL=C.UTF-8 in the rules
file, right?

Thanks for your patience and sorry for the complications,
Mt.

On Wed, Nov 12, 2014 at 01:34:04PM +0100, Lucas Nussbaum wrote:
> Hi,
> 
> On 12/11/14 at 11:27 +0100, Martin Quinson wrote:
> > Hello,
> > 
> > I must confess that I fail to reproduce your bug.
> > 
> > it seems to me that the bug comes from a strange setting in LC_ALL.
> 
> # locale
> LANG=
> LANGUAGE=
> LC_CTYPE="POSIX"
> LC_NUMERIC="POSIX"
> LC_TIME="POSIX"
> LC_COLLATE="POSIX"
> LC_MONETARY="POSIX"
> LC_MESSAGES="POSIX"
> LC_PAPER="POSIX"
> LC_NAME="POSIX"
> LC_ADDRESS="POSIX"
> LC_TELEPHONE="POSIX"
> LC_MEASUREMENT="POSIX"
> LC_IDENTIFICATION="POSIX"
> LC_ALL=
> 
> > before the java compiler, msggrep complains that ANSI_X3.4-1968 is not
> > a valid value for UTF-encoded files.
> > 
> > Did your chroot have any unconventional settings with that regard?
> 
> No. Also, I did not notice any other locale-related failure while filing bugs.
> 
> Lucas



-- 
HARDWARE n.m.: partie de l'ordinateur qui reçoit les coups quand le
software se plante.


signature.asc
Description: Digital signature


Processed: Re: Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-12 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

> retitle 768732 plm: FTBFS in non-UTF-8 settings
Bug #768732 [src:plm] plm: FTBFS in jessie: src/plm/core/model/Game.java:97: 
error: unmappable character for encoding ASCII
Changed Bug title to 'plm: FTBFS in non-UTF-8 settings' from 'plm: FTBFS in 
jessie: src/plm/core/model/Game.java:97: error: unmappable character for 
encoding ASCII'
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
768732: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768732
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems


--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org



Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-12 Thread Lucas Nussbaum
Hi,

On 12/11/14 at 11:27 +0100, Martin Quinson wrote:
> Hello,
> 
> I must confess that I fail to reproduce your bug.
> 
> it seems to me that the bug comes from a strange setting in LC_ALL.

# locale
LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

> before the java compiler, msggrep complains that ANSI_X3.4-1968 is not
> a valid value for UTF-encoded files.
> 
> Did your chroot have any unconventional settings with that regard?

No. Also, I did not notice any other locale-related failure while filing bugs.

Lucas


signature.asc
Description: Digital signature


Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-12 Thread Martin Quinson
Hello,

I must confess that I fail to reproduce your bug.

it seems to me that the bug comes from a strange setting in LC_ALL.
before the java compiler, msggrep complains that ANSI_X3.4-1968 is not
a valid value for UTF-encoded files.

Did your chroot have any unconventional settings with that regard?

Thanks for any additional info,
Mt

On Sun, Nov 09, 2014 at 08:14:08AM +0100, Lucas Nussbaum wrote:
> Source: plm
> Version: 2.4.11+repack-1
> Severity: serious
> Tags: jessie sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20141108 qa-ftbfs
> Justification: FTBFS in jessie on amd64
> 
> Hi,
> 
> During a rebuild of all packages in jessie (in a jessie chroot, not a
> sid chroot), your package failed to build on amd64.
> 
> Relevant part (hopefully):
> > make[1]: Entering directory '/«BUILDDIR»/plm-2.4.11+repack'
> > # Copy our resource within the wannabe jar file
> > mkdir -p debian/_jh_build.plm
> > cp -r lib/resources debian/_jh_build.plm
> > # Copy our image files (but prune the svg files)
> > cp -r img debian/_jh_build.plm
> > find debian/_jh_build.plm -name "*.svg" -print0 | xargs -0 rm
> > # Copy other mandated files in place
> > jarctn=`find src -name "*.py"; \
> > find src -name "*.java"; \
> > find src -name "*.scala"; \
> > find src -name "*.c"; \
> > find src -name "*.html"; \
> > find src -name "*.png"; \
> > find src -name  "*.map"`; \
> > for file in $jarctn ; do\
> >whereto=`echo $file|sed 's|^src/||'` ; \
> >install -D -m 644 $file debian/_jh_build.plm/$whereto; \
> > done
> > # Generate the translation files
> > ant i18n-generate-jar
> > Buildfile: /«BUILDDIR»/plm-2.4.11+repack/build.xml
> >   [taskdef] Could not load definitions from resource 
> > scala/tools/ant/antlib.xml. It could not be found.
> > 
> > i18n-init:
> > 
> > i18n-extract:
> > [gettext-extract] src
> > [gettext-extract] /tmp/srcfiles4590680762197888444.tmp
> > [gettext-extract] Executing: xgettext -c --from-code=utf-8 
> > --output=/«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot --language=Java 
> > -ktrc:1c,2 -ktrnc:1c,2,3 -ktr -kmarktr -ktrn:1,2 -k 
> > --files-from=/tmp/srcfiles4590680762197888444.tmp
> > 
> > i18n-update:
> > [gettext-merge] Invoking msgmerge for po files in 
> > '/«BUILDDIR»/plm-2.4.11+repack/l10n/engine'.
> > [gettext-merge] Processing en.po
> > [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/en.po 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> > [gettext-merge] Processing fr.po
> > [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/fr.po 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> > [gettext-merge] Processing it.po
> > [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/it.po 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> > [gettext-merge] Processing pt_BR.po
> > [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/pt_BR.po 
> > /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> > 
> > i18n-check:
> >  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> > from
> >  [exec]   input file charset "UTF-8".
> >  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> > from
> >  [exec]   input file charset "UTF-8".
> >  [exec]   Output of 'msggrep' might be incorrect.
> >  [exec]   Possible workarounds are:
> >  [exec]   Output of 'msggrep' might be incorrect.
> >  [exec]   Possible workarounds are:
> >  [exec]   - Set LC_ALL to a locale with encoding UTF-8.
> >  [exec]   - Convert the translation catalog to ASCII 
> > using 'msgconv',
> >  [exec]   - Set LC_ALL to a locale with encoding UTF-8.
> >  [exec]   - Convert the translation catalog to ASCII 
> > using 'msgconv',
> >  [exec] then apply 'msggrep',
> >  [exec] then convert back to UTF-8 using 'msgconv'.
> >  [exec] then apply 'msggrep',
> >  [exec] then convert back to UTF-8 using 'msgconv'.
> >  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> > from
> >  [exec]   input file charset "UTF-8".
> >  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> > from
> >  [exec]   input file charset "UTF-8".
> >  [exec]   Output of 'msggrep' might be incorrect.
> >  [exec]   Possible workarounds are:
> >  [exec]   Output of 'msggrep' might be incorrect.
> >  [exec]   Possible workarounds are:
> >  [exec]   - Set LC_ALL to a locale

Bug#768732: plm: FTBFS in jessie: src/plm/core/model/Game.java:97: error: unmappable character for encoding ASCII

2014-11-08 Thread Lucas Nussbaum
Source: plm
Version: 2.4.11+repack-1
Severity: serious
Tags: jessie sid
User: debian...@lists.debian.org
Usertags: qa-ftbfs-20141108 qa-ftbfs
Justification: FTBFS in jessie on amd64

Hi,

During a rebuild of all packages in jessie (in a jessie chroot, not a
sid chroot), your package failed to build on amd64.

Relevant part (hopefully):
> make[1]: Entering directory '/«BUILDDIR»/plm-2.4.11+repack'
> # Copy our resource within the wannabe jar file
> mkdir -p debian/_jh_build.plm
> cp -r lib/resources debian/_jh_build.plm
> # Copy our image files (but prune the svg files)
> cp -r img debian/_jh_build.plm
> find debian/_jh_build.plm -name "*.svg" -print0 | xargs -0 rm
> # Copy other mandated files in place
> jarctn=`find src -name "*.py"; \
>   find src -name "*.java"; \
>   find src -name "*.scala"; \
>   find src -name "*.c"; \
> find src -name "*.html"; \
> find src -name "*.png"; \
>   find src -name  "*.map"`; \
> for file in $jarctn ; do\
>whereto=`echo $file|sed 's|^src/||'` ; \
>install -D -m 644 $file debian/_jh_build.plm/$whereto; \
> done
> # Generate the translation files
> ant i18n-generate-jar
> Buildfile: /«BUILDDIR»/plm-2.4.11+repack/build.xml
>   [taskdef] Could not load definitions from resource 
> scala/tools/ant/antlib.xml. It could not be found.
> 
> i18n-init:
> 
> i18n-extract:
> [gettext-extract] src
> [gettext-extract] /tmp/srcfiles4590680762197888444.tmp
> [gettext-extract] Executing: xgettext -c --from-code=utf-8 
> --output=/«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot --language=Java 
> -ktrc:1c,2 -ktrnc:1c,2,3 -ktr -kmarktr -ktrn:1,2 -k 
> --files-from=/tmp/srcfiles4590680762197888444.tmp
> 
> i18n-update:
> [gettext-merge] Invoking msgmerge for po files in 
> '/«BUILDDIR»/plm-2.4.11+repack/l10n/engine'.
> [gettext-merge] Processing en.po
> [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/en.po 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> [gettext-merge] Processing fr.po
> [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/fr.po 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> [gettext-merge] Processing it.po
> [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/it.po 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> [gettext-merge] Processing pt_BR.po
> [gettext-merge] Executing: msgmerge -q --backup=numbered -U 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/pt_BR.po 
> /«BUILDDIR»/plm-2.4.11+repack/l10n/engine/plm.pot
> 
> i18n-check:
>  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> from
>  [exec]   input file charset "UTF-8".
>  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> from
>  [exec]   input file charset "UTF-8".
>  [exec]   Output of 'msggrep' might be incorrect.
>  [exec]   Possible workarounds are:
>  [exec]   Output of 'msggrep' might be incorrect.
>  [exec]   Possible workarounds are:
>  [exec]   - Set LC_ALL to a locale with encoding UTF-8.
>  [exec]   - Convert the translation catalog to ASCII 
> using 'msgconv',
>  [exec]   - Set LC_ALL to a locale with encoding UTF-8.
>  [exec]   - Convert the translation catalog to ASCII 
> using 'msgconv',
>  [exec] then apply 'msggrep',
>  [exec] then convert back to UTF-8 using 'msgconv'.
>  [exec] then apply 'msggrep',
>  [exec] then convert back to UTF-8 using 'msgconv'.
>  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> from
>  [exec]   input file charset "UTF-8".
>  [exec] msggrep: warning: Locale charset "ANSI_X3.4-1968" is different 
> from
>  [exec]   input file charset "UTF-8".
>  [exec]   Output of 'msggrep' might be incorrect.
>  [exec]   Possible workarounds are:
>  [exec]   Output of 'msggrep' might be incorrect.
>  [exec]   Possible workarounds are:
>  [exec]   - Set LC_ALL to a locale with encoding UTF-8.
>  [exec]   - Convert the translation catalog to ASCII 
> using 'msgconv',
>  [exec]   - Set LC_ALL to a locale with encoding UTF-8.
>  [exec]   - Convert the translation catalog to ASCII 
> using 'msgconv',
>  [exec] then apply 'msggrep',
>  [exec] then convert back to UTF-8 using 'msgconv'.
>  [exec] then apply 'msggrep',
>  [exec] then convert back to UTF-8 using 'msgconv'.
> 
> i18n-generate-jar:
> [mkdir] Cr