Bug#1067404: ITP: fonts-pretendard -- Fine tuned derived font for Korean body text
Package: wnpp Severity: wishlist Owner: Changwoo Ryu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-pretendard Version : 1.3.9 Upstream Contact: https://github.com/orioncactus/pretendard * URL : https://github.com/orioncactus/pretendard * License : SIL OFL 1.1 Programming Lang: Description : Fine tuned derived font for Korean body text This package contains a font family Pretendard, which is derived from three different fonts; Source Han Sans, Inter and M PLUS 1P. The widths of characters and distances between characters are tuned for good looking Korean body text, especially when it's mixed with English text. - Note: used for DebConf24 logo text
Bug#1063354: ITP: h2orestart -- LibreOffice import filter for Hancom HWP document
Package: wnpp Severity: wishlist Owner: Changwoo Ryu X-Debbugs-Cc: debian-de...@lists.debian.org, debian-l10n-kor...@lists.debian.org * Package name: h2orestart Version : 0.6.0 Upstream Contact: https://github.com/ebandal/H2Orestart * URL : https://github.com/ebandal/H2Orestart * License : GPL-3.0-or-later Programming Lang: Java Description : LibreOffice import filter for Hancom HWP document This enhances LibreOffice Writer to read Hancom Office documents, as known as HWP, which are widely used especially by South Korean government organizations. . It supports the HWP v5 format or the HWPx format only. It doesn't work for the ancient HWP v3 format.
Bug#1061202: RM: nautilus-filename-repairer -- ROM; FTBFS, Dead upstream
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: nautilus-filename-repai...@packages.debian.org, debian-l10n-kor...@lists.debian.org Control: affects -1 + src:nautilus-filename-repairer Please remove nautilus-filename-repairer. It fails to build with recent nautilus (#1017623) and upstream stopped maintenance.
Bug#1034868: grub2: [INTL:ko] Korean translation update for debconf templates
Package: grub2 Severity: wishlist Tags: patch l10n Hello, This updates the Korean translation for the debconf templates. -- System Information: Debian Release: 12.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.1.0-7-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages grub2 depends on: ii grub-common 2.06-12 pn grub-pc grub2 recommends no packages. grub2 suggests no packages. # Changwoo Ryu , 2014, 2017, 2023. # msgid "" msgstr "" "Project-Id-Version: grub_debian\n" "Report-Msgid-Bugs-To: gr...@packages.debian.org\n" "POT-Creation-Date: 2023-04-23 20:27+\n" "PO-Revision-Date: 2023-04-26 18:55+0900\n" "Last-Translator: Changwoo Ryu \n" "Language-Team: Korean \n" "Language: ko\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: boolean #. Description #: ../grub-pc.templates.in:2001 msgid "Chainload from menu.lst?" msgstr "menu.lst에서 단계별로 읽어들이시겠습니까?" #. Type: boolean #. Description #: ../grub-pc.templates.in:2001 msgid "GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub." msgstr "" "GRUB 업그레이드 스크립트에서 /boot/grub 안의 GRUB 과거 버전 설정을 발견했습니" "다." #. Type: boolean #. Description #: ../grub-pc.templates.in:2001 msgid "" "In order to replace the Legacy version of GRUB in your system, it is " "recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image " "from your existing GRUB Legacy setup. This step can be automatically " "performed now." msgstr "" "시스템의 GRUB 구버전을 현재 GRUB 2로 바꾸려면, /boot/grub/menu.lst 파일을 조" "정해 기존 GRUB 과거 버전 설정에서 GRUB 2 부팅 이미지를 읽어들이는 방법을 추천" "합니다. 이 단계는 자동으로 수행할 수 있습니다." #. Type: boolean #. Description #: ../grub-pc.templates.in:2001 msgid "" "It's recommended that you accept chainloading GRUB 2 from menu.lst, and " "verify that the new GRUB 2 setup works before it is written to the MBR " "(Master Boot Record)." msgstr "" "먼저 menu.lst에서 단계별로 GRUB 2를 읽어들이게 하고, 그 다음에 GRUB 2 설정이 " "동작하는지 확인한 다음 MBR(마스터 부트 레코드)에 GRUB 2를 설치하는 걸 추천합" "니다." #. Type: boolean #. Description #: ../grub-pc.templates.in:2001 msgid "" "Whatever your decision, you can replace the old MBR image with GRUB 2 later " "by issuing the following command as root:" msgstr "" "어떻게 선택하든, 나중에 root로 다음 명령을 실행하면 과거 MBR 이미지를 GRUB 2 " "이미지로 바꿀 수 있습니다." #. Type: multiselect #. Description #. Type: multiselect #. Description #: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001 msgid "GRUB install devices:" msgstr "GRUB 설치 장치:" #. Type: multiselect #. Description #: ../grub-pc.templates.in:3001 msgid "" "The grub-pc package is being upgraded. This menu allows you to select which " "devices you'd like grub-install to be automatically run for, if any." msgstr "" "grub-pc 패키지를 업그레이드하는 중입니다. 이 메뉴에서 (실행할 장치가 있다면) " "어떤 장치에 대해 grub-install을 자동으로 실행할지 설정합니다." #. Type: multiselect #. Description #: ../grub-pc.templates.in:3001 msgid "" "Running grub-install automatically is recommended in most situations, to " "prevent the installed GRUB core image from getting out of sync with GRUB " "modules or grub.cfg." msgstr "" "대부분의 상황에서는 grub-install 자동 실행을 추천합니다. 그래야 설치한 GRUB " "이미지가 GRUB 모듈이나 grub.cfg 파일과 어긋나지 않습니다." #. Type: multiselect #. Description #. Type: multiselect #. Description #: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001 msgid "" "If you're unsure which drive is designated as boot drive by your BIOS, it is " "often a good idea to install GRUB to all of them." msgstr "" "어떤 드라이브를 BIOS에서 사용할 부팅 드라이브로 설정할지 잘 모르겠다면, GRUB" "을 모든 드라이버에 설치하는 것도 좋은 방법입니다." #. Type: multiselect #. Description #. Type: multiselect #. Description #: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001 msgid "" "Note: it is possible to install GRUB to partition boot records as well, and " "some appropriate partitions are offered here. However, this forces GRUB to " "use the blocklist mechanism, which makes it less reliable, and therefore is " "not recommended." msgstr "" "주의: GRUB을 파티션 부트 레코드에 설치할 수도
Bug#1027986: glibc: [l10n] Updated Korean debconf templates translation
Package: glibc Severity: wishlist Tags: l10n patch Here is the Korean translation update of the glibc debconf templates -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-6-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled # Korean translations for glibc package # glibc 패키지에 대한 한국어 번역문. # Copyright (C) 2007 THE glibc'S COPYRIGHT HOLDER # This file is distributed under the same license as the glibc package. # Sunjae Park , 2007 - 2008. # Changwoo Ryu , 2023. # msgid "" msgstr "" "Project-Id-Version: glibc\n" "Report-Msgid-Bugs-To: gl...@packages.debian.org\n" "POT-Creation-Date: 2023-01-03 21:34+0100\n" "PO-Revision-Date: 2023-01-06 00:11+0900\n" "Last-Translator: Changwoo Ryu \n" "Language-Team: Korean \n" "Language: ko\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0;\n" #. Type: multiselect #. Choices #: ../debhelper.in/locales.templates:1001 msgid "All locales" msgstr "모든 로캘" #. Type: multiselect #. Description #: ../debhelper.in/locales.templates:1002 msgid "Locales to be generated:" msgstr "생성할 로캘 목록:" #. Type: multiselect #. Description #: ../debhelper.in/locales.templates:1002 msgid "" "Locales are a framework to switch between multiple languages and allow users " "to use their language, country, characters, collation order, etc." msgstr "" "로캘이란 여러 언어 중에서 선택하여 사용자들이 자신의 언어, 국가, 문자, 정렬순" "서 등을 사용할 수 있도록 해주는 구성틀입니다." #. Type: multiselect #. Description #: ../debhelper.in/locales.templates:1002 msgid "" "Please choose which locales to generate. UTF-8 locales should be chosen by " "default, particularly for new installations. Other character sets may be " "useful for backwards compatibility with older systems and software." msgstr "" "생성하고자 하는 로캘을 선택하여 주십시오. 기본적으로는 UTF-8 로캘을 선택하시" "고, 특히 새로 설치하는 시스템에서는 더더욱 이를 선택하십시오. 기존 시스템이" "나 소프트웨어와의 역호환성을 위해서는 다른 문제셋을 선택하셔도 됩니다." #. Type: select #. Choices #: ../debhelper.in/locales.templates:2001 msgid "None" msgstr "없음" #. Type: select #. Description #: ../debhelper.in/locales.templates:2002 msgid "Default locale for the system environment:" msgstr "시스템 환경의 기본 로캘:" #. Type: select #. Description #: ../debhelper.in/locales.templates:2002 msgid "" "Many packages in Debian use locales to display text in the correct language " "for the user. You can choose a default locale for the system from the " "generated locales." msgstr "" "데비안에 있는 많은 꾸러미들은 사용자에게 맞는 언어로 출력하기 위해 로캘을 사" "용합니다. 생성된 로캘 중에서 시스템의 기본 로캘로 사용할 로캘을 선택하실 수 " "있습니다." #. Type: select #. Description #: ../debhelper.in/locales.templates:2002 msgid "" "This will select the default language for the entire system. If this system " "is a multi-user system where not all users are able to speak the default " "language, they will experience difficulties." msgstr "" "이 선택은 시스템 전체의 기본 언어를 결정합니다. 기본 언어를 사용할 수 없는 사" "용자도 있는 복수 사용자 시스템일 경우에는 그 사용자들이 시스템 사용에 어려움" "을 겪으실 수 있습니다." #. Type: boolean #. Description #: ../debhelper.in/libc.templates:1001 msgid "Do you want to upgrade glibc now?" msgstr "지금 glibc를 업그레이드 하시겠습니까?" #. Type: boolean #. Description #: ../debhelper.in/libc.templates:1001 msgid "" "Running services and programs that are using NSS need to be restarted, " "otherwise they might not be able to do lookup or authentication any more. " "The installation process is able to restart some services (such as ssh or " "telnetd), but other programs cannot be restarted automatically. One such " "program that needs manual stopping and restart after the glibc upgrade by " "yourself is xdm - because automatic restart might disconnect your active X11 " "sessions." msgstr "" "NSS를 사용중인 서비스와 프로그램들을 다시 시작시키지 않으면 색인 작업이나 인" "증 작업을 더 이상 사용할 수 없게 됩니다. ssh이나 telnetd 등의 서비스들 일부" "는 설치 과정이 다시 시작을 시킵니다만, 자동으로 다시 시작시키지 못하는 프로그" "램도 있습니다. glibc 업그레이드 후 사용자가 직접 다시 정지시킨 후 다시 시작시" "켜야 하는 대표적인 프로그램으로 xdm이 있습니다. 자동으로 다시 시작을 시키면 " "사용중인 X11 세션을 중지시킬 수 있기 때문입니다." #. Type: boolean #. De
Bug#1027983: tzdata: [l10n] Updated Korean translation of debconf templates
Package: tzdata Severity: wishlist Tags: l10n patch Here is the updated Korean translation of the tzdata debconf templates. # tzdata debconf templates translation # This file is distributed under the same license as the tzdata package. # Changwoo Ryu , 2021-2022. # msgid "" msgstr "" "Project-Id-Version: tzdata\n" "Report-Msgid-Bugs-To: tzd...@packages.debian.org\n" "POT-Creation-Date: 2023-01-02 11:15+0100\n" "PO-Revision-Date: 2023-01-05 23:33+0900\n" "Last-Translator: Changwoo Ryu \n" "Language-Team: Debian L10N Korean \n" "Language: Korean\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Africa" msgstr "아프리카" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "America" msgstr "아메리카" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Antarctica" msgstr "남극" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Australia" msgstr "오스트레일리아" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Arctic" msgstr "북극" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Asia" msgstr "아시아" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Atlantic" msgstr "대서양" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Europe" msgstr "유럽" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Indian" msgstr "인도양" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:1001 ../tzdata.templates:12001 msgid "Pacific" msgstr "태평양" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "US" msgstr "미국" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Etc" msgstr "기타" #. Type: select #. Description #: ../tzdata.templates:1002 msgid "Geographic area:" msgstr "지리적 지역:" #. Type: select #. Description #: ../tzdata.templates:1002 msgid "" "Please select the geographic area in which you live. Subsequent " "configuration questions will narrow this down by presenting a list of " "cities, representing the time zones in which they are located." msgstr "" "거주하고 있는 지리적 지역을 선택하십시오. 이후의 설정 질문에서는 지역을 특정" "하려고 도시의 목록을 표시합니다. 표시하는 도시는 도시 위치의 표준 시간대를 나" "타냅니다." #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:2001 msgid "Abidjan" msgstr "아비장" #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:2001 msgid "Accra" msgstr "아크라" #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:2001 msgid "Addis_Ababa" msgstr "아디스아바바" #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdat
Bug#1027418: autopkgtest failure - iconv issue?
Control: severity -1 normal Control: notfound -1 0.7.92-1 This bug appears to occur only in an incomplete chroot environment. Please check your chroot again. You can reopen if it still occurs in a general environment.
Bug#1027417: hunspell-dict-ko: missing test dependecy: python3
Control: severity -1 normal 2022년 12월 31일 (토) 오후 5:21, Rene Engelhard 님이 작성: > > Source: hunspell-dict-ko > Version: 0.7.92-1 > Severity: important > > Dear Maintainer, > > I tried to look after the hunspell-dict-ko failure and created a minimal > chroot + installing the test > dependencies for that. > > I got: > > rene@frodo:~/hunspell-dict-ko-0.7.92$ make hosttest > HOST_DICT_PATH=/usr/share/hunspell/ko > make: python3: No such file or directory > make -C tests test DICT=/usr/share/hunspell/ko > make[1]: Entering directory '/home/rene/hunspell-dict-ko-0.7.92/tests' > echo | hunspell -d /usr/share/hunspell/ko | head -1 > Hunspell 1.7.1 - hunspell-dict-ko 0.7.92 (requires Hunspell 1.3.1) > https://spellcheck-ko.github.io/ > python3 checkhunspellversion.py > make[1]: python3: No such file or directory > make[1]: *** [Makefile:8: test] Error 127 > make[1]: Leaving directory '/home/rene/hunspell-dict-ko-0.7.92/tests' > make: *** [Makefile:53: hosttest] Error 2 > > I think python3 should be there. It is probably already installed by > autopkgtest, but anyways. It's correct that the minimal system installed by autopkgtest has always python3. Isn't the test supposed to be run by autopkgtest? There seems to be no documentation on the default installed packages, so adding python3 would be safe for the possible future autopkgtest change. But in practice, missing python3 in Depends doesn't break anything.
Bug#1027418: autopkgtest failure - iconv issue?
2023년 1월 2일 (월) 오전 5:31, Rene Engelhard 님이 작성: > > Hi, > > Am 01.01.23 um 21:25 schrieb Changwoo Ryu: > > I can't reproduce it myself. > I am not sure either what happens... > > In your test, every word failed to be checked with the same error and > > the error message came from hunspell, when iconv() conversion on text > > fails. Probably your chroot environment lacked some libs necessary for > > iconv(). > > Yes, but that then needs to be reflected in the test depends strictly > speaking... If there's a missing dependency which breaks hunspell like this, then it needs to be added to hunspell dependencies, not to this test's. It is enough having 'hunspell' in Depends to run hunspell. But I believe dependency is not an issue. I think you made your chroot dir without fully installing libc6. Note that glibc's iconv() function loads dynamic encoding conversion libs under /usr/lib/x86_64-linux-gnu/gconv/ on runtime. I ran the test like this (and it succeeded): $ sudo autopkgtest-build-docker $ sudo autopkgtest . -- docker autopkgtest/debian:unstable
Bug#1027418: autopkgtest failure - iconv issue?
Hello, 2022년 12월 31일 (토) 오후 5:36, Rene Engelhard 님이 작성: > It even fails here locally with 1.7.2+really1.7.1-2 which I needed to do > due to > https://ci.debian.net/data/autopkgtest/testing/amd64/r/r-cran-hunspell/29793480/log.gz. > > In a clean chroot + test deps + python3 (see #1027417), I get: > > rene@frodo:~/hunspell-dict-ko-0.7.92$ make hosttest > HOST_DICT_PATH=/usr/share/hunspell/ko > make -C tests test DICT=/usr/share/hunspell/ko > make[1]: Entering directory '/home/rene/hunspell-dict-ko-0.7.92/tests' > echo | hunspell -d /usr/share/hunspell/ko | head -1 > Hunspell 1.7.1 - hunspell-dict-ko 0.7.92 (requires Hunspell 1.3.1) > https://spellcheck-ko.github.io/ > python3 checkhunspellversion.py > Testing 001-pos-dependent-inflection.test... > error - iconv: ANSI_X3.4-1968 -> UTF-8 > error - iconv: ANSI_X3.4-1968 -> UTF-8 > . > make[1]: *** [Makefile:9: test] Error 1 > make[1]: Leaving directory '/home/rene/hunspell-dict-ko-0.7.92/tests' > make: *** [Makefile:53: hosttest] Error 2 > > This is with LANG=C but C.UTF-8 or even ko_KR.UTF-8 have the same problem. > > Somehow I don't believe it's hunspell at fault here (especially as 1.7.1 > now also fails and it obviously passed once), but... I can't reproduce it myself. In your test, every word failed to be checked with the same error and the error message came from hunspell, when iconv() conversion on text fails. Probably your chroot environment lacked some libs necessary for iconv(). There is a successful autopkgtest log with hunspell 1.7.2+really1.7.1-2: https://ci.debian.net/data/autopkgtest/testing/amd64/h/hunspell-dict-ko/29801950/log.gz
Bug#1017623: nautilus-filename-repairer: Fails to build with Nautilus 43
I reviewed the code for a while but it needs a significant change to migrate. Adopting new APIs was relatively easy, but this repairer extension works by launching several modal synchronous dialogs, which are obsolete in GTK4, in sequence. This impacts the whole flow of this program in GTK4 migration. Maybe it's time for this old package to retire. I'll consider ITP as new if the upstream does the migration in the future.
Bug#995701: tzdata: [INTL:ko] Korean debconf templates translation
Package: tzdata Version: 2021c-1 Severity: wishlist Tags: l10n patch Please find the attached the debconf templates translation into Korean. -- Changwoo Ryu # tzdata debconf templates translation # This file is distributed under the same license as the tzdata package. # Changwoo Ryu , 2021. # msgid "" msgstr "" "Project-Id-Version: tzdata\n" "Report-Msgid-Bugs-To: tzd...@packages.debian.org\n" "POT-Creation-Date: 2021-09-29 00:36+0200\n" "PO-Revision-Date: 2021-10-04 20:49+0900\n" "Last-Translator: Changwoo Ryu \n" "Language-Team: Debian L10N Korean \n" "Language: Korean\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Africa" msgstr "아프리카" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "America" msgstr "아메리카" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Antarctica" msgstr "남극" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Australia" msgstr "오스트레일리아" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Arctic" msgstr "북극" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Asia" msgstr "아시아" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Atlantic" msgstr "대서양" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Europe" msgstr "유럽" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Indian" msgstr "인도양" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:1001 ../tzdata.templates:12001 msgid "Pacific" msgstr "태평양" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "US" msgstr "미국" #. Type: select #. Choices #. Note to translators: #. - "Etc" will present users with a list #. of "GMT+xx" or "GMT-xx" timezones #: ../tzdata.templates:1001 msgid "Etc" msgstr "기타" #. Type: select #. Description #: ../tzdata.templates:1002 msgid "Geographic area:" msgstr "지리적 지역:" #. Type: select #. Description #: ../tzdata.templates:1002 msgid "" "Please select the geographic area in which you live. Subsequent " "configuration questions will narrow this down by presenting a list of " "cities, representing the time zones in which they are located." msgstr "거주하고 있는 지리적 지역을 선택하십시오. 이후의 설정 질문에서는 지역을 특정하려고 도시의 목록을 표시합니다. 표시하는 도시는 도시 위치의 표준 시간대를 나타냅니다." #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:2001 msgid "Abidjan" msgstr "아비장" #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:2001 msgid "Accra" msgstr "아크라" #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates:2001 msgid "Addis_Ababa" msgstr "아디스아바바" #. Type: select #. Choices #. Translators: do not translate underscores. You can use spaces instead. #: ../tzdata.templates
Bug#992670: ibus: drop ibus-gtk and im-config to Suggests
I think the best choice is to keep ibus-gtk in Recommends, as long as there are gtk2 apps in Debian. Without ibus-gtk installed, XIM will be used as the fallback and its bugs will confuse users. There are already several open bugs about this. When ibus-gtk was in OR'ed Recommends, many users just did "apt install ibus" and had trouble with XIM unnecessarily. Fixing the bugs is not an answer; this legacy protocol has its limits and ambiguity in the design.The ibus upstream refuses to fix XIM related bugs and I also think those bugs are not worth fixing.
Bug#988540: im-config: breaks the keyboard configuration
Hello, 2021년 5월 15일 (토) 오후 8:21, Gunnar Hjalmarsson 님이 작성: > > I see one thing which looks suspicious: You have set the LC_ALL > environment variable to C. LC_ALL is not supposed to be set permanently. > Ever. Especially not to C, which disables UTF-8 encoding. Actually LC_ALL=C is set by reportbug and it's an intended behavior; see /usr/share/doc/reportbug/README.developers.gz
Bug#984457: 特殊符號第二頁有重複字
Control: reassign -1 libchewing3-data 0.5.1-4 The dictionary is provided by libchewing
Bug#959474: Issues with Chinese language (all variants) when building some pages in buster
Korean is affected too and I added the "-O1" option workaround also to Korean.
Bug#967649: nabi: depends on deprecated GTK 2
Control: tags -1 + wontfix Nabi implements the legacy XIM protocol only and it's not used much (popcon <3) nowadays. There haven't been any new releases since 2013. This package will be removed from the archive when GTK2 removal is a must.
Bug#946201: ibus: some keystrokes are taken in account
Control: retitle -1 ibus: some keystrokes are not taken into account Control: tag -1 + unreproducible It is welcome to help in reproducing this. I couldn't reproduce this in my system or in a newly installed one.
Bug#964996: ibus-unikey: Remove deps on ibus IM module packages
Package: ibus-unikey Version: 0.7.0~beta1-0.1 Severity: normal Currently ibus-unikey depends on ibus-gtk and ibus-gtk3. These IM module package are for supporting UIs and they should not be in Depends of ibus language engine packages.
Bug#964927: ibus-avro: Remove deps on ibus IM module packages
2020년 7월 14일 (화) 오전 12:39, Gunnar Hjalmarsson 님이 작성: > > Control: tags -1 + pending > > Fix pushed to repo: > https://salsa.debian.org/input-method-team/ibus-avro/-/commit/06990e57 > > (Don't know why salsa didn't do this automatically.) That is not set as default. Add the "tagpending' webhook URL below in the project settings. https://salsa.debian.org/salsa/salsa-webhook
Bug#964927: ibus-avro: Remove deps on ibus IM module packages
2020년 7월 13일 (월) 오전 4:37, Gunnar Hjalmarsson 님이 작성:
>
> Thanks for your report!
>
> On 2020-07-12 19:01, Changwoo Ryu wrote:
> > ibus-avro depends on ibus-gtk, ibus-gtk3 and ibus-clutter.
> >
> > These IM module package are for supporting UIs and they should not be
> > in Depends of ibus language engine packages.
>
> I packaged ibus-avro last year, and took those dependencies from some
> pre-Debian .deb package out there.
>
> But as regards ibus-gtk and ibus-gtk3 I gave it some consideration. At
> that time the recommends in the ibus package with respect to those
> packages was a bit vague. It could lead to issues in e.g. Kubuntu. Some
> user installed ibus-avro which pulled ibus, but since Kubuntu is KDE
> based, libqt5gui5 was already there, so ibus-gtk and ibus-gtk3 were not
> pulled and it "didn't work".
>
> So why Depends and not just Recommends? Well, one of the Ubuntu flavors
> (Lubuntu) was at least previously very focused on disk space, so by
> default they didn't pull Recommends. Before dropping those ibus-gtk{,3}
> dependencies I'd like to know how they do it today.
>
> I see that ibus now clearly recommends ibus-gtk and ibus-gtk3, so if
> Lubuntu does it otherwise nowadays, those dependencies could probably be
> dropped from ibus-avro.
Yes, it's the old alternate Recommends in ibus and fixed in ibus
1.5.21-5. It was an ibus issue and it doesn't have to be handled by
another package.
Most other ibus language engine packages don't have such Depends.
> Otherwise: Do the ibus-gtk/ibus-gtk3 depends have any adverse effects?
By the policy, Depends is used when the depending package requires the
dependencies to provide a significant amount of functionalities. By
the design of IBus, ibus-avro works without installing
ibus-gtk/ibus-gtk3.
> > Especially it's strange to pull ibus-clutter when no application
> > package in Debian uses clutter-imcontext.
>
> TBH I know nothing about clutter, but assumed that it may be needed in
> some situations. If not, why would im-config set the
> CLUTTER_IM_MODULE env var?
"apt rdepends libclutter-imcontext-0.1-0" shows no client apps so
there's no current use in Debian. In theory, it could be used if
someone wrote an application using clutter-imcontext for their own
use, but no one would do that in practice. (clutter-imcontext is not
part of Clutter.Clutter is a drawing library and does not have any
kind of input support.)
The CLUTTER_IM_MODULE setting in im-config is just a decade old
history. It was for the failed company platform Maemo and later
Moblin. These platforms were Debian based so it was fun and useful to
install additional debs including im-config in Maemo/Moblin devices.
Maemo/Moblin apps used Clutter and clutter-imcontext, and the Maemo IM
framework Maliit support is also in im-config for this reason.
Anyway I'm not suggesting removing clutter-imcontext from Debian. Just
avoid useless dependency on this ancient package.
Bug#964927: ibus-avro: Remove deps on ibus IM module packages
Package: ibus-avro Version: 1.2-1 Severity: normal ibus-avro depends on ibus-gtk, ibus-gtk3 and ibus-clutter. These IM module package are for supporting UIs and they should not be in Depends of ibus language engine packages. Especially it's strange to pull ibus-clutter when no application package in Debian uses clutter-imcontext.
Bug#961640: fontforge: Shows no glyphs when running on Wayland
Package: fontforge Version: 1:20190801~dfsg-4 Severity: important Hello, When I run fontforge in Wayland (gnome-shell or weston), $ env LANG=en_US.UTF-8 fontforge LexiGulim.ttf It doesn't show the font glyphs. Also I cannot see window decorations. I can access the menu but the current selection is not highlighted. If I run fontforge in XWayland, $ env WAYLAND_DISPLAY= LANG=en_US.UTF-8 fontforge LexiGulim.ttf This shows glyphs and window decorations as expected. See the screenshots attached. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fontforge depends on: ii fontforge-common 1:20190801~dfsg-4 ii libc6 2.30-8 ii libfontforge3 1:20190801~dfsg-4 ii libgdraw6 1:20190801~dfsg-4 fontforge recommends no packages. Versions of packages fontforge suggests: ii fontforge-doc 1:20190801~dfsg-4 ii fontforge-extras 1:20190801~dfsg-4 ii potrace1.16-2 ii python3-fontforge 1:20190801~dfsg-4 -- no debconf information
Bug#961192: im-config: Remove imhangul support; packages removed since buster
Control: tags -1 + pending Thanks for the fix! Next time please include bug number in resolving commit message. Then salsa webhook will automatically append "pending" tag.
Bug#961192: im-config: Remove imhangul support; packages removed since buster
Package: im-config Version: 0.44.1-1 Severity: normal The imhangul support in im-config seems to be for imhangul (GTK2/3) and qimhangul (QT3/4) packages, but those packages have been removed since buster. Just remove the imhangul support. The menu name "hangul" (which is also the name of Korean writing system) can misleads like a generic Korean input support. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages im-config depends on: ii gettext-base 0.19.8.1-10 Versions of packages im-config recommends: ii whiptail0.52.21-4+b1 ii x11-common 1:7.7+20 ii zenity 3.32.0-5 im-config suggests no packages. -- no debconf information
Bug#960645: firefox: Please build with WebRTC pipewire support for GNOME Wayland
Package: firefox Version: 76.0.1-1 Severity: normal Hello, Currently in Firefox, WebRTC screen capture works only on X11. In Wayland, only XWayland windows can be captured. Wayland doesn't support screen capture by defaults but GNOME supports the feature using pipewire. The pipewire support is already in Firefox source since version 68 (media/webrtc/trunk/webrtc/modules/desktop_capture/linux/base_capturer_pipewire.*) but it is not built as a default. Debian GNOME desktop is running on Wayland as defaults since buster, and its default browser is Firefox. So I think the Debian Firefox package needs to be built with pipewire capture support. In Fedora, pipewire support is enabled with this patch: https://src.fedoraproject.org/rpms/firefox/blob/master/f/firefox-pipewire.patch -- Package-specific info: -- Addons package information -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.6.0-1-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages firefox depends on: ii debianutils 4.9.1 ii fontconfig 2.13.1-4.1 ii libatk1.0-0 2.36.0-2 ii libc6 2.30-8 ii libcairo-gobject2 1.16.0-4 ii libcairo2 1.16.0-4 ii libdbus-1-3 1.12.16-2 ii libdbus-glib-1-20.110-5 ii libevent-2.1-7 2.1.11-stable-1 ii libffi7 3.3-4 ii libfontconfig1 2.13.1-4 ii libfreetype62.10.1-2 ii libgcc-s1 10.1.0-1 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-4 ii libglib2.0-02.64.2-1 ii libgtk-3-0 3.24.20-1 ii libnspr42:4.25-1 ii libnss3 2:3.52-1 ii libpango-1.0-0 1.44.7-4 ii libstdc++6 10.1.0-1 ii libvpx6 1.8.2-dmo1 ii libx11-62:1.6.9-2+b1 ii libx11-xcb1 2:1.6.9-2+b1 ii libxcb-shm0 1.14-2 ii libxcb1 1.14-2 ii libxcomposite1 1:0.4.5-1 ii libxdamage1 1:1.1.5-2 ii libxext62:1.3.3-1+b2 ii libxfixes3 1:5.0.3-2 ii libxrender1 1:0.9.10-1 ii libxt6 1:1.1.5-1+b3 ii procps 2:3.3.16-4 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages firefox recommends: ii libavcodec58 10:4.2.2-dmo8 Versions of packages firefox suggests: ii fonts-lmodern 2.004.5-6 pn fonts-stix | otf-stix ii libcanberra0 0.30-7 ii libgssapi-krb5-2 1.17-7 ii libgtk2.0-02.24.32-4 ii pulseaudio 13.0-5 -- no debconf information
Bug#955227: ibus-cangjie: Migrate from /usr/lib/ibus to /usr/libexec
Control: tags -1 + patch See merge request at https://salsa.debian.org/input-method-team/ibus-cangjie/-/merge_requests/1 I found that the upstream Makefile.am overrided $(libexecdir) for some reason. https://github.com/Cangjians/ibus-cangjie/issues/58 But I think it's better to install the files just to /usr/libexec.
Bug#954060: node-unicode-data: Uses missing emoji files in unicode-data 13.0
Control: severity -1 normal Control: retitle -1 Use unicode-data (>= 13.0.0-2) The updated unicode-data 13.0.0-2 ships the emoji files. (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953795#38) Please use the updated version (>= 13.0.0-2) instead of (>= 13.0.0) in Build-Depends.
Bug#955246: ibus-zhuyin: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-zhuyin Version: 0.1.0-2 Severity: wishlist Hello, ibus-zhuyin uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-zhuyin doesn't have setup in /usr/lib/ibus so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955245: ibus-unikey: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-unikey Version: 0.6.1-1.1+b1 Severity: wishlist Control: block 955219 by -1 Hello, ibus-unikey uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-unikey has setup in /usr/lib/ibus and it was not specified in the XML, /usr/share/ibus/component/unikey.xml. Please specify the setup command path in the XML if possible. Or, if it's too difficult to patch, add versioned dependency ibus (>= 1.5.22-2). Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955241: ibus-sunpinyin: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-sunpinyin Version: 2.0.3+git20181120-5 Severity: wishlist Hello, ibus-sunpinyin uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-sunpinyin has setup in /usr/lib/ibus but it was specified in the in the XML so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955242: ibus-table: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-table Version: 1.9.25-1 Severity: wishlist Hello, ibus-table uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-table has setup in /usr/lib/ibus but it was specified in the in the XML so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955240: ibus-skk: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-skk Version: 1.4.3-1 Severity: wishlist Control: block 955219 by -1 Hello, ibus-skk uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-skk has setup in /usr/lib/ibus and it was not specified in the XML, /usr/share/ibus/component/skk.xml. Please specify the setup command path in the XML if possible. Or, if it's too difficult to patch, add versioned dependency ibus (>= 1.5.22-2). Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955239: ibus-pinyin: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-pinyin Version: 1.5.0-6+b1 Severity: wishlist Hello, ibus-pinyin uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-pinyin has setup in /usr/lib/ibus but it was specified in the in the XML so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955238: ibus-m17n: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-m17n Version: 1.4.2-1 Severity: wishlist Hello, ibus-m17n uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-m17n has setup in /usr/lib/ibus but it was specified in the in the XML so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955236: ibus-libthai: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-libthai Version: 0.1.4-5 Severity: wishlist Hello, ibus-libthai uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-libthai has setup in /usr/lib/ibus but it was specified in the in the XML so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955237: ibus-libzhuyin: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-libzhuyin Version: 1.9.1-1 Severity: wishlist Hello, ibus-libzhuyin uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-libzhuyin has setup in /usr/lib/ibus but it was specified in the in the XML so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955235: ibus-libpinyin: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-libpinyin Version: 1.11.1-2 Severity: wishlist Hello, ibus-libpinyin uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-libpinyin has setup in /usr/lib/ibus but it was specified in the in the XML so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955233: ibus-kmfl: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-kmfl Version: 11.0.101-1 Severity: wishlist Hello, ibus-kmfl uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-kmfl doesn't have setup in /usr/lib/ibus so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955231: ibus-kkc: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-kkc Version: 1.5.22-2 Severity: wishlist Control: block 955219 by -1 Hello, ibus-kkc uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-kkc has setup in /usr/lib/ibus and it was not specified in the XML, /usr/share/ibus/component/kkc.xml. Please specify the setup command path in the XML if possible. Or, if it's too difficult to patch, add versioned dependency ibus (>= 1.5.22-2). Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955230: ibus-keyman: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-keyman Version: 11.0.103-4 Severity: wishlist Hello, ibus-keyman uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-keyman doesn't have setup in /usr/lib/ibus so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955229: ibus-input-pad: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-input-pad Version: 1.4.2-2 Severity: wishlist Control: block 955219 by -1 Hello, ibus-input-pad> uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-input-pad has setup in /usr/lib/ibus and it was not specified in the XML, /usr/share/ibus/component/input-pad.xml. Please specify the setup command path in the XML if possible. Or, if it's too difficult to patch, add versioned dependency ibus (>= 1.5.22-2). Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955228: ibus-chewing: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-chewing Version: 1.6.1-1 Severity: wishlist Hello, ibus-chewing uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-chewing has setup in /usr/lib/ibus but it was specified in the in the XML /usr/share/ibus/component/chewing.xml. So you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955226: ibus-array: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-array Version: 0.2.1-5 Severity: wishlist Control: block 955219 by -1 Hello, ibus-array uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-array has setup in /usr/lib/ibus and it was not specified in its XML, /usr/share/ibus/component/array.xml. Please specify the setup command path in the XML if possible. Or, if it's too difficult to patch, add versioned dependency ibus (>= 1.5.22-2). Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955227: ibus-cangjie: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-cangjie Version: 2.4-4 Severity: wishlist Hello, ibus-cangjie uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-cangjie doesn't have setup in /usr/lib/ibus so you don't have to change other things. Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955224: ibus-anthy: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-anthy Version: 1.5.11-1+b1 Severity: wishlist Control: block 955219 by -1 Hello, ibus-anthy uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-anthy has setup and it was not specified in the XML. Please specify the setup command path in the XML if possible. Or, if it's too difficult to patch, add versioned dependency ibus (>= 1.5.22-2). Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec dir /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec dir as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955220: ibus-hangul: Migrate from /usr/lib/ibus to /usr/libexec
Package: ibus-hangul Version: 1.5.3-1 Severity: wishlist Control: breaks 955219 by -1 Hello, ibus-hangul uses --libexec-dir=/usr/lib/ibus configure flag. But it is not needed anymore. Please remove the --libexec-dir flag in the next uploads. ibus-hangul has setup and it was not specified in the XML. Please specify the setup command path in the XML if possible. Or, if it's too difficult to patch, add versioned dependency ibus (>= 1.5.22-2). Details: ibus used /usr/lib/ibus as "libexec" dir for FHS 2.x compliance. And all the ibus engine packages also used the same libexec /usr/lib/ibus, because ibus-setup searched ibus-setup-NAME in libexec as fallback. But FHS 3.0 allows using /usr/libexec, so the newer ibus 1.5.22-2 just uses /usr/libexec. ibus-setup provides compatibility with the old fallback setup path /usr/lib/ibus/ibus-setup-NAME. When ibus-setup uses such a fallback, it will display a warning like this: Warning: Using old FHS 2.x path /usr/lib/ibus/ibus-setup-NAME This FHS 2.x compatibility is to be removed after some time. If your ibus-NAME package have explicit in your /usr/share/ibus/NAME.xml, you don't have to worry and just remove --libexec-dir=/usr/lib/ibus flag in the next uploads. If your package does not have in /usr/share/ibus/.xml, it is encouraged to patch your package to have in the XML. Then it will work with older versions of ibus package. For example: https://salsa.debian.org/input-method-team/ibus-hangul/blob/master/debian/patches/specify-setup-in-ibus-component.patch Please don't forget to upstream the changes. Without or --libexec-dir flag, /usr/libexec/ibus-setup-NAME will work only with the newer versions of ibus. If it's too difficult to patch and you decided not to patch, don't forget to add the versioned dependency "ibus (>= 1.5.22-2)" to Depends. Thanks,
Bug#955219: ibus: Stop /usr/lib/ibus/ibus-setup-NAME compatibility after migration
Package: ibus Version: 1.5.22-2 Severity: wishlist ibus 1.5.22-2 removed --libexec-dir=/usr/lib/ibus configure flags for the FHS 3.0 compliance, but it also provides /usr/lib/ibus/ibus-setup-NAME compatibility for the old engine packages. See https://salsa.debian.org/debian/ibus/-/blob/master/debian/patches/libexec-fhs2-compat.patch This compatibility patch will be removed after all the engine packages migrate. Current packages in unstable which install files in /usr/lib/ibus: ibus-anthy: /usr/lib/ibus/ibus-engine-anthy ibus-anthy: /usr/lib/ibus/ibus-setup-anthy ibus-array: /usr/lib/ibus/ibus-engine-array ibus-array: /usr/lib/ibus/ibus-setup-array ibus-cangjie: /usr/lib/ibus/ibus-engine-cangjie ibus-chewing: /usr/lib/ibus/ibus-engine-chewing ibus-chewing: /usr/lib/ibus/ibus-setup-chewing ibus-hangul: /usr/lib/ibus/ibus-engine-hangul ibus-hangul: /usr/lib/ibus/ibus-setup-hangul ibus-input-pad: /usr/lib/ibus/ibus-engine-input-pad ibus-input-pad: /usr/lib/ibus/ibus-setup-input-pad ibus-keyman: /usr/lib/ibus/ibus-engine-keyman ibus-kkc: /usr/lib/ibus/ibus-engine-kkc ibus-kkc: /usr/lib/ibus/ibus-setup-kkc ibus-kmfl: /usr/lib/ibus/ibus-engine-kmfl ibus-libpinyin: /usr/lib/ibus/ibus-engine-libpinyin ibus-libpinyin: /usr/lib/ibus/ibus-setup-libpinyin ibus-libthai: /usr/lib/ibus/ibus-engine-libthai ibus-libthai: /usr/lib/ibus/ibus-setup-libthai ibus-libzhuyin: /usr/lib/ibus/ibus-engine-libzhuyin ibus-libzhuyin: /usr/lib/ibus/ibus-setup-libzhuyin ibus-m17n: /usr/lib/ibus/ibus-engine-m17n ibus-m17n: /usr/lib/ibus/ibus-setup-m17n ibus-pinyin: /usr/lib/ibus/ibus-engine-pinyin ibus-pinyin: /usr/lib/ibus/ibus-setup-pinyin ibus-skk: /usr/lib/ibus/ibus-engine-skk ibus-skk: /usr/lib/ibus/ibus-setup-skk ibus-sunpinyin: /usr/lib/ibus/ibus-engine-sunpinyin ibus-sunpinyin: /usr/lib/ibus/ibus-setup-sunpinyin ibus-table: /usr/lib/ibus/ibus-engine-table ibus-table: /usr/lib/ibus/ibus-setup-table ibus-unikey: /usr/lib/ibus/ibus-engine-unikey ibus-unikey: /usr/lib/ibus/ibus-setup-unikey ibus-zhuyin: /usr/lib/ibus/ibus-engine-zhuyin
Bug#954207: getting gtk3 warnings of glib version too old after update
Control: tags -1 + confirmed 2020년 3월 19일 (목) 오전 8:40, shirish शिरीष 님이 작성: > Dear Changwoo, > > Here are the details you needed - > > $ apt-cache policy ibus-gtk3 > ibus-gtk3: > Installed: 1.5.22-1 > Candidate: 1.5.22-1 > Version table: > *** 1.5.22-1 900 > 900 http://deb.debian.org/debian testing/main amd64 Packages > 100 http://deb.debian.org/debian unstable/main amd64 Packages > 100 /var/lib/dpkg/status > > $ apt-cache policy libglib2.0-0 > libglib2.0-0: > Installed: 2.62.5-1 > Candidate: 2.62.5-1 > Version table: > 2.64.1-1 100 > 100 http://deb.debian.org/debian unstable/main amd64 Packages > *** 2.62.5-1 900 > 900 http://deb.debian.org/debian testing/main amd64 Packages > 100 /var/lib/dpkg/status > > I hope and guess that this will go away when libglib2.0-0 2.64.1-1 > migrates to testing. I am going to wait the necessary 2-3 days it will > take for the new version of libglib2.0-0 to migrate by itself. > > Ideally, it should have put the package back or in non-upgradable, not > installable mode till libglib2.0-0 2.64.1-1 doesn't migrate over. Thanks for the info. I was confused but I got it now. Currently ibus built with glib 2.64.x can be installed with glib 2.62.x in testing. I'll investigate why the runtime glib version should be checked and remove it if possible.
Bug#954207: getting gtk3 warnings of glib version too old after update
Hi, 2020년 3월 18일 (수) 오후 11:24, shirish शिरीष 님이 작성: > > Package: ibus-gtk3 > Version: 1.5.22-1 > Severity: normal > > Dear Maintainer, > > I am getting the following GTK3 warnings while running any gtk3 aware app. > > (gedit:255189): Gtk-WARNING **: 19:47:32.240: GModule > (/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-ibus.so) > initialization check failed: GLib version too old (micro mismatch) I don't see this warning message. This happens when your glib version is older than the version which ibus-gtk3 was built with. It's a typical compatibility check. > Could you please look into the above and fix it. I am not sure which > glib version to report it too if it pertains to that, whether > libglib2.0-0 2.62.5-1 or something else. According to buildd.d.o, ibus-gtk3:amd64 1.5.22-1 has been built with glib 2.64.1-1. It shouldn't print such warning with glib 2.62.5-1. Please make sure if you were really running ibus 1.5.22-1 and glib 2.62.5-1. > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (900, 'testing'), (500, 'testing-debug'), (100, > 'unstable-debug'), (100, 'experimental'), (100, 'unstable'), (50, > 'experimental-debug') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.0-4-amd64 (SMP w/4 CPU cores) > Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8), LANGUAGE=en_IN:en > (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages ibus-gtk3 depends on: > ii libc6 2.30-2 > ii libglib2.0-02.62.5-1 > ii libgtk-3-0 3.24.14-1 > ii libibus-1.0-5 1.5.22-1 > ii libpango-1.0-0 1.42.4-8 >
Bug#953795: unicode-data: Missing emoji*.txt after upgrading to 13.0.0
Control: severity -1 normal It seems that ibus is the only FTBFS package by this issue. So I decided to include emoji-test.txt in the ibus source (at least for now). I'm lowering the severity.
Bug#954060: node-unicode-data: Uses missing emoji files in unicode-data 13.0
Source: node-unicode-data Version: 0~20190709+git706d06c0-4 Severity: important Hello, I found node-unicode-data used emoji-*.txt files which have been removed from unicode-data in upstream version 13.0. (#953795) debian/rules:19:ln -s $(UNICODE)/emoji/emoji-sequences.txt data/$(VERSION)-emoji-sequences.txt debian/rules:21:ln -s $(UNICODE)/emoji/emoji-zwj-sequences.txt data/$(VERSION)-emoji-zwj-sequences.txt debian/resources.js:18: 'emoji-sequences': '/usr/share/unicode/emoji/emoji-sequences.txt', debian/resources.js:19: 'emoji-zwj-sequences': '//usr/share/unicode/emoji/emoji-zwj-sequences.txt', I'm not sure whether node-unicode-data needs those emoji files or not. If these files are not required, just remove uses of them. (And build binary package node-unicode-data-13.0.0 maybe.) Or if the emoji files are required, please see #953795 and tell your opinion about how to resolve it. Thanks, -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#953961: ibus: fails to change languages
Control: tags -1 + moreinfo On Sun, 15 Mar 2020 03:49:57 +0200 "K.D." wrote: >* What exactly did you do (or not do) that was effective (or > ineffective)? >When $sudo udevadm trigger --subsystem-match=input --action=change >was executed, I can use ctrl+alt to change the language. >If I do not execute the previous I have to manually change the language >[i.e. by clicking to the language icon in the systems tray] ... > adding to my previous email, I solved the problem by following the steps. > 1. Application-->settings-->keyboard-->Layout-->ctrl+alt [or something] > 2. Application-->settings-->Ibus preferences and untick *show icon in systems > tray* > 3. Right click on system tray Panel-->add new items-->keyboard settings > 4. Reboot > > It seems that Ibus has a bug. Your problem is most likely not an ibus issue. These settings are not provided by ibus, but by XFCE. We need more information about how keyboard settings and layout switching work in XFCE. Is it integrated with ibus input method switching like GNOME? Or is it just about XKB (setxkbmap)?
Bug#953795: unicode-data: Missing emoji*.txt after upgrading to 13.0.0
2020년 3월 14일 (토) 오전 12:06, Thorsten Glaser 님이 작성: > > Changwoo Ryu dixit: > > >Possible solutions would be shipping additional emoji files in unicode-data, > >or creating a new source package for unicode emoji files like Fedora does > >(https://src.fedoraproject.org/rpms/unicode-emoji) > > Why not just create a multiple-upstream-tarballs package and > ship the files from unicode-data again? No need for an extra > package. Using multiple orig tarballs is also possible. But as there's no upstream tarball release for these emoji files, tarball should be downloaded manually anyway. IMO it's not very pleasant to maintain extra files in this package when the upstream doesn't want to ship them in UCD.zip anymore. It's decision by the maintainer.
Bug#953795: unicode-data: Missing emoji*.txt after upgrading to 13.0.0
Package: unicode-data Version: 13.0.0-1 Severity: important Control: block 953775 by -1 Control: block 953793 by -1 Hello, The ibus and node-unicode-tr51 (and possibly others I have not found yet) packages have FTBFS with unicode-data 13.0.0-1. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953775 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=953793 They are because the upstream UCD.zip doesn't ship emoji-sequences.txt, emoji-test.txt and emoji-zwj-sequences.txt files anymore since version 13. Possible solutions would be shipping additional emoji files in unicode-data, or creating a new source package for unicode emoji files like Fedora does (https://src.fedoraproject.org/rpms/unicode-emoji) Any opinions? -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-4-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#953793: node-unicode-tr51: FTBFS with unicode-data 13.0.0
Package: src:node-unicode-tr51 Version: 9.1.0+ds-2 Severity: serious Tags: ftbfs Hello, node-unicode-tr51 FTBFS with upgraded unicode-data 13.0.0-1. It looks like emoji-sequences.txt, emoji-test.txt and emoji-zwj-sequences.txt have been removed from unicode character database download (UCD.zip). ibus package has the same issue: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=953775 Here's the failure log: dh build dh_update_autotools_config dh_autoreconf debian/rules override_dh_auto_build make[1]: Entering directory '/home/debian/tmp/node-unicode-tr51-9.1.0+ds' mkdir data ln -s /usr/share/unicode/emoji/emoji-data.txt data/ ln -s /usr/share/unicode/emoji/emoji-sequences.txt data/ ln -s /usr/share/unicode/emoji/emoji-zwj-sequences.txt data/ node scripts/parse-emoji-data.js node scripts/parse-emoji-sequences.js fs.js:114 throw err; ^ Error: ENOENT: no such file or directory, open 'data/emoji-sequences.txt' at Object.openSync (fs.js:443:3) at Object.readFileSync (fs.js:343:35) at parseEmojiSequences (/home/debian/tmp/node-unicode- tr51-9.1.0+ds/scripts/parse-emoji-sequences.js:8:20) at Object. (/home/debian/tmp/node-unicode- tr51-9.1.0+ds/scripts/parse-emoji-sequences.js:28:19) at Module._compile (internal/modules/cjs/loader.js:778:30) at Object.Module._extensions..js (internal/modules/cjs/loader.js:789:10) at Module.load (internal/modules/cjs/loader.js:653:32) at tryModuleLoad (internal/modules/cjs/loader.js:593:12) at Function.Module._load (internal/modules/cjs/loader.js:585:3) at Function.Module.runMain (internal/modules/cjs/loader.js:831:12) make[1]: *** [debian/rules:12: override_dh_auto_build] Error 1 make[1]: Leaving directory '/home/debian/tmp/node-unicode-tr51-9.1.0+ds' make: *** [debian/rules:4: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 debuild: fatal error at line 1182: dpkg-buildpackage -us -uc -ui failed
Bug#953775: FTBFS with unicode-data 13.0.0
Package: src:ibus Version: 1.5.21-5 Severity: serious Tags: ftbfs ibus build fails with missing emoji-test.txt in unicode-data 13.0.0. configure: error: Not found /usr/share/unicode/emoji/emoji-test.txt. You can get the emoji files from http://www.unicode.org/Public/emoji/4.0/ It looks like emoji-sequences.txt, emoji-test.txt and emoji-zwj-sequences.txt have been removed from unicode character database download (UCD.zip) since version 13. A possible solutions would be creating a new package for unicode emoji files like Fedora does (https://src.fedoraproject.org/rpms/unicode-emoji), or (if there's no other package depending on this) having copies of the emoji files in the ibus source.
Bug#950104: Bug#951046: ibus: Numpad not working in GDM lockscreen when ibus installed in Stretch
Control: reopen 950104 Oops, I'm sorry. It was a typo.
Bug#951046: ibus: Numpad not working in GDM lockscreen when ibus installed in Stretch
Control: tag -1 + unreproducible moreinfo 2020년 2월 10일 (월) 오후 8:24, Julien Negros 님이 작성: > > Package: ibus > Version: 1.5.14-3+deb9u2 > Severity: important > > Hi ! > > Not sure I'm doing the right thing since this issue is not present with > updated version of the ibus package, like in Buster. But in Stretch, > still supported Debian version, there is this annoying problem of numpad > not working when locking the screen. The workaround is to to click "Log > in as another user" and then select your user. > No more issue when removing "ibus". I could not reproduce it in new 9.12.0 installation. Please check whether you enabled "Mouse key" accessibility option in gnome-control-center. This option uses numeric keys for moving pointer.
Bug#948142: apparmor: Update abstractions/ibus socket path
Package: apparmor
Version: 2.13.3-7
Severity: normal
In short, the ibus socket path in needs to be changed
for the recent ibus versions like this:
unix (connect, receive, send)
type=stream
peer=(addr="@{HOME}/.cache/ibus/dbus-*"),
Details:
This is follow-up to debian/patches/debian/allow-access-to-ibus-socket.patch.
In IBus upstream 1.5.21, the upstream has changed the default socket path
to"/tmp/ibus" to make it distinguishable. But it is not secure as a malicious
user can create "/tmp/ibus" with restrictive permission. In IBus upstream git
after 1.5.21, the upstream has changed the socket path to
"$XDG_CACHE_HOME/ibus" for Linux and "/tmp" for non-Linux. (See
https://github.com/ibus/ibus/issues/2095 and
https://github.com/ibus/ibus/issues/2116 for more information.) AppArmor is
Linux specific so allowing Unix socket "${HOME}.cache/ibus/dbus-*" is enough.
Debian ibus 1.5.21-5 has these changes (to fix non-linux FTBFS).
You can also remove the old socket path and then "ibus (<< 1.5.21-5)" should be
added to Breaks.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8),
LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages apparmor depends on:
ii debconf [debconf-2.0] 1.5.73
ii libc6 2.29-7
ii lsb-base 11.1.0
ii python33.7.5-3
apparmor recommends no packages.
Versions of packages apparmor suggests:
pn apparmor-profiles-extra
pn apparmor-utils
-- debconf information:
apparmor/homedirs:
Bug#885815: fcitx-configtool-gtk2: Depends on libunique
Control: tags -1 + pending On Fri, 29 Dec 2017 21:45:12 -0500 Jeremy Bicha wrote: > Package: fcitx-configtool-gtk2 > Version: 0.4.9-1 > Severity: important > User: pkg-gnome-maintain...@lists.alioth.debian.org > Usertags: oldlibs libunique > Tags: sid buster > > As announced [1], we do not intend to release Debian 10 "Buster" with > the old libgnome (and related) libraries. These libraries have been > deprecated and unmaintained for several years. > > Your package depends and or build-depends on libunique. > > Please consider dropping fcitx-configtool-gtk2 to help us achieve this > goal. > > [1] https://lists.debian.org/debian-devel/2017/10/msg00299.html > > On behalf of the Debian GNOME team, > Jeremy Bicha Hello, Jeremy. Your 0.4.10-3 upload two months ago has been auto-rejected as it refers "orig.tar.gz" file instead of "orig.tar.xz". Could you upload again with existing orig tarball? Thanks, Changwoo Ryu
Bug#947690: fcitx-hangul: Remove or hide "auto reordering" option (not available in Debian)
Package: fcitx-hangul
Version: 0.3.1-2
Severity: normal
The libhangul1 package in Debian is based on the upstream git version. Unlike
the released 0.1.0 version, this git version doesn't support "auto reordering"
feature. Toggling this settings in fcitx-hangul has no effect.
To avoid confusion, please remove or hide this setting. And the default value
should be fixed as FALSE instead of TRUE. ibus-hangul package does the same
thing. This is Debian specific so there's no need to upstream.
Relevant code:
$ grep -i -r reorder src
src/eim.h:boolean autoReorder;
src/eim.c:if (!hangul->fh.autoReorder) {
src/config.c:CONFIG_BINDING_REGISTER("Hangul", "AutoReorder", autoReorder)
src/fcitx-hangul.desc:# [Hangul/AutoReorder]
src/fcitx-hangul.desc:Description=Auto Reorder
$
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-3-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8),
LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages fcitx-hangul depends on:
pn fcitx-modules
ii libc6 2.29-6
ii libhangul1 0.1.0+git20191003-2
Versions of packages fcitx-hangul recommends:
pn fcitx
fcitx-hangul suggests no packages.
Bug#947262: ibus: Please omit ibus-tests binary package on Ubuntu/i386
Control: tags -1 pending 2019년 12월 24일 (화) 오전 4:27, Steve Langasek 님이 작성: > > Package: ibus > Version: 1.5.21-4 > Severity: minor > Tags: patch > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu focal ubuntu-patch > > Dear maintainers, > > In Ubuntu, we are in the process of moving the i386 architecture to a > compatibility-only layer on amd64. We are keeping ibus on i386 because > ibus-gtk is relevant for legacy applications, but the ibus-tests package > built from this source has dependencies on other packages that are not being > kept as part of the compatibility library set (e.g. gnome-shell). > > We would like to drop the ibus-tests binary package rather than keeping it > around in the Ubuntu archive and uninstallable. Would you please consider > applying the attached patch, or something like it, to omit building this > binary package on Ubuntu? > > Thanks for considering, Applied in the git. Thanks for the patch. Generally speaking, how about proposing a build profile for compatibility only build, rather than checking Ubuntu/i386? I guess ibus is not the only package having this issue and other distros have (or will have in the future) the same issue.
Bug#946326: python3-reportbug: reportbug runs bugscript in "C" locale
Control: retitle -1 Document that bugscripts run in "C" locale 2019년 12월 8일 (일) 오전 5:39, Nis Martensen 님이 작성: > > When programs called by bugscripts provide output in the user's locale, > this can make the information unintelligible to the debian maintainer. > Please see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546276 > for why the "LC_ALL=C" was introduced ten years ago. I am not sure that > reverting this is a good idea. It should probably be documented in > README.developers, so bugscript authors are aware of it. > > Note that reportbug already includes the most important locale > information in all bug reports by default. In your example, it is this > line in the "System Information" section of the report: > Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), > LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) I'm convinced. Adding documentation about it would be good. Thanks.
Bug#946500: ibus-cangjie: Cannot run ibus-setup-cangjie
Package: ibus-cangjie
Version: 2.4-3
Severity: important
ibus-setup-cangjie just finished with a Python exception:
$ /usr/bin/ibus-setup-cangjie cangjie
Traceback (most recent call last):
File "/usr/bin/ibus-setup-cangjie", line 42, in
from ibus_cangjie.setup import Setup
File "/usr/lib/python3/dist-packages/ibus_cangjie/setup.py", line 23, in
gi.require_version('Gio','3.0')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 121, in
require_version
(namespace, loaded_version))
ValueError: Namespace Gio is already loaded with version 2.0
$ /usr/bin/ibus-setup-cangjie quick
Traceback (most recent call last):
File "/usr/bin/ibus-setup-cangjie", line 42, in
from ibus_cangjie.setup import Setup
File "/usr/lib/python3/dist-packages/ibus_cangjie/setup.py", line 23, in
gi.require_version('Gio','3.0')
File "/usr/lib/python3/dist-packages/gi/__init__.py", line 121, in
require_version
(namespace, loaded_version))
ValueError: Namespace Gio is already loaded with version 2.0
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8),
LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ibus-cangjie depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.34.0-1
ii gir1.2-ibus-1.0 1.5.21-4
ii ibus 1.5.21-4
ii python3 3.7.5-3
ii python3-gi 3.34.0-3
ii python3-pycangjie1.3-1+b1
ibus-cangjie recommends no packages.
ibus-cangjie suggests no packages.
-- no debconf information
Bug#946201: ibus: some keystrokes are taken in account
> > > == locale == > > > LANG=fr_FR.UTF-8 > > > LANGUAGE= > > > LC_CTYPE="C" > > > LC_NUMERIC="C" > > > LC_TIME="C" > > > LC_COLLATE="C" > > > LC_MONETARY="C" > > > LC_MESSAGES="C" > > > LC_PAPER="C" > > > LC_NAME="C" > > > LC_ADDRESS="C" > > > LC_TELEPHONE="C" > > > LC_MEASUREMENT="C" > > > LC_IDENTIFICATION="C" > > > LC_ALL=C > > > > This can be a problem. 'C" locale is basically ASCII only so some > > characters won't be input in some applications. > > It is weird because if I input locale command in a terminal I get: Never mind. It was reportbug overriding LC_ALL env variable. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946326
Bug#946326: python3-reportbug: reportbug runs bugscript in "C" locale
Package: python3-reportbug
Version: 7.5.3
Severity: normal
reportbug seems to run bugscript in "C" locale. In /usr/lib/python3/dist-
packages/reportbug/utils.py:
rc = runner('LC_ALL=C %s %s %s' % (handler, pipes.quote(bugscript),
pipes.quote(filename)))
It prevents the ibus bugscript from getting "locale" command result. For
example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=946201#5
I understand that running locale dependent bugscript can be often buggy and
confusing, but some bugscripts want the locale dependent behavior. I think
settings locale settings should be up to the individual bugscript authors.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8),
LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages python3-reportbug depends on:
ii apt1.8.4
ii file 1:5.37-6
ii python33.7.5-3
ii python3-apt1.8.4+b1
ii python3-debian 0.1.36
ii python3-debianbts 3.0.2
ii python3-requests 2.22.0-2
ii sensible-utils 0.0.12+nmu1
python3-reportbug recommends no packages.
Versions of packages python3-reportbug suggests:
ii reportbug 7.5.3
-- no debconf information
Bug#946321: gir1.2-ggit-1.0: Incorrect Python override path
Package: gir1.2-ggit-1.0 Version: 0.28.0.1-1+b1 Severity: normal $ dpkg -S /usr/lib/python3/dist-packages/gi/overrides/overrides/Ggit.py gir1.2-ggit-1.0:amd64: /usr/lib/python3/dist- packages/gi/overrides/overrides/Ggit.py $ gir1.2-ggit-1.0 has /usr/lib/python3/dist- packages/gi/overrides/overrides/Ggit.py (overrides under overrides) which looks like incorrect install. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.3.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gir1.2-ggit-1.0 depends on: ii gir1.2-glib-2.0 1.62.0-2 ii libgit2-glib-1.0-0 0.28.0.1-1+b1 gir1.2-ggit-1.0 recommends no packages. gir1.2-ggit-1.0 suggests no packages. -- no debconf information
Bug#716334: [Mayhem] Bug report on sunpinyin-utils: slmthread crashes with exit status 139
Control: forcemerge 716334 716344 716401 716402 716403 Control: forwarded 716334 https://github.com/sunpinyin/sunpinyin/issues/98 Control: retitle 716334 sunpinyin-utils: Crashes by missing fopen() failure checks Still reproducible. All these crashes are by missing fopen() error checks. Merging bugs.
Bug#946201: ibus: some keystrokes are taken in account
Control: tags -1 + moreinfo 2019년 12월 5일 (목) 오후 7:06, gpe92 님이 작성: > > Package: ibus > Version: 1.5.21-3 > Severity: normal > > Dear Maintainer, > > Since ibus comes in testing I encounter lot of problems with keystrokes > which are not taken in account. Especially the accentuated characters > (french keyboard) and some specific characters, for example * needs to > be stroke 4 or 5 times before taking in account. > Another problem is that the compose key is no longer take in account ... I can't reproduce it with GNOME/X11 session and fr layout. I had no problem to input accentuated characters, asterisk, the AltGr key. Please be more specific. Which application did you use? Does it occur in all applications and always? > == locale == > LANG=fr_FR.UTF-8 > LANGUAGE= > LC_CTYPE="C" > LC_NUMERIC="C" > LC_TIME="C" > LC_COLLATE="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_PAPER="C" > LC_NAME="C" > LC_ADDRESS="C" > LC_TELEPHONE="C" > LC_MEASUREMENT="C" > LC_IDENTIFICATION="C" > LC_ALL=C This can be a problem. 'C" locale is basically ASCII only so some characters won't be input in some applications.
Bug#946147: RM: fonts-woowa-hanna -- ROM; replaced by fonts-woowa-bm
Package: ftp.debian.org Severity: normal fonts-woowa-hanna has been replaced by fonts-woowa-bm. fonts-woowa-bm includes all font families including the Hanna font. There's no rdeps.
Bug#936718: ibus-pinyin: Python2 removal in sid/bullseye
Control: forwarded https://github.com/ibus/ibus-pinyin/pull/5 Control: tags -1 + patch pending Control: blocks 944387 by -1 I just pushed patch from the upstream push request to salsa. It seems to work.
Bug#936717: ibus-array: Python2 removal in sid/bullseye
Control: Tags -1 + patch A suggested patch is attached. diff --git a/debian/control b/debian/control index 303a216..ba06f15 100644 --- a/debian/control +++ b/debian/control @@ -8,6 +8,7 @@ Build-Depends: autoconf (>= 2.5), autopoint, debhelper (>= 9), dh-autoreconf, + dh-python, libibus-1.0-dev, libsqlite3-dev, libtool (>= 2.2), diff --git a/debian/rules b/debian/rules index 28e31a5..1dddbcf 100755 --- a/debian/rules +++ b/debian/rules @@ -8,6 +8,6 @@ export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed,-ldl dh $@ --with python3,autoreconf override_dh_auto_configure: - dh_auto_configure -- \ + env PYTHON=/usr/bin/python3 dh_auto_configure -- \ --libexecdir=/usr/lib/ibus
Bug#944614: fixed in ibus 1.5.21-2
On Tue, 12 Nov 2019 21:03:50 + Boyuan Yang wrote: > + Downgrade dependency of ibus-tests -> gnome-shell to >recommendation on s390x since gnome-shell currently FTBFS on >s390x architecture. >This makes ibus able to migrate to testing. (Closes: #944614) Does it make a difference? ibus-tests still depends on gnome-session which depends on gnome-shell. ibus-tests needs GNOME session to work. If it's difficult to fix gnome-shell s390x FTBFS, then ibus-tests should be disabled for s390x.
Bug#762266: glib-2.0 GDateTime locale tests
The test code needs to be corrected: setlocale() is required before calling POSIX locale-aware functions. --- glibtestold.c2019-11-11 11:27:21.489271420 +0900 +++ glibtest.c2019-11-11 11:27:09.737139535 +0900 @@ -1,3 +1,4 @@ +#include #include #include @@ -6,6 +7,8 @@ gchar *time; gchar *date; gchar *str; + +setlocale(LC_ALL, ""); datetime=g_date_time_new_now_local(); time=g_date_time_format(datetime, "%X"); After this changes, $ env LANG=th_TH ./glibtest 11:24:34 (null) $ "(null)" matches the original bug report. No idea which part of glib and/or th_TH locale make this wrong result.
Bug#893253: Is it still reproducible?
2019년 11월 10일 (일) 오후 7:06, 님이 작성: > > On 2019-11-09 11:19 Changwoo Ryu wrote: > > Is it still reproducible with recent versions of ibus and clients? > > My main problem with JabRef is gone. I can insert 日本語 without a > problem. > > But "Anki" (current upstream and official-deb-repository version) still > does not work. Do not understand why. Maybe this is a app specific > problem. Your problems don't seem to related with this bug #893253. Please post to relevant bug or file a new bug if there isn't one.
Bug#914704: ibus: candidate window appears at bottom
I still can't reproduce it in Cinamon desktop in a new account with the same im-config settings. Something should be different in the reproducing desktop.
Bug#893253: Is it still reproducible?
Control: tag -1 + moreinfo Is it still reproducible with recent versions of ibus and clients?
Bug#917931: Lowering severity of ibus/XIM bugs
Control: retitle: -1 ibus: Chromium shortcuts with letter keys do not work via XIM Control: outlook -1 0 Control: severity -1 minor Control: tags -1 + wontfix This problem is XIM only and easily avoided by installing ibus-gtk3. -- I'm lowering severity of the XIM related ibus bugs. I'm also adding wontfix tag when a clear workaround exists (e.g. installing ibus-gtk3 for GTK apps). One reason is that the upstream doesn't consider XIM related issues as open bugs. I agree with the upstream; the protocol is ancient and limited, the protocol spec is vague and client implementations are often buggy. While we can't drop XIM as some clients (e.g. Java) do not support other IM, I think most of the XIM bugs are not very worth to fix.
Bug#883014: Lowering severity of ibus/XIM bugs
Control: retitle: -1 Using poedit textboxes via XIM without ibus-gtk3 Control: outlook -1 0 Control: severity -1 minor Control: tags -1 + wontfix This problem is XIM only and easily avoided by installing ibus-gtk3. -- I'm lowering severity of the XIM related ibus bugs. I'm also adding wontfix tag when a clear workaround exists (e.g. installing ibus-gtk3 for GTK apps). One reason is that the upstream doesn't consider XIM related issues as open bugs. I agree with the upstream; the protocol is ancient and limited, the protocol spec is vague and client implementations are often buggy. While we can't drop XIM as some clients (e.g. Java) do not support other IM, I think most of the XIM bugs are not very worth to fix.
Bug#879044: gobject-introspection: mini-policy: clarify where language overrides should be shipped
But one problem of having Python (for example) overrides file in gir1.2-* package is, that it creates unnecessary dependency on python even for non-python rdepends. Currently some gir1.2-* packages with Python overrides files have intentionally missing python dependency to avoid such unnecessary dependency and have lintian-overrides to avoid lintian error python-package-missing-depends-on-python. (https://lintian.debian.org/tags/python-package-missing-depends-on-python.html) I'm not against having language overrides in gir1.2-* packages. But when we choose to do it, it would be great if the mini policy clarify this: If gir1.2-foo has Python overridess file, should gir1.2-foo depend on Python? If not, is it OK to have lintian-overrides?
Bug#944387: gir1.2-ibus-1.0: Remove Python2 g-i overrides file
Package: gir1.2-ibus-1.0 Version: 1.5.2-1 Severity: normal Control: block -1 by 936717 For Python2 removal in sid/bullseye, the Python 2.x gobject-introspection overrides file should be removed from gir1.2-ibus-1.0. Currently ibus-array (0.2.1-2) is the only affected package. I'm filing this bug to track rdepends bug (#936717) before the removal. Fixing this bug can be done just by adding --disable-python2 configure flag.
Bug#857115: dconf update does not change defaults
Control: tags -1 confirmed Control: forwarded -1 https://github.com/ibus/ibus/issues/2150 Control: severity -1 minor Control: retitle -1 ibus: ibus-setup doesn't use the installed dconf profile The original title was confusing. "dconf update" updates the system dconf db file which is not necessarily the default. The problem is on ibus-setup reading the settings. See the forwarded upstream issue.
Bug#941018: libdbus-glib-1-2: libdbus-glib auth problem
For summary, This is a dbus-glib upstream issue (https://gitlab.gnome.org/GNOME/glib/issues/1831). An ongoing merge request exists at https://gitlab.gnome.org/GNOME/glib/merge_requests/1176. It's most likely a race condition on auth which makes a gdbus server to receive invalid client UID/GID. It breaks the typical same-user authentication check. Original bug was from ibus. Because of this, Qt 5.x apps failed to connect to ibus with a proper security fix (#940267).
Bug#940634: ibus: FTBFS: emojier.vala:915.48-915.53: error: Assignment: Cannot convert from `GLib.SList' to `GLib.SList?'
Control: tags -1 + fixed-upstream It's been fixed in upstream 1.5.20 or later. Maybe we can just upload 1.5.21-1~exp2 in experimental to unstable.
Bug#834331: failed tests work only in GUI
I found that the RH ibus package also disables three tests, ibus-compose, ibus-keypress and test-stress: https://src.fedoraproject.org/rpms/ibus/blob/f31/f/ibus.spec#_329 I believe that the failed tests are assumed to be run in a GUI session. Then they will break buildd and CI. Why not just disable them?
Bug#933767: ibus: New upstream version available
Hello, Boyuan I realized you already worked on ibus 1.5.21 in experimental branch while I was doing the same thing. :) So I rebased my changes onto your work. Please review my MR: https://salsa.debian.org/debian/ibus/merge_requests/3 Changwoo Ryu
Bug#883014: XIM related
Control: tag -1 + upstream This also looks like XIM related. I can't reproduce this bug with ibus-gtk3 installed. Please note that XIM related issues are nowadays considered as non-supported by upstream IM frameworks.
Bug#914704: unreproducible in ibus 1.5.19-4+b1
Control: tag -1 + moreinfo unreproducible I couldn't reproduce it in GNOME session w/ ibus 1.5.19-4+b1 and ibus-libpinyin.
Bug#917931: XIM only issue
Control: tag -1 + upstream Control: forwarded -1 https://github.com/ibus/ibus/issues/2073 This can be reproduce only with XIM. Users can just install ibus-gtk3. Todays, XIM related issues are considered as non-supported ones by upstream IM frameworks.
Bug#934147: extra databases
2019년 8월 24일 (토) 오후 7:56, Changwoo Ryu 님이 작성: > > Please clarify about dropping the extra databases. > > So dropping extra city/ASN databases is because their upstream sources > are now shipped in separate ZIP files. And you don't want to maintain > these databases in new source packages. Am I correct? I just want to > know what to do for those who still need those databases. Now I understand the situation after checking #918709. IMO the conversion script should be enhanced to work on the extra databases.
Bug#934147: extra databases
Please clarify about dropping the extra databases. So dropping extra city/ASN databases is because their upstream sources are now shipped in separate ZIP files. And you don't want to maintain these databases in new source packages. Am I correct? I just want to know what to do for those who still need those databases.
Bug#935060: dbconfig-common: debconf template Korean translation update
Source: dbconfig-common
Version: 2.0.12
Severity: wishlist
Tags: patch l10n
Please apply this file as the Korean debconf template translation.
(debian/po/ko.po)
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8),
LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
# Korean translations for dbconfig-common package
# dbconfig-common 패키지 한국어 번역문.
# Copyright (C) 2007 THE dbconfig-common'S COPYRIGHT HOLDER
# This file is distributed under the same license as the dbconfig-common
package.
# Sunjae Park , 2007.
# Changwoo Ryu , 2009, 2015, 2016, 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: dbconfig-common\n"
"Report-Msgid-Bugs-To: dbconfig-com...@packages.debian.org\n"
"POT-Creation-Date: 2019-08-18 20:35+0200\n"
"PO-Revision-Date: 2019-08-19 04:04+0900\n"
"Last-Translator: Changwoo Ryu \n"
"Language-Team: Korean \n"
"Language: ko\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=1; plural=0;\n"
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid "Will this server be used to access remote databases?"
msgstr "이 서버가 원격 데이터베이스에 접속합니까?"
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid ""
"For the database types that support it, dbconfig-common includes support for "
"configuring databases on remote systems. When installing a package's "
"database via dbconfig-common, the questions related to remote configuration "
"are asked with a priority such that they are skipped for most systems."
msgstr ""
"원격 연결을 지원하는 데이터베이스의 경우, dbconfig-common에서 원격 시스템의 "
"데이터베이스를 설정할 수 있습니다. dbconfig-common을 통해 패키지 데이터베이스"
"를 설치하는 경우, 대부분 시스템에서 원격 설정과 관련한 질문은 넘어가도록 우"
"선 순위가 설정되어 있습니다."
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid ""
"If you select this option, the default behavior will be to prompt you with "
"questions related to remote database configuration when you install new "
"packages."
msgstr ""
"이 옵션을 선택하면, 새 패키지를 설치할 때 기본적으로 원격 데이터베이스 설정"
"에 관련한 질문을 묻습니다."
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:2001
msgid "If you are unsure, you should not select this option."
msgstr "잘 모르겠으면 이 옵션을 선택하지 마십시오."
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid "Remember database passwords permanently in debconf?"
msgstr "debconf에 데이터베이스 암호를 계속 저장합니까?"
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid ""
"When you configure, upgrade, or remove applications with dbconfig-common, "
"administrator-level database passwords are needed. By default, these "
"passwords are not stored, so you will be prompted for them each time."
msgstr ""
"dbconfig-common으로 애플리케이션을 설정/업그레이드/제거하는 경우, 관리자 수준"
"의 데이터베이스 암호를 입력해야 합니다. 기본값으로 이 암호는 저장하지 않기 때"
"문에, 매번 입력창이 나타납니다."
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid ""
"Alternatively the passwords can be permanently remembered in the debconf "
"database (which is protected by Unix file permissions), though this is less "
"secure and thus not the default setting."
msgstr ""
"아니면 암호를 debconf 데이터베이스에 계속 저장할 수도 있습니다. (유닉스 파일 "
"권한으로 보호됩니다.) 이 방식은 보안상 별로 안전하지 않으므로 기본값이 아닙니"
"다."
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:3001
msgid ""
"If you would rather not be bothered for an administrative password every "
"time you upgrade a database application with dbconfig-common, you should "
"choose this option. Otherwise, you should refuse this option."
msgstr ""
"dbconfig-common을 통해 데이터베이스 응용 프로그램을 업그레이드할 때마다 관리"
"자용 암호를 입력하고 싶지 않다면, 이 옵션을 선택하십시오. 그렇지 않다면 이 옵"
"션을 선택하지 마십시오."
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:4001
msgid "Configure database for ${pkg} with dbconfig-common?"
msgstr "${pkg}의 데이터베이스를 dbconfig-common으로 설정하시겠습니까?"
#. Type: boolean
#. Description
#: ../dbconfig-common.templates:4001
msgid ""
"The ${pkg} package must have a databas
Bug#934594: freevial: Please avoid to use fonts-unfonts-core
Package: freevial Version: 1.3-2.1 Severity: normal I'm trying to find and remove dependencies on fonts-unfonts-* fonts. fonts- unfonts fonts look bad on ordinary screens and there are alternatives. I have no idea why freevial chose "UnBatang" as the default font. But I don't think there was a specific need for it. Please to use other fonts. If freevial needs an international font with serifs, I suggest to use Noto Serif CJK in fonts-noto-cjk -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freevial depends on: ii fonts-freefont-ttf 20120503-9 ii fonts-unfonts-core 1:1.0.2-080608-16 ii python 2.7.16-1 ii python-lxml 4.3.3-2 ii python-pygame 1.9.4.post1+dfsg-3 freevial recommends no packages. freevial suggests no packages. -- no debconf information
Bug#934588: freeciv-client-sdl: Use fonts-noto-cjk instead of fonts-unfonts-core
Control: tags -1 + patch I made a MR (without d/changelog entry): https://salsa.debian.org/games-team/freeciv/merge_requests/1
Bug#934588: freeciv-client-sdl: Use fonts-noto-cjk instead of fonts-unfonts-core
Package: freeciv-client-sdl Version: 2.6.0-3 Severity: normal Tags: l10n I'm trying to find and remove dependencies on fonts-unfonts-* fonts. fonts- unfonts-core fonts look bad on ordinary screens and there are alternatives. Freeciv doesn't seem to need a specific font but needs just a free Korean font in general. Then I suggest to use Noto Sans CJK in fonts-noto-cjk. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.2.0-2-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages freeciv-client-sdl depends on: ii fonts-arphic-uming0.2.20080216.2-10 ii fonts-dejavu-core 2.37-1 ii fonts-ipafont-gothic 00303-18 ii fonts-unfonts-core1:1.0.2-080608-16 ii freeciv-data 2.6.0-3 ii libbz2-1.01.0.6-9.2 ii libc6 2.28-10 ii libcurl3-gnutls 7.65.3-1 ii liblzma5 5.2.4-1 ii libsdl2-2.0-0 2.0.9+dfsg1-1 ii libsdl2-gfx-1.0-0 1.0.4+dfsg-3 ii libsdl2-image-2.0-0 2.0.5+dfsg1-1 ii libsdl2-mixer-2.0-0 2.0.4+dfsg1-2 ii libsdl2-ttf-2.0-0 2.0.15+dfsg1-1 ii zlib1g1:1.2.11.dfsg-1+b1 Versions of packages freeciv-client-sdl recommends: ii freeciv-server 2.6.0-3 Versions of packages freeciv-client-sdl suggests: pn freeciv-client-extras pn freeciv-sound-standard -- no debconf information
Bug#934008: mlterm-tiny: Remove fonts-baekmuk from Suggests
Control: clone 934008 -1 Control: reassign -1 mlterm-tiny Control: retitle -1 mlterm-tiny: Remove fonts-baekmuk from Suggests Control: reopen -1 Thanks. mlterm-tiny binpkg also needs to be fixed.
Bug#934012: O: wand -- Python interface for ImageMagick library
Package: wnpp Severity: normal I orphan this package, wand. I don't use it anymore. I updated it recently (0.5.5-1) and it's in pretty good shape. See https://salsa.debian.org/debian/wand if you are interested.
Bug#934008: mlterm: Remove fonts-baekmuk from Suggests
Package: mlterm Version: 3.8.8-2 Severity: minor Hello, Please remove fonts-baekmuk from Suggests. The baekmuk fonts are old and lead to undesirable result in modern displays. I skimmed mlterm source code and I found no direct reference to the Baekmuk fonts. So it seems that fonts-baekmuk is suggested as one Korean font. Then I suggest to use fonts-noto-cjk | fonts-nanum instead. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores) Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8), LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages mlterm depends on: ii libc6 2.28-10 ii libfreetype62.9.1-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-02.60.6-1 ii libx11-62:1.6.7-1 ii mlterm-common 3.8.8-2 Versions of packages mlterm recommends: ii mlterm-tools 3.8.8-2 Versions of packages mlterm suggests: ii fonts-arphic-bsmi00lp 2.10-17 ii fonts-arphic-gbsn00lp 2.11-15 ii fonts-baekmuk 2.2-13 ii fonts-freefont-ttf 20120503-9 ii fonts-ipaexfont-gothic [fonts-japanese-gothic] 00401-1 ii fonts-ipafont-gothic [fonts-japanese-gothic]00303-18 ii fonts-nanum 20180306-3 ii fonts-vlgothic [fonts-japanese-gothic] 20141206-5 pn mlterm-im-m17nlib pn mlterm-im-scim pn mlterm-im-uim pn t1-cyrillic pn unifont pn xfonts-efont-unicode
Bug#934006: mlterm: Menu contains ancient XIMs
Package: mlterm
Version: 3.8.8-2
Severity: normal
In debian/config-menu,
"XIM" {
"kinput2" "xim=kinput2:ja_JP.eucJP"
"ami" "xim=Ami:ko_KR.eucKR"
"xcin (big5)" "xim=xcin:zh_TW.Big5"
"xcin (gb)" "xim=zh_CN.GB2312:zh_CN.GB2312"
"skkinput" "xim=skkinput:ja_JP.eucJP"
}
These old input methods have been out of major use for more than a decade and
AFAIK are not in Debian anymore. mlterm-im-{fcitx,ibus,uim} plugin packages do
the job so this Debian specific menu is not needed.
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Locale: LANG=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8 (charmap=UTF-8),
LANGUAGE=ko_KR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mlterm depends on:
ii libc6 2.28-10
ii libfreetype62.9.1-4
ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii libglib2.0-02.60.6-1
ii libx11-62:1.6.7-1
ii mlterm-common 3.8.8-2
Versions of packages mlterm recommends:
ii mlterm-tools 3.8.8-2
Versions of packages mlterm suggests:
ii fonts-arphic-bsmi00lp 2.10-17
ii fonts-arphic-gbsn00lp 2.11-15
ii fonts-baekmuk 2.2-13
ii fonts-freefont-ttf 20120503-9
ii fonts-ipaexfont-gothic [fonts-japanese-gothic] 00401-1
ii fonts-ipafont-gothic [fonts-japanese-gothic]00303-18
ii fonts-nanum 20180306-3
ii fonts-vlgothic [fonts-japanese-gothic] 20141206-5
pn mlterm-im-m17nlib
pn mlterm-im-scim
pn mlterm-im-uim
pn t1-cyrillic
pn unifont
pn xfonts-efont-unicode
