Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian

[Osamu Aoki]

Hi,

This is very convoluted issue.

Disclaimer: I use (n)vim and anthy and voted for non-free-firmware=yes (i.e.,
prioritize user experience)

On Thu, 2023-03-02 at 09:42 +, Simon McVittie wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 28 Jan 2023 at 16:46:35 +0900, YOSHINO Yoshihito wrote:
> > As mentioned in Bug #984875, gnome-initial-setup's default choice of
> > input method is hardcoded in the dependent libgnome-desktop-4-2 package.
> > The Japanese one is anthy
> > https://sources.debian.org/src/gnome-desktop/43.1-1/libgnome-desktop/default-input-sources.h/#L39
> > preferred by upstream (Fedora/Red Hat) perhaps because its code base is
> > simple and easy to maintain, while this is not suitable for most Debian
> > Japanese users, who use mozc because of its better conversion quality,
> > thus task-japanese-gnome-desktop and task-japanese-desktop has preferred
> > mozc over anthy. So the hardcoded value should be adjusted for our
> > users.
> 
> Is there consensus among Japanese-speaking users of Debian that mozc is
> a better default for all Japanese speakers, including new users who are
> not familiar with GNOME or Debian?

Choice of input method engine and its framework are hot topics without easy
unanimous agreements. 

Before going into that kind of discussion, I would like to draw attention to
general performance perception and some technical points.

* Why mozc:
In general, mozc tends to provide better suggestions for the possible choice of
input conversion choices than ones provided by anthy.  This may be the reason
why people like mozc than anthy.

* Why anthy:
In debian/control, mozc source package comes as:
> Architecture: i386 amd64 armel armhf arm64 riscv64
while anthy doesn't have such limitation.  My vague memory tells me that the
code for mozc is written for the little endian system only.  (mozc's C++ header
file structure and shipped data requires specific endianness.)

Also data used for obtaining conversion proposals are more opaque for mozc. 
Data for anthy is more intuitive for modification than that of mozc.  Neither
are easy to do, though.

> I want to avoid changing this from anthy to mozc-jp, and then getting a
> second bug report from a different Japanese user saying that we need to
> change it back!
> 
> Looking at #984875 and #983653, I also see a mention of mozc only being
> available on certain architectures: it's available on x86, ARM and riscv64,
> but not on mips*el, ppc64el or s390x.

Correct.

> How does this interact with the default being mozc-jp? Do we need to use
> a #ifdef to make the default be mozc on architectures that have it, and
> anthy on architectures that don't?

If we decide to propose mozc as preferred choice, that should be a possible
choice.

> I'm also concerned that mozc still depends on GTK 2 (a switch to GTK
> 3 was tried and then reverted, see #967641). This is OK for bookworm,
> but will probably not be supportable in Debian 13.

> > Upstream prefers ibus-anthy for Japanese input
> 
> Please talk to upstream about this: if mozc is a better default for Debian,
> then it's probably also a better default for upstream.
>
> The only issue reports I could find upstream are
> https://gitlab.gnome.org/GNOME/gnome-desktop/-/issues/181 which is about
> switching the default from kkc to anthy, and
> https://gitlab.gnome.org/GNOME/gnome-initial-setup/-/issues/104 which is
> older and refers to kkc as being the default.

 * kkc and anthy are both in GPL: kkc was intended to be improved replacement of
anthy by RH developer.  Its resulting performance was not convincing to replace
anthy.  Anthy was by Japanese government sponsored and it's last updates was
gathered and organized by DD (muto-san).

 * mozc is mostly BSD-3-Clause with its opaque learned data being BSD-3-Clause-
with-ICOT-term.  It's by google employee, if I recall.  RH ppl may not like
opaqueness of learned data outside of their easy update.  Learned data is only
provided as a data dump.

> On Wed, 22 Feb 2023 at 15:09:15 +0900, ken...@xdump.org wrote:
> >   Thus with attached patch, gnome-initial-setup will not
> >   show label for mozc-jp as "日本語 (Mozc)" by default.
> 
> What would be the best label to be displayed there?
> 
> What is actually displayed instead?
> 
> >   To display label correctly, fetch_ibus_engines_result must be called 
> >   in advance.
> 
> That's probably not possible: fetch_ibus_engines_result is called
> asynchronously with the result of a D-Bus method call, so it's already
> called as early as possible, and before that point we don't have the
> necessary information.
> 
> Probably the best we can do there is to hard-code a special case for
> mozc-jp.
> 
>     smcv

In order to get mozc to be promoted to be more prominent position, we need to
make sure the maintainer of mozc feels comfortable.  He (Iwamatsu-san) seems to
be making curating many patches and making patch to keep up with gtk3
transition.  Gunnar also seems to be doing QA and regression checks. 

Bug#1029112: Surprise build issue with ibus-libzhuyin

[Osamu Aoki]

Hi,

Debian official packages are required to build without downloading external
files during their build.  (Builddd is in isolated network environment only with
access to the Debian package repository.


> Tags: ftbfs

So if it requires wget file access, it is ftbfs.  Don't make build script to do
this.   ... (continue to the bottom).

> Making all in model
> make[4]: Entering directory '/<>/data/model'
> wget http://downloads.sourceforge.net/libzhuyin/models/model13.text.tar.gz
> /bin/bash: line 1: wget: command not found
> 
> And yes, it's true that wget is not included in Build-Depends. But 
> previously that has not been needed. This is from the buildlog for the 
> latest successful build:
> 
> Making all in model
> make[4]: Entering directory '/<>/data/model'
> rm -f phrase_index.bin pinyin_index.bin addon_phrase_index.bin 
> addon_pinyin_index.bin bigram.db tsi.bin
> gen_binary_files --table-dir ../../data/model
> import_interpolation --table-dir ../../data/model < 
> ../../data/model/interpolation2.text
> gen_unigram --table-dir ../../data/model
> 
> or just:
> 
> Making check in model
> make[3]: Entering directory '/<>/data/model'
> make[3]: Nothing to be done for 'check'.
> 
> I have not found any code changes which would explain the new behavior. 
> And when trying (in an Ubuntu PPA) to add wget to Build-Depends, it 
> failed to resolve the download URL. (It builds fine on my harddisk, though.)
> 
> I figured out that this patch would help it build successfully:
> 
> --- a/data/Makefile.am
> +++ b/data/Makefile.am
> @@ -27,7 +27,6 @@
> 
>    SUBDIRS = \
>    icons \
> -    model \
>    $(NULL)
> 
>    appdatadir = @datadir@/appdata
> 
> But since I don't know how that would affect the functionality of the 
> package, I have left it in its failed state for now.
> 
> In other words: I need help to solve this.


If I were you, I will build package "without this mod in an environment with
wget included as Build-dep" and "with this mod only without wget in chroot". 
Then I will check resulting binary packages.

If these generated packages contain different model data, then you need to
modify code to use pre-existing data and download such model data in advance to
be included in debian/ directory.  Of course, you need to check license terms of
such model data and document it.

If these contain same model data, your proposed fix should be OK.

Regards,

Osamu

Bug#919058: its-tools: crashes

[Osamu Aoki]

Control: affects 919058 - src:debmake-doc

Since debmake-doc has stopped using its-tools from 1.16-1 this is no longer 
issue.
po4a is used to handle xml.

Osamu

Bug#979524: debian-reference: build-depends on libopencc2-data, which no longer exists

[Osamu Aoki]

Hi,

I just uploaded 2.77 addressing all the issues.

I also made a merge of Boyan's changes while overriding them.

I hope this is OK since my change history should have most of the fixes
proposed.  If I am wrong, let me know.  That goes to 2.78.

On Sat, 2021-01-09 at 14:40 +0900, Osamu Aoki wrote:
> Hi,
> 
> I think it is time to fix this bug and upload package.  Let me make
> final check.  Osamu
> 
> On Fri, 2021-01-08 at 23:28 -0500, Boyuan Yang wrote:
> > 
...
> 

Bug#979524: debian-reference: build-depends on libopencc2-data, which no longer exists

[Osamu Aoki]

Hi,

I think it is time to fix this bug and upload package.  Let me make
final check.  Osamu

On Fri, 2021-01-08 at 23:28 -0500, Boyuan Yang wrote:
> Hi,
> 
> 在 2021-01-08星期五的 09:49 +0800，xiao sheng wen(肖盛文)写道：
> > Hi,
> > 
> >  libopencc2-data had change name to libopencc-data in bullseye
> > sid.
> > 
> > As the opencc upstream had changed the version number, SONAME, etc.
> > 
> > Update debian-reference build-depends on libopencc-data should fix
> > this bug.
> 
> This bug as well as the python2->3 migration has long been fixed in
> git
> trunk. We just need another upload.
> 
> Osamu: do you have time to review all changes after 2.76 tag and make
> another upload for debian-reference package? This will fix at least
> one
> RC-buggy bug so it might be worthwhile to get fixed before freeze.
> 
> Thanks,
> Boyuan Yang
> 
> 
> > 在 2021/1/8 上午12:55, Ivo De Decker 写道:
> > > package: src:debian-reference
> > > version: 2.76
> > > tags: bullseye sid ftbfs
> > > severity: serious
> > > 
> > > Hi,
> > > 
> > > It seems debian-reference build-depends on libopencc2-data, which
> > > no longer
> > > exists.
> > > 
> > > Cheers,
> > > 
> > > Ivo
> > > 
> 
> 

Bug#936604: FYI: Python 3 migration of distributuion

[Osamu Aoki]

Hi,

It's a fork with a new upstream with some issues.  (Not supported by
the old upstream)

Anyway, I switched out from getmail to other MUA.

No one seems to take over this package maintenance.

So please remove this package.  I am not going to package the new
getmail6.

Regards,

Osamu


On Wed, 2020-10-21 at 22:41 +0200, Moritz Mühlenhoff wrote:
> On Tue, Nov 19, 2019 at 10:43:49PM +0900, Osamu Aoki wrote:
> > On Sun, Nov 17, 2019 at 02:28:44PM +0900, Osamu Aoki wrote:
> > > Hi,
> > > 
> > > On Wed, Nov 13, 2019 at 11:11:43AM -0600, Charles Cazabon wrote:
> > > > Osamu Aoki  wrote:
> > > > > 
> > > > > Currently, getmail is a candidate for removal from the
> > > > > upcoming Debian
> > > > > release if it is not updated to support python 3 by someone
> > > > > (not
> > > > > necessary by upstream).
> > > > 
> > > > Thanks for the update, Osamu.  I have actually been playing
> > > > with a prototype
> > > > refactoring of getmail to not just support but require a recent
> > > > Python 3.x
> > > > version.  Such a project would give me the opportunity to
> > > > remove a lot of
> > > > historical cruft and backwards-compatibility code that getmail
> > > > has accumulated
> > > > over 20+ years.
> > > 
> > > That's great.  (I thought you rejected idea to move to 3.0.)
> > > 
> > > I tried to do it around getmail 5.5 days.  (I didn't finish it)
> > 
> > 
> > FYI: I found this repo
> > https://gitlab.com/dkg/getmail/commits/python3
> > I think this is better work than my local work.
> 
> Hi Osamu,
> given that a Py3-compatible version is now available as src:getmail6,
> let's go ahead and remove getmail?
> 
> Cheers,
>     Moritz    

Bug#969177: debmake: cannot create deb for nodejs modeule

[Osamu Aoki]

Control: severity -1 important

Hi,

Thanks for the log which helps

It only breaks for javascript/nodejs.  

Javascript/nodejs support is new and needs help.  Besides

(You shouldn't file a grave RC bug without throurough review against
policy.)

On Fri, 2020-08-28 at 21:39 +0530, Pirate Praveen wrote:
> package: debmake
> version: 4.3.2-1
> severity: grave
> 
> Using pretty-ms node module as example. debmake 4.3.2-1 worked.

I don"t know how people download such nodejs tarball from where.
 Please tell me how you did it.  Please tell me how so I can test.

> (debian-sid)pravi@ilvala2:~/packaging/node-pretty-ms-7.0.0$ debmake
> I: set parameters
> I: sanity check of parameters
> I: pkg="node-pretty-ms", ver="7.0.0", rev="1"
> I: *** start packaging in "node-pretty-ms-7.0.0". ***
> I: provide node-pretty-ms_7.0.0.orig.tar.gz for non-native Debian 
> package
> I: pwd = "/home/pravi/packaging"
> I: Use existing "node-pretty-ms_7.0.0.orig.tar.gz" as upstream
> tarball
...
"debian/control", debmake.control.control(para), 
> tutorial=para["tutorial"]
>   File "/usr/lib/python3/dist-packages/debmake/control.py", line 60,
> in 
> control
> desc_long_type = debmake.read.read(
>   File "/usr/lib/python3/dist-packages/debmake/read.py", line 30, in 
> read
> with open(file, mode="r", encoding="utf-8") as f:
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/usr/share/debmake/extra0desc_long/nodejs'

Hahaha, that's my mistake.  I forgot to add place holder file.


Osamu

Bug#919058: its-tools: crashes

[Osamu Aoki]

Control: affects -1 debmake-doc

Although FTBFS bugs aren't filed, I see FTBFS on i386 and armhf with
debmake-doc 1.14-1.  amd64 and arm64 seems to do OK.

(debmake-doc 1.13-1 and older had other issues.)

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/debmake-doc.html
itstool -i xslt/docbook.its -m po/ru.mo -o po/ru/ debmake-doc.en.x02
Warning: Could not merge zh-cn translation for msgid:
Export the build environment as “LC_ALL=C.UTF-8” (see ).
Warning: Could not merge zh-cn translation for msgid:
Let’s consider that the upstream source tarball of the libfoo library is updated from 
libfoo-7.0.tar.gz to libfoo-8.0.tar.gz with a new SONAME major version which affects 
other packages.
Warning: Could not merge zh-cn translation for msgid:
For the shared library, required libraries found simply by "objdump -p /path/to/program 
| grep NEEDED" are covered by the shlib substvar.
Warning: Could not merge zh-cn translation for msgid:
If there were no -dbg packages defined in 
the debian/control file, no special care is 
needed for updating the package after the Stretch 9.0 release.
Warning: Could not merge zh-cn translation for msgid:
The addon values are listed all separated by “,”, e.g., “-w 
"python2,autoreconf"”.
Warning: Could not merge zh-cn translation for msgid:
For Autotools based packages, setting autoreconf as addon forces 
running “autoreconf -i -v -f” for every 
package building. Otherwise, autotools-dev 
as addon is used as the default.
cp po/zh-cn/debmake-doc.en.x02 debmake-doc.zh-cn.x02
rm po/zh-cn/debmake-doc.en.x02
rmdir po/zh-cn
make[2]: *** [Makefile.dbk:122: debmake-doc.de.x02] Segmentation fault
make[2]: *** Waiting for unfinished jobs
cp po/ja/debmake-doc.en.x02 debmake-doc.ja.x02
rm po/ja/debmake-doc.en.x02
rmdir po/ja
...

Bug#905259: im-config 0.38-1: Bug#905264, #905259, #905260 ... future proof

[Osamu Aoki]

Hi,

Thanks to Boyuan Yang, this bug was quickly fixed in 0.37-1.

I thought I checked by looking at contributed patch.  But these typos
were so easy to overlook ;-(

I realized, this could have been prevented by introducing build time
automatic syntax check just like we do for devscripts.  Thus I uploaded
0.38-1 to prevent any future problem.

I hope sh --> bash change for im-config should not cause problem.

Regards,

Osamu

Bug#899958: Getting ibus-anthy and ibus-pinyin back into testing

[Osamu Aoki]

On Sat, Jun 30, 2018 at 12:06:18PM +0200, intrigeri wrote:
> Hi,
> 
> do you plan to fix #899958 and #899538 soon? I could not find updates
> nor any Git repo on Salsa.

Yah, I am behind.  I just uploaded few packages with salsa.
 getmail
 maildrop
 maint-guide
...
 
> These bugs caused ibus-anthy and ibus-pinyin to be removed from
> testing, which makes it harder e.g. for derivatives (such as Tails)
> that try to start working on their migration to Debian Buster, which
> is why these problems appeared on my radar.
> 
> If you lack time to take care of it yourself soon, I can offer to NMU
> these packages in order to set the maintainer address to person listed
> in the Uploaders field who did most of the recent uploads. Just let me
> know :)

You are welcomed to do so.  Just move old alioth data from
alioth-archive.

Osamu

Bug#897554: maint-guide: FTBFS: dh_install: missing files, aborting

[Osamu Aoki]

Hi Boyuan Yang,

On Wed, May 02, 2018 at 10:59:48PM +0200, Lucas Nussbaum wrote:
> Source: maint-guide
> Version: 1.2.40
> Severity: serious
> Tags: buster sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20180502 qa-ftbfs
> Justification: FTBFS on amd64
> 
> Hi,
> 
> During a rebuild of all packages in sid, your package failed to build on
> amd64.
> 
> Relevant part (hopefully):
> >  fakeroot debian/rules binary
> > dh  binary
> >dh_testroot
> >dh_prep
> >dh_auto_install
> >dh_install
> > dh_install: Cannot find (any matches for) "tmp/maint-guide.zh-cn.pdf" 
> > (tried in ., debian/tmp)
> > 
> > dh_install: maint-guide-zh-cn missing files: tmp/maint-guide.zh-cn.pdf
> > dh_install: Cannot find (any matches for) "tmp/maint-guide.zh-tw.pdf" 
> > (tried in ., debian/tmp)
> > 
> > dh_install: maint-guide-zh-tw missing files: tmp/maint-guide.zh-tw.pdf
> > dh_install: missing files, aborting
> > make: *** [debian/rules:35: binary] Error 25
> 
> The full build log is available from:
>http://aws-logs.debian.net/2018/05/02/maint-guide_1.2.40_unstable.log
> 
> A list of current common problems and possible solutions is available at
> http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute!
> 
> About the archive rebuild: The rebuild was done on EC2 VM instances from
> Amazon Web Services, using a clean, minimal and up-to-date chroot. Every
> failed build was retried once to eliminate random failures.

Can you look into this problem?  Is this tool chain problem or missiong
dependency package?

I thought you enabled zh-* build since tool chain is now ready...

Regards,

Osamu

Bug#894320: ibus: Drop Build-Depends on gconf2

[Osamu Aoki]

Hi,

I trust your patch is a good one.  I don't have time now to update for
upload.

Please commit them to salsa and upload with my pre-approval, if you can
also update git repo to the new salsa site:
 https://salsa.debian.org/debian/ibus

Also update maintainer group address to the new one as:
 debian-input-met...@lists.debian.org

Regards,

Osamu

Bug#892382: devscripts: FTBFS in mipsel/mips64el: uscan_ftp test timeouts

[Osamu Aoki]

Hi,

I am a bit confused...

On Fri, Mar 09, 2018 at 05:51:42PM +0100, Mattia Rizzolo wrote:
> On Sat, Mar 10, 2018 at 01:30:20AM +0900, Osamu Aoki wrote:
> > I don't see my patchies applied on salsa git repo.
> 
> Yes they are.
> 
> > I guess you are testing my old commit to alioth.
> 
> I'm not _testing_ anything, this is with commit

Where can I find this commit? Alith or salsa?  URL, please.

> 77ecff2e9b18c74e8391aa0c8dccdd86a50544d5 that contains your changes

I don't see this in salsa.

> below.
> 
> > I found out that using fixed port was problematic.  So I fixed this
> > bug.
> > If you squish my changes to a single patch, this should make a clean commit.
> > 
> > commit af4594ec380d78ebf2586e8d22299800be2bf06f (HEAD -> master, 
> > origin/master, origin/HEAD)
> > commit 363144086f16db9a9f944ee71012efd09a737126
> > commit 50844c1ba710eebfb7645e07416e7377a5dbd495 (wip)
> > commit 656c66fcfe41da0e5851e4e7e1c6e8caa2c535e8
> 
> All these 4 commits were included in the release, and it's failing with
> them.

Is this your private repo?

Let's see the same thing first ;-)

Osamu

Bug#892382: devscripts: FTBFS in mipsel/mips64el: uscan_ftp test timeouts

[Osamu Aoki]

Hi,

On Thu, Mar 08, 2018 at 05:22:40PM +0100, Mattia Rizzolo wrote:
> Source: devscripts
> Version: 2.18.1
> Severity: serious
> X-Debbugs-Cc: Osamu Aoki <os...@debian.org>
> 
> Hi Osamu-san :)
> 
> the new uscan_ftp tests seems to misbehave on mipsel/mips64el.
> Just to mention one:
> 
> |testWatch4NonNativeDlUversion
> |FTP starting ... /tmp/tmp.XEqC4nYhhq/repo
> |uscan warn: In directory ., downloading
> |  ftp://127.0.0.1:37207/0.0/foo/ooo/foo-0.0.tar.gz.asc failed: 401 
> [LWP::Protocol::MyFTP] Timeout
> |uscan die: FAIL Checking OpenPGP signature (no signature file downloaded).
> |uscan: Newest version of foo on remote site is 0.0, specified download 
> version is 0.0
> |ASSERT:uscan: exit_code!=0 but exit_code=0 expected:<255> but was:<0>
> |ASSERT:foo_0.0.orig.tar.gz missing: opts=pgpsigurlmangle=s/$/.asc/ 
> @@@url@@@([\.\d]+)/(.+)/(.+)/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian 
> uupdate
> |./test_uscan_ftp: 293: cd: can't cd to /tmp/tmp.XEqC4nYhhq/foo-0.0
> |ASSERT:pristine tarball is not extracted
> |tail: cannot open 'debian/changelog' for reading: No such file or directory
> |dpkg-parsechangelog: error: tail of debian/changelog subprocess returned 
> exit status 1
> |ASSERT:uscan: Version should be 0.0-1 but  expected:<> but was:<0.0-1>
> 
> Could you please have a look at it?

I don't see my patchies applied on salsa git repo.

I guess you are testing my old commit to alioth.  I found out that using fixed 
port was problematic.  So I fixed this bug.  If you squish my changes to a 
single patch, this should make a clean commit.


commit af4594ec380d78ebf2586e8d22299800be2bf06f (HEAD -> master, origin/master, 
origin/HEAD)
Author: Osamu Aoki <os...@debian.org>
Date:   Thu Feb 1 04:24:07 2018 +

uscan: Use random available port for FTP

Fixed port was problematic.
So use the available random user port.

Signed-off-by: Osamu Aoki <os...@debian.org>

commit 363144086f16db9a9f944ee71012efd09a737126
Author: Osamu Aoki <os...@debian.org>
Date:   Thu Feb 1 02:24:37 2018 +

uscan: changelog update

Signed-off-by: Osamu Aoki <os...@debian.org>

commit 50844c1ba710eebfb7645e07416e7377a5dbd495 (wip)
Author: Osamu Aoki <os...@debian.org>
Date:   Thu Feb 1 01:59:00 2018 +0000

uscan: Add example for decompress

Example watch file for the signature made for the decompressed tarball.

Signed-off-by: Osamu Aoki <os...@debian.org>

commit 656c66fcfe41da0e5851e4e7e1c6e8caa2c535e8
Author: Osamu Aoki <os...@debian.org>
Date:   Wed Jan 31 22:50:29 2018 +

uscan: Fix signature extension and add ftp test

     * New ftp based test
 * Compression and repacking test
 * Signature test with decompress
 * Debug signature extension of uscan

Signed-off-by: Osamu Aoki <os...@debian.org>

commit 8751486cd98955c3ae359381f3ac5bc3f727dbf8
Author: Mattia Rizzolo <mat...@debian.org>
Date:   Thu Jan 25 13:35:27 2018 +0100

reproducible-check: Instruct to install python3-xdg if missing.
.

Osamu

Bug#884807: getmail: does not ship /usr/bin/getmail

[Osamu Aoki]

Hi,

On Wed, Dec 20, 2017 at 11:23:54AM -0500, Daniel Kahn Gillmor wrote:
> On Thu 2017-12-21 00:48:44 +0900, Osamu Aoki wrote:
> >
> >   # Always use debian/getmail as destination (not debian/tmp)
> >   # even when dummy getmail4 package exists
> >   override_dh_auto_install:
> >   dh_auto_install --destdir debian/getmail
> 
> ok, it looks like i tend to prefer the more declarative style, and you
> prefer the imperative style.  You're the maintainer, so your decision
> goes :)

Just for the record, let me clarify my position.  I thought about this
concern.

> Just so you know why i prefer the declarative style, though:

I also prefer the declarative style for *splitting* generated files into
*multiple* binary packages from the debian/tmp directory.  But that is
for *splitting* into binary packages ;-)

> i think with your imperative changes to the debian/rules makefile, a new
> upstreamversion that injects something funky into the filesystem will
> just have it happen (possibly without the maintainer noticing).

I see your point.  You are considering *.install as a one level of
security check.  Then you should raise concern to the current
dh_auto_install behavior (maybe since debhelper compat>=4) which doesn't
use the debian/tmp directory as the DESTDIR.  All
"single_binary_package"-type packages use the debian/
directory as the DESTDIR and ship all generated files without filtering.

I remember this DESTDIR choice was flip-flopped before debhelper compat
4.  But the current choice of DESTDIR is quite stable since then. 

> With the declarative approach i'd outlined (that is, listing everything
> explicitly in debian/getmail.{docs,install,manpages}, and including
> dh_missing --fail-missing), the packager has to actively acknowledge
> changes to the installed filesystem, which i like as a double-check
> during packaging itself.

Please note there were imperative changes to the debian/rules even in
your proposed version which got carried over from my previous script.  I
mean "rm -rf debian/.../usr/share/doc/getmail-*".  I thought installing
documentation from upstream installed ones in DESTDIR are better than
copying from the source tree.  That was the reason why I changed from
"rm -rf" to "mv".

> > So when we drop getmail4 transition package, migration needs only
> > dropping it in the debian/control field.
> 
> I think that would happen either way :)

Once we drop getmail4 in buster+1, we will be back to the
"single_binary_package"-type package unless we change dh_auto_install to
override its default by setting --destdir=debian/tmp.
I thought that is a bit overkill.  Instead, I set
--destdir=debian/getmail since this is practically a single binary
package except for generating a dummy package.  Then with "mv" already
applied, I just don't need to have *.install.  That is what happened.

> anyway, just thought i'd explain my reasoning.  I'm happy to follow your
> lead on the package.

No problem.  Since I noticed your rationale, I just wanted to explain my
rationale ;-)

Osamu

Bug#884807: getmail: does not ship /usr/bin/getmail

[Osamu Aoki]

On Tue, Dec 19, 2017 at 06:36:15PM -0500, Daniel Kahn Gillmor wrote:
> On Tue 2017-12-19 16:47:01 -0500, Daniel Kahn Gillmor wrote:
> > somehow /usr/bin/getmail got dropped from the getmail 5.5-1 packaging :/
> 
> I've pushed some changes to the master branch of
> https://anonscm.debian.org/git/collab-maint/getmail.git that resolve
> this matter for me.
> 
> they also do a little bit of packaging cleanup.  I hope they're useful!

Thanks. I realized your change just before upload.  Good.
Yes this cleans my rough edges.

I had some changes locally with a bit different style too ;-) I have
debian/rules with:

  # Always use debian/getmail as destination (not debian/tmp)
  # even when dummy getmail4 package exists
  override_dh_auto_install:
  dh_auto_install --destdir debian/getmail

So when we drop getmail4 transition package, migration needs only
dropping it in the debian/control field.

So I made a bit more changes to simplify packaging.

Osamu

Bug#882059: python-ibus package is missing in testing repository

[Osamu Aoki]

Hi,

Thanks for the reply ;-)

Please don't feel to "sorry".  My comments are not meant to blame you but to
be educational one to get you involved smoothly.

On Sat, Dec 16, 2017 at 03:04:46PM -0800, Van Goodwin wrote:
> Hello,
...
> I did use this package seriously.  I have used it since I first started using
> Debian.  It is necessary to be able to use the tegaki handwriting recognizer 
> as
> an input method.

I see.
 
> Well, no one using any current version of Debian is using it now since it is
> broken.  According to a post on Github, the tegaki project is no longer being
> maintained so there will be no fix coming from them.  I expect that this issue
> will not get fixed and ibus-tegaki will be removed from stable, testing, and
> unstable.  It is a shame since it was the best Japanese handwriting input
> method I have found for Linux.  The tegaki recognizer still works, but without
> integration with ibus or scim working  and no way to copy to the clipboard, it
> is useless for anything except for practicing one's handwriting.

Can you work on updating the script?  Hints are in my previous mail.

I have many backlog on important packages such as ibus itself.

Your help is most appreciated.

Regards,

Osamu
 

Bug#882059: python-ibus package is missing in testing repository

[Osamu Aoki]

control: tags -1 - l10n
control: retitle -1 rewrite ibus-tegaki with GObject introspection (GI)
control: reassign -1 ibus-tegaki
control: tags -1 jessie
control: tags -1 stretch

Hi,

This bug report was very difficult to understand for me initially ...
When filing bug a report, please make sure to explain situation clearly.

Also, are you using this package seriously or were you just trying to
use this package for curiosity...

On Sat, Nov 18, 2017 at 02:23:41AM -0800, Ben Goodwin wrote:
> Package: python-ibus
> Version: 1.5.1.is.1.4.2-1~bpo70+1

What is this o-o-stable package version doing here?.

o-o-stable1.4.1-9+deb7u1
o-o-bpo   1.5.1.is.1.4.2-1~bpo70+1
oldstable 1.5.9-1
stable1.5.14-3
testing   1.5.14-3
unstable  1.5.14-3
Ubuntu1.5.14-3ubuntu1

> Severity: grave

When you file a GRAVE bug with the not-exactly-correct facts, you are
causing negative service to many people.  Please be careful.  I hope you
understand this.  In short, there is no bug for ibus.  Wrong package to
blame!  Unless you are very sure, don't use this level of bug.

> Tags: l10n

For case like this, please don't label ibus bug as i10n.  This is
neither translation error, not the encoding problem, nor localization
specific font rendering problem.

> Justification: renders package unusable

That's because ibus-tegaki is broken for the new upstream core package.

> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')


My intial thought ...

 Why you have oddly old package installed?  Are you doing this
 intentionally?  (Or did you forgot to do "dist-upgrade"?  Using
 "upgrade" only has bad side effects and not recommended to update to the
 newer releases.   

> The package python-ibus is missing from the testing repository. 

That is intentional.  It's upstream choice.  Keeping up with upstream
core package changes are the responsibility of leaf packages such as
ibus-tegaki.

> The latest python-ibus package available is in wheezy-backports. 

>I am using
> Debian testing (buster), so python-ibus is not available to me.

Sure.  That is the way it is recently.  All maintained packages which
used to use ibus-python has been updated.

> This causes ibus-tegaki to fail which prevents me from launching the
> tegaki Japanese/Chinese handwriting IME via the ibus hotkeys and tray
> icon.

I see.  When python binding is migrated to GI, ibus-tegaki update its
code.  If no one volunteers to update, that happens.  I doubt Li is not
so active DD if I am not mistaken.  If anyone is willing to maintain it,
please step up.

It's trivial rerwites which upstream may have done it or other distro
may have.

The trick is to bind python scripts to ibus via GI.  I don't have time
now.  You can get the idea from ibus-pinyin bug reports like:
 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=746969

> According to the tegaki developers, python-ibus is a dependency for
> ibus-tegaki, even though the maintainer of the ibus-tegaki Debian
> package never included python-ibus as a dependency. In the past I have
> been able to get ibus-tegaki to work by installing python-ibus, but that
> is not possible now. I tried installiing the version of python-ibus
> available in wheezy-backports, 

Now I see the reason for the strange version in this bug report.

> but it does not work, presumably because it
> was compiled for wheezy and not for the current testing version
> (buster).
> 
> I request that the python-ibus package be made available in the current
> Debian repositories since it is required for ibus-tegaki and possibly
> other packages to function.

No that is not the way to fix this bug.

Reassigning bug to ibus-tegaki  If no one takes on this bug, ibus-tegaki
shall be removed from testing/unstable.  GRAVE: true for ibus-tegaki.

Wait, ibus-tegaki can't work with the jessie nor stretch version too as
I observe.  They got released without people complaining...

Hmmm... maybe no one is using this package... it should be removed from
all stable/testing/unstable

Osamu

Bug#874708: anthy (EUCJP->UTF-8) and *-anthy packages

[Osamu Aoki]

Hi,

On Mon, Nov 06, 2017 at 05:28:13AM -0500, Jeremy Bicha wrote:
> Control: tags -1 +moreinfo
>
> What exactly is the problem the missing library causes? This sounds
> like a normal library transition that Debian does all the time. The
> old library (libanthy0) is removed because everything in Debian will
> build against the new library (libanthy1).

No ABI change is involved.  Data passed from library call is now encoded
in UTF-8 instead of EUCJP by the new library (or I should say the new
library use new data in anthy-common in UTF-8)

> Osamu, can we lower the severity of this bug so that this package can
> migrate to testing?

See below.

On Tue, Nov 07, 2017 at 07:04:54PM +0900, d...@debian.org wrote:
> Control: tags -1 + moreinfo
> 
> 1:0.3-6 has been uploaded. Can we close this bug?

Actually, we may need to upload few manually updated packages.

One package just uploaded with such manual patch by NOKUBI Takatsugu.

  ibus-anthy_1.5.9-2.1_amd64.changes ACCEPTED unstable

So at least anthy is usable with ibus now in unstable.

Are *-anthy packages uploaded to cope with this new anthy just like ibus-anthy?
 fcitx-anthy
 hime-anthy
 scim-anthy
 uim-anthy

Otherwise, they are broken in unstable now. (I did not have time to test
them yet)

Even these are updated with manual patches, all these updated package
needs to move together from unstable to testing.  I am not very familiar
with this ABI breaking library update.  We may need to add BREAKS: to
anthy to ensure this.  (I am not sure)  That may reqire to upload -7 for
anthy.

Anyway, these need to be properly coordinated.

Jeremy, your guidance is highly appreciated.

Osamu

Bug#873860: [Pkg-ime-devel] Bug#873860: ibus-anthy FTBFS: UnicodeDecodeError: 'euc_jp' codec can't decode byte 0xe5 in position 46: illegal multibyte sequence

[Osamu Aoki]

Hi,

On Fri, Oct 27, 2017 at 04:38:08PM +0900, Takatsugu Nokubi wrote:
> On Fri, 22 Sep 2017 23:20:39 +0900 Osamu Aoki <aoki.os...@gmail.com> wrote:
> > On Fri, Sep 22, 2017 at 09:14:22AM +0200, John Paul Adrian Glaubitz wrote:
> > > This FTBFS can be easily fixed with:
> > >
> > > --- ibus-anthy-1.5.9.orig/data/zipcode-textdic.py
> > > +++ ibus-anthy-1.5.9/data/zipcode-textdic.py
> > > @@ -21,7 +21,7 @@ if len(sys.argv) < 2:
> > >  anthy_zipfile = sys.argv[1]
> > >
> > >  try:
> > > -contents = codecs.open(anthy_zipfile, 'r', 'euc_jp').read()
> > > +contents = codecs.open(anthy_zipfile, 'r', 'utf-8').read()
> > >  except UnicodeDecodeError as e:
> > >  print('Your file is not eucJP? %s' % anthy_zipfile, file=sys.stderr)
> > >  contents = open(anthy_zipfile).read()
> 
> I think it seems right way.
> 
> > Question is how to coordinate with other anthy users and the latest
> > ibus.
> 
> I had to see the upstream code, and the script seems not there.
> https://github.com/phuang/ibus-anthy/tree/master/data
> 
> I think we can choose the 2 ways:
> 
> 1. just apply this patch
> It seems not come from the upstream, so we don't need to take
> care about it.
> 
> 2. fix to work with both encoding zipfile
> When the script get the exception, retry to open as utf-8, it may work
> both version of anthy.


I think 1 should be the way to move forward.

I thought about uploading ibus first but maybe I was wrong.  If you have
time, please upload fixed package.

The only thing to do maybe adding conflict to anthy in sid 1:0.3-6
to all the older non-UTF-8 compatible IM packages of
 ibus-anthy
 uim-anthy
 fcitx-anthy
as 1:0.3-7.  Then we can make all these packages move together from sid
to testing.  

Osamu

Bug#878270: This NMU of anthy is not good enough

[Osamu Aoki]

Source: anthy
Severity: grave
Version: 1:0.3-5.1

In short, my NMU was bad.

I need to upload new version based on 1:0.3-5.
(Maybe with typo fix.)

Although NMU tries to accomodate slow library migration, it doesn't
reach its goal.

This is due to binary packages anthy and anthy-common arn't
versioned.  Itis too much and fixing ibus-anthy and letting it
migrate together is better.

-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- debconf information excluded

Bug#873860: FTBFFS can't be in buster

[Osamu Aoki]

control: tags -1 - buster
thanks

This FTBFS was caused by the upload of anthy to unstable/sid.  

Those broken versions are blocked by the RC bug to stay in unstable.

The testing/buster has the same version of anthy as the one in
stable/stretch.

Thus tagging this as buster bug is wrong ;-)  Also, my NMU'd version of
anthy (once accepted to unstable) should fix issues in unstable and
allow anthy package transition to buster without problem.

So I am dropping the buster tag.

Osamu

Bug#873860: This is anthy packaging bug

[Osamu Aoki]

control: severity -1 important
control: tags -1 pending
thanks

I just made an NMU of anthy with delayed 7 days.

So this will not be pressing problem.

Of course, it will be nice to update packages to newer version.

But the order will be ibus and ibus-anthy :-)

Regards,

Osamu

Bug#789927: This is bug in anthy

[Osamu Aoki]

control: severity -1 important
control: tags -1 pending
thanks

Hi

With the delayed 7 day upload of anthy, this problem is gone.

Osamu

Bug#789927: uploaded as delayed 7-days

[Osamu Aoki]

Hi,

Uploaded after adding changelog entry as delayed 7 days.

Regards,

Osamu
From 506f093cbd075df4491001d4b85f59e0d116f86e Mon Sep 17 00:00:00 2001
From: Osamu Aoki <os...@debian.org>
Date: Fri, 29 Sep 2017 22:56:53 +0900
Subject: [PATCH] Bump -dev package name

Since this is not just EUC -> UTF-8 change but is a big change which requires
other dependency packages to be updated to get them build, let's bump *-dev
package to prevent FTBFS.  This change should allow anthy to move to testing
without waiting for all ibus/fcitx/uim updates to the new libraries.  Here,
coexistence with both version is the key.

Also this bumps soname of libanthyinput to avoid upgrade problem.

In this patch unused debian patches are removed.

Signed-off-by: Osamu Aoki <os...@debian.org>
---
 debian/changelog   | 10 ++
 debian/control | 14 +++-
 debian/{libanthy-dev.docs => libanthy1-dev.docs}   |  0
 ...{libanthy-dev.install => libanthy1-dev.install} |  0
 ...nput-dev.install => libanthyinput1-dev.install} |  0
 ...banthyinput0.install => libanthyinput1.install} |  0
 .../patches/_libanthyinput_bump_soname.patch   | 18 ++
 debian/patches/10_Makefile.am_remove-elc   | 39 --
 debian/patches/series  |  2 +-
 debian/patches/utf8_heartmark  | 10 --
 src-util/Makefile.am   |  1 +
 11 files changed, 35 insertions(+), 59 deletions(-)
 rename debian/{libanthy-dev.docs => libanthy1-dev.docs} (100%)
 rename debian/{libanthy-dev.install => libanthy1-dev.install} (100%)
 rename debian/{libanthyinput-dev.install => libanthyinput1-dev.install} (100%)
 rename debian/{libanthyinput0.install => libanthyinput1.install} (100%)
 create mode 100644 debian/patches/_libanthyinput_bump_soname.patch
 delete mode 100644 debian/patches/10_Makefile.am_remove-elc
 delete mode 100644 debian/patches/utf8_heartmark

diff --git a/debian/changelog b/debian/changelog
index 76db720..bf476a3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+anthy (1:0.3-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload. 
+  * Fix upgrade problem by bumping soname.  Closes: #789927, #874708
+  * Made lib* and lib*-dev package name include soname major version
+to enable smooth and slow migration without many FTBFS and install
+problems.  Closes: #789927, #788253, #789914, #789927, #810351, #873860
+
+ -- Osamu Aoki <os...@debian.org>  Sat, 30 Sep 2017 01:32:00 +0900
+
 anthy (1:0.3-5) unstable; urgency=medium
 
   * debian/control (Breaks, Replaces): Fix version specification using <<,
diff --git a/debian/control b/debian/control
index fd1e137..dea62fb 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Description: Japanese kana-kanji conversion - dictionary
  hiragana text to mixed kana and kanji.  It is implemented as a library
  and stores private information in ~/.anthy/.
  .
- This package provides common dictonary data files.
+ This package provides common dictionary data files.
 
 Package: anthy-el
 Section: lisp
@@ -55,7 +55,7 @@ Description: Japanese kana-kanji conversion - runtime library
  .
  This package provides runtime shared libraries for Anthy.
 
-Package: libanthy-dev
+Package: libanthy1-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
@@ -68,13 +68,11 @@ Description: Japanese kana-kanji conversion - runtime library
  This package provides the files necessary for compiling programs that
  use Anthy.
 
-Package: libanthyinput0
+Package: libanthyinput1
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
-Replaces: libanthy0 (<< 1:0.3-1)
-Breaks: libanthy0 (<< 1:0.3-1)
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Japanese kana-kanji conversion - runtime library for input
  Anthy is kana-kanji conversion engine for Japanese.  It converts
@@ -83,13 +81,11 @@ Description: Japanese kana-kanji conversion - runtime library for input
  .
  This package provides shared library for input method.
 
-Package: libanthyinput-dev
+Package: libanthyinput1-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Replaces: libanthy-dev (<< 1:0.3-1)
-Breaks: libanthy-dev (<< 1:0.3-1)
-Depends: libanthyinput0 (= ${binary:Version}), ${misc:Depends}
+Depends: libanthyinput1 (= ${binary:Version}), ${misc:Depends}
 Description: Japanese kana-kanji conversion - runtime library for input
  Anthy is kana-kanji conversion engine for Japanese.  It converts
  hiragana text to mixed kana and kanji.  It is implemented as a library
diff --git a/debian/libanthy-dev.docs b/debian/libanthy1-dev.docs
similarity index 100%
rename from debian/libanthy-dev.docs
rename to debian/libanthy1-dev.docs
diff --git a/debian/libanthy-dev.install b/debian/libanthy1-dev.install
similarity index 100%
rename from debian/liba

Bug#789927: Updated patch

[Osamu Aoki]

control: reassign 789927 src:anthy
control: reassign 874708 src:anthy
forcemerge 789927 874708

Hi,

Here is an updated patch with matched package name.

I will make delayed upload.

Regards,

Osamu
From d1c044efb9bca24f60c3a8241e249425ade52a3b Mon Sep 17 00:00:00 2001
From: Osamu Aoki <os...@debian.org>
Date: Fri, 29 Sep 2017 22:56:53 +0900
Subject: [PATCH] Bump -dev package name

Since this is not just EUC -> UTF-8 change but is a big change which requires
other dependency packages to be updated to get them build, let's bump *-dev
package to prevent FTBFS.  This change should allow anthy to move to testing
without waiting for all ibus/fcitx/uim updates to the new libraries.  Here,
coexistence with both version is the key.

Also this bumps soname of libanthyinput to avoid upgrade problem.

In this patch unused debian patches are removed.

Signed-off-by: Osamu Aoki <os...@debian.org>

bump

Signed-off-by: Osamu Aoki <os...@debian.org>
---
 debian/control | 14 +++-
 debian/{libanthy-dev.docs => libanthy1-dev.docs}   |  0
 ...{libanthy-dev.install => libanthy1-dev.install} |  0
 ...nput-dev.install => libanthyinput1-dev.install} |  0
 ...banthyinput0.install => libanthyinput1.install} |  0
 .../patches/_libanthyinput_bump_soname.patch   | 18 ++
 debian/patches/10_Makefile.am_remove-elc   | 39 --
 debian/patches/series  |  2 +-
 debian/patches/utf8_heartmark  | 10 --
 src-util/Makefile.am   |  1 +
 10 files changed, 25 insertions(+), 59 deletions(-)
 rename debian/{libanthy-dev.docs => libanthy1-dev.docs} (100%)
 rename debian/{libanthy-dev.install => libanthy1-dev.install} (100%)
 rename debian/{libanthyinput-dev.install => libanthyinput1-dev.install} (100%)
 rename debian/{libanthyinput0.install => libanthyinput1.install} (100%)
 create mode 100644 debian/patches/_libanthyinput_bump_soname.patch
 delete mode 100644 debian/patches/10_Makefile.am_remove-elc
 delete mode 100644 debian/patches/utf8_heartmark

diff --git a/debian/control b/debian/control
index fd1e137..dea62fb 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Description: Japanese kana-kanji conversion - dictionary
  hiragana text to mixed kana and kanji.  It is implemented as a library
  and stores private information in ~/.anthy/.
  .
- This package provides common dictonary data files.
+ This package provides common dictionary data files.
 
 Package: anthy-el
 Section: lisp
@@ -55,7 +55,7 @@ Description: Japanese kana-kanji conversion - runtime library
  .
  This package provides runtime shared libraries for Anthy.
 
-Package: libanthy-dev
+Package: libanthy1-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
@@ -68,13 +68,11 @@ Description: Japanese kana-kanji conversion - runtime library
  This package provides the files necessary for compiling programs that
  use Anthy.
 
-Package: libanthyinput0
+Package: libanthyinput1
 Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
-Replaces: libanthy0 (<< 1:0.3-1)
-Breaks: libanthy0 (<< 1:0.3-1)
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Japanese kana-kanji conversion - runtime library for input
  Anthy is kana-kanji conversion engine for Japanese.  It converts
@@ -83,13 +81,11 @@ Description: Japanese kana-kanji conversion - runtime library for input
  .
  This package provides shared library for input method.
 
-Package: libanthyinput-dev
+Package: libanthyinput1-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Replaces: libanthy-dev (<< 1:0.3-1)
-Breaks: libanthy-dev (<< 1:0.3-1)
-Depends: libanthyinput0 (= ${binary:Version}), ${misc:Depends}
+Depends: libanthyinput1 (= ${binary:Version}), ${misc:Depends}
 Description: Japanese kana-kanji conversion - runtime library for input
  Anthy is kana-kanji conversion engine for Japanese.  It converts
  hiragana text to mixed kana and kanji.  It is implemented as a library
diff --git a/debian/libanthy-dev.docs b/debian/libanthy1-dev.docs
similarity index 100%
rename from debian/libanthy-dev.docs
rename to debian/libanthy1-dev.docs
diff --git a/debian/libanthy-dev.install b/debian/libanthy1-dev.install
similarity index 100%
rename from debian/libanthy-dev.install
rename to debian/libanthy1-dev.install
diff --git a/debian/libanthyinput-dev.install b/debian/libanthyinput1-dev.install
similarity index 100%
rename from debian/libanthyinput-dev.install
rename to debian/libanthyinput1-dev.install
diff --git a/debian/libanthyinput0.install b/debian/libanthyinput1.install
similarity index 100%
rename from debian/libanthyinput0.install
rename to debian/libanthyinput1.install
diff --git a/debian/patches/_libanthyinput_bump_soname.patch b/debian/patches/_libanthyinput_bump_soname.patch
new file mode 100644
index 000..11e8601
--- /dev/n

Bug#789927: anthy package upgrade issue

[Osamu Aoki]

control: tags -1 patch
control: severity -1 serious
control: forcemerge 789927 874708
thanks

Hi,

Let's keep this in unstable until this bug is resolved.  Otherwise lot's
of problem to other dependent packages.

Somehow,  libanthyinput0's soname version was not updated while others
were.  I think I fixed this by adjusting libtool.  This one line
addition is in debian patch but may be good idea to forward to the
upstream.

Niibe-san, you seem to be upstream too.  What do you think of libtool
setting to be upstreamed.

(It may be good idea to match package name from libanthyinput1 but
that"s cosmetic and I didn't do it here.)

Also, it will take some time for us to update ibus/fcitx/uim/...

In order to have smooth transition, I bumped -dev package version too.

This include one typo fix.

Osamu

From 6d6d67a0dfb9499bc628943236e4faaa26822006 Mon Sep 17 00:00:00 2001
From: Osamu Aoki <os...@debian.org>
Date: Fri, 29 Sep 2017 22:56:53 +0900
Subject: [PATCH] Bump -dev package name

Since this is not just EUC -> UTF-8 change but is a big change which requires
other dependency packages to be updated to get them build, let's bump *-dev
package to prevent FTBFS.  This change should allow anthy to move to testing
without waiting for all ibus/fcitx/uim updates to the new libraries.  Here,
coexistence with both version is the key.

Also this bumps soname of libanthyinput to avoid upgrade problem.

In this patch unused debian patches are removed.

Signed-off-by: Osamu Aoki <os...@debian.org>

bump

Signed-off-by: Osamu Aoki <os...@debian.org>
---
 debian/control |  8 ++---
 debian/{libanthy-dev.docs => libanthy1-dev.docs}   |  0
 ...{libanthy-dev.install => libanthy1-dev.install} |  0
 .../patches/_libanthyinput_bump_soname.patch   | 18 ++
 debian/patches/10_Makefile.am_remove-elc   | 39 --
 debian/patches/series  |  2 +-
 debian/patches/utf8_heartmark  | 10 --
 src-util/Makefile.am   |  1 +
 8 files changed, 22 insertions(+), 56 deletions(-)
 rename debian/{libanthy-dev.docs => libanthy1-dev.docs} (100%)
 rename debian/{libanthy-dev.install => libanthy1-dev.install} (100%)
 create mode 100644 debian/patches/_libanthyinput_bump_soname.patch
 delete mode 100644 debian/patches/10_Makefile.am_remove-elc
 delete mode 100644 debian/patches/utf8_heartmark

diff --git a/debian/control b/debian/control
index fd1e137..30bf03d 100644
--- a/debian/control
+++ b/debian/control
@@ -28,7 +28,7 @@ Description: Japanese kana-kanji conversion - dictionary
  hiragana text to mixed kana and kanji.  It is implemented as a library
  and stores private information in ~/.anthy/.
  .
- This package provides common dictonary data files.
+ This package provides common dictionary data files.
 
 Package: anthy-el
 Section: lisp
@@ -55,7 +55,7 @@ Description: Japanese kana-kanji conversion - runtime library
  .
  This package provides runtime shared libraries for Anthy.
 
-Package: libanthy-dev
+Package: libanthy1-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
@@ -73,8 +73,6 @@ Section: libs
 Architecture: any
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
-Replaces: libanthy0 (<< 1:0.3-1)
-Breaks: libanthy0 (<< 1:0.3-1)
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: Japanese kana-kanji conversion - runtime library for input
  Anthy is kana-kanji conversion engine for Japanese.  It converts
@@ -87,8 +85,6 @@ Package: libanthyinput-dev
 Section: libdevel
 Architecture: any
 Multi-Arch: same
-Replaces: libanthy-dev (<< 1:0.3-1)
-Breaks: libanthy-dev (<< 1:0.3-1)
 Depends: libanthyinput0 (= ${binary:Version}), ${misc:Depends}
 Description: Japanese kana-kanji conversion - runtime library for input
  Anthy is kana-kanji conversion engine for Japanese.  It converts
diff --git a/debian/libanthy-dev.docs b/debian/libanthy1-dev.docs
similarity index 100%
rename from debian/libanthy-dev.docs
rename to debian/libanthy1-dev.docs
diff --git a/debian/libanthy-dev.install b/debian/libanthy1-dev.install
similarity index 100%
rename from debian/libanthy-dev.install
rename to debian/libanthy1-dev.install
diff --git a/debian/patches/_libanthyinput_bump_soname.patch b/debian/patches/_libanthyinput_bump_soname.patch
new file mode 100644
index 000..11e8601
--- /dev/null
+++ b/debian/patches/_libanthyinput_bump_soname.patch
@@ -0,0 +1,18 @@
+Description: Bump soname also for libanthyinput
+ libanthyinput0 fails to upgrade from 'sid' since it trying 
+ to overwrite /usr/lib/x86_64-linux-gnu/libanthyinput.so.0.0.0.
+ Bumping soname as other libraries with this patch, this bug
+ is avoided.  Closes: #789927
+Author: os...@debian.org
+Bug-Debian: https://bugs.debian.org/789927
+Last-Update: 2017-09-29
+
+--- anthy-0.3.orig/src-util/Makefile.am
 anthy-0.3/src-util/Makefile.am
+@@ -26,5 +26,6 @@ lib_LTLIB

Bug#873860: ibus-anthy FTBFS: UnicodeDecodeError: 'euc_jp' codec can't decode byte 0xe5 in position 46: illegal multibyte sequence

[Osamu Aoki]

On Fri, Sep 22, 2017 at 09:14:22AM +0200, John Paul Adrian Glaubitz wrote:
> Source: ibus-anthy
> Version: 1.5.9-2
> Followup-For: Bug #873860
> 
> Hola!
> 
> This FTBFS can be easily fixed with:
> 
> --- ibus-anthy-1.5.9.orig/data/zipcode-textdic.py
> +++ ibus-anthy-1.5.9/data/zipcode-textdic.py
> @@ -21,7 +21,7 @@ if len(sys.argv) < 2:
>  anthy_zipfile = sys.argv[1]
>  
>  try:
> -contents = codecs.open(anthy_zipfile, 'r', 'euc_jp').read()
> +contents = codecs.open(anthy_zipfile, 'r', 'utf-8').read()
>  except UnicodeDecodeError as e:
>  print('Your file is not eucJP? %s' % anthy_zipfile, file=sys.stderr)
>  contents = open(anthy_zipfile).read()
> 
> I don't know whether it has any other ramifications but after
> applying the patch, ibus-anthy builds fine again and I can even
> type Japanese again.
> 
> すごいね？
> 
> アドリアン

LGTM.

I think you are right.

Question is how to coordinate with other anthy users and the latest
ibus.

If you have time to go over all the dependency package coordination,
please go ahead start uploading patched packages. I am a bit short on
time.  I have not updated ibus to Debian.  Also, I think anthy should
have bumped library version to prevent this breakage in unstable.

But I haven't checked details.  You are welcomed to lead this task and
upload as long as you will take responsibility.

Osamu

Bug#873860: ibus-anthy FTBFS: UnicodeDecodeError: 'euc_jp' codec can't decode byte 0xe5 in position 46: illegal multibyte sequence

[Osamu Aoki]

On Fri, Sep 22, 2017 at 09:14:22AM +0200, John Paul Adrian Glaubitz wrote:
> Source: ibus-anthy
> Version: 1.5.9-2
> Followup-For: Bug #873860
> 
> Hola!
> 
> This FTBFS can be easily fixed with:
> 
> --- ibus-anthy-1.5.9.orig/data/zipcode-textdic.py
> +++ ibus-anthy-1.5.9/data/zipcode-textdic.py
> @@ -21,7 +21,7 @@ if len(sys.argv) < 2:
>  anthy_zipfile = sys.argv[1]
>  
>  try:
> -contents = codecs.open(anthy_zipfile, 'r', 'euc_jp').read()
> +contents = codecs.open(anthy_zipfile, 'r', 'utf-8').read()
>  except UnicodeDecodeError as e:
>  print('Your file is not eucJP? %s' % anthy_zipfile, file=sys.stderr)
>  contents = open(anthy_zipfile).read()
> 
> I don't know whether it has any other ramifications but after
> applying the patch, ibus-anthy builds fine again and I can even
> type Japanese again.
> 
> すごいね？
> 
> アドリアン

LGTM.

I think you are right.

Question is how to coordinate with other anthy users and the latest
ibus.

If you have time to go over all the dependency package coordination,
please go ahead start uploading patched packages. I am a bit short on
time.  I have not updated ibus to Debian.  Also, I think anthy should
have bumped library version to prevent this breakage in unstable.

But I haven't checked details.  You are welcomed to lead this task and
upload as long as you will take responsibility.

Osamu

Bug#871493: debian-reference FTBFS

[Osamu Aoki]

control: tags -1 pending

Thanks for the tip.  Committed to git.

Now that I know better, I better make nice cover page.

Regards,

Osamu

Bug#789927: Anthy library breakage

[Osamu Aoki]

Hi,

On Tue, Sep 05, 2017 at 09:00:52AM +0900, NIIBE Yutaka wrote:
> Osamu Aoki <os...@debian.org> wrote:
> 
> Thanks.  Now, I understand (I didn't know that fully).  I should have
> learned before uploading to Sid.


After I failed to make ibus transition like your case, I made a memo as:
 https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#libnames

This sites are useful:
 https://debconf4.debconf.org/talks/dependency-hell/img0.html
 https://wiki.debian.org/Teams/ReleaseTeam/Transitions

I will check the whole situation a bit carefully to make recommendation
later, if I can.

If upstream didn't bump so name for this UTF-8 change, that complicates
things.  Did he?

> I have been using Anthy since its birth, but I only use through Emacs
> with egg.  Even if I don't use, I should be careful when I touch Debian
> package.
> 
> Today, the Emacs module egg requires total rewrite for Emacs 25, due to
> the change of Emacs (display property thing).  I was considering making
> a loadable module for Emacs for Anthy.  That was another pressure.

I see.  I may need to update im-config once you do this.

> Any suggestions are welcome.  It seems for me that it would be better
> to change the -dev package name.

I think "Use the versioned -dev package names: libfoo7-dev and
libfoo8-dev" is the way to go for this case.  But I need to check more.

Use the versioned -dev package names: libfoo7-dev and libfoo8-dev

This is the special case.
Two versions of the library source packages are allowed simultaneously in the 
archive.

 * Make all dependent packages depend on libfoo-dev.
 * Make both libfoo7-dev and libfoo8-dev provide libfoo-dev.
 * The source package needs to be renamed as libfoo7-7.0.tar.gz and 
libfoo8-8.0.tar.gz respectively from libfoo-?.0.tar.gz.
 * The package specific install file path including libfoo7 and libfoo8 
respectively for header files etc. needs to be chosen to make them 
co-installable.

Regards,

Osamu

Bug#789927: Anthy library breakage

[Osamu Aoki]

Hi,

https://bugs.debian.org/873860#10

If what NOKUBI Takatsugu's comment is correct, I wonder why anthy is
upgraded without coordinating with key users:
 ibus
 uim
 fcitx

(Please note these have many dependence packages so the testing
migration is slow if package version dependency is correctly recorded.)

I agree moving to utf8 is right thing to do but this breakage is
something we should avoid.

If -dev package version is bumped, we can have slow migration without
breaking packages depending on old anthy.  But if we share the same -dev
package name, all related package needs to be uploaded together
(otherwise we suffer long broken sid system).

I know we tend to forget about it.  (I did this for ibus killing
ibus-mozc for few months alienating many uses).

But if library change its API spec from non-utf8 to utf8, this needs to
be coordinated carefully.

I haven't checked all the facts but it seems we should have bumped
package version and set conflict with -dev etc.

Just uploading new package may fix it in sid but this kind of api change
can't be detected by symbol file and probable break testing.  

It's not simple. What does people think is the right way to fix.

Osamu

Bug#871092: maint-guide: FTBFS: dh_install: missing files, aborting

[Osamu Aoki]

control: severity -1 important

Hi,

I see 2 problems:

1. wget chokes when $HOME is not writable (New feature of them.)

2. pdf generation chokes while building with new texlive.
   texlive-binaries amd64 2017.20170613.44572-3 [8082 kB]

For texlive bugs related to the pdf generation, seriously it is almost
inevitable at this time :-) Its tex and it is always like this for last several
releases.  If it persists, I will simply kill build for PDF when it becomes
close to freeze.  Thanks for reminding me for this.

For this I will probably wait for a while so I lowered the severity.

For wget, its their new "feature" for them I guess.  But I think it is their
bug.  I will discuss with them.

Osamu

Bug#863101: Uscan uses all available memory of the system when run against guitarix

[Osamu Aoki]

Hi,

On Sun, May 21, 2017 at 11:09:03PM +0200, Víctor Cuadrado Juan wrote:
> On 21/05/17 22:05, Adam D. Barratt wrote:
> > 
> > I've been unable to reproduce this using either jessie or sid's uscan
> > (running on a jessie host, admittedly). I'd be interested if anyone else
> > can reproduce this or if there's anything unusual about the machine.
> 
> Seems that it isn't only present on uscan: while running debsign I get a
> segmentation fault.

Have you checked hardware failure?  Did you reinstall perl to be safe
side?

> I've carried out heavy tasks on the machine (compiling,etc), and apart
> from this everything looks fine.

Like compiling kernel in C code?   debsign and uscan are perl code.  Any
of these regex tends to eat more memory but strange 
 
> I was able to reproduce it again on my workstation configuration deployed
> into a fresh lxc container (using https://github.com/viccuad/salt-configs).
> There, uscan consumes all the cpu until it gets killed by zsh, and debsign
> the same.

Why don't you create a new account with minimal customization and bash
as login under a real machine.  Let"s not complicate matter with lxc.
Do you still suffer?

Osamu

Bug#863101: Uscan uses all available memory of the system when run against guitarix

[Osamu Aoki]

Hi,

On Sun, May 21, 2017 at 10:26:28PM +0200, Mattia Rizzolo wrote:
> On Sun, May 21, 2017 at 09:05:38PM +0100, Adam D. Barratt wrote:
> > Is there any particular reason you're not using something simpler, along
> > the lines suggested by the manpage? This gives the expected result for
> > me:
> > 
> > version=3
> > http://sf.net/guitarix/ 
> > guitarix2(?:[_-]v?)?(\d.*)\.(?:tar\.xz|txz|tar\.bz2|tbz2|tar\.gz|tgz)
> 
> btw, recentish uscan has support for subst patterns, which would reduce
> all of that regexp to
> guitarix2@ANY_VERSION@@ARCHIVE_EXT
> which I kind of recommend to everybody…

I am happy to hear you like this feature.  To be precise, you need
tailing @:

guitarix2@ANY_VERSION@@ARCHIVE_EXT@

But I intentionally made these to be a bit conservative grep.
  @ANY_VERSION@ doesn't match -v23
  @ARCHIVE_EXT@ doesn't match tgz or tgx
So far only one bug report requesting tgz.  I may consider adding it
after careful regression check in buster.  

At least ? Actual target file can be matched as above :-)
   guitarix2-0.35.3.tar.xz

Osamu

Bug#846734: debmake-doc: FTBFS: dpkg-buildpackage: error: check-commmand 'lintian' not found

[Osamu Aoki]

On Sat, Dec 03, 2016 at 08:48:47AM +0100, Lucas Nussbaum wrote:
> Source: debmake-doc
> Version: 1.6-1
> Severity: serious
> Tags: stretch sid
> User: debian...@lists.debian.org
> Usertags: qa-ftbfs-20161202 qa-ftbfs
> Justification: FTBFS on amd64

...
> > dpkg-buildpackage: error: check-commmand 'lintian' not found
> > 
> > debuild: fatal error at line 1100:
> > 
> > dpkg-buildpackage -rfakeroot -us -uc --hook-check=cd ..;  -i 
> > --check-command=lintian failed
> > 
> > Makefile:24: recipe for target 'all' failed
> > make[3]: *** [all] Error 1

Thanks.  My chroot had lintian ... I will add it to "Depends".

(Need to update more to avoid FTBFS for new debuild behavior...)

Bug#841709: [uscan] missing package parameter at call of debian/repack.sh

[Osamu Aoki]

control: severity -1 normal

Hi,

On Sat, Oct 22, 2016 at 04:19:29PM +0200, Jörg Frings-Fürst wrote:
> Package: devscripts
> Version: 2.16.8
> Severity: grave
^ Please read the policy.
> at download a new release with uscan the repack failed.
> 
> At the call of debian/repack.sh the parameter $3 is missing:

Ok.  Please show me your debian/watch file.

If you are using uscan with version=4 watch file, $3 should not be there.

Please describe exact way for me to reproduce your problem.

Osamu

Bug#818359: maildrop: Please release 2.7.1-4 as prepared in git

[Osamu Aoki]

On Wed, Mar 16, 2016 at 12:11:07PM +0100, Ondřej Surý wrote:
> Package: maildrop
> Version: 2.7.1-3
> Severity: grave
> Justification: renders package unusable
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Hi,
> 
> with courier-authlib 0.66.4-5 release the libcourierauth*so were moved
> to /usr/lib, SOVERSION was added, and Breaks for maildrop << 2.7.1-4~
> was added.  Could you please release 2.7.1-4 I have pushed to
> collab-maint?  Or just ping me back, I'll do the NMU.

Please NMU.  Thanks in advance.

Bug#818359: maildrop: Please release 2.7.1-4 as prepared in git

[Osamu Aoki]

Hi,

On Thu, Mar 17, 2016 at 11:34:46AM +0100, Ondřej Surý wrote:
> Hi Osamu,
> 
> I had to fix FTBFS in unstable (something about debcomp not found, I
> have to delete pregenerated Makefile.in to make it work) and while at it
> I also update the package to latest upstream (2.8.3), added
> autotools-dev support to dh and enabled hardening.

Good.

> Are you still fine with me NMU-uploading such package or do you want to
> review the changes before the upload?

Yes.
 

Bug#812188: debiandoc-sgml-doc-pt-br: FTBFS: make[1]: nsgmls: Command not found

[Osamu Aoki]

control: reopen -1

On Mon, Feb 01, 2016 at 03:22:53PM +0100, Jérémy Bobbio wrote:
> Debian Bug Tracking System:
> > This package is caught up in the package transition which caused:
> > 
> > >   make[1]: nsgmls: Command not found
> > 
> > With recent NMU of debiandoc-sgml changing by Niel its package
> > dependencies, this should have been fixed. See Bug#805061
> 
> The last build attempted on 2016-01-31 on reproducible.debia.net failed
> with the same error.

I see. debian/rules calls nsgmls -> need to be changed to onsgml

Osamu

Bug#813111: ibus crash Cinamon desktop in dual core PC

[Osamu Aoki]

Control: severity 813111 normal
Control: tags 813111 moreinfo

On Fri, Jan 29, 2016 at 10:57:43AM +0300, Strelok wrote:
> Package: ibus
> Version: 1.5.9-1
> Severity: grave

Just because you are facing hard time using this program, it does not
get "grave" rating.  See https://www.debian.org/Bugs/Developer#severities

> I trying install Jessie with Cinamon desktop from amd64 netinstall ISO to
> PC with dual core amd64 CPU. After this I'm try run "apt-get install
> ibus-anthy" in root terminal. And system menu is freezing.

Did you run "apt-get update" before?  Besides, I can not tell what is
causing "freeze" from what you described.

> It still
> visible, but don't react to mouse. Reset, apt-get purge ibus ibus-anthy,
> apt-get install ibus-anthy - result the same. After this I'm tested this
> bug in VirtualBox and try setup only ibus. If I'm set VirtualBox to use
> two core, display image is freezing after ibus installation, but mouse
> cursor still work.

Are you in virtual box?  Then there may be other reasons for the problem.
If you are reporting bug to ibus, please make sure and narrow down
poroblem using a simplest possible system.

> If I'm use one core - bug may appear, and may not
> appear (may be synchronization problem betwen two core?). If I'm try
> install ibus from LiveCD, this bug also don't appear.

H... network problem of your virtual environment?  If it works under
LiveCD, it is not ibus problem.

> Also I'm trying setup ibus-anthy in Mate desktop. In this case ibus work,
> but Japanese input show Latin characters when I'm excepted hiragana.

???

> After single reboot this bug disappear.

Of course, you need to restart the ibus system.  This is normal. For
newbie, reboot is the easiest way to achieve restart.  Please read
/usr/share/doc/ibus/README.Debian before filing a bug.

(Debian's input method configuration utility is a minimalist one.)

> If I'm try reproduce this bug in
> VirtualBox setting to use one core, this bug don't appear.
> 
> For more info - I'm use integrated graphics processor. May be this is root
> of problem. But other software work without bug.

Unless you have concrete evidence ibus has bug, this bug report serve
almost nothing.  I see you seem to have system configuration problem
with unknown source.

> PS Sorry if my English is bad.

You are doing better than me :-)

Regards,

osamu

Bug#782614: not fixed in jessie

[Osamu Aoki]

Hi,

On Fri, Dec 04, 2015 at 12:10:27AM +0100, Christoph Zimmermann wrote:
> Hi
> 
> I can confirm that this bug is fixed in the debian package for unstable
> (4.48.0) but the current package for jessie is somehow still affected.

Yes that is what the bug web page say:

   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782614

Found in version getmail4/4.46.0-1
Fixed in versions getmail4/4.48.0-1, getmail4/4.46.0-1+deb8u1
Done: Osamu Aoki <os...@debian.org>

> I looked at the jessie package and I didn't saw the new MAXLINE part in
> the file _retrieverbases.py
> 
> The unstable package installs fine on my jessie machine and my bug is
> away.

You can also enable stable-proposed-updates by adding following apt
line or similar:

 deb http://ftp.fr.debian.org/debian/ stable-proposed-updates main

4.46.0-1+deb8u1 is there.  Next stable release should pick up this
package.

Osamu

Bug#802395: debmake-doc: FTBFS: ImportError: No module named 'gi'

[Osamu Aoki]

Hi,

This reproduceble build bug is really reproduceble :-)

On Mon, Oct 19, 2015 at 10:31:37PM +0100, Chris West (Faux) wrote:
> Source: debmake-doc
> Version: 1.0-1
> Severity: serious
> Justification: fails to build from source
> Tags: sid stretch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> The package fails to build:
> 
>   pybuild --test -i python{version} -p "3.5 3.4" --dir .
> I: pybuild base:170: cd 
> /debmake-doc-1.0/debhello-1.3-pkg1/test/debhello-1.3/.pybuild/pythonX.Y_3.5/build;
>  python3.5 -m unittest discover -v 
> hello_py (unittest.loader._FailedTest) ... ERROR
> 
> ==
> ERROR: hello_py (unittest.loader._FailedTest)
> --
> ImportError: Failed to import test module: hello_py
> Traceback (most recent call last):
>   File "/usr/lib/python3.5/unittest/loader.py", line 462, in _find_test_path
> package = self._get_module_from_name(name)
>   File "/usr/lib/python3.5/unittest/loader.py", line 369, in 
> _get_module_from_name
> __import__(name)
>   File 
> "/debmake-doc-1.0/debhello-1.3-pkg1/test/debhello-1.3/.pybuild/pythonX.Y_3.5/build/hello_py/__init__.py",
>  line 2, in 
> from gi.repository import Gtk
> ImportError: No module named 'gi'


I got the same with my local pbuilder build.  I wonder why I did not
catch this in the first place.

Anyway, adding python3-gi to B-D should fix this.  Thanks.

Osamu

Bug#791563: Please remove axel-kapt from archive

[Osamu Aoki]

Hi,

On Mon, Jul 06, 2015 at 11:30:16AM +0200, Dr. Tobias Quathamer wrote:
 Package: axel-kapt
 Version: 2.4-1
 Severity: serious
 
 Hi,
 
 please remove the package axel-kapt from the Debian archive. It depends
 on the package kaptain, which is about to be removed from the archive
 as well. The reason is that kaptain still uses Qt4 and cannot be ported
 easily to Qt5. Moreover, kaptain is no longer maintained upstream. See
 bug #789819 for details.
 
 If you don't have the time, I'll upload an NMU of axel which removes the
 package axel-kapt in a few weeks.
 
 Another option might be to remove the package axel altogether, because
 it seems to be abandoned upstream as well. That is your decision, of course.

I vote for the removal of the package axel altogether.  The maintainer
seems to be not acting at all and refuses to get this package removed.

I made a template upload to experimental for him if he cares but no action.

 axel (2.4-1.1) experimental; urgency=low
 .
   * Non-maintainer upload.
   * Remove dpatch dependency. (E build-depends-on-obsolete-package)
   * Add hardening with dh v9. Closes: #645271
   * Include unreleased upstream fixes. Closes: #533103
   * Fix FTBFS for GNU/Hurd. Closes: #532793
   * Add ja.po and unfuzzy translations. Closes: #663286
   * Support IPv6. Closes: #525290
   * Support copyright-format 1.0 and update policy to 3.9.3.

He did not make any upload to sid.  This package should be removed if
maintainer has not put his priority.  

Osamu


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

Bug#782453: [Pkg-ime-devel] Help to sponsor ibus-cangjie for Jessie

[Osamu Aoki]

Hi,

I am a bit confused.  If this is 2.2-2+deb8u1 update on 2.2-2, why there
is change for Makefile.am.  I thought your change only happens in
debian/patches/*


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

Bug#782453: [Pkg-ime-devel] Bug#782453: Bug#782453: ibus-cangjie: Many UX issues fixed upstream

[Osamu Aoki]

Hi,

On Wed, Apr 29, 2015 at 01:59:48PM +0200, Mathieu Bridon wrote:
 On Wed, 2015-04-29 at 19:43 +0800, ChangZhuo Chen wrote:
  On Wed, Apr 29, 2015 at 12:08:55PM +0200, Mathieu Bridon wrote:
   So 8.0 is out now, can we get that into 8.1?
  
  Is backport good enough for this issue?
 
 Issue**s** ;)
 
 I'm not sure if Debian users tend to use backports. 

It is default=enabled for the fresh new jessie install.
(This was a surprize last minutes change of jessie)

 If it's well
 documented, and there's an expectation that users should look into

Maybe ...

 backports, then sure. (and realistically, it's better to have it fixed
 in backports than not at all ;) )

Yes.

If patch is clean focused one, push to jerssie itself may be good idea.
But usually, pushing to backport takes less efforts for the maintainer
and release manager.

Osamu


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

Bug#782850: sloppy copyright name bunching

[Osamu Aoki]

Package: debmake
Version: 4.1.7-2
Severity: serious

Since I found error in copyright holder list generation, this is best
not to release for Jessie.

It is a bit too rough to stay in stable.

Osamu

PS: It is still useful in most cases.  Anyway, I am uploading fiixed one
soon for post-jessie.

-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages debmake depends on:
ii  devscripts   2.15.3
ii  dpkg-dev 1.17.25
ii  python3  3.4.2-2
pn  python3:any  none
ii  rsync3.1.1-3

Versions of packages debmake recommends:
ii  build-essential  11.7
ii  curl 7.38.0-4
ii  strace   4.9-2
ii  wget 1.16-1

Versions of packages debmake suggests:
ii  autotools-dev 20140911.1
ii  ccache3.1.10-1
ii  cmake 3.0.2-1
ii  cowbuilder0.73
ii  dh-autoreconf 10
ii  dh-python 1.2014-2
ii  eatmydata 82-6
pn  gem2deb   none
ii  git   1:2.1.4-2.1
ii  git-buildpackage  0.6.22
ii  gitk  1:2.1.4-2.1
ii  javahelper0.48
ii  lintian   2.5.30+deb8u4
ii  mc3:4.8.13-3
ii  pbuilder  0.215+nmu3
ii  quilt 0.63-3
ii  rpm2cpio  4.11.3-1.1

-- no debconf information


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

Bug#778893: [search-web-for-addr...@pyropus.ca: Re: [PATCH] Fix bug in IMAP IDLE mode with `delete_after`]

[Osamu Aoki]

- Forwarded message from Charles Cazabon 
search-web-for-addr...@pyropus.ca -

Date: Wed, 25 Feb 2015 19:16:27 -0600
From: Charles Cazabon search-web-for-addr...@pyropus.ca
To: getm...@lists.pyropus.ca
Subject: Re: [PATCH] Fix bug in IMAP IDLE mode with `delete_after`
User-Agent: Mutt/1.5.21 (2010-09-15)

Charles Cazabon search-web-for-addr...@pyropus.ca wrote:
 Osamu Aoki os...@debian.org wrote:
  
  If you release very soon, I will keep Debian bug status as 'grave' since
  it causes data loss.  I will update Debioan package as soon as you
  release to get it accepted to Jessie release.
 
 I'll try to get the fix out today.

It didn't happen yesterday, but I've got it out now.  

It's not exactly data loss - as I understand it, getmail simply ends up
ignoring the delete_after delay of X days after it has been in IMAP IDLE mode
for that number of days, and starts deleting messages immediately after
successful retrieval.

Charles
-- 
---
Charles Cazabon
GPL'ed software available at:   http://pyropus.ca/software/
---

-
To unsubscribe, e-mail: getmail-unsubscr...@lists.pyropus.ca
For additional commands, e-mail: getmail-h...@lists.pyropus.ca


- End forwarded message -


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

Bug#778893: [PATCH] Fix bug in IMAP IDLE mode with `delete_after`

[Osamu Aoki]

HI,

On Wed, Feb 18, 2015 at 10:10:53PM -0600, Charles Cazabon wrote:
 Johannes Weißl jar...@molb.org wrote:
  If e.g. `delete_after=7`, getmail will delete *all* retrieved messages
  after running for 7 days in IDLE mode (like `delete=True`).
 Thanks very much for the patch!  It will be in the next version.

Are you putting the high priority to upload this bug fix release
soonish?

If you release very soon, I will keep Debian bug status as 'grave' since
it causes data loss.  I will update Debioan package as soon as you
release to get it accepted to Jessie release.

Otherwise, I guess you consider this a corner case.  So I will downgrade
Debian bug to Important and make the next Debian release to come with
this bug.

I only use POP3 so I can't judge exact situation of this bug.

Regards,

Osamu


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

Bug#778893: bug in IMAP IDLE mode with `delete_after`

[Osamu Aoki]

Source: getmail4
Version: 4.46.0-1
Severity: grave
Tags: patch

As reported in
 http://article.gmane.org/gmane.mail.getmail.user/5341

 I discovered a bug with the IMAP IDLE implementation in getmail
 4.46.0,
 which manifests itself when using an option such as `delete_after`.

 If e.g. `delete_after=7`, getmail will delete *all* retrieved messages
 after running for 7 days in IDLE mode (like `delete=True`).

DATA loss is the grave bug although I do not use this feature.

Patch is posted in the URL.

Upstream will soon release the updated source.

Osamu
-- System Information:
Debian Release: 8.0
  APT prefers testing-updates
  APT policy: (500, 'testing-updates'), (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

-- no debconf information


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

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

Hi,

On Mon, Dec 08, 2014 at 03:41:57PM +0100, Raphael Hertzog wrote:
 Hi,
 
 On Mon, 08 Dec 2014, Osamu Aoki wrote:
  Si I should change getmail4 (4.46.0-1~deb7u1) wheezy-security as:
   * Version: 4.46.0-1~deb6u1   change
   * target: squeeze-security   change
 
 target is squeeze-lts in fact but there are no queues in front of that
 repository, what you upload is directly installed (like in unstable).

Fixed this and ...
 * Policy changed to 3.9.1 from 3.9.4
 * unknown-field-in-control multi-arch -- removed stanza
 
  Looks like it is not so complicated :-)

I initially thought --with python2 was not available but it is
available. Backporting was not so difficult after all. 

 Feel free to make the package available somewhere and I can take care of
 sending it together with the Debian LTS Advisory on
 debian-lts-annou...@lists.debian.org.

OK.  I signed with my latest GPG key with the new debsign command in
jessie.

I made a big tarball containing all files and debdiff results:
   https://people.debian.org/~osamu/debmake-140721.tar.xz

Debdiffs included are against wheezy-security package.

Regards,

Osamu


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

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

On Tue, Dec 09, 2014 at 10:05:08PM +0900, Osamu Aoki wrote:
...

 OK.  I signed with my latest GPG key with the new debsign command in
 jessie.

Note:
 Package itself is build in the squeeze chroot as expected.  
 Only the signiture was made under jessie.

Osamu


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

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

Hi,

On Thu, Dec 04, 2014 at 12:04:57PM +0100, Raphael Hertzog wrote:
 On Fri, 28 Nov 2014, Osamu Aoki wrote:
  Although I am not comfortable to package this way if I do it again (I
  inherited it and did not touch it back then.), I should do the same
  strange packaging style again considering oldstable update if I do.
 
 Not really, if you switch to a new upstream version, it's certainly fine
 to start with the latest packaging and just fix up things so that they
 work in squeeze.

Let me do some reality chack under squeeze.

 debhelper 8.0.0
  /usr/share/perl5/Debian/Debhelper/Sequence/python_support.pm
 python2.6.6-3+squeeze7
  python: /usr/share/man/man1/dh_python2.1.gz
  python: /usr/bin/dh_python2

 Neither python-support nor dh_python2 are a strong requirement.

Let's see if they are available:
 dh-python non-existing package as wheezy
 dh_python2 is available in python package
 python-support 1.0.10

I see I can use dh_python2 or python_support.
 
 Sure the debdiff will mean nothing but as long as you tested that an
 upgrade works, and that the package still runs, it's good enough IMO.

Since dh_python2 is available, --with python2 as in wheezy package
seems most natural choice.

Available debhelper is 8.0.0 - compat=8 is OK.
wheezy package had Build-Depends: debhelper (= 9).  This needs
change. Standards-Version: 3.9.4 maybe too new but keep is as is.

Si I should change getmail4 (4.46.0-1~deb7u1) wheezy-security as:
 * Version: 4.46.0-1~deb6u1   change
 * target: squeeze-security   change
 * compat: 8  keep
 * Build-Depends: debhelper (= 8)change

Looks like it is not so complicated :-)

Osamu


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

Bug#771024: [Pkg-ime-devel] scim-pinyin is marked for autoremoval from testing

[Osamu Aoki]

control: severity 771024 important
control: tags 771024 moreinfo
control: tags 771024 unreproducible

Hi,

I guess the original bug reporter is not familiar with the Debian BTS
and no one from SCIM maintaining people is interested enough to clean up
BTS.

Just a simple housekeeping ... 

FYI: My main interest is ibus and Japanese. 

Osamu


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

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

Hi,

On Tue, Nov 25, 2014 at 09:39:36PM +0900, Osamu Aoki wrote:
 On Tue, Nov 25, 2014 at 10:04:34AM +0100, Raphael Hertzog wrote:
  On Sun, 23 Nov 2014, Osamu Aoki wrote:
  
  We can consider a new upstream version for squeeze-lts
  and we can ask the security team's opinion for wheezy.
  
  Would you like to prepare a 4.46.0-1~deb6u1.dsc working in
  squeeze and submit it for review to debian-...@lists.debian.org ?
 
 See below.  It does not look like simple re-versioning and safe
 backporting without careful review.
  
  It would be nice if you could test it though, because we don't
  have many testers before release...
 
...
 This package is one of those python package using debian/rules as:
 
 %:
 dh $@ --with python2

As I checked oldstable package

%:
dh $@

If everything is clean and neat, this change should have been the only
thing needed for backports for important things, but things are a bit
messy.

 I am not really motivated to do this 

I looked into this anyway.  This squeeze package was made before I
reorganized packaging to my taste.  

The source comes with setup.py.  I now use setup.py to generate files to
be installed for wheeze/jessie.  Back then, the source was patched and
installed directly from source tree.  There are patches such as:

# For Debian Python-support
--- a/getmail_maildir
+++ b/getmail_maildir
@@ -26,6 +26,8 @@

 import os

+sys.path.append(/usr/share/getmail4)
+
 from getmailcore.message import Message
 from getmailcore.utilities import *
 from getmailcore.exceptions import *

Hmmm... this python-support thing, I do not remember how it should be
done.  

It looks like modules were installed into
/usr/share/getmail4/getmailcore by getmail.install.  This does not look
normal search path used even in these days.  That was why these
sys.path.append() was needed.  Yack.

Although I am not comfortable to package this way if I do it again (I
inherited it and did not touch it back then.), I should do the same
strange packaging style again considering oldstable update if I do.

If I have time, I may make test package...

I need to check how python-support package used to be used back then.

If anyone can give my guidance for how lts packages should be made in
this case, let me know.  (Now I am leaning to follow the old ugly
packkging style of squeeze package.)

Osamu


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

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

On Tue, Nov 25, 2014 at 10:04:34AM +0100, Raphael Hertzog wrote:
 Hi,
 
 On Sun, 23 Nov 2014, Osamu Aoki wrote:
  By the way, I uploaded getmail4_4.46.0-1~bpo70+1_amd64
 
 We can consider a new upstream version for squeeze-lts
 and we can ask the security team's opinion for wheezy.
 
 Would you like to prepare a 4.46.0-1~deb6u1.dsc working in
 squeeze and submit it for review to debian-...@lists.debian.org ?

See below.  It does not look like simple re-versioning and safe
backporting without careful review.
 
 It would be nice if you could test it though, because we don't
 have many testers before release...

I only use this package for POP3.  Most of the changes are in IMAP4 code
so my test with POP3 is useless.  Henrique's test on my backported
package is the good reference.
 
  https://ftp-master.debian.org/new/getmail4_4.46.0-1~bpo70%2B1.html

I build this under pure wheezy chroot.

 This can probably be renumbered 4.46.0-1~deb7u1.dsc and submitted
 to the security team ? Or does it depend on other packages from backports ?

This package is one of those python package using debian/rules as:

%:
dh $@ --with python2

Since I build this jessie package in the old jessie/sid environment
which is very similar to released wheezy, I was not asked to add the
dh-python dependency to the debian/control.  In wheezy, --with python2
is supported via python package, as I understood.

So building for wheezy point release is simple and safe with bumping
version to 4.46.0-1~deb7u1.

I am not quite sure what change is needed for backporting python package
with older python helper scripts.  Also, I do not know if compat 8 is
supported by squeeze.  (as for debhelper, I see no major issue as long
as compat7 is provided.) Thus, squeeze is a bit more complicated and
requires more testing.

FYI: I moved to current packaging style in 2011-07 with 4.20.3-1  The
oldstable package oldstable 4.20.0-1 was made with different python
helper script in 2010-07.  (If I do this backport as my job, I will
probably keep old packaging style.)  For all practical purpose, if
someone needs to use this package under oldstable, he should do so by
just dpkg -i newpackage  since python helper script does not matter
for binary packages.  I am not really motivated to do this 

Osamu


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

Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0

[Osamu Aoki]

Hi,

Thanks for your comment. (Charles is the upstream,)

On Sat, Nov 22, 2014 at 01:30:41PM -0600, Charles Cazabon wrote:
 Osamu Aoki os...@debian.org wrote:
  
  In Debian, its security update policy prohibits any new feature added
  with security updates.
 
 It's kind of a bogus distinction.  As Linus Torvalds says, there's no real
 difference between bugfix and security fix, and I would argue there's
 almost as little difference between bugfix and new feature.

If you added an unrelated HTTP-server feature to getmail for the remote
configuration, I call it a feature changes (, enhancement, bloat, or
...).

  There are needs for updating 4.32.0 and 4.20.0 for the MITM security
  issues.  
   CVE-2014-7273
   CVE-2014-7274
   CVE-2014-7275
 
 The changes in getmail to allow it to perform server SSL certificate
 validation and various other advanced SSL options: would you call
 those a new feature?  Because it clearly is.  

It is a boarder line case.

 But on the other hand, some people consider the previous behavior a
 bug, so perhaps its a bugfix.  But others say it closes a security
 hole, so it's a security fix.

I forward your insightful argument to the Debian security team.

 I see no way to make a clear-cut distinction between any of those three
 possibilities.

I concur.

  I for one as being its maintainer in Debian see it theoretically
  possible but am scared to make mistakes when dropping non-security fix
  changes.
 
 I don't think you need to drop *anything*.  getmail hasn't had much in
 the way of new features in many years, and I try to maintain
 compatibility as much as is practical.  Just update to the latest
 version.

Thank you.

Osamu


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

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

Hi,

By the way, I uploaded getmail4_4.46.0-1~bpo70+1_amd64

https://ftp-master.debian.org/new/getmail4_4.46.0-1~bpo70%2B1.html

What do I have to do to get it pushed to backports?  Did I have to
upload it to another server?  I do not know why it is stack there.  I
just used dput.  In
https://qa.debian.org/developer.php?login=osamucomaint=yes this
package is listed under new for testing/unstable.

Regards,

Osamu


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

Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0

[Osamu Aoki]

(resent after subscribing with proper return path mail address)
Hi,

In Debian, its security update policy prohibits any new feature added
with security updates.

There are needs for updating 4.32.0 and 4.20.0 for the MITM security
issues.  
 CVE-2014-7273
 CVE-2014-7274
 CVE-2014-7275

I for one as being its maintainer in Debian see it theoretically
possible but am scared to make mistakes when dropping non-security fix
changes.
  https://bugs.debian.org/766670

Someone suggested Maybe you can ask upstream if they are willing to
point you the correct set of commits?.

Can someone tell me such answer?

I will be happy to get either Yes or No as the answer.

Regards,

Osamu


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

Bug#766670: Security fix without feature enhancement for 4.32.0 and 4.20.0

[Osamu Aoki]

Hi,

In Debian, its security update policy prohibits any new feature added
with security updates.

There are needs for updating 4.32.0 and 4.20.0 for the MITM security
issues.  
 CVE-2014-7273
 CVE-2014-7274
 CVE-2014-7275

I for one as being its maintainer in Debian see it possible but
am scared to make mistakes when dropping non-security fix changes.
  https://bugs.debian.org/766670

Someone suggested Maybe you can ask upstream if they are willing to
point you the correct set of commits?.

Can someone tell me such answer?

I will be happy to get any Yes or No answer.

Regards,

Osamu


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

Bug#766670: RC bug in stable and oldstable for getmail4

[Osamu Aoki]

Hi,

Thanks for filing bug report.
   https://bugs.debian.org/766670
  I think your report on 4.2.0-1 is typo.

These only affect stable 4.32.0-2 and oldstable 4.20.0-1.

I think that the use of backported current testing package is the
reasonable option.  The updates listed in the upstream changelog (see
below) are releted to security updatyes and their regression fixes?

Quite frankly, I am not competent enough to extract a correct set of
patches out of these changes without breaking the program?  It is too
risky since even upstream had few regressions.

The changelog entry in 4.46.0 implied Python 2.6 or newer. The available
Python versions are:
  oldstable 2.6.6-3+squeeze7 OK
  stable2.7.3-4+deb7u1   OK

=== upstream CHANGELOG ===

Version 4.46.0
6 April 2014
-fix --idle checking Python version incorrectly, resulting in incorrect 
warning about running with Python  2.5.  Thanks: Voytek, Krzysztof 
Warzecha.
-add missing support for SSL certificate checking in POP3 which broke
POP retrieval in v4.45.0.  Requires Python 2.6 or newer.  Thanks: mancha.

Version 4.45.0
30 March 2014
-perform hostname-vs-certificate matching of SSL certificate if validating
the certifcate.  Thanks: mancha.
-fix missing plaintext versions of documentation.

Version 4.44.0
22 March 2014
-add extended SSL options for IMAP retrievers, allowing certificate 
verification and other features.  Thanks: Steven Murdoch.
-fix missing plaintext versions of documentation.  Thanks: Osamu Aoki.
-fix Header instance has no attribute 'strip' error which cropped up
in some configurations.  Thanks: Krzysztof Warzecha.

Version 4.43.0
25 August 2013
-add IMAP IDLE support.  Thanks: Jon Gjengset.

Version 4.42.0
3 August 2013
-fix problem with non-ascii characters in newly-added message header fields
with output from Filter_classifier.  Thanks: Gour.

Version 4.41.0
26 May 2013
-messages retrieved with POP could have a blank trailing line removed when
delivered; fixed.  Thanks: Christoph Mitterer, Krzysztof Warzecha.
-fix an ImportError when IMAP retriever used with getmail under Python 2.4.

Version 4.40.3
10 May 2013
-increase system recursion limit when run with Python 2.3, to prevent
recursion errors in parsing some pathologically complex MIME emails.
Thanks: Kenneth Pronovici.

Version 4.40.2
8 May 2013
-fix a backwards incompatibility with Python 2.3 and 2.4 introduced in
getmail 4.38.0.  Thanks: Massimo Zambelli, Krzysztof Warzecha.

Version 4.40.1
22 April 2013
-again change protocol codes passed to OSX, as they're not only reserved
codes, but also case-sensitive.  Use the ones an OSX user reports work
properly.  Thanks: Tim Gray.

Version 4.40.0
21 April 2013
-convert SIGTERM to SIGINT so getmail can cleanup and exit normally if 
killed with a default signal.  Thanks: Carl Lei.
-fix change which resulted in passing full protocol name to OSX keyring
program, which can't handle it (restricted to 4-character code).
Thanks: Tim Gray.

Version 4.39.1
10 March 2013
-fix a bug that could crop up when retrieving mail via IMAP from Gmail, and
the Gmail servers provided weird data in their header extensions.
Thanks: Krzysztof Warzecha.

Version 4.39.0
22 February 2013
-fix an oldmail filename issue that occurred with certain non-ASCII 
characters in an IMAP mailbox name.  Thanks: Michael Kockmeyer.

Version 4.38.0
16 February 2013
-fix retrieving mail from an IMAP mailbox with non-ASCII characters in its
name causing difficult-to-understand unicode errors during delivery.
Thanks: fsLeg, Krzysztof Warzecha.

Version 4.37.0
27 January 2013
-handle IMAP servers which include / in message IDs better, so those 
messages aren't always thought to be new.  Thanks: Bradley Rintoul.
-record (IMAP) mailbox retrieved from in X-getmail-retrieved-from-mailbox:
header field, and make it available as %(mailbox) substitution in 
MDA_external arguments.  Thanks: Les Barstow.
-add delete_bigger_than option to allow removal of large messages after
retrieval, even if not deleting messages otherwise.  Thanks: Jan Vereecke.

Version 4.36.0
15 December 2012
-add support for retrieving POP/IMAP passwords from, and storing them to,
the Gnome keyring.  Thanks: Krzysztof Warzecha, Scott Hepler.

Version 4.35.0
24 October 2012
-fix From_ quoting in mbox delivery; use of the Python stdlib function 
meant getmail was incorrectly using mboxo-style quoting instead of
mboxrd quoting, probably since early in the v4 series.  
Thanks: Christoph Mitterer.

Version 4.34.0
8 September 2012
-retrieve Gmail metadata (labels, thread ID, message ID) via IMAP extension
and record it in new message headers.  Thanks: Krzysztof Warzecha.

Version 4.33.0
7 August 2012
-allow normal exit on interrupt (ctrl-c) to allow the user to abort message
retrieval while

Bug#761001: NVIDIA non-free driver may break gdm3

[Osamu Aoki]

control: tags 761001 moreinfo
control: severity 761001 important
Hi,

Since I do not have NVIDIA GPU on my system, I removed all its non-free
drivers from my system.  Then my problem is gone.  

For my case, non-free NVIDIA software seems to be interfering with the
GPU detection for GLX on Intel integrated GPU which then caused gdm3 and
GNOME desktop to crash.  I doubt this is a bug for gdm3.  Instead, this
should be bug on NVIDIA code breaking GLX.

The breakage of gdm3 and GNOME can happen due to these reasons.  Unless
Kurt can provide sufficient evidence that his breakage report is caused
by the bug in gdm3, having RC bug report here serves no use.

Kurt, can you provide log file for failed gdm3?
Kurt, can you check your GPU drivers?

Regards,

Osamu


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

Bug#761001: Gnome3/Gdm3 gone :-)

[Osamu Aoki]

Hi Kurt, 

What is your system (CPU/GPU)?  Do you see the same kind of syslog as I
quote below?

I see linux-kernel mesa and mutter are updated on my system yesterday.
Maybe one of these are causing this.

Here is my situation.

 * GDM3 crashes after upgrade yesterday (testing).
   upgrading to unstable version does not fix.
   gdm3 3.14.0-1 MIGRATED to testing 2014-10-18 *** suspicious but ...
 * Logging into GNOME3 (normal and fall back) from KDM crashes.
 * Logging into XFce (GTK3+) and KDE (Qt) works as long as KDM or lightdm
   are used.
 * xorg has not changed since 2014-04-07.  So they are not to be blamed.
 * systemd (logind) has not changed since [2014-10-06] So they are not
   to be blamed.

I have Intel integrated graphics (on Haswell i5)

Something specific in the lower level of GNOME3 broke this system.
If gdm3 was the real cause, this breakage should have happened before.

I found the following in my syslog when GDM3 failed.

This is strange.


Oct 29 20:19:58 goofy gdm3[639]: Failed to give slave programs access to the 
display. Trying to proceed.

...

Oct 29 20:19:58 goofy /usr/bin/dbus-launch[1020]: Xlib:  extension GLX 
missing on display :0.
Oct 29 20:19:58 goofy /usr/bin/dbus-launch[1020]: Xlib:  extension GLX 
missing on display :0.
Oct 29 20:19:58 goofy /usr/bin/dbus-launch[1020]: Xlib:  extension GLX 
missing on display :0.
Oct 29 20:19:58 goofy /usr/bin/dbus-launch[1020]: gnome-session-is-accelerated: 
No hardware 3D support.
Oct 29 20:19:58 goofy /usr/bin/dbus-launch[1020]: Xlib:  extension GLX 
missing on display :0.
Oct 29 20:19:58 goofy /usr/bin/dbus-launch[1020]: 
gnome-session-check-accelerated: Helper exited with code 256


Looking into apt log:
Start-Date: 2014-10-27  01:04:40
Commandline: apt-get dist-upgrade -y
Install: linux-image-3.16-3-amd64:amd64 (3.16.5-1, automatic)
Upgrade: valac:amd64 (0.26.0-1, 0.26.1-1), empathy-common:amd64 (3.12.6-1, 
3.12.7-1), empathy:amd64 (3.12.6-1, 3.12.7-1), gir1.2-evince-3.0:amd64 
(3.14.0-2, 3.14.1-1), libblas-common:amd64 (1.2.20110419-9, 1.2.20110419-10), 
libgee-0.8-dev:amd64 (0.14.0-3, 0.16.1-1), iw:amd64 (3.14-1, 3.17-1), 
valac-0.26-vapi:amd64 (0.26.0-1, 0.26.1-1), evince:amd64 (3.14.0-2, 3.14.1-1), 
libblas3:amd64 (1.2.20110419-9, 1.2.20110419-10), valac-0.26:amd64 (0.26.0-1, 
0.26.1-1), libgee-0.8-2:amd64 (0.14.0-3, 0.16.1-1), gir1.2-gee-0.8:amd64 
(0.14.0-3, 0.16.1-1), gnome-backgrounds:amd64 (3.14.0-1, 3.14.1-1), 
liblapack3:amd64 (3.5.0-3, 3.5.0-4), evince-common:amd64 (3.14.0-2, 3.14.1-1), 
libldap-2.4-2:amd64 (2.4.39-1.1+b1, 2.4.40-2), baobab:amd64 (3.14.0-1, 
3.14.1-1), dictionaries-common:amd64 (1.23.12, 1.23.14), libevview3-3:amd64 
(3.14.0-2, 3.14.1-1), linux-image-amd64:amd64 (3.16+61, 3.16+62), 
manpages-dev:amd64 (3.71-1, 3.74-1), libvala-0.26-0:amd64 (0.26.0-1, 0.26.1-1), 
manpages:amd64 (3.71-1, 3.74-1), libevdocument3-4:amd64 (3.14.0-2, 3.14.1-1), 
linux-libc-dev:amd64 (3.16.3-2, 3.16.5-1), whois:amd64 (5.2.0, 5.2.1)
End-Date: 2014-10-27  01:05:23

Start-Date: 2014-10-27  01:05:23
Commandline: apt-get autoremove -y
Remove: linux-image-3.14-2-amd64:amd64 (3.14.15-2), libgnutls26:amd64 
(2.12.23-17)
End-Date: 2014-10-27  01:05:25

Start-Date: 2014-10-27  23:09:26
Commandline: apt-get dist-upgrade
Install: libllvm3.5:amd64 (3.5-6, automatic)
Upgrade: libio-socket-ssl-perl:amd64 (1.998-1, 2.002-1), libfontembed1:amd64 
(1.0.59-1, 1.0.61-2), libegl1-mesa:amd64 (10.2.8-1, 10.3.1-1), 
libopenvg1-mesa:amd64 (10.2.8-1, 10.3.1-1), libegl1-mesa-drivers:amd64 
(10.2.8-1, 10.3.1-1), foomatic-db-compressed-ppds:amd64 (20140730-1, 
20141016-1), libgl1-mesa-dri:amd64 (10.2.8-1, 10.3.1-1), 
openprinting-ppds:amd64 (20140730-1, 20141016-1), libglapi-mesa:amd64 
(10.2.8-1, 10.3.1-1), gir1.2-mutter-3.0:amd64 (3.14.0-1, 3.14.1-1), 
cups-browsed:amd64 (1.0.59-1, 1.0.61-2), libgl1-mesa-glx:amd64 (10.2.8-1, 
10.3.1-1), cups-filters-core-drivers:amd64 (1.0.59-1, 1.0.61-2), 
libxatracker2:amd64 (10.2.8-1, 10.3.1-1), libwayland-egl1-mesa:amd64 (10.2.8-1, 
10.3.1-1), cups-filters:amd64 (1.0.59-1, 1.0.61-2), libgbm1:amd64 (10.2.8-1, 
10.3.1-1), mutter-common:amd64 (3.14.0-1, 3.14.1-1), libmutter0e:amd64 
(3.14.0-1, 3.14.1-1), libcupsfilters1:amd64 (1.0.59-1, 1.0.61-2)
End-Date: 2014-10-27  23:09:38

Start-Date: 2014-10-27  23:15:48
Install: locales:amd64 (2.19-11)
Remove: libllvm3.4:amd64 (3.4.2-10)
End-Date: 2014-10-27  23:15:52



Regards,

Osamu


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

Bug#761001: Gnome3/Gdm3 gone :-)

[Osamu Aoki]

Hi,

Looking at the date of OP's situation, problem may be different.

Booting with the older kernel linux-image-3.16-2-amd64 did not fix my
situation.  My problem may be mutter or mesa.

Osamu


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

Bug#754670: ibus: FTBFS: if python-gi-dev is installed

[Osamu Aoki]

Hi,

I can reproduce this FTBFS bug. (libpcrc3 and related packages are at
hold with testing version)

| dh_install --fail-missing -X.la
| dh_install: usr/lib/python2.7/dist-packages/gi/overrides/IBus.py exists in 
debian/tmp but is not installed to anywhere
| dh_install: usr/lib/python2.7/dist-packages/gi/overrides/IBus.pyo exists in 
debian/tmp but is not installed to anywhere
| dh_install: usr/lib/python2.7/dist-packages/gi/overrides/IBus.pyc exists in 
debian/tmp but is not installed to anywhere
| dh_install: usr/lib/python3/dist-packages/gi/overrides/IBus.py exists in 
debian/tmp but is not installed to anywhere
| dh_install: 
usr/lib/python3/dist-packages/gi/overrides/__pycache__/IBus.cpython-34.pyc 
exists in debian/tmp but is not installed to anywhere
| dh_install: 
usr/lib/python3/dist-packages/gi/overrides/__pycache__/IBus.cpython-34.pyo 
exists in debian/tmp but is not installed to anywhere

Removing --fail-missing maybe a short term fix but what are these files
in gi/overrides directories are for.  IBus.py has:

| from gi.repository import GObject
| 
| from ..overrides import override
| 
| # for newer pygobject: https://bugzilla.gnome.org/show_bug.cgi?id=686828
| # from ..module import get_introspection_module
| # IBus = get_introspection_module('IBus')
| from ..importer import modules
| IBus = modules['IBus']._introspection_module
| 

As I see SPEC file of FEDORA, when this is generated, it makes some
extra package to store the result:

| %if %with_python2_override_pkg
| %package py2override
| Summary:IBus python2 override library
| Group:  System Environment/Libraries
| Requires:   %{name}-libs%{?_isa}   = %{version}-%{release}
| # Owner of %%python2_sitearch/gi/overrides
| Requires:   pygobject3-base
| 
| %description py2override
| This is a python2 override library for IBus. The python files override
| some functions in gobject-introspection.
| %endif
...

In debian speak, this is something like ibus-py2override package.

I have no idea if this is required by some packages on Debian.  So far,
I have not seen one.  Does any one have idea?

Also, overrides under python3 side are not packaged.

Changwoo, do you have any use for installing thise files?

Regards,

Osamu


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

Bug#754670: RFH: gi and overrides, how it should be packaged

[Osamu Aoki]

Hi gnome folks,

The input method packaging team is wondering what to do with the
/usr/lib/python*/dist-packages/gi/overrides/Ibus.py files generated when
python-gi-dev is in the build environment.

Do we make python-ibus just for them?  Or put it inside gir* packages.

I have no idea which one is better.  (gir* is easier for me...)

See more as below and let us know your thought.

On Sun, Jul 20, 2014 at 06:04:44PM +0900, Changwoo Ryu wrote:
 2014-07-20 (일), 15:18 +0900, Osamu Aoki:
 ...
  In debian speak, this is something like ibus-py2override package.
  
  I have no idea if this is required by some packages on Debian.  So far,
  I have not seen one.  Does any one have idea?
  
  Also, overrides under python3 side are not packaged.
  
  Changwoo, do you have any use for installing thise files?
 
 In general, those g-i overrides provide additional or modified APIs
 when automatically generated g-i bindings are not enough. For example
 when automatic bindings don't look good in Python. And they are
 transparent; you don't have to specify explicitly to use the overridden
 code.
 
 So when the ibus g-i overrides are installed, the ibus programs in
 Python transparently use them. But interestingly, all ibus Python
 programs in Debian seem to work without the overrides.
 
 I still think the overrides should be installed, because they are the
 officially provided ibus Python APIs anyway.
 
 In Debian, the g-i overrides are packaged in python-* packages or
 sometimes in gir* packages. I have no idea which one is better.
 
 $ apt-file search /gi/overrides/
 gedit: /usr/lib/python3/dist-packages/gi/overrides/Gedit.py
 gir1.2-dee-1.0: /usr/lib/python2.7/dist-packages/gi/overrides/Dee.py
 gir1.2-dee-1.0: /usr/share/pyshared/gi/overrides/Dee.py
 gir1.2-gexiv2-0.10: /usr/lib/python2.7/dist-packages/gi/overrides/GExiv2.py
 gir1.2-gexiv2-0.10: /usr/lib/python3/dist-packages/gi/overrides/GExiv2.py
 gir1.2-grip: /usr/lib/python2.7/dist-packages/gi/overrides/Grip.py
 gir1.2-grip: /usr/lib/python3/dist-packages/gi/overrides/Grip.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/GIMarshallingTests.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/GLib.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/GObject.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/Gdk.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/Gio.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/Gtk.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/Pango.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/__init__.py
 python-gi: /usr/lib/python2.7/dist-packages/gi/overrides/keysyms.py
 python-gst-1.0: /usr/lib/python2.7/dist-packages/gi/overrides/Gst.py
 python-gst-1.0: /usr/lib/python2.7/dist-packages/gi/overrides/GstPbutils.py
 python-gst-1.0: /usr/lib/python2.7/dist-packages/gi/overrides/_gi_gst.so
 python-gst-1.0-dbg: /usr/lib/python2.7/dist-packages/gi/overrides/_gi_gst_d.so
 python-v-sim: /usr/lib/python2.7/dist-packages/gi/overrides/v_sim.py
 python-v-sim: /usr/share/pyshared/gi/overrides/v_sim.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/GIMarshallingTests.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/GLib.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/GObject.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/Gdk.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/Gio.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/Gtk.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/Pango.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/__init__.py
 python3-gi: /usr/lib/python3/dist-packages/gi/overrides/keysyms.py
 python3-gst-1.0: /usr/lib/python3/dist-packages/gi/overrides/Gst.py
 python3-gst-1.0: /usr/lib/python3/dist-packages/gi/overrides/GstPbutils.py
 python3-gst-1.0: 
 /usr/lib/python3/dist-packages/gi/overrides/_gi_gst.cpython-34m-x86_64-linux-gnu.so
 python3-gst-1.0-dbg: 
 /usr/lib/python3/dist-packages/gi/overrides/_gi_gst.cpython-34dm-x86_64-linux-gnu.so
 $
 
 
 
 Regards
 
 Changwoo
 
 


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

Bug#754670: ibus: FTBFS: if python-gi-dev is installed

[Osamu Aoki]

Hi,

On Sun, Jul 13, 2014 at 08:50:55PM +0900, Changwoo Ryu wrote:
 Source: ibus
 Version: 1.5.7-1
 Severity: serious
 Justification: FTBFS
 
 ibus fails to build from source if python-gi-dev is installed.
 
 Error part:
 
 ...
 dh_install --fail-missing -X.la
 dh_install: usr/lib/python3/dist-packages/gi/overrides/IBus.py exists in
 debian/tmp but is not installed to anywhere
 dh_install:
 usr/lib/python3/dist-packages/gi/overrides/__pycache__/IBus.cpython-34.pyo 
 exists in debian/tmp but is not installed to anywhere
 dh_install:
 usr/lib/python3/dist-packages/gi/overrides/__pycache__/IBus.cpython-34.pyc 
 exists in debian/tmp but is not installed to anywhere
 dh_install: usr/lib/python2.7/dist-packages/gi/overrides/IBus.py exists
 in debian/tmp but is not installed to anywhere
 dh_install: usr/lib/python2.7/dist-packages/gi/overrides/IBus.pyo exists
 in debian/tmp but is not installed to anywhere
 dh_install: usr/lib/python2.7/dist-packages/gi/overrides/IBus.pyc exists
 in debian/tmp but is not installed to anywhere
 dh_install: missing files, aborting
 debian/rules:40: recipe for target 'override_dh_install' failed
 make[1]: *** [override_dh_install] Error 2
 make[1]: Leaving directory '/tmp/buildd/ibus-1.5.7'
 debian/rules:12: recipe for target 'binary' failed
 make: *** [binary] Error 2
 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit
 status 2

I actually can not install valac to my unstable system after updating my
system to unstable recently with GNOME 3.12 packages.  The upgrade was
not smooth but that is unstable when these large group of packages are
making large scale changes. I can not even run clean target as a result.

All the failures seem to be
 dh_install: usr/lib/python2.7/dist-packages/gi/overrides/IBus.pyc exists
 in debian/tmp but is not installed to anywhere
This is because of debian/rules  having:
   dh_install --fail-missing -X.la
  ^^

Maybe dh-python changed behavior to generate these files in debian/tmp

Maybe I should test this build in testing chroot.

Let's wait a bit until it settles down. Give me simetime.

Osamu

 


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

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Osamu Aoki]

Hi,

On Sun, Jun 29, 2014 at 02:14:49PM -0400, Guo Yixuan wrote:
 The only problem for using uversionmangle is:
 
 I: librime source:
 debian-watch-file-should-dversionmangle-not-uversionmangle line 3
 N:
 N:The version of this package contains dfsg, ds, or debian, but a
 N:misleading upstream version mangling occurs in the debian/watch file.
 N:Since the dfsg string is not part of the upstream version and its
 N:addition is Debian-specific, the the debian/watch file should use the
 N:dversionmangle option to remove, instead of adding in uversionmangle,
 N:the dfsg before comparing version numbers.
 N:
 N:Refer to http://wiki.debian.org/DEHS for details.
 N:
 N:Severity: wishlist, Certainty: certain
 N:
 N:Check: watch-file, Type: source
 
 But if we use dversionmangle instead of uversionmangle,
 then the renamed origin tarball has name librime_1.1.orig.tar.gz,
  which needs to be manually renamed to librime_1.1+dfsg.orig.tar.gz.
 
 A related bug is here. [1]
 
 [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=748465

Did you try the solution at the bottom?

Also, adding yourself to uploader, go ahead.  This means you will stay
with us and keep working on this :-)

Osamu


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

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Osamu Aoki]

Hi,

On Sun, Jun 29, 2014 at 02:11:18AM -0400, Guo Yixuan wrote:
 On Mon, Jun 23, 2014 at 8:03 AM, Osamu Aoki osamu_aoki_h...@nifty.com
  You did not present rationale to do extrastep with the second option.
 
 There seems to be something more than ABI break.
 librime 1.0 modified several struct member definitions, eg., in the
 definition of RimeMenu in include/rime_api.h. Is it an API break?
 If yes, then we should rename, in my opinion. (By the way, other
 source code imcompatibilities may exist, as indicated in the
 ChangeLog, while source code compatibility is largely
 maintained with the exception ...)

Very good.  this is what I wanted to hear.
 
  I see
  librime1 (= ${source:Version}), librime1 ( ${source:Version}+1~)
 
  This seems binNMU unsafe.  Please drop max version limitation.

Very good.

I added few lines to debian/rules for stable build test with
debian/rules etc.

I also checked source with debmake -k
=== debian/copyright checked for 260 data ===
Pattern #00: *
  File: thirdparty/src/opencc-windows/opencc.h
thirdparty/src/opencc-windows/opencc_types.h
- GPL-3
+ Apache-2.0

Pattern #02: thirdparty/include/X11/*
  File: thirdparty/include/X11/keysymdef.h
thirdparty/include/X11/keysym.h
- MIT
+ ISC

Pattern #03: thirdparty/include/msvc/*
  File: thirdparty/include/msvc/stdint.h
- BSD-3-clause
+ BSD-3-Clause

The first one is positively wrong.  licensecheck command also agrees with
me.

Second one is one of the MIT but it is more like ISC than Expat.
Usually Expat is marked as MIT. (Minor problem)
Expat: Permission is hereby granted  ...
ISC:  Permission to use, copy, modify, ...
(Included MIT liocense does not match source having ISC.)

The last one is a false positive.  Minor case difference between:
 https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 http://spdx.org/licenses/

Also DEP-5 has been adoped as
http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/

So I made minor adjustments in GIT for these.

Also, what are you going to do with curl.exe etc.  I can not sponsor
upload of package with binary blob.  In future, we need to consider
automating this.  Please read
http://www.eyrie.org/~eagle/notes/debian/git.html
https://wiki.debian.org/BenFinney/software/repack

I took care these manually for now.

I will push this to GIT for now:

Oops, lintian gives me:

E: librime source: weak-library-dev-dependency librime1-dev on librime1 (= 
${source:Version})
N: 
N:The given package appears to be a shared library -dev package, but the
N:dependency on what seems to be a corresponding shared library package
N:does not force the same package version. To ensure that compiling and
N:linking works properly, and that the symlinks in the -dev package point
N:to the correct files in the shared library package, a -dev package
N:should normally use (= ${binary:Version}) for the dependency on the
N:shared library package.
N:
N:Sometimes, such as for -dev packages that are architecture-independent
N:to not break binNMUs or when one doesn't want to force a tight
N:dependency, a weaker dependency is warranted. Something like (=
N:${source:Upstream-Version}), ( ${source:Upstream-Version}+1~),
N:possibly using ${source:Version} instead, is the right approach. The
N:goal is to ensure that a new upstream version of the library package
N:doesn't satisfy the -dev package dependency, since the minor version of
N:the shared library may have changed, breaking the *.so links.
N:
N:Refer to Debian Policy Manual section 8.5 (Dependencies between the
N:packages of the same library) for details.
N:
N:Severity: important, Certainty: possible
N:
N:Check: control-file, Type: source

Let me think ... I may have been wrong.

Now you also need to update ibus/fcits-rime.

Osamu


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

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Osamu Aoki]

On Sun, Jun 29, 2014 at 11:30:52AM -0400, Guo Yixuan wrote:
 For this, I think it's easier to add a Files-Excluded line to
 debian/copyright
 header, and let uscan do the repacking: [1]
 
 Files-Excluded: thirdparty/bin/curl.exe
 thirdparty/src/opencc-windows/opencc.dll
 thirdparty/src/opencc-windows/opencc.exe
 thirdparty/src/opencc-windows/opencc_dict.exe

Great!  Please update GIT.
 
 In addition, we should add +dfsg to the package version, so it should
 be 1.1+dfsg-1, and we need to add some mangle rules to debian/watch.

Yep.  This is what I did before uploading.  It is in NEW.

If you find issues, please tell me to reupload another version.

 I think these two packages are already updated to the new API.
 I'll double check it soon, and update fcitx-rime to 0.3.1.

Please.

Osamu


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

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Osamu Aoki]

Hi,

On Sun, Jun 22, 2014 at 12:01:49PM -0400, GUO Yixuan wrote:
 On Sun, Jun 22, 2014 at 08:27:12PM +0900, Osamu Aoki wrote:
  
  On Sun, Jun 22, 2014 at 01:45:32AM +0800, Aron Xu wrote:
   On Sun, Jun 22, 2014 at 1:33 AM, GUO Yixuan culu@gmail.com wrote:
I'm just waiting for a confirmation on the librime-dev = librime1-dev
renaming, from Aron, as we discussed in a previous thread. [1]
   
   
   As said before, I don't have strong opinion on either way.
  
  My popsition is that you have not presented enough reason to do this.
  So do not do this.
 
 I remember one possible reason: librime 1.0 breaks some ABI and API
 compatibility, 

Yes.  Thus you need to change librime0 to librime1 etc.

 so we should change the -dev package name. [1][2]

No.  Your reference does not say so.

This is only needed if you are having massive dependency and transition
library in complicated arrangement which you seem not to chase.

KISS (Keep it simple and S***) is the reason why I said no.  (I am not
saying your method break things)

As long as all dependency packages are binNMUed using the standard
procedure, the same librime-dev is sufficient and simple.

Let's review what your reference say:

 [1] https://wiki.debian.org/TransitionBestPractices

The first reminder is:

If there's a backward-incompatible ABI change (binary incompatibility)
which prevents old programs from working with the new library: you need
to change the library soname, and you need to change the library package
name, but you usually should not change the -dev package name.
  ^

 [2] 
 http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
Hmmm... not therer but look at:
http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id249952

1. -DEV package names

Package maintainer has two options when naming a shared library -DEV
package. 
...  This document is neutral on which method to deploy.

You did not present rationale to do extrastep with the second option.

I see 
librime1 (= ${source:Version}), librime1 ( ${source:Version}+1~)

This seems binNMU unsafe.  Please drop max version limitation.

Regards,

Osamu


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

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: What is the hold-up of uploadin new package

[Osamu Aoki]

Hi,

On Sun, Jun 22, 2014 at 01:45:32AM +0800, Aron Xu wrote:
 On Sun, Jun 22, 2014 at 1:33 AM, GUO Yixuan culu@gmail.com wrote:
  I'm just waiting for a confirmation on the librime-dev = librime1-dev
  renaming, from Aron, as we discussed in a previous thread. [1]
 
 
 As said before, I don't have strong opinion on either way.

My popsition is that you have not presented enough reason to do this.
So do not do this.
 
  In addition, because the symbol files are not useful, should we create
  a shlibs file?
 
  [1] 
  https://lists.alioth.debian.org/pipermail/pkg-ime-devel/2014-May/004168.html
 
 
 Don't think it's so useful nowadays, either use symbols or don't use
 anything in normal cases.

Hmmm... I think if we drop the symbol file, packaging tool chain
automatically generates the shlibs file.   Please look into your
generated binary package to verify :-)  I see it there.

I suggest you to add the following at the top of debian/rules file if
you have not.  I am doing this for all my new upload (see ibus).

# See dpkg-buildflags(1)
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/default.mk
#export DEB_BUILD_MAINT_OPTIONS = hardening=+all
export DEB_CFLAGS_MAINT_APPEND  = -Wall -pedantic
export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed

This also helps you to test build consistently etc.  This is good idea
for the newer dpkg(1.16.1).

See explantion in the EXAMPLES section of dpkg-buildflags(1) manpage.

Regards,

Osamu


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

Bug#750623: [Pkg-ime-devel] Bug#750623: Bug#750623: librime-dev: not installable on sid

[Osamu Aoki]

Hi,

On Sat, Jun 21, 2014 at 01:50:39PM -0400, GUO Yixuan wrote:
 On Sat, Jun 07, 2014 at 01:18:53AM +0900, Osamu Aoki wrote:
...
  This seems to be not-so-correct package dependency in the debian/control
  case which breaks with binNMU.
 
 It seems to be no binNMU-safe way for a maximum version dependency (=),
 from arch: all to arch: any. [1] However, we can change librime-dev to
 be arch: any, and solve this problem. (This is also required for an
 migration to multiarch.)
 
 [1] https://wiki.debian.org/binNMU

Here is my summary in my debmake package documentation.
 http://people.debian.org/~osamu/debmake.html#control

For the safe binNMU, the dependency among binary packages from a same
source package needs attention if there are both Architecture: any and
Architecture: all packages involved in it.

Architecture: any package depends on Architecture: any foo package
Depends: foo (== ${binary:Version})
Architecture: any package depends on Architecture: all bar package
Depends: bar (== ${source:Version}
Architecture: all package depends on Architecture: any baz package
Depends: baz (= ${source:Version}) 
(This is good enough for most cases.)

So do not put the max version limitation.

Also, as you pointed out, make this multiarch and fix pkgconfig file
and make this arch: any package.  Then use
Depends: foo (== ${binary:Version})

As I checked this source, I see windows platform binaries included in the
upstream source.  (exe and dll)  I do not see source for curl.exe in
this package.  So at least we should remove this in the source to be
DFSG.

I have not spend time to do the full review but this is FYI.

Regards,

Osamu


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

Bug#750623: [Pkg-ime-devel] Bug#750623: What is the hold-up of uploadin new package

[Osamu Aoki]

Hi,

Why are not we uploading the new librime?

Osamu


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

Bug#750902: RFH: Bug#750902: ibus: Have unconditional B-D on libwayland-dev - prevents build on kfreebsd

[Osamu Aoki]

Hi,

Simon, thanks for quick help.

Uploading it.

Osamu


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

Bug#750902: RFH: Bug#750902: ibus: Have unconditional B-D on libwayland-dev - prevents build on kfreebsd

[Osamu Aoki]

Hi Gnome folks and Niels,

Ibus is the input method GNOME uses as default and I am adding the
wayland support.

I need help on the ibus bug #750902 but can not locate good examples to
follow.

On Sun, Jun 08, 2014 at 11:31:51AM +0200, Niels Thykier wrote:
 The ibus package added an unconditional Build-Depends on
 libwayland-dev, but libwayland-dev is currently only built on linux,
 whereas ibus has been built on kfreebsd and hurd.  This prevents ibus
 from being rebuilt in these architectures and thereby prevents ibus
 from migrating to testing.

True.
 
 Possible solutions include:
  * Have wayland ported to kfreebsd (and hurd)

I am not seeking this path.

  * Make ibus-wayland a linux-only binary and make the Build-Depends
a linux-any dependency

I want to do this but I am not quite sure what exactly to do.

What I need is an working example of existing package.  Can you point me
any good example?

My specific questions are how to update debian/control and debian/rules?

You say linux-only binary but what exactly should I use in the
debian/control?  linux-any seems to be the word used in the policy
( 
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec
 )

Is this correct for debian/control?
 
http://anonscm.debian.org/gitweb/?p=pkg-ime/ibus.git;a=blob;f=debian/control;hb=HEAD
 
 
| Source: ibus
| ...
| Build-Depends: autoconf,
| ...
|libwayland-dev [linux-any],
| ...
| 
| Package: ibus-wayland
| Architecture: linux-any
| ...

Also, what is the most effective way to make debian/rules architecture
dependent?  I do not know how to set $(OS) elegantly.
 
http://anonscm.debian.org/gitweb/?p=pkg-ime/ibus.git;a=blob;f=debian/rules;hb=HEAD

| ifdef ($(OS),linux-any)
| override_dh_auto_configure:
| dh_auto_configure -- \
| --enable-wayland \
| --enable-introspection \
| ...
| else
| override_dh_auto_configure:
| dh_auto_configure -- \
| --enable-introspection \
| ...
| endif

Your help to point me to the good example is most appreciated.

Regards,

Osamu


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

Bug#750623: [Pkg-ime-devel] Bug#750623: librime-dev: not installable on sid

[Osamu Aoki]

Hi,

 On Thu, Jun 05, 2014 at 07:35:56AM +0200, Ralf Treinen wrote:
 Package: librime-dev
 Version: 0.9.9-1
 Severity: grave
 User: trei...@debian.org
 Usertags: edos-outdated
 
 librime-dev can no longer be installed in sid since it depends on
 librime0  0.9.9-1+1~. However, the version of librim0 in sid is
 0.9.9-1+b1.

This seems to be not-so-correct package dependency in the debian/control
case which breaks with binNMU.

 Since librime-dev is architecture=all it needs a sourceful upload.

Now that upstream has 1.1 out there, it is time to upload new upstream
package anyway.  Hmmm... it seems Guo Yixua is working in GIT.

Regards,

Osamu


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

Bug#746136: ibus and FTBFS

[Osamu Aoki]

Hi,

Thanks for the patch and updating git repo for 1.5.6.  I should have
pushed my updated repo.

gi transition and python3/wayland support are the reason of my delay.
The vala issue was fixed by the upstream developer (in Fedora) and I am
using that fix now in here.

Now that ibus-pinyin is out of gi transition, I think I can drop
python-ibus and should be easy to package just for python3.

Please be paitient.

Osamu


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

Bug#746136: ibus: FTBFS: switcher.vala:343.23-343.29: error: Assignment: Cannot convert from `Gdk.EventKey**' to `Gdk.EventKey*'

[Osamu Aoki]

Hi,

On Sun, Apr 27, 2014 at 02:07:09PM +0200, David Suárez wrote:
 Source: ibus
 Version: 1.5.5-1
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20140426 qa-ftbfs
 Justification: FTBFS on amd64

Upstream fixed this in new upstream release 1.5.6
I can see their commit message to git and ML announcement.

| ibus 1.5.6 is released:
| https://github.com/ibus/ibus/releases/tag/1.5.6
| 
| * data/dconf: Don't run dconf update if $(DESTDIR) is set
| * Support python3 [1]
| * Fix to show Property Panel when the mode is auto hide.
| * Do not let property panel follow cursor when it's always shown.
| * Fix a build error of Gdk.EventKey with vala 0.23.2
| * Use XKB layout string instead of ibus-keyboard icon on panel.
| 
| [1] To enable python3, run './configure --with-python=python3' in ibus
| source directory.

But they are not doing release of tarball at the normal place.
This makes it difficult to find the new upstream release.

I will get their src.rpm from FEDORA to get the tar for now.
 http://arm.koji.fedoraproject.org/koji/buildinfo?buildID=191821

Osamu


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

Bug#737090: [Pkg-ime-devel] Bug#737090: Bug#737090: ibus-pinyin: Perhaps need pinyin database

[Osamu Aoki]

control: reopen 737090
control: fixed 737090 ibus-pinyin/1.5.0-1
control: unfound 737090 ibus-pinyin/1.0.1-3
control: unfound 737090 ibus-pinyin/1.0.1-4

Hi,

On Sun, Feb 02, 2014 at 08:49:03PM -0800, Hongzheng Wang wrote:
 I have installed and tested your new version (1.0.1-4).  It works fine.

This is about libpyzy 1.0.1-4.

So my recent found/unfound was with wrong versions.

Adjusting it by this, I hope.

Osamu 


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

Bug#737090: [Pkg-ime-devel] Bug#737090: ibus-pinyin: Perhaps need pinyin database

[Osamu Aoki]

control:  block 737090 by 737136

Hi,

On Wed, Jan 29, 2014 at 11:02:56PM -0800, Hongzheng Wang wrote:
 The package ibus-pinyin in sid just updated to 1.5.0.  I noticed that it no
 longer depends on ibus-pinyin-db-open-phrase/android.  My question is where
 the new ibus-pinyin gets pinyin database.  I checked Fedora package and
 found there is a pyzy that contains a file 'main.db'.  By contrast, Debian's
 libpyzy contains only pyzy algorithms.

My upload of new  libpyzy fixing 737136 should have fixed this bug for
you.  Please confirm since you can use these packages.  I can not.

I keep tyhis bug as grave for now to prevent going to testing.

Once new libpyzy 1.0.1-4 is in testing, I will close this bug.
Than also uplad new -5 splitting db file as separate package.

I wonder why keep in this complicated 2 source packages. I think it is
better to package as 2 simple separate source packages.

Regards,

Osamu


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

Bug#737090: [Pkg-ime-devel] Bug#737090: Bug#737090: ibus-pinyin: Perhaps need pinyin database

[Osamu Aoki]

control: clone 737090 -1
control: severity -1 important
control: reassign -1 libpyzy
control: retitle -1 Please include pyzy-database-1.0.0

Let's keep grave for 737090 to prevent testing migration.

Considering urgent situation of fixing this 737090 bug;

 So they include pyzy-database-1.0.0.tar.bz2 .  Considering this database
 may be arch-indep.  We may be better off packaging separately.

Official upstream:
https://code.google.com/p/pyzy/downloads/detail?name=pyzy-database-1.0.0.tar.bz2
 
https://pyzy.googlecode.com/files/pyzy-database-1.0.0.tar.bz2

https://code.google.com/p/pyzy/downloads/detail?name=pyzy-0.1.0.tar.gz
https://pyzy.googlecode.com/files/pyzy-0.1.0.tar.gz

 (Although this is not pkg-ime package but considering people inviolved
 and archive used, i hope it is OK to include it into pkg-ime.
 
 * Tue May 28 2013 Peng Wu p...@redhat.com - 0.1.0-6
 - Obsoletes ibus-pinyin-db

I propose 2 step approach:

Step 1, upload libpyzy with pyzy-database-1.0.0
Step 2, split libpyzy into libpyzy and pyzy-database
let libpyzy depend on pyzy-database
 (For size, this is better)

Osamu


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

Bug#736612: Does nothing

[Osamu Aoki]

control: severity 736612 normal

Hi,

FYI: I do not have any problem here 

On Sat, Jan 25, 2014 at 05:14:29PM +0200, Juhapekka Tolvanen wrote:
 Package: im-config
 Version: 0.24-1

This is sid/testing version

 Severity: grave

This should not be used to indicate you are extremely annoyed.

 When I use im-config, it writes these to console:

Can you elaborate how you started X.  (Or are you in X)
Which desktop
 
 % im-config  
 
 ** (zenity:2238): WARNING **: Couldn't register with accessibility
 bus: Did not receive a reply. Possible causes include: the remote
 application did not send a reply, the message bus security policy
 blocked the reply, the reply timeout expired, or the network
 connection was broken.

I would say What the h*** too.  But problem seems to be not im-config
but zenity in your environment.

 ** (zenity:3354): WARNING **: Couldn't register with accessibility
 bus: Did not receive a reply. Possible causes include: the remote
 application did not send a reply, the message bus security policy
 blocked the reply, the reply timeout expired, or the network
 connection was broken.
 head: virhe luettaessa tiedostoa ”Asiakirjat”: On hakemisto
 tail: virhe luettaessa tiedostoa ”Asiakirjat”: On hakemisto
 E: Configuration in Asiakirjat is manually managed. Doing nothing.

In order to make problem cleaner, can you change Desktop locale to be
en_US.UTF-8.  I would like to see exactly what happens under
reproducible environment from my side.

 virhe luettaessa tiedostoa ”Asiakirjat”: On hakemisto means: error
 reading file ”Asiakirjat”: Is directory. Asiakirjat happens to be the
 first file or directory in my home directory, when running running
 command ls.

Meaning is one thing but we need to track the code where these strings
are living in.  The program is written in English strings while they get
translated with gettext mechanism.  So, please.
 
 Why on earth it tries to do something in that directory ~/Asiakirjat ?
 Where is the current configuration of im-config?

I do not know.  but to identify issues and forward to zenity with
meaningful message, we need more data from you.  At least, I do not have
problem like yours here on sid.

 -- System Information:
 Debian Release: jessie/sid
   APT prefers stable
   APT policy: (990, 'stable'), (500, 'testing-proposed-updates'), (500, 
 'oldstable-updates'), (500, 'oldstable-proposed-updates'), (102, 'testing'), 
 (101, 'unstable')

H... this make me think   Why are you reporting sid/testing
version bug with such system.

Why put aggressive testing-proposed-updates in 500 while keeping testing
in 102.  This seems to indicate you tend to believe library from any
repo can be mixed.  (Debian's package version dependency description is
getting better on handling odd combinations but this is like playing
with fire.)  For your case, upgrade to testing seems right thing to do
if you can.

Please make sure you have consistent library from a single set of repo
unless you know extremely well on this library ABI issue.

To me, you have broken library ABI issue by using unsupported
combination of packages.

Hmmm... unless you have a clean rational report as follow-up in a week
or so, I will close this bug.  (I consider this to be user
mis-configuration at this moment.)

Osamu


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

Bug#712577: fixed in ibus-input-pad 1.4.0-3

[Osamu Aoki]

Hi,

On Thu, Dec 05, 2013 at 11:01:29AM +0100, Andreas Beckmann wrote:
 On Wednesday, 19. June 2013 14:48:16 Osamu Aoki wrote:
   ibus-input-pad (1.4.0-3) unstable; urgency=low
   .
 * Team upload.
 * Fix libexecdir to match ibus-setup expectation.
   Closes: #712577
 
 Hi,
 
 while all the similar libexecdir ibus bugs have already been fixed in the 
 previous wheezy point release, this one here seems to have been overlooked. 
 The window for 7.3 will close on the coming weekend ...

Looks like I overlooked this rarely used package.

(I had halffinished commit in local git. After uploading it, I realize
it was not complete.  I will reupload fixed one soon once current
package is rejected.)

Osmau


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

Bug#710664: sbackup maintainer?

[Osamu Aoki]

Hi,

Although fixing this serious bug is not a big deal but another NMU for
very outdated version does not make much sense to me.

I tried newer 0.11.4-0ubuntu5 Ubuntu source package which builds OK.
  https://launchpad.net/sbackup
  https://launchpad.net/ubuntu/+source/sbackup
(I see some rooms for improvement)

(I see no Fedora package...)

Since Christian was NMU and it was removed previously, can I consider
this practically orphaned and candidates for take over.  (This is marked
as lowNMU too.)

  http://packages.qa.debian.org/s/sbackup.html

I do not know if I have time to do so ... but it is good to check
status before making efforts.

Regards,

Osamu


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

Bug#721489: system default background color value

[Osamu Aoki]

control: forcemerge 721489 723721

Hi,

gnome-terminal as installed is set to use system default color for text
and background.  Let's start it under different DE:

Under GNOME3, gnome-terminal is black text on white background.
Under XFce,   gnome-terminal is black text on black background.
Under KDE,gnome-terminal is black text on black background.

If I configure this terminal to a custom setting by unchecking use
color from system theme under Color tab, things work as expected
(Green on Black) for all cases.  So problem is the default background
color setting value nterpretation is different for DEs.

This needs to be fixed properly.

(Under KDE, I started gnome-terminal from another console, terminal size
seems strange.  That is another story.)

Osamu


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

Bug#724226: [Pkg-ime-devel] Bug#724226: input-pad = 1.0.2-1 breaks ibus-input-pad

[Osamu Aoki]

Hi,

On Sat, Oct 05, 2013 at 07:35:42PM +0200, Pino Toscano wrote:
...
 ... because both input-pad and ibus-input-pad must use the *same* gtk 
 version, be it gtk2 or gtk3, to avoid this clash.

Thanks for kind explanation.

With the recent upload of ibus-input-pad, I hope I fixed this bug.

diff --git a/debian/control b/debian/control
index 8d1f110..7bcbbf0 100644
--- a/debian/control
+++ b/debian/control
@@ -8,9 +8,9 @@ Build-Depends:
  automake,
  autotools-dev,
  intltool (= 0.40.0),
- libgtk2.0-dev,
+ libgtk-3-dev,
  libibus-1.0-dev,
- libinput-pad-dev (= 1.0.0),
+ libinput-pad-dev (= 1.0.2-2~),
  libxkbfile-dev,
  libxklavier-dev (= 4.0),
  libxml2-dev (= 2.0),
diff --git a/debian/rules b/debian/rules
index 53c072c..5ba69eb 100755
--- a/debian/rules
+++ b/debian/rules
@@ -3,4 +3,4 @@
dh  $@
 
 override_dh_auto_configure:
-   dh_auto_configure -- --libexecdir=/usr/lib/ibus
+   dh_auto_configure -- --libexecdir=/usr/lib/ibus --with-gtk=3.0 

Now cleanly with-gtk=3.0. I can input :-)  ↛↜↝↡↢↣‰‱⁑℉㍱㎑㎒㎓

Osamu


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

Bug#724226: [Pkg-ime-devel] Bug#724226: input-pad = 1.0.2-1 breaks ibus-input-pad

[Osamu Aoki]

control: reassign 724226 libinput-pad-dev 
control: retitle  724226 libinput-pad-dev: Should depend on libgtk-3-dev (not 
libgtk2.0-dev)

Hi,

On Sat, Oct 05, 2013 at 03:03:19PM +0200, Pino Toscano wrote:
 tag 724226 - unreproducible
 severity 724226 serious
 retitle 724226 FTBFS: input-pad = 1.0.2-1 breaks ibus-input-pad
 thanks
 
 Hi,
 
 the problem is due to input-pad 1.0.2-1 switching to gtk3 instead of 
 gtk2: 

Yes, I switched input-pad to use gtk3.

 while pkg-config succeeds in doing the existence check of
 input-pad.pc, querying it for cflags and libraries fails in a clean 
 chroot:
 
 | $ pkg-config --cflags input-pad
 | Package gtk+-3.0 was not found in the pkg-config search path.
 | Perhaps you should add the directory containing `gtk+-3.0.pc'
 | to the PKG_CONFIG_PATH environment variable
 | Package 'gtk+-3.0', required by 'input-pad', not found

libinput-pad-dev is depending on 
 * libinput-pad1 and
 * libgtk2.0-dev (Hmmm... this is strange.)

libinput-pad1 is depending on 
 * libgtk-3-0(So you should have this in chroot)

So in clean chroot with all the dependency installed, you have
libgtk-3-0 but no gtk+-3.0.pc file from libgtk-3-dev.

 this happens as input-pad is built against gtk3, while ibus-input-pad is 
 currently built against gtk2, and a clean buildd chroot has no gtk3 
 installed.

I thought I can keep ibus-input-pad in gtk2 while input-pad as gtk3.  That
is what I did. 

 This means there are two possible solutions
 a) switch also ibus-input-pad to gtk3  ** I do not mind doing this **
** as next step **
 b) switch back input-pad to gtk2 (and reassign this bug to it)

I think what is needed is:
  * Change dependency of libinput-pad-dev to libgtk-3-dev

This is a bug to be fixed.

(I do not know how I got away with build using cowbuilder)

Osamu


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

Bug#725134: ibus: ERROR:root:Could not find any typelib for Gtk

[Osamu Aoki]

control: severity 725134 normal
control: retitle 725134 add Depends: gir1.2-gtk-3.0

Hi, I think I figured out the cause 

Recently I know testing had ibus 1.5 transioton and missing dependency 
package issues but I thought all these are fixed now.

On Tue, Oct 01, 2013 at 11:49:34AM -1000, Ryo Furue wrote:
 Package: ibus
 Version: 1.5.3-7

We had problem in 1.5.3-5: http://bugs.debian.org/722121

Partial system upgrade may be the cause. Please run:

$ sudo apt-get update; sudo apt-get dist-upgrade

(But you seems to be quite current)

 Basically, I cannot use ibus any longer:
 $ /usr/bin/ibus-setup
 ERROR:root:Could not find any typelib for Gtk
 Traceback (most recent call last):
   File /usr/share/ibus/setup/main.py, line 29, in module
 from gi.repository import Gtk
 ImportError: cannot import name Gtk

Oh not iBus but GTK. H

Do you have: gir1.2-gtk-3.0 package?

If not please install ... If fixed, I guess I need to add dependency

Please tell me the result.

Thanks in advance

Osamu



   APT policy: (500, 'testing')
Good.
 
 Kernel: Linux 3.10-3-686-pae (SMP w/8 CPU cores)
 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
 Shell: /bin/sh linked to /bin/dash
 
 Versions of packages ibus depends on:
 ii  dconf-cli0.16.1-1
 ii  dconf-gsettings-backend [gsettings-backend]  0.16.1-1
 ii  gir1.2-ibus-1.0  1.5.3-7
Good

 ii  python-gi3.8.2-1
Good.

The above error message does not make sense.

Osamu


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

Bug#724226: [Pkg-ime-devel] Bug#724226: ibus-input-pad: FTBFS: setup-gtk2.c:26:23: fatal error: input-pad.h: No such file or directory

[Osamu Aoki]

control: tags 724226 - serious
control: tags 724226 + unreproduceble

Thanks David for your valuable work.  But unlike your other reports,
this one can not be reproduced under pbuilder as below.

I can not identify possible cause for your case ...

May I close this bus since this may be some transient error?

On Sun, Sep 22, 2013 at 06:56:22PM +0200, David Suárez wrote:
 Source: ibus-input-pad
 Version: 1.4.0-3
 Severity: serious
 Tags: jessie sid
 User: debian...@lists.debian.org
 Usertags: qa-ftbfs-20130922 qa-ftbfs
 Justification: FTBFS on amd64
... 
 Relevant part (hopefully):
  gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../engine 
  -DDATAROOTDIR=\/usr/share\ 
  -DIBUS_INPUT_PAD_SETUP_UI_FILE=\/usr/share/ibus-input-pad/setup/setup-gtk2.ui\
 -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/ibus-1.0 
  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  
  -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include 
  -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 
  -I/usr/include/pango-1.0 -I/usr/include/gio-unix-2.0/ 
  -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
  -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 
  -I/usr/include/libdrm -I/usr/include/harfbuzz   -g -O2 -fstack-protector 
  --param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o 
  ibus_setup_input_pad-setup-gtk2.o `test -f 'setup-gtk2.c' || echo 
  './'`setup-gtk2.c
  setup-gtk2.c:26:23: fatal error: input-pad.h: No such file or directory
   #include input-pad.h
 ^
  compilation terminated.
  make[3]: *** [ibus_setup_input_pad-setup-gtk2.o] Error 1

I just recompiled this source with pbuilder under amd64 ... no problem as:

...Relevant part (hopefully):
libtool: link: ar cru .libs/libiconfig.a .libs/libiconfig_la-iconfig-gtk2.o 
libtool: link: ranlib .libs/libiconfig.a
libtool: link: ( cd .libs  rm -f libiconfig.la  ln -s 
../libiconfig.la libiconfig.la )
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../engine -DDATAROOTDIR=\/usr/share\ 
-DIBUS_INPUT_PAD_SETUP_UI_FILE=\/usr/share/ibus-input-pad/setup/setup-gtk2.ui\
   -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/ibus-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -pthread -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/harfbuzz 
-I/usr/include/input-pad-1.0 -pthread -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm 
-I/usr/include/harfbuzz   -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security -c -o ibus_setup_input_pad-main.o `test -f 
'main.c' || echo './'`main.c
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../engine -DDATAROOTDIR=\/usr/share\ 
-DIBUS_INPUT_PAD_SETUP_UI_FILE=\/usr/share/ibus-input-pad/setup/setup-gtk2.ui\
   -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/ibus-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -pthread -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12 -I/usr/include/libdrm -I/usr/include/harfbuzz 
-I/usr/include/input-pad-1.0 -pthread -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/pixman-1 
-I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/libdrm 
-I/usr/include/harfbuzz   -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security -c -o ibus_setup_input_pad-setup-gtk2.o `test 
-f 'setup-gtk2.c' || echo './'`setup-gtk2.c
/bin/bash ../libtool --tag=CC   --mode=link gcc -pthread 
-I/usr/include/ibus-1.0 -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include   -pthread -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gtk-2.0 
-I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/atk-1.0 
-I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ 

Bug#713459: [Pkg-ime-devel] Bug#713459: gcin: FTBFS: win1.cpp:164: undefined reference to `GTK_TABLE'

[Osamu Aoki]

Hi,

Thanks David.

Although Yao Wei does not face this bug on his system, as I checked, I
faced a bit different bugi with a newer source:

...
make[2]: Entering directory `/home/osamu/src/gcin/ftbfs/gcin-2.8.1+dfsg'
Makefile:3: config.mak: No such file or directory
Makefile:277: .depend: No such file or directory
g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -D_FORTIFY_SOURCE=2 -DUNIX=1  -g  -I./IMdkit/include 
-I./im-client -DDEBUG=0 -DGCIN_TABLE_DIR=\\ -DGCIN_OGG_DIR=\\ 
-DDOC_DIR=\\ -DGCIN_ICON_DIR=\\ -DGCIN_SCRIPT_DIR=\\ -DGCIN_BIN_DIR=\\ 
-DSYS_ICON_DIR=\\ -DFREEBSD= -DMAC_OS= -DG_DISABLE_SINGLE_INCLUDES 
-DG_DISABLE_DEPRECATED -DGDK_DISABLE_SINGLE_INCLUDES -DGDK_DISABLE_DEPRECATED 
-DGTK_DISABLE_SINGLE_INCLUDES -DGTK_DISABLE_DEPRECATED -MM *.cpp  .depend
/bin/sh: 1: g: not found
make[2]: [.depend] Error 127 (ignored)

strange and fails later.

Yao, please build using Debian tar balls after unpacking with
dpkg-source -s

Full log attached as xz-file.


gcin_2.8.1+dfsg-1_amd64.build.xz
Description: Binary data

Bug#724600: [Pkg-ime-devel] Bug#724600: ibus-table-latex: Can't switch to latex input method

[Osamu Aoki]

Hi,

FYI: ibus in testing had gone through 1.4 - 1.5 library transition.  
At the same time python binding method and its dependency situation has
changed.

On Wed, Sep 25, 2013 at 05:53:46PM +0200, frydo wrote:
 Package: ibus-table-latex
 Version: 1.3.0.20100528-3
 Severity: grave
 Justification: renders package unusable
 
 It's not possible to switch to latex input method in Ibus.
 I can have the Hangul input method, but not the latex input method.

1.5.0.is.1.5.0.20130419-2 went to testing a bit too early.  (Blame me.)

Do you have ibus 1.5.3-7 (which is in testing today)

Hmmm. This ibus-table-latex was not touched.  Maybe I need to add
python-ibus dependency to it for new situation.  Can you check?

If these do not work, I need to check.

 I guess this comes from a recent update, maybe one of ibus-table.

I do not know how to use ibus-table-latex to test.
Please let me know minimal case to test.

Osamu


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

Bug#722713: ibus-clutter: FTBFS with ibus 1.5

[Osamu Aoki]

Source: ibus-client-clutter
Version: 0.0+git20090728.a936bacf-5
Severity: serious
Justification: FTBFS

 ibus-client-clutter
FTBFS,
https://buildd.debian.org/status/package.php?p=ibus-client-cluttersuite=sid

Also, will you consider to join pkg-ime group like other IM related
package for this one?

  https://wiki.debian.org/Teams/IMEPackagingTeam
  http://qa.debian.org/developer.php?login=pkg-ime-de...@lists.alioth.debian.org

Oh, I can not find source at
http://git.moblin.org/cgit.cgi/ibus-client-clutter

Where is it?  

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (100, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.11-rc7-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


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

Bug#722713: ibus-clutter: FTBFS with ibus 1.5

[Osamu Aoki]

On Fri, Sep 13, 2013 at 02:52:35PM -0400, Jeremy Bicha wrote:
 Please see the Ubuntu patch:
 
 https://launchpadlibrarian.net/146107977/ibus-client-clutter_0.0%2Bgit20090728.a936bacf-5_0.0%2Bgit20090728.a936bacf-5ubuntu1.diff.gz

Oh, I overlooked it.  I will NMU.  Thanks for reminder.


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

Bug#722121: installing `gir1.2-gtk-3.0` doesn't fix this bug here

[Osamu Aoki]

Hi,

On Wed, Sep 11, 2013 at 06:24:48PM +0200, Ivan Sergio Borgonovo wrote:
 On Thu, 12 Sep 2013 00:31:43 +0900
 Osamu Aoki os...@debian.org wrote:
 
  Hi,
 
  Try install python-gi

This is needed for some rare case.

 Sorry if I wasn't clear.
 At least for cangjie and quick it works.
 
 I did test with xkbc installed. ibus-setup doesn't fail to start, I
 tried to type with xkbc selected and it simply wrote latin characters
 and I couldn't see any selection box as the one I'm used to see with

I am not 100% sure but sounds like normal thing to expect since this
xkbc is for deadkey etc for some european languages with funny marking
around characters.

 Chinese. I simply don't know if this is the correct behavior but at
 least it doesn't fail to start as before.
 
 python-gi was already installed.

Usually on Desktop, yes.

 So for what I need it works.

Anyway, this is some transition problem or no problem.  Let me close
this original bug and address your bug if it happens under some well
defined situation.

Osamu


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

Bug#722121: installing `gir1.2-gtk-3.0` doesn't fix this bug here

[Osamu Aoki]

Hi,

Try install python-gi


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

Bug#722121: installing `gir1.2-gtk-3.0` doesn't fix this bug here

[Osamu Aoki]

Hi,

On Mon, Sep 09, 2013 at 08:44:48PM +0200, Ivan Sergio Borgonovo wrote:
 I can confirm the problem and having installed gir1.2-gtk-3.0 doesn't
 seem to work here.

Question is what ibus modules are you using.

If you are using ibus-* packages listed as bad in 
 http://release.debian.org/transitions/html/ibus1.5.html

This is expected situation under sid during transition.

Please let me know what packages you use.

Also, python dependency needs to be installed as Jeremy pointed out.
  * python-ibus for some ibus modules (ibus-setup)
or
  * python-gi + gir1.2-ibus-1.0 for some ibus modules

Osamu


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

Bug#715568: ibus 1.5.3 polishing

[Osamu Aoki]

control: severity 715568 important
control: retitle 715568 IM icon etc. missing
control: found 715568 1.5.3-2
control: found 715568 1.5.3-3

Hi,

I just uploaded 1.5.3-3.  I think it is better based on newer 1.5.3
based FC19 using their site publishing rc.rpm

  http://arm.koji.fedoraproject.org/koji/
  http://arm.koji.fedoraproject.org/koji/packageinfo?packageID=3103

It works if you configure with ibus-setup.  But GNOME's control-center
does not work and some icon at the top right side is missing and flying
notification at the center of sreen is missing and SUPER-SPACE does not
work.

So I am downing severity and changing bug title.

Chances are I need to touch other packages and possibly fix multiarch
related file path.

Osamu


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

Bug#715568: Please do not use --disable-ibus

[Osamu Aoki]

Hi #715568,

   Changed path of dbus is related following commit:
   https://github.com/ibus/ibus/commit/458945e7308ab2661355edbf6880102c5f628dbe

This commit was from June 13th and was included in my 1.5.2-3 package as patch 
0015-*.

Of course, 1.5.3-1 include this.  Does this require any patch to other programs?

So far, removing --disable-ibus and recompiling both 
 * gnome-control-center 3.4.3
 * gnome-settings-daemon 3.8.4
get me have functional ibus 1.5 on GNOME 3.8.

But there are few things missing in comparison to FC19.
I do not get nice warning for super-space usage.  Let me figure out it
as a separate bug.

So what ibus should do for the #715568 bug is done with 1.5.3-1.  Just
wait other packages to cope with this in #720489 and its clone -1.

Also what ibus-anthy should do for the #720071 bug is done with 1.5.3-2.
Just wait other packages to fix bugs to get ibus-anthy working again.

Regards,

Osamu

PS: I will focus removal of --disable-ibus in bug #720489


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

Bug#715568: [Pkg-ime-devel] Bug#720071: Bug#715568: Please do not use --disable-ibus

[Osamu Aoki]

Hi,

On Sat, Aug 24, 2013 at 02:18:50PM +0800, Aron Xu wrote:
 On Sat, Aug 24, 2013 at 2:14 PM, Osamu Aoki os...@debian.org wrote:
  Hi #715568,
 
Changed path of dbus is related following commit:
https://github.com/ibus/ibus/commit/458945e7308ab2661355edbf6880102c5f628dbe
 
  This commit was from June 13th and was included in my 1.5.2-3 package as 
  patch 0015-*.
 
  Of course, 1.5.3-1 include this.  Does this require any patch to other 
  programs?
 
  So far, removing --disable-ibus and recompiling both
   * gnome-control-center 3.4.3
   * gnome-settings-daemon 3.8.4
  get me have functional ibus 1.5 on GNOME 3.8.
 
 
 Good to know! If you have such environment, can you do a bit more test
 to see if other input method can function correctly without
 --disable-ibus (I can think of uim, scim, and fcitx)? If no more
 problem I can do the commit on removing --disable-ibus.

fcitx may if we do not install ibus without breaking others.
I doubt others.  That is GNOME upstream decision.  Unless someone
provide patches, I am not optimistic.
 
  But there are few things missing in comparison to FC19.
  I do not get nice warning for super-space usage.  Let me figure out it
  as a separate bug.
 
 
 Guess this means missing ibus-gjs on Debian?

Aha, FC19 had patch for that. I once made package with them and showing
pop-ups.  maybe later.  I am out of time.

Osamu

 
 
 -- 
 Regards,
 Aron Xu
 
 ___
 Pkg-ime-devel mailing list
 pkg-ime-de...@lists.alioth.debian.org
 http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-ime-devel


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