Bug#388141: Progress in relicensing agreements: 167 ok out of 216 alioth
Hi Simon and members, 2012/10/21 Simon Paillard spaill...@debian.org: Hi, On Wed, Oct 17, 2012 at 06:18:02PM +0200, Thijs Kinkhorst wrote: We sent the first batch to the Alioth users, and are quite happy that, among the 213 members of the Alioth webwml group we contacted, 104 members already sent us back the agreement, and 44 other persons (who already provided content but who currently don't have commit access) sent it also back to us. Thanks to Simon who is tracking the received answers for the figures. I am one of recently inactive members of Alioth webwml project and kept silent on the relicensing confirmation. Sorry for my late reply. (Since I cannot read emails to my old address, I set my new address to my account nori1-guest a few minutes ago.) I agree with relicensing under dual MIT/GPL2+ since I devoted translations for the sake of the project and the community, and it is happy for me to keep them freely useful for the project and the community, although I have not been able to join and contribute anything recent years (but I want to do again). (Since I have not generated a GPG key for this mail address, I am very sorry but I cannot provide any signatures to this important reply...) Thanks a lot, -nori -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#515062: release-notes: Check libfam0 instead of libfam0c102?
Package: release-notes Severity: normal Tags: patch Hi, 4.5.6.1. Upgrading a desktop system in the lenny release notes asks users to check libfam0c102 for the desktop system and to install libfam0. However, libfam0c102 is not installed in pure etch desktop systems. In my desktop environment, the following command line results in nothing: # dpkg -l libfam0c102 | grep ^ii Since libfam0 seems to have replaced libfam0c102 in etch, checking libfam0c102 and installing libfam0 is only correct in the sarge-etch upgrade. IMHO, users should check libfam0 itself before installing it in the etch-lenny upgrade instead (although I have not checked it because I don't have an environment for testing it). Could you please consider applying this patch? Since this patch changes nothing but package names. So, unfuzzying translations is easy. Sorry for my too late bug report. Best regards, -nori -- System Information: Debian Release: 5.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (90, 'unstable'), (80, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Index: en/upgrading.dbk === --- en/upgrading.dbk (リビジョン 6435) +++ en/upgrading.dbk (作業コピー) @@ -936,11 +936,11 @@ or with the the GNOME or KDE packages installed. /para para -Check whether you have the systemitem role=packagelibfam0c102/systemitem +Check whether you have the systemitem role=packagelibfam0/systemitem package installed: /para screen -# dpkg -l libfam0c102 | grep ^ii +# dpkg -l libfam0 | grep ^ii /screen para If you do have it installed, run:
Bug#514891: release-notes: fixing an obvious typo: the the
Package: release-notes Severity: normal Tags: patch Hi, Could you please consider getting this obvious typo fix into the release notes? I think the msguntypot command in Po4a will help you. Thanks, -nori -- System Information: Debian Release: 5.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (90, 'unstable'), (80, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Index: en/upgrading.dbk === --- en/upgrading.dbk (リビジョン 6435) +++ en/upgrading.dbk (作業コピー) @@ -933,7 +933,7 @@ titleUpgrading a desktop system/title para This step concerns systems with the literaldesktop/literal task installed, -or with the the GNOME or KDE packages installed. +or with the GNOME or KDE packages installed. /para para Check whether you have the systemitem role=packagelibfam0c102/systemitem
Bug#513945: release-notes: fixing a floating footnote and an empty section
Package: release-notes Severity: normal Tags: patch Hi, upgrading.dbk has an odd paragraph which only contains a footnote. The footnote should be included just after some word in another paragraph or changed to a normal note. I prefer the latter. Also, the last section of that file, identified as plans-for-nigel, only contains a subsection for arm and armel. This results in plans-for-nigel being an empty section for other architectures. I propose to add a property 'arch=arm;armel' to the section likewise to make it shown only in release notes for arm and armel. Here is a patch to do so. Could you please consider applying it? # I have made many corrections and improvements directly to English files, # but this change is slightly big. So, I file this as a bug report. ;-) Many thanks, -nori -- System Information: Debian Release: 5.0 APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing'), (90, 'unstable'), (80, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Index: en/upgrading.dbk === --- en/upgrading.dbk (リビジョン 6129) +++ en/upgrading.dbk (作業コピー) @@ -670,15 +670,15 @@ Need to get xx.xMB/yyyMB of archives. After unpacking AAAMB will be used. Would download/install/remove packages. /screen +note + para Running this command at the beginning of the upgrade process + may give an error, for the reasons described in the next sections. In that + case you will need to wait until you've done the minimal system upgrade as in + xref linkend=minimal-upgrade/ and upgraded your kernel as in xref + linkend=upgrading-kernel/ before running this command to estimate the disk + space. /para +/note para -footnotepara Running this command at the beginning of the upgrade process -may give an error, for the reasons described in the next sections. In that -case you will need to wait until you've done the minimal system upgrade as in -xref linkend=minimal-upgrade/ and upgraded your kernel as in xref -linkend=upgrading-kernel/ before running this command to estimate the disk -space. /para /footnote -/para -para If you do not have enough space for the upgrade, make sure you free up space beforehand. You can: /para @@ -1933,7 +1933,9 @@ /section -section id=plans-for-nigel +!-- Please remove 'arch=arm;armel' when this section gets subsections +related to some other architectures. -- +section id=plans-for-nigel arch=arm;armel titlePlans for the next Debian release/title section arch=arm;armel
Bug#503374: nautilus-cd-burner: hungs when burning a CD with a huge number of files in a flat directory
Hi, When I click on the Write CD button, the windows that ask for the burning options (i.e. unit to use or speed) appears, but all its widgets are deactivated, in gray, and it says that it is calculating the size used. That window becomes unresponsive, not rendering anymore when damaged. CPU usage by Nautilus as reported by top is around 20% first, and after a while it drops to zero. Finally, the full Nautilus becomes unresponsive and I have to restart it in order to continue using it. The same issue (probably) occurs to me. I also find that the property dialogue opened from the Property nemu in the CD/DVD Creator window also hangs, although the property dialogue opened from the general Nautilus window correctly displays the result. Many thanks, -nori -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508485: fop: executable does not work; binary package dependency needs updating
Hi, On Thu, 11 Dec 2008 20:52:04 +0100 Vincent Fourmond fourm...@debian.org wrote: Hmmm... I had started to fix these dependencies ages ago in the SVN, but for some reason I didn't upload them. Funny. But I hadn't spotted all of them, so thanks for you report. I didn't actually use your patch as such, sorry, but it is fixed anyway. Please expect an upload within a few minutes, just the time for me to check it autobuilds fine. Thanks for your quick replies and quick fix. I have tested fop with openjdk-6-jre by running my personal (non-simple) XSL-FO programs and made sure it works well. If I find some errors potentially due to non-Sun runtime, I'll report it. ;-) Thanks a lot, -nori -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494366: release-notes: please document emdebian 1.0 release, based on Debian Lenny 5.0
tag 494366 + pending thanks Hi, This description has already been incorporated in the release notes. So, I tag this bug as pending. # Martin, did you try to add the pending tag and mistakingly add the patch tag? ;-) 2008/8/9 W. Martin Borgert [EMAIL PROTECTED]: On 2008-08-08 15:52, Neil Williams wrote: Package: release-notes Severity: wishlist wontfix :~) Have a nice day, -nori -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494366: release-notes: please document emdebian 1.0 release, based on Debian Lenny 5.0
tag 494366 + pending thanks Hi, This description has already been incorporated in the release notes. So, I tag this bug as pending. # Martin, did you try to add the pending tag and mistakingly add the patch tag? ;-) 2008/8/9 W. Martin Borgert [EMAIL PROTECTED]: On 2008-08-08 15:52, Neil Williams wrote: Package: release-notes Severity: wishlist wontfix :~) Have a nice day, -nori -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#504560: lilo's po-debconf ja.po reviewed
Hi, I have reviewed and made some corrections to translations of descriptions concerned with the 'large-memory' options. Could you please incorporate this change? Many thanks, -nori # #Translators, if you are not familiar with the PO format, gettext #documentation is worth reading, especially sections dedicated to #this format, e.g. by running: # info -n '(gettext)PO Files' # info -n '(gettext)Header Entry' # #Some information specific to po-debconf are available at #/usr/share/doc/po-debconf/README-trans # or http://www.debian.org/intl/l10n/po-debconf/README-trans # #Developers do not need to manually edit POT or PO files. # # msgid msgstr Project-Id-Version: lilo 1:22.8-6.3\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2008-10-27 11:51+0900\n PO-Revision-Date: 2008-11-05 11:26+0900\n Last-Translator: Hideki Yamane (Debian-JP) [EMAIL PROTECTED]\n Language-Team: Japanese [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. Type: note #. Description #: ../lilo.templates:1001 msgid LILO configuration msgstr LILO ã®è¨å® #. Type: note #. Description #: ../lilo.templates:1001 msgid It seems to be your first LILO installation. It is absolutely necessary to run liloconfig(8) when you complete this process and execute /sbin/lilo after this. msgstr LILO ã®ã¤ã³ã¹ãã¼ã«ã¯åãã¦ã®ããã§ãããã®ããã»ã¹ãçµäºããããliloconfig (8) ãå®è¡ãããããã /sbin/lilo ãå®è¡ãããã¨ãã絶対ã«å¿ è¦ã§ãã #. Type: note #. Description #: ../lilo.templates:1001 msgid LILO won't work if you don't do this. msgstr ãããå®è¡ããªã㨠LILO ã¯åä½ãã¾ããã #. Type: note #. Description #: ../lilo.templates:2001 msgid Deprecated parameters in LILO configuration msgstr LILO ã®è¨å®ã«å»æ¢äºå®ã®ãã©ã¡ã¼ã¿ãããã¾ã #. Type: note #. Description #: ../lilo.templates:2001 msgid Deprecated files have been found on your system. You must update the 'install=' parameter in your LILO configuration file (/etc/lilo.conf) in order to properly upgrade the package. msgstr ã·ã¹ãã å ã«å»æ¢äºå®ã®ãã¡ã¤ã«ãè¦ä»ããã¾ãããããã±ã¼ã¸ããã¡ãã¨ã¢ããã° ã¬ã¼ããããããLILO ã®è¨å®ãã¡ã¤ã« (/etc/lilo.conf) ä¸ã® 'install=' ãã©ã¡ã¼ ã¿ãæ´æ°ããå¿ è¦ãããã¾ãã #. Type: note #. Description #: ../lilo.templates:2001 msgid The new 'install=' options are: msgstr æ°ãã 'install=' ãªãã·ã§ã³: #. Type: note #. Description #: ../lilo.templates:2001 msgid new: install=bmp\n old: install=/boot/boot-bmp.b msgstr æ°: install=bmp\n æ§: install=/boot/boot-bmp.b #. Type: note #. Description #: ../lilo.templates:2001 msgid new: install=text\n old: install=/boot/boot-text.b msgstr æ°: install=text\n æ§: install=/boot/boot-text.b #. Type: note #. Description #: ../lilo.templates:2001 msgid new: install=menu\n old: install=/boot/boot-menu.b or boot.b msgstr æ°: install=menu\n æ§: install=/boot/boot-menu.b or boot.b #. Type: boolean #. Description #: ../lilo.templates:3001 msgid Do you want to add the large-memory option? msgstr large-memory ãªãã·ã§ã³ã追å ãã¾ãã? #. Type: boolean #. Description #: ../lilo.templates:3001 msgid By default, LILO loads the initrd file into the first 15MB of memory to avoid a BIOS limitation with older systems (earlier than 2001). msgstr ããã©ã«ãã§ã¯ãLILO ã¯å¤ãã·ã¹ãã (2001 å¹´ããåã®ãã®) ã§ã® BIOS å¶éãå é¿ãããããinitrd ãã¡ã¤ã«ãæåã® 15MB ã¡ã¢ãªå ã«ãã¼ãããããã«ãã¦ãã¾ ãã #. Type: boolean #. Description #: ../lilo.templates:3001 msgid However, with newer kernels the combination of kernel and initrd may not fit into the first 15MB of memory and so the system will not boot properly. It seems that the boot issues appear when the kernel+initrd combination is larger than 8MB. msgstr ããããæ°ããã«ã¼ãã«ã®å ´åãã«ã¼ãã«ã¨ initrd ã®çµã¿åãããæåã® 15MB ã¡ ã¢ãªã«ã¯åã¾ããªããªã£ã¦ãã·ã¹ãã ã¯æ£å¸¸ã«èµ·åããªãããããã¾ãããã«ã¼ãã« ï¼initrd ã 8MB ãã大ãããªã£ãå ´åã«ãã®èµ·ååé¡ãçºçããããã§ãã #. Type: boolean #. Description #: ../lilo.templates:3001 msgid If this machine has a recent BIOS without the 15MB limitation, you can add the 'large-memory' option to /etc/lilo.conf to instruct LILO to use more memory for passing the initrd to the kernel. You will need to re-run the 'lilo' command to make this option take effect. msgstr ãã®ãã·ã³ã® BIOS ãæè¿ã®ãã®ã§ 15MB å¶éãç¡ãå ´åã/etc/lilo.conf ã« 'large-memory' ãªãã·ã§ã³ãä»ãå ãããã¨ã§ãLILO ã initrd ãã«ã¼ãã«ã«æ¸¡ã
Bug#503634: aptitude in testing-proposed-updates depends on libept0 in sid
Hi, 2008/10/27 Deng Xiyue [EMAIL PROTECTED]: On Mon, Oct 27, 2008 at 09:27:45AM +0100, Christian Perrier wrote: Quoting Christian Perrier ([EMAIL PROTECTED]): Quoting Kobayashi Noritada ([EMAIL PROTECTED]): Package: aptitude Version: 0.4.11.10-1lenny1.1 Severity: normal Hi, aptitude 0.4.11.10-1lenny1.1 uploaded to testing-proposed-updates depends on libept0 (=0.5.26), but testing (lenny) currently ships libept0 0.5.22, making aptitude uninstallable: OK, my mistake. I built it in a sid chroot...:-( So, RM, you should not allow aptitude from t-p-u to enter testing. Failed attempt of mine:-( And, sorry for this, but I won't have time in the next days to do another attempt IMHO scheduling a binNMU should be enough to handle this. I think so after checking the source package. Is it possible to do binNMU for testing-proposed-updates against testing? I have checked http://wiki.debian.org/binNMU. Is a following line enough for the request? aptitude_0.4.11.10-1lenny1.1, Rebuild against testing fixes #503634, 1, i386 Thanks, -nori -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500641: gettext-el: C-j po-msgid-to-msgstr first error
tag 500641 + patch thanks Hi, I sent a patch for fixing this issue to upstream in May, but I have not got any replies yet... Please refer to a following message: http://lists.gnu.org/archive/html/bug-gnu-utils/2008-08/msg00019.html I repost a patch here. Thanks, -nori Index: gettext/gettext-tools/misc/po-mode.el === --- gettext.orig/gettext-tools/misc/po-mode.el 2008-05-29 17:12:52.0 +0900 +++ gettext/gettext-tools/misc/po-mode.el 2008-05-29 04:15:35.0 +0900 @@ -692,7 +692,6 @@ (defvar po-end-of-msgstr-form) (defvar po-end-of-entry) (defvar po-entry-type) -(defvar po-msgstr-form-flavor) ;; A few counters are usefully shown in the Emacs mode line. (defvar po-translated-counter) @@ -1900,11 +1899,9 @@ (defun po-get-msgstr-form () Extract and return the unquoted msgstr string. - (let ((flavor (po-get-msgstr-flavor)) -(string (po-extract-unquoted (current-buffer) + (let ((string (po-extract-unquoted (current-buffer) po-start-of-msgstr-form po-end-of-msgstr-form))) -(setq po-msgstr-form-flavor flavor) string)) (defun po-set-msgid (form) @@ -1935,7 +1932,7 @@ Returns 'nil' if the buffer has not been modified, for if the new msgstr described by FORM is merely identical to the msgstr already in place. (let ((string (po-eval-requoted form - po-msgstr-form-flavor + (po-get-msgstr-flavor) (eq po-entry-type 'obsolete (save-excursion (goto-char po-start-of-msgstr-form)
Bug#423315: xfonts-base: strange glyphs for codepoints between U+30D0 (KATAKANA LETTER BA) and U+30D3 (KATAKANA LETTER BI)
tag 423315 + patch thanks Hi maintainers, I have created a patch to remove 4 strange katakana glyphs mentioned in the report. Could you please check and apply this patch? This bug is annoying for Japanese users because Clean font is used in some web pages (e.g. http://diamond.jp/series/analysis/10003/?page=2 ), which results in users accidentally encountering these strange glyphs in exploring the Internet. It would be happy for us to see this bug fixed in lenny. Many thanks, -nori --- font-schumacher-misc-X11R7.0-1.0.0/clR6x12.bdf.orig 2006-02-22 10:33:58.0 +0900 +++ font-schumacher-misc-X11R7.0-1.0.0/clR6x12.bdf 2008-09-30 03:42:13.0 +0900 @@ -46,7 +46,7 @@ CAP_HEIGHT 8 X_HEIGHT 5 ENDPROPERTIES -CHARS 1197 +CHARS 1193 STARTCHAR char0 ENCODING 0 SWIDTH 480 0 @@ -22657,82 +22657,6 @@ 08 00 ENDCHAR -STARTCHAR uni30D0 -ENCODING 12496 -SWIDTH 480 0 -DWIDTH 6 0 -BBX 6 12 0 -3 -BITMAP -40 -F8 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -ENDCHAR -STARTCHAR uni30D1 -ENCODING 12497 -SWIDTH 480 0 -DWIDTH 6 0 -BBX 6 12 0 -3 -BITMAP -10 -F8 -00 -00 -00 -00 -00 -00 -00 -00 -00 -00 -ENDCHAR -STARTCHAR uni30D2 -ENCODING 12498 -SWIDTH 480 0 -DWIDTH 6 0 -BBX 6 12 0 -3 -BITMAP -20 -20 -20 -20 -20 -20 -20 -20 -20 -20 -20 -20 -ENDCHAR -STARTCHAR uni30D3 -ENCODING 12499 -SWIDTH 480 0 -DWIDTH 6 0 -BBX 6 12 0 -3 -BITMAP -00 -00 -20 -20 -20 -20 -20 -20 -20 -20 -00 -00 -ENDCHAR STARTCHAR fi ENCODING 64257 SWIDTH 480 0
Bug#500132: [release-notes] [l10n] CJK users need to install poppler-data (non-free) package to view PDF files with evince or so
Hi,
2008/9/26 Jens Seidel [EMAIL PROTECTED]:
On Fri, Sep 26, 2008 at 04:58:13PM +0900, Noritada Kobayashi wrote:
2008/9/26 Hideki Yamane [EMAIL PROTECTED]:
On Thu, 25 Sep 2008 17:57:07 +0200
Jens Seidel [EMAIL PROTECTED] wrote:
Please explain in more detail. I have no problem viewing
/usr/share/doc/Debian/quick-reference/quick-reference.ja.pdf.gz
using evince 2.22.2-2 without poppler-data. Also xpdf, ... works well.
Most of PDF files are not able to view without poppler-data.
To explain clearly, we cannot display fonts that are not embedded in
we == evince
or
we == Asian people???
Debian users or Free software users. ;-)
(And, fonts means CJK fonts.)
the displayed PDF file, although we have no problems viewing PDF files
in which CJK fonts are embedded.
This is basically due to the Adobe CMAP issue that CMAP files for
PS/PDF are not approved to be modified (and thus cannot be included in
the main section in Debian). This issue is problematic for (at
So there is a license problem. Isn't it strange that xpdf is able to
display the mentioned PDF file? Yep, it outputs
Error: Unknown character collection 'Adobe-Japan1'
but most (all?) glyphs are readable!
Hmm..., I confirmed that Xpdf can render Japanese text in that
document without xpdf-japanese. But it seems to be a correct
behaviour. I checked fonts inside that PDF with pdffonts (included in
xpdf-utils/poppler-utils packages) and found that fonts are embedded
in that PDF. So, what is curious is that Poppler cannot display fonts
that are embedded inside the PDF. Gee... I cannot explain now.
Instead, let's try to display documentations for Tokyo Debian study
meetings, such as:
http://tokyodebian.alioth.debian.org/pdf/debianmeetingresume200806.pdf
In this PDF, fonts are not embedded. With Evince and Inkscape
(without poppler-data), Japanese text only does not show up. With
Xpdf (without xpdf-japanese), Japanese text looks garbled. This is a
behaviour that I expected.
least) Japanese users for around ten years (sigh...) and we work
around the issue by additionally installing
cmap-adobe-{cns1,gb1,japan1,japan2,korea1}, gs-cjk-resource, and
xpdf-japanese for viewing PS/PDF files.
I don't have any of these packages installed in my Lenny system ...
(But I have KDE4 packages from experimental, maybe this includes free
font replacements?)
No, CMap is not a font; it is only a mapping. CJK-related
documentation[1] of Ghostscript explains that A CMap provides a map
from the multibyte character code to the CID of corresponding glyph,
under a specified encoding system. It is only a data like a map of
Unicode, but OTOH it is also a PostScript program (so, it is
impossible to create a free alternative by copying and pasting
uncopyrighted data...).
[1] http://pages.cs.wisc.edu/~ghost/doc/gnu/7.05/CJK.htm
Poppler, which is based on Xpdf, used to read CMAP files from the same
place as Xpdf did. So, we need only above packages to display CJK
fonts using Poppler. In recent versions, however, Poppler reads CMAPs
from its own path. So, we must additionally install poppler-data
which installs CMAPs for Poppler.
I also have poppler-data not installed.
# I think it would be better to make Xpdf and Poppler share CMAP files
# again, but at least we have no time for lenny. ;-)
Where does the the fonts used by xpdf come from? Does xpdf replace not found
commercial fonts with free ones? If yes, than evince should do it as
well.
According to strace xpdf opens /usr/lib/libfreetype.so.6, all other
opened files are probably less relevant.
Is this explanation comprehensible to you, Jens?
Related to this bug report, yes, it is. Thanks for the explanations.
I'm nevertheless curious why xpdf has no (obvious) problems.
So, from an inspection with pdffonts, what is curious is Poppler,
which can display some PDF files with fonts embedded but cannot do so
other ones. Thank you for noticing this fact. I'll check more.
Thanks,
-nori
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500132: [release-notes] [l10n] CJK users need to install poppler-data (non-free) package to view PDF files with evince or so
Hi,
2008/9/26 Hideki Yamane [EMAIL PROTECTED]:
On Thu, 25 Sep 2008 17:57:07 +0200
Jens Seidel [EMAIL PROTECTED] wrote:
Please explain in more detail. I have no problem viewing
/usr/share/doc/Debian/quick-reference/quick-reference.ja.pdf.gz
using evince 2.22.2-2 without poppler-data. Also xpdf, ... works well.
Most of PDF files are not able to view without poppler-data.
To explain clearly, we cannot display fonts that are not embedded in
the displayed PDF file, although we have no problems viewing PDF files
in which CJK fonts are embedded.
# I don't know which is the majority, whether embedding fonts in PDF
# files or not, but I usually do not embed fonts when creating PDF
# files with pLaTeX + dvipdfmx. ;-)
This is basically due to the Adobe CMAP issue that CMAP files for
PS/PDF are not approved to be modified (and thus cannot be included in
the main section in Debian). This issue is problematic for (at
least) Japanese users for around ten years (sigh...) and we work
around the issue by additionally installing
cmap-adobe-{cns1,gb1,japan1,japan2,korea1}, gs-cjk-resource, and
xpdf-japanese for viewing PS/PDF files.
Poppler, which is based on Xpdf, used to read CMAP files from the same
place as Xpdf did. So, we need only above packages to display CJK
fonts using Poppler. In recent versions, however, Poppler reads CMAPs
from its own path. So, we must additionally install poppler-data
which installs CMAPs for Poppler.
# I think it would be better to make Xpdf and Poppler share CMAP files
# again, but at least we have no time for lenny. ;-)
Is this explanation comprehensible to you, Jens?
Many thanks,
-nori
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490305: remove kazehakase?
reassign 490305 libglib2-ruby1.8 0.17.0~rc1-5
tag 490305 + patch
thanks
Hi Lucas,
2008/9/17 Lucas Nussbaum [EMAIL PROTECTED]:
On 09/09/08 at 08:39 +0200, Lucas Nussbaum wrote:
2008/9/7 Thomas Viehmann:
Noritada Kobayashi wrote:
Please wait a little while. This issue may not be resulted from a bug
inside Kazehakase.
I can't speak for the release team, but I'd like to point out that a
little while is more likely be measured in lower single-digit number of
days than weeks or months, so you should hurry indeed.
All right. Now I reassign the bug to ruby1.8.
I don't think it's a bug in ruby1.8. Garbage collection changed a bit
recently, which triggered some bugs in several libs (see #494515 for
example). If it's not a bug in kazehakase itself, it's more likely to be
a bug in libgtk-ruby1.8, since it happens while requiring that lib in
/usr/share/kazehakase/ext/ruby/kazehakase-init-pre.rb.
FWIW, I tried with libgtk2-ruby1.8 0.17.0~rc1-5, but it doesn't fix the
problem.
Based on the above info, I'm reassigning to libgtk2-ruby1.8. Feel free
to reassign to ruby1.8 if it turns out that it's a bug in ruby1.8. But
it doesn't sound like the most likely candidate.
I tried to work on this a bit more.
In a pure lenny chroot, on a different machine, I can't reproduce the
bug (but I still reproduce it on my laptop). I found no proof that it
isn't a bug in kazehakase, but in ruby or ruby-gnome2, so I'm
reassigning to kazehakase.
Thank you very much for working on that issue. It seems that time has
come for us to close the bug. :-)
Today, Kouhei Sutou, an upstream developer of both Ruby/GNOME2 and
Kazehakase's Ruby extension, finally figured out that the issue is
caused by a bug in libglib2-ruby1.8. He fixed the bug in the
repository of Ruby/GNOME2 at r3312. So, I created an attached patch
based on that revision, rebuilt the ruby-gnome2 package with it
applied, and confirmed that the issue is no more reproduced.
It took a bit long time since Kouhei couldn't reproduce the bug on his
machine (Debian sid, amd64). I must thank him for working on the
issue on such a condition.
Thanks,
-nori
Index: ruby-gnome2-0.17.0~rc1/ChangeLog
===
--- ruby-gnome2-0.17.0~rc1.orig/ChangeLog 2008-09-18 10:53:22.0 +0900
+++ ruby-gnome2-0.17.0~rc1/ChangeLog 2008-09-18 10:55:05.0 +0900
@@ -1,3 +1,8 @@
+2008-09-18 Kouhei Sutou [EMAIL PROTECTED]
+
+ * src/rbglib_maincontext.c: use VALUE not guint to
+ rb_set_end_proc()'s data. This will fix Debian bug [#490305].
+
2008-05-23 Kouhei Sutou [EMAIL PROTECTED]
* run-tests.rb: don't use open3, just output to stdout and stderr.
Index: ruby-gnome2-0.17.0~rc1/glib/src/rbglib_maincontext.c
===
--- ruby-gnome2-0.17.0~rc1.orig/glib/src/rbglib_maincontext.c 2008-09-18 10:53:22.0 +0900
+++ ruby-gnome2-0.17.0~rc1/glib/src/rbglib_maincontext.c 2008-09-18 10:53:40.0 +0900
@@ -753,6 +753,14 @@
}
#endif
+#ifndef HAVE_RB_THREAD_BLOCKING_REGION
+static void
+ruby_source_remove(VALUE tag)
+{
+g_source_remove(NUM2UINT(tag));
+}
+#endif
+
void
Init_glib_main_context()
{
@@ -831,7 +839,7 @@
source = ruby_source_new();
tag = g_source_attach(source, NULL);
g_source_unref(source);
-rb_set_end_proc((void (*)(VALUE))g_source_remove, (VALUE)tag);
+rb_set_end_proc(ruby_source_remove, UINT2NUM(tag));
}
#endif
}
Bug#490305: remove kazehakase?
reassign 490305 ruby1.8 thanks Hi, This bug may be a GC bug of Ruby 1.8. Also, this is reported as Bug 456816[1] on Fedora's BTS and the report shows us that the bug got unreproducible with ruby 1.8.6.287-1.fc10. So, I reassign the bug to ruby1.8. Please change the severity if it is not appropriate. Still investigating the bug in the upstream mailing list of Kazehakase[2]. [1] https://bugzilla.redhat.com/show_bug.cgi?id=456816 [2] http://lists.sourceforge.jp/mailman/archives/kazehakase-devel/2008-September/thread.html#2838 (in Japanese) 2008/9/7 Thomas Viehmann: Noritada Kobayashi wrote: Please wait a little while. This issue may not be resulted from a bug inside Kazehakase. I can't speak for the release team, but I'd like to point out that a little while is more likely be measured in lower single-digit number of days than weeks or months, so you should hurry indeed. All right. Now I reassign the bug to ruby1.8. I'd like to see the bug fixed in lenny and I try to get a patch in 3 days. Thanks for comments. Thanks, -nori -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490305: remove kazehakase?
Hi, 2008/9/7 Thomas Viehmann [EMAIL PROTECTED]: at almost two months #490305 (segfault on startup) isn't exactly a brand new bug, yet there has been no maintainer response. It has no reverse dependencies and only 95 votes in popcon. As such it appears that kazehakase is a removal candidate. This bug occurs in kazehakase running require 'kazehakase-init-pre' from its C code ext/ruby/kz-rb-ext.c. However, /usr/share/kazehakase/ext/ruby/kazehakase-init-pre.rb (and other code in kazehakase) may not have a problem. I figured out that by inserting 'puts' to many places in Ruby libraries. Here is the result: $ kazehakase before requiring gtk2 before requiring gtk2/base before requiring glib2 before requiring gettext before requiring locale before requiring locale/object zsh: segmentation fault kazehakase $ sudo kazehakase before requiring gtk2 before requiring gtk2/base before requiring glib2 before requiring gettext before requiring locale before requiring locale/object inside locale/object after requiring locale/object after requiring locale after requiring gettext after requiring glib2 after requiring gtk2/base after requiring gtk2 (and kazehakase runs correctly...) Please wait a little while. This issue may not be resulted from a bug inside Kazehakase. Thanks, -nori -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494816: Patch to fix the Yes/No confirmation messages issue in ja.po
unmerge 494816 tags 494816 + patch thanks Hi, This is a patch to fix ja.po in the second way that Kenshi Muto suggested. #475802 should be separately fixed (in lenny+1) and I'll provide a trial patch separately. Could you please find and apply the attachment? Thanks, -nori # HG changeset patch # User Noritada Kobayashi [EMAIL PROTECTED] # Date 1220177460 -32400 # Node ID a53c4170d9e8908c697b68a58d2e48965c59ea18 # Parent 1e07d3be4389d78b7b8404a29534ca045c1993b0 po/ja.po: Fix the cannot-input-confirmation-messages issue. (Closes: #494816) diff -r 1e07d3be4389 -r a53c4170d9e8 po/ja.po --- a/po/ja.po Sat Aug 30 11:24:56 2008 +0900 +++ b/po/ja.po Sun Aug 31 19:11:00 2008 +0900 @@ -1339,11 +1339,11 @@ #: src/cmdline/cmdline_prompt.cc:720 msgid Yes -msgstr ã¯ã (Y) +msgstr Yes #: src/cmdline/cmdline_prompt.cc:720 msgid No -msgstr ããã (N) +msgstr No #: src/cmdline/cmdline_prompt.cc:724 #, c-format @@ -4763,7 +4763,7 @@ #: src/pkg_item.cc:61 msgid Yes, I am aware this is a very bad idea -msgstr ã¯ãããããé常ã«ã¾ããèãã ã¨ããã£ã¦ãã¾ã +msgstr Hai, korega totemo yokunai kotodato wakatteimasu #: src/pkg_item.cc:86 #, c-format
Bug#475802: Patch to alert translators to non-ASCII confirmation messages
tags 475802 + patch
thanks
Hi,
This is a (trial) patch to alert translators to usage of non-ASCII
characters in confirmation messages. Could you please review and
apply it with hg import if it's good?
The changelog is as follows (and available in the patch):
[[[
Alert translators to usage of non-ASCII characters in confirmation
messages. (Closes: #475802)
Since users (especially CJK users) should be able to input confirmation
messages without input methods, translations of those messages should
include nothing but ASCII characters. This trial patch inserts comments
to alert translators to such cases. Also, this patch changes a
confirmation message Yes and No to YES and NO respectively so
that they differ from menu dialog messages Yes and No.
]]]
This patch may be for lenny+1, not lenny, since it changes a message.
Also, the message change will result in unlocalized Yes and No
dialog messages since they are marked for translation in cwidget but
that library does not have real po/mo files.
Many thanks,
-nori
# HG changeset patch
# User Noritada Kobayashi [EMAIL PROTECTED]
# Date 1220063096 -32400
# Node ID 1e07d3be4389d78b7b8404a29534ca045c1993b0
# Parent b9aed5b27b3a336d0a69f6a9cf7341a32eb5eddc
Alert translators to usage of non-ASCII characters in confirmation messages. (Closes: #475802)
Since users (especially CJK users) should be able to input confirmation
messages without input methods, translations of those messages should
include nothing but ASCII characters. This trial patch inserts comments
to alert translators to such cases. Also, this patch changes a
confirmation message Yes and No to YES and NO respectively so
that they differ from menu dialog messages Yes and No.
diff -r b9aed5b27b3a -r 1e07d3be4389 src/cmdline/cmdline_prompt.cc
--- a/src/cmdline/cmdline_prompt.cc Mon Aug 25 16:10:25 2008 +0200
+++ b/src/cmdline/cmdline_prompt.cc Sat Aug 30 11:24:56 2008 +0900
@@ -717,7 +717,10 @@
}
- const string okstr=_(Yes), abortstr=_(No);
+ // ForTranslators: This string is a confirmation message, which
+ // users (especially CJK users) should be able to input without
+ // input methods. Please include nothing but ASCII characters.
+ const string okstr=_(YES), abortstr=_(NO);
while(1)
{
diff -r b9aed5b27b3a -r 1e07d3be4389 src/pkg_item.cc
--- a/src/pkg_item.cc Mon Aug 25 16:10:25 2008 +0200
+++ b/src/pkg_item.cc Sat Aug 30 11:24:56 2008 +0900
@@ -58,6 +58,9 @@
using namespace widgets;
}
+// ForTranslators: This string is a confirmation message, which users
+// (especially CJK users) should be able to input without input
+// methods. Please include nothing but ASCII characters.
static const char *confirm_str=N_(Yes, I am aware this is a very bad idea);
static void try_delete_essential(wstring s,
Bug#496064: lurker: [INTL:ja] Japanese debconf templates translation
Hi, I've got some review comments and made improvements to ja.po. Could you please include this one instead? Thanks, -nori # Japanese debconf templates translation for lurker. # Copyright (C) 2007-2008 Noritada Kobayashi # This file is distributed under the same license as the lurker package. # msgid msgstr Project-Id-Version: lurker (debconf) 2.1-12.1\n Report-Msgid-Bugs-To: [EMAIL PROTECTED] POT-Creation-Date: 2008-02-05 11:15+0100\n PO-Revision-Date: 2008-08-25 03:10+0900\n Last-Translator: Noritada Kobayashi [EMAIL PROTECTED]\n Language-Team: Japanese [EMAIL PROTECTED]\n MIME-Version: 1.0\n Content-Type: text/plain; charset=UTF-8\n Content-Transfer-Encoding: 8bit\n #. Type: boolean #. Description #: ../templates:1001 msgid Configure apache2 automatically for lurker? msgstr apache2 ã« lurker ç¨ã®è¨å®ãèªåçã«è¡ãã¾ãã? # FIXME: Are /etc/apache*/conf.d examples of inclue dir? #. Type: boolean #. Description #: ../templates:1001 msgid It is possible to configure your apache2 webserver automatically in the way that lurker archive pages are directly available at http://localhost/lurker. This requires apache2 to provide an include dir in /etc/apache2/conf.d, like the debian apache2 package does. msgstr lurker ã®ã¢ã¼ã«ã¤ããã¼ã¸ã http://localhost/lurker ã§ç´æ¥é²è¦§å¯è½ã«ããã ããapache2 ã¦ã§ããµã¼ããèªåçã«è¨å®ã§ãã¾ãããã®ããã«ã¯ãDebian ã® apache2 ããã±ã¼ã¸ã®ããã«ãapache2 ã /etc/apache2/conf.d ã« include ãã£ã¬ ã¯ããªãæä¾ãã¦ããå¿ è¦ãããã¾ãã #. Type: note #. Description #: ../templates:2001 msgid No webserver will be configured automatically msgstr ã©ã®ã¦ã§ããµã¼ãã«ãèªåçãªè¨å®ãè¡ãã¾ãã #. Type: note #. Description #: ../templates:2001 msgid It seems like you have not installed a supported webserver. The script did not detect an apache2 include directory at /etc/apache2/conf.d. Therefore, the script did not configure a webserver, and you have to configure manually any webserver that you want to use with lurker. msgstr ãµãã¼ãããã¦ããã¦ã§ããµã¼ããã¤ã³ã¹ãã¼ã«ããã¦ããªãããã§ãã/etc/ apache2/conf.d ã«ãã apache2 ã® include ãã£ã¬ã¯ããªãã¹ã¯ãªããã§æ¤åºã§ãã¾ ããã§ããããã®ããããã®ã¹ã¯ãªããã§ã¯ã¦ã§ããµã¼ãã®è¨å®ãã§ããªãã®ã§ã lurker ã使ç¨ããã¦ã§ããµã¼ãã®è¨å®ã¯æåã§è¡ããªããã°ãªãã¾ããã #. Type: string #. Description #: ../templates:3001 msgid Archive Name: msgstr ã¢ã¼ã«ã¤ãå: #. Type: string #. Description #: ../templates:3001 msgid The name that lurker uses to refer to the archive. msgstr lurker ãã¢ã¼ã«ã¤ããåç §ããã¨ãã«ä½¿ç¨ããååã§ãã #. Type: string #. Description #: ../templates:4001 msgid Admin Name: msgstr 管çè å: #. Type: string #. Description #: ../templates:4001 msgid This is the administrative contact information displayed at the bottom-right of generated pages. You should probably set it to something useful. msgstr ããã¯ãçæããããã¼ã¸ã®æä¸é¨å³å´ã«è¡¨ç¤ºããã管çè ã®é£çµ¡å ã§ããä½ãæç¨ ãªæ å ±ãè¨å®ããã¨ããã§ãããã #. Type: string #. Description #: ../templates:5001 msgid Admin Address: msgstr 管çè ã®ã¢ãã¬ã¹ #. Type: password #. Description #: ../templates:6001 msgid Password for the lurker system group: msgstr lurker ã·ã¹ãã ã°ã«ã¼ãã®ãã¹ã¯ã¼ã: #. Type: password #. Description #: ../templates:6001 msgid A password for the lurker system group needs to be set. It is requested when deleting mail from archive through the web button. You can change the password later by running 'gpasswd lurker'. msgstr lurker ã·ã¹ãã ã°ã«ã¼ãã®ãã¹ã¯ã¼ããè¨å®ããå¿ è¦ãããã¾ãããã¹ã¯ã¼ãã¯ã ã¦ã§ããã¼ã¸ã®ãã¿ã³ãç¨ãã¦ã¢ã¼ã«ã¤ãããã¡ã¼ã«ãåé¤ããéã«å¿ è¦ã«ãªãã¾ ãã'gpasswd lurker' ãå®è¡ãã¦ããã¹ã¯ã¼ããå¾ã§å¤æ´ãããã¨ãå¯è½ã§ãã # FIXME: Do not mark for translation! #~ msgid apache, apache2, apache-ssl, apache-perl #~ msgstr apache, apache2, apache-ssl, apache-perl #~ msgid Servers that you would like to be configured automatically: #~ msgstr èªåçã«è¨å®ãè¡ããµã¼ã: # FIXME: Separate options. #~ msgid automatic, manual #~ msgstr èªå, æå # FIXME: It seems question and options are not corresponding well #~ msgid Upgrade the lurker database automatically: #~ msgstr lurker ã®ãã¼ã¿ãã¼ã¹ãèªåçã«ã¢ããã°ã¬ã¼ããã¾ãã? # FIXME: What is [1] and [2]? # FIXME: What is a second time? #~ msgid #~ The database format changed with this release. A script is provideed to #~ automatically upgrade your database. It can be found at /usr/share/doc/ #~ lurker/lurker-regenerate. Invoke it without arguments for manual database
Bug#494816: Comments on the Yes/No-translation issue from aptitude's Japanese translator
Hi,
[#475802]
Deng Xiyue wrote:
For Chinese user, Yes will be translated to 是, which will be used
for the is_ok comparison. Meanwhile, 是 will not be able to input
when input method is unavailable, which in turn isn't installed by
default install settings.
Yeah, it's true for Japanese users. Yes and No are respectively
はい (hai) and いいえ (iie) in Japanese. Since they can be input
only via input methods, however, softwares usually provide a prompt
like Yes/No or Y/N to us. Forcing users to input はい is not a
good idea.
This is quite a dilemma for users using non-en_US based locales,
especially CJK-based locales. I'd propose such usage to be changed to
a letter-based comparison, as Y for Yes and N for No or something like
that.
I think this solution is a little bit extreme, since there are many
non-English locales and they cannot be considered in one group. Take
a look at German for example. Since Yes and No are Ja and
Nein in German, people are familiar with J/N prompts instead of Y/N
prompts. Forcing users to input Ja does not have a problem.
Although I don't know about other Western cultures well, I think most
of Western languages, like German, does not have any issues since they
are composed of alphabets.
[#494816]
Hideki Yamane wrote;
Then, how can we continue? ...we should enter localized YES message,
such as ' はい (Y) ' (Japanese YES message) by copypaste, '(' and ')'
are also needed to do. Umm.
See attached screenshot_aptitude-localized-continue01.png file.
Translating Yes and No to はい (Y) and いいえ (N) is an idea
from Ubuntu's aptitude package. These are good for Y/N dialog strings
indeed, but have a by-product when used as a command line prompt as
you have shown, sigh...
This confuses non-English users, they want to continue by entering just
Yes, but they can't do that. So could you try to give us any fix or
workaround for this issue by default? Needs help.
Not all non-English users as I described above.
Kenshi Muto wrote:
I made two patches.
- - cmdline_prompt.patch
This patch lets aptitude allows Y*/y*/N*/n* also for Yes/No prompt
in addition to the translated Yes/No.
I think this is better patch than later one.
One problem I can imagine is that this check may go to failure
if local language means Y* for No or N* for Yes, but it will be
very rare and I didn't see it in current po files.
It seems to be a little bit confusing that users can go ahead by
inputting Y although aptitude asks users to input はい (Y). Also,
aptitude wants to make confirmation here by forcing users to input
some longer strings instead of forcing to press just one key. So, I
consider the latter to be a better workaround.
- - japo-yesno.patch
This patch reverts Yes/No translation of Japanese po file.
If you Daniel won't touch the code, please apply this one.
(But you'll lose a chance to close #475802 :) )
Since it's frozen for lenny now, I prefer this translation
workaround (Actually, we had resolved similar Y/N prompt issue
(#401598) by changing translations likewise under the freeze for
etch...). Yes and No can be left untranslated as most of Japanese
can understand what they mean.
This issue is a little bit complex since Yes and No messages are
used in two ways: as dialog messages on cwidget side and as
confirmation messages on aptitude side. Since dialogs work good, I
propose a solution to add another string for confirmation input and
allot one role to one message like this:
- _(Yes), _(No): strings displayed on dialogs (coded on cwidget
side). _(yes_key) and _(no_key) coded on aptitude side are also
used for keyboard operations. CJK translators can translate Yes
and No to messages with their CJK characters and specify y and
n to keyboard operations.
- _(YES), _(NO): string for confirmation (coded on aptitude side).
CJK translators may well have to make these translations only have
ASCII characters so that users can input these messages correctly
without input methods.
However, it's a post-lenny solution, IMHO.
Many thanks,
-nori
