Bug#964284: [gnutls-help] Bug#964284: guile-gnutls: update to use guile 3.0
Hello Ludo, Ludovic Courtès writes: > This is because Guile >= 3.0.1 and >= 2.2.7 changes the GMP allocation > functions such that they go through libgc¹. As a result, libgc may > reuse that memory when it becomes unreachable from its point of view; in > this case, since GnuTLS structures are not scanned by libgc, libgc > doesn’t “see” pointers to those bignums and thus considers they are no > longer reachable. That's interesting, though I might not follow completely. > • In Guile-GnuTLS, arrange so that GnuTLS allocations are made through > libgc. Unfortunately, ‘gnutls_global_set_mem_functions’ was > deprecated in GnuTLS 3.3.0 so this doesn’t look like an option. GnuTLS doesn't call mp_set_memory_functions, so even if it is possible, I doubt that it would affect the current behavior. On the other hand, if GnuTLS (or Nettle) internally allocates an mpz_t, it should be done using the libgc-backed allocator set by Guile and the pointers should be reachable until it is no longer, if I understand correctly. Therefore, I suspect that there might be some code that confuses libgc to track the pointers; one thing that comes to my mind is a manual copy of mpz_t values: https://gitlab.com/gnutls/gnutls/-/blob/master/lib/nettle/pk.c#L141 If you replace memcpy with mpz_init_set, does it work? Regards, -- Daiki Ueno
Bug#956045: gnome-keyring: several cryptographic vulnerabilities
"brian m. carlson" writes: > On 2020-04-08 at 12:15:22, Daiki Ueno wrote: >> "brian m. carlson" writes: >> > [2] is an example of a cross-VM cryptographic timing attack, which can >> > also be applied across processes. Other timing attacks are known even >> > across networks. >> >> I am not sure why you suddenly mention cross-VM attacks while VMs are a >> different beast from containers. > > The attack I mentioned states that it is possible to simply run on the > same processor as the affected process to conduct a side-channel attack. > That applies to containers as well as other processes, in addition to > VMs. That attack assumes that the gnome-keyring-daemon process is running inside the VM and the attacker on the host has full control. That certainly falls into the category of active attacks. >> > It is, in general, not safe to assume that any timing attack is >> > unexploitable. >> >> I would also be concerned with that, if this was reported against crypto >> components. However, this was reported against desktop, where >> protecting active attacks is not a goal for various reasons: >> https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy#Active_Attacks > > gnome-keyring stores data in a cryptographic format and is therefore a > cryptographic tool. The standard cryptographic model assumes an active > attacker, Mallory, who tampers with the data and monitors the actors. We never say that that it is not worth fixing, but we consider it's not our priority, because it's not vulnerable in our supported use-cases. > Moreover, protecting against timing attacks like this is extremely > simple. It can be done with three lines of portable C: > > int x = 0; > for (size_t i = 0; i < n; i++) > x |= a[i] ^ b[i]; And you thought that it's more effective to report it as a vulnerability and just wait 45 days, rather than providing a trivial patch. > You have also not mentioned the other attack which I mentioned in > which there is information disclosure of metadata. That's because it has already been disclosed 5 months before you reported. See the slides (from page 19) at my GUADEC presentation: https://people.gnome.org/~dueno/libsecret-guadec.pdf Although I admit I probably should have filed an issue on the upstream tracker, I don't see any point re-evaluating the same issue and forcing embargo. > I should also point our that when someone reports a security issue to > you with a disclosure deadline, the right time to discuss the matter or > dispute the findings is during the coordination period. If you don't > bother to respond then, then the reporter can only assume that you don't > care at all. I received no such discussion or feedback about the > reports during the 45 day disclosure window, only notification that some > bug reports were filed. Our security team lead immediately forwarded your report to us and discussed the impact with the maintainers. While we agreed that none of those issues are considered to be serious enough, we also filed the upstream issues to track those, which you've never got involved with. If our agreement was not clear to you, there was probably a communication problem. > I would not perform coordinated disclosure with the GNOME Project again.
Bug#956045: gnome-keyring: several cryptographic vulnerabilities
"brian m. carlson" writes: > On 2020-04-07 at 13:45:20, Daiki Ueno wrote: >> "brian m. carlson" writes: >> >> > First, the code to verify the integrity hash is done with memcmp. This >> > is not safe against timing attacks, so an attacker can tamper with the >> > data and determine how much of the hash matches based on the amount of >> > time it takes[0]. This comparison should be done in a constant-time >> > way. >> > >> > [0] This can be a problem with an untrusted container with the user's >> > home directory mounted in it. There's documentation for VS Code that >> > tells people how to do exactly this, so it's clearly a common situation. >> >> Could you elaborate which document you are referring to? I'm wondering >> how it can be a problem provided that VS Code and gnome-keyring-daemon >> are running as a separate process. I believe that both snap and flatpak >> provide a process isolation mechanism. > > The document at [0] provides documentation on how to mount your home > directory into containers. It is well known that people download > containers using Docker that are not audited and may contain malware[1]. How could that be relevant? Note that, to leverage the weakness you reported, you would need to monitor either the activity of gnome-keyring-daemon running on the host, or potentially, any communication between other (trusted) applications and gnome-keyring-daemon. I don't think this container use-case could help. > [2] is an example of a cross-VM cryptographic timing attack, which can > also be applied across processes. Other timing attacks are known even > across networks. I am not sure why you suddenly mention cross-VM attacks while VMs are a different beast from containers. > It is, in general, not safe to assume that any timing attack is > unexploitable. I would also be concerned with that, if this was reported against crypto components. However, this was reported against desktop, where protecting active attacks is not a goal for various reasons: https://wiki.gnome.org/Projects/GnomeKeyring/SecurityPhilosophy#Active_Attacks Fortunately, the situation is improving thanks to the emerging sandboxing technologies (snap, flatpak) and the Wayland security model, though we can't be perfect as long as the user can always choose insecure options to install untrusted applications. >> It's a bit disappointing that you didn't quote the full response with >> the additional context. Here it goes, for reference: > > I believe my report substantially mentioned the relevant points, which > are that > > * you are aware of the issues; > * you don't see the issues as warranting an immediate fix; and > * you are working on a plan to address them in gnome-keyring, but the > point at which they will be fixed is not presently specified. By omitting the text, your report didn't convey the following important points: * we have a different analysis, stance, and ongoing efforts on the issues as mentioned in the linked article * that article indicates that running untrusted applications with unnecessary previleges IS the problem > It was my intention to fairly and accurately present the substance of > your comments as relevant to the bug report without quoting the full > email. I am afraid this didn't work apparently. Regards,
Bug#956045: gnome-keyring: several cryptographic vulnerabilities
"brian m. carlson" writes: > First, the code to verify the integrity hash is done with memcmp. This > is not safe against timing attacks, so an attacker can tamper with the > data and determine how much of the hash matches based on the amount of > time it takes[0]. This comparison should be done in a constant-time > way. > > [0] This can be a problem with an untrusted container with the user's > home directory mounted in it. There's documentation for VS Code that > tells people how to do exactly this, so it's clearly a common situation. Could you elaborate which document you are referring to? I'm wondering how it can be a problem provided that VS Code and gnome-keyring-daemon are running as a separate process. I believe that both snap and flatpak provide a process isolation mechanism. > This was originally reported to the Debian Security Team on February 3, > but they were unable to issue a CVE, so I reported it to the GNOME > Security Team on February 4. The response was the gnome-keyring team is > "aware of those issues" but they "don't think those issues are severe > enough to urge an immediate fix" and plan to address them at an > unspecified point in the future. It's a bit disappointing that you didn't quote the full response with the additional context. Here it goes, for reference: --8<---cut here---start->8--- Hello Brian, First, thank you for reaching out to us. We were aware of those issues and have been piloting a new keyring format in libsecret[1], that should address most of them, aiming at eventually merging it back to gnome-keyring. That said, we don't think those issues are severe enough to urge an immediate fix. I'm also particularly concerned with the use of AES-GCM you suggested for encrypting data at rest, considering its brittleness in terms of nonce reuse, and that using a key wrapping algorithm would be more appropriate for certification purposes[2]. Footnotes: [1] https://opensource.com/article/19/11/secrets-management-flatpak-applications [2] https://phabricator.services.mozilla.com/D54589#1662092 Regards, --8<---cut here---end--->8---
Bug#903159: RFS: libskk/1.0.4-1
Hello Boyuan, Boyuan Yang <073p...@gmail.com> writes: > libskk (1.0.4-1) unstable; urgency=medium > . >* Team upload. >* New upstream release. (2018-06-26) >* Bump Standards-Version to 4.1.5. (no changes needed) >* debian/patches: Refresh patches and backported patches. Thank you for packaging. I have a couple of suggestions. First, the package seems to include the patches from an unmerged PR: https://github.com/ueno/libskk/pull/54. I generally don't recommend backporting patches not merged into master, because there is usually a reason to keep them unmerged. Of course, you can pick any patch as you want; in that case, it would be appreciated if you give a code review on the PR :-) Secondly, you can remove myself from uploaders as I am no longer a DM[1]. The same applies to the other few packages[2]. Footnotes: [1] https://wiki.debian.org/DebianMaintainer#Debian_Maintainer_retirement [2] https://qa.debian.org/developer.php?email=ueno%40unixuser.org Regards, -- Daiki Ueno
Bug#876498: gettext: msgunfmt: heap corruption
Jakub Wilk <jw...@jwilk.net> writes:
> Package: gettext
> Version: 0.19.8.1-4
>
> msgunfmt crashes on the attached file:
>
> $ zcat bad.mo.gz | msgunfmt
> *** Error in `msgunfmt': corrupted size vs. prev_size: 0x57b0abf0 ***
> ...
> Aborted
>
> Unhelpful backtrace:
Running msgunfmt under valgrind might give you more hints. Anyway, I am
suspecting this is caused by a missing NUL termination in
get_sysdep_string in read-mo.c, which should be fixed by the attached patch.
Regards,
--
Daiki Ueno
>From 3c66e050e344ec890f0c1e467753c2ed46bc7bb8 Mon Sep 17 00:00:00 2001
From: Daiki Ueno <u...@gnu.org>
Date: Sat, 23 Sep 2017 18:09:33 +0200
Subject: [PATCH] msgunfmt: Avoid heap buffer overrun
* gettext-tools/src/read-mo.c (get_sysdep_string): NUL-terminate the result.
* gettext-tools/tests/msgunfmt-3: Check no-nul-sysdep.mo.
* gettext-tools/tests/no-nul-sysdep.mo: New test data.
Reported by Jakub Wilk in:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876498
---
gettext-tools/src/read-mo.c | 3 ++-
gettext-tools/tests/msgunfmt-3 | 4 ++--
gettext-tools/tests/no-nul-sysdep.mo | Bin 0 -> 2805 bytes
3 files changed, 4 insertions(+), 3 deletions(-)
create mode 100644 gettext-tools/tests/no-nul-sysdep.mo
diff --git a/gettext-tools/src/read-mo.c b/gettext-tools/src/read-mo.c
index 9ddd6b2d2..33d7a5828 100644
--- a/gettext-tools/src/read-mo.c
+++ b/gettext-tools/src/read-mo.c
@@ -194,7 +194,8 @@ get_sysdep_string (const struct binary_mo_file *bfp, size_t offset,
}
/* Allocate and fill the string. */
- string = XNMALLOC (length, char);
+ string = XNMALLOC (length + 1, char);
+ string[length] = '\0';
p = string;
s_offset = get_uint32 (bfp, offset);
for (i = 4; ; i += 8)
diff --git a/gettext-tools/tests/msgunfmt-3 b/gettext-tools/tests/msgunfmt-3
index 42dc1cc55..3d06d1c52 100755
--- a/gettext-tools/tests/msgunfmt-3
+++ b/gettext-tools/tests/msgunfmt-3
@@ -5,8 +5,8 @@
: ${MSGUNFMT=msgunfmt}
-for n in 1 2 3 4 5 6; do
- LANGUAGE= LC_ALL=C ${MSGUNFMT} "$abs_srcdir"/overflow-$n.mo 2>mu-3.err >/dev/null
+for f in "$abs_srcdir"/overflow-*.mo "$abs_srcdir"/no-nul-sysdep.mo; do
+ LANGUAGE= LC_ALL=C ${MSGUNFMT} $f 2>mu-3.err >/dev/null
test $? != 0 || Exit 1
grep ' is truncated' mu-3.err >/dev/null || Exit 1
done
diff --git a/gettext-tools/tests/no-nul-sysdep.mo b/gettext-tools/tests/no-nul-sysdep.mo
new file mode 100644
index ..6bcaa510535cc77b4b1bd48ecad9741bd4549021
GIT binary patch
literal 2805
zcmca7#4^>ufB_5);D7<nf-o2iT!1P(fEYyr%JTt=CxGODm<fpg0|8teNSp@$m!
k7!85Z5Eu=C(GVC7fzc2c4S_)(0;sK@LGIX5=iv+i0ObD<LI3~&
literal 0
HcmV?d1
--
2.13.5
Bug#854797: pinentry: Add pinentry-emacs package
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > /tmp/emacs$UID/pinentry is not a sensible choice of paths, since it is > within a world-writable directory (/tmp). Ephemeral communications > sockets like this belong in /run on a modern GNU/Linux system. In which degree do you argue against that? emacs --daemon and emacsclient traditionally use a similar path (/tmp/emacs$UID/server) and the file permissions are properly set. Do you think those should be fixed or this pinentry use-case is special for some reason? >> The use case is the following: I am using a terminal inside emacs, I run an >> operation calling gpg-agent, and gpg-agent will query the emacs instance >> through the UNIX socket. (In my case, I am using the emacs instance as a >> window manager, so it makes perfect sense to ask the passphrase through it.) > > I see -- your use case makes sense to me, but we can agree that the > overwhelming majority of uses of emacs do *not* meet this pattern, > right? Not really. It has been a common use-case for a decade: https://www.emacswiki.org/emacs/EasyPG#toc4 Until the majority of distributions adopted GnuPG 2, the suggestion was to install gpg1 along with gpg2 (as EasyPG prefers gpg1). However, it no longer works because some distributions do not ship gpg1 anymore. > If pinentry-emacs is enabled during the build, it looks to me like it > affects the fallback modes for graphical agents that can't find access > to their graphical display as well. It is not activated unless the user explicitly enables it in ~/.gnupg/gpg-agent.conf, as I wrote before. Regards, -- Daiki Ueno
Bug#854797: pinentry: Add pinentry-emacs package
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > I'm sorry, clearly i'm confused! I thought that pinentry-emacs was > "emacs-specific stuff entirely", and therefore it was addressed as well > by the e-mail above. > > What do you think would be the ideal situation with pinentry-emacs, > gnupg-agent, "the INSIDE_EMACS hack", and debian? I would honor the upstream default, which is currently neglected in the Debian package, for uncertain reasons. If you have any concrete concerns, I would suggest you to discuss it in upstream, like in this bug: >> By the way, we have been waiting for your response to the upstream bug >> for a long time: https://bugs.gnupg.org/gnupg/issue2034 > > I was unaware that anything was needed from me here. re-reading it, i'm > still not sure. Can you help me understand what you need from me?for > that bug report? You expressed your uncertainity. Neal provided the docuementation trying to clarify the concerns (though it's not correct). Then you became completely silent. I don't think it's a constructive behavior. > you might think these are far-fetched questions, but i think i've run > into the equivalent of all of these scenarios for the non-emacs > pinentries. I wouldn't answer to those questions here. You should have brought up those in upstream discussion. > I've been reluctant to bring in the additional emacs complexity to the > debian pinentry situation because i don't know that i can support it > well if there are problems, and i want to focus my debian time on things > that i think i can reasonably support. But I would welcome help in > providing this kind of support, if we think that having more direct > pinentry + emacs integration in debian is the right thing to do. Even if you compile it with --enable-inside-emacs, it wouldn't be activated unless the user explicitly set "allow-emacs-pinentry" in ~/.gnupg/gpg-agent.conf. Isn't it feasible to declare it as "unsupported", until the implementation meets your criteria? Regards, -- Daiki Ueno
Bug#854797: pinentry: Add pinentry-emacs package
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > Back on 2016-06-09, in Message-Id: m3r3c6hgch.fsf-u...@gnu.org on > gnupg-de...@gnupg.org, > Daiki Ueno <u...@gnu.org> (cc'ed here) wrote: > >>>If the loopback pinentry evolves into general purpose mechanism, I would >>>rather suggest to remove the Emacs specific stuff entirely. The >>>rationale is: >>> >>>- The immediate motivation behind the Emacs pinentry was that the >>> loopback pinentry had some limitations when used as a replacement of >>> gpg1's passphrase prompt, e.g. [1], which was fixed a while ago. >>> >>>- Debian seems unlikely to build in the Emacs mode with Pinentry[2]. >>> That means to add another (non-working) configuration vector and >>> upstream Emacs cannot rely on that feature[3]. >>> >>>What do you think? Is there really anything that can be done better >>>with the Emacs pinentry than with the loopback pinentry? >>> >>>Footnotes: >>>[1] https://bugs.gnupg.org/gnupg/issue1976 >>> >>>[2] https://bugs.gnupg.org/gnupg/issue2034 >>> >>>[3] http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/epg.el#n607 > > Certainly pinentry-emacs isn't going to be distributed by default, since > there are many more non-emacs users of gpg-agent than there are users of > gpg-agent. I am confused that you quote the above email while it doesn't say anything about the pinentry-emacs subpackage, but is talking about the INSIDE_EMACS hack, which is disabled in Debian. By the way, we have been waiting for your response to the upstream bug for a long time: https://bugs.gnupg.org/gnupg/issue2034 Regards, -- Daiki Ueno
Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote: >> Jens Lechtenboerger <jens.lechtenboer...@fsfe.org> writes: >>> The mml code is based on EasyPG by Daiki Ueno (cc’ed). EasyPG makes >>> use of sub-keys and their IDs for encryption commands, instead of >>> relying on GnuPG’s selections. >> >> It was suggested by Werner to do key selection in Emacs, like GPGME. I >> don't know whether GPGME changed the logic though. > > I don't know what this means -- i don't think that GPGME itself does key > selection. Can you tell me more? My wording might be confusing; let me rephase: I don't think GPGME has a means of using GnuPG's selections, which the applications can rely on. EasyPG is modelled after GPGME, and Gnus is an application using it, thus it is a responsiblity of Gnus to select usable keys by itself. > Presumably users who use emacs with gpg also use gpg with other tools > (possibly even other MUAs), or even gpg on its own. Collecting key > preference data in multiple places while sharing the underlying key > store seems like a recipe for synchronization problems and confusing > behavior, particularly for folks who don't know how the tools fit > together. If there is the means to do that in GPGME now, yes, it would be nice for EasyPG to provide a similar mechanism which can be used from Gnus. Otherwise, IMO, neither EasyPG nor Gnus should try to do the selection by calling gpg directly, even if it could be useful. Regards, -- Daiki Ueno
Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t
Jens Lechtenboerger <jens.lechtenboer...@fsfe.org> writes: >> Modern versions of GnuPG automatically select the key which GnuPG knows >> to have the best validity among all matches for the selector, thanks to >> work put in by Justus Winter (cc'ed), so letting GnuPG make the decision >> would relieve emacs of most of the hard work here, and would also mean >> that any changes that the user makes to their GnuPG keyring would >> automatically take effect in emacs without mml-mode needing to do >> anything. > > The mml code is based on EasyPG by Daiki Ueno (cc’ed). EasyPG makes > use of sub-keys and their IDs for encryption commands, instead of > relying on GnuPG’s selections. It was suggested by Werner to do key selection in Emacs, like GPGME. I don't know whether GPGME changed the logic though. >> Modern versions of GnuPG also provide a "tofu" mechanism to store and >> track that kind of decision in. Neal Walfield (also cc'ed here) put in >> a lot of that implementation, so he might have some suggestions for the >> best way to handle it. I'm afraid I wouldn't do any work toward tofu at this level of quality; in particular, until they reach the consensus whether tofu is only activated when encryption is triggered by an email address. Regards, -- Daiki Ueno
Bug#839991: [pkg-gnupg-maint] Bug#839991: gnupg-agent: 'allow-emacs-pinentry' setting in agent conf makes gpg2 respond no secret key
Werner Koch <w...@gnupg.org> writes:
> Alrthough we could handle this in gpg-agent, I consider it better to fix
> this in Pinentry. The name "allow-emacs-prompt" means to me that Emacs
> support is optional and thus Pinentry should just return OK. A new
> Pinentry version is anyway due.
That makes sense. How about this trivial patch?
Regards,
--
Daiki ueno
>From 7546cf8afd4c28c8b6615f28a4f23060b7853314 Mon Sep 17 00:00:00 2001
From: Daiki Ueno <u...@gnu.org>
Date: Mon, 10 Oct 2016 10:33:36 +0200
Subject: [PATCH] core: Don't report error on setting option
Previously "OPTION allow-emacs-pinentry" returned an error if the Emacs
pinentry is not compiled in. Since it is merely an option, it would
make more sense to just return OK.
Suggested by: Werner Koch <w...@gnupg.org>
Signed-off-by: Daiki Ueno <u...@gnu.org>
---
pinentry/pinentry.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/pinentry/pinentry.c b/pinentry/pinentry.c
index e5cb806..3131b1e 100644
--- a/pinentry/pinentry.c
+++ b/pinentry/pinentry.c
@@ -910,8 +910,6 @@ option_handler (assuan_context_t ctx, const char *key, const char *value)
{
#ifdef INSIDE_EMACS
pinentry_enable_emacs_cmd_handler ();
-#else
- return gpg_error (GPG_ERR_NOT_SUPPORTED);
#endif
}
else if (!strcmp (key, "invisible-char"))
--
2.7.4
Bug#838060: po.m4: warning: AM_PROG_MKDIR_P: this macro is deprecated, and will soon be removed.
Paul Wise <p...@debian.org> writes: > When I use AM_GNU_GETTEXT in my configure.ac, I get these warnings at > autoreconf time. My po.m4 is auto-copied from gettext: > > configure.ac:43: warning: AM_PROG_MKDIR_P: this macro is deprecated, > and will soon be removed. > configure.ac:43: You should use the Autoconf-provided > 'AC_PROG_MKDIR_P' macro instead, > configure.ac:43: and use '$(MKDIR_P)' instead of '$(mkdir_p)'in your > Makefile.am files. > aclocal.m4:746: AM_PROG_MKDIR_P is expanded from... > m4/po.m4:23: AM_PO_SUBDIRS is expanded from... > m4/gettext.m4:57: AM_GNU_GETTEXT is expanded from... > configure.ac:43: the top level This was fixed long ago in upstream as: http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=2cccb4c6 However, gettext distributes old macros for compatibility reasons and they could be pulled if you specify AM_GNU_GETTEXT_VERSION() in your configure.ac. Regards, -- Daiki Ueno
Bug#825936: [Pkg-ime-devel] Bug#825936: ibus-skk: when I use nicola layout, ibus-skk does not work except last character
Yukiharu YABUKI <yyab...@debian.org> writes: > Package: ibus-skk > Version: 1.4.2-1 > Severity: normal > > Dear Maintainer, > > When I use ibus-skk with nicola layout, ibus-skk does not work to convert > kanji.It seems to me that > "Start kanji" mode can accept last > one character. I have checked normal skk layout is ok. > > Please check nicola layout. Thanks for reporting that. It should be fixed with: https://github.com/ueno/libskk/commit/6a232e75de6d5dbe543ab17c9b85dc7560093509 Regards, -- Daiki Ueno
Bug#824642: Doesn't detect glade files for whatever reason
Santiago Vila <sanv...@unex.es> writes: > Hello Wouter. Considering that Debian gettext does not deviate from > upstream a lot (you will see that the number of patches is really > small), this would be most probably an upstream bug. Yes, it's a known regression in upstream. I am now preparing 0.19.8, but for the meantime you can find a patch: http://lists.gnu.org/archive/html/bug-gettext/2016-01/msg9.html http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=21ca680c Regards, -- Daiki Ueno
Bug#809846: [bug-gettext] [h...@realh.co.uk: Bug#809846: gettext: Does not recognise glade]
I realized a minor regression since 0.19.6. With the provided reproducing steps, xgettext is invoked with the '-L Glade' option and it works. However, if the option is not given, xgettext produces the same warnings, as *.glade is not recognized as a GtkBuilder file. I recall that we equally treated *.glade and *.ui files in 0.19.6. I don't know how widely the *.glade file extension is used for GtkBuilder files, but it would be a bit safer to add one line patch to /usr/share/gettext-0.19.7/its/glade.loc: https://git.sv.gnu.org/cgit/gettext.git/commit/?id=21ca680c I might update the Fedora package with this, if there is any FTBFS caused by this change. Thanks, -- Daiki Ueno
Bug#809846: [bug-gettext] [h...@realh.co.uk: Bug#809846: gettext: Does not recognise glade]
Santiago Vila <sanv...@unex.es> writes: > Simple question: Would it make sense to modify the "PACKAGING" file > accordingly? (See attached patch for an example). Thanks, applied the patch with a slight modification. > I don't quite understand why this gettext-VERSION is needed. It is merely needed to distinguish user-supplied *.its files, which shall be installed in /usr/share/gettext/its, from our own. This is analogous to the use of /usr/share/aclocal-VERSION in Automake or /usr/share/vala-VERSION/vapi in Vala. Regards, -- Daiki Ueno
Bug#804141: gettext: please respect SOURCE_DATE_EPOCH wen generating ChangeLog entries
Santiago Vila <sanv...@unex.es> writes: > The gettextize tool should probably not be called automatically, only > by hand. That's why the autopoint program exists. Yes, as it is explicitly noted as an "interactive tool" in the documentation: http://www.gnu.org/software/gettext/manual/html_node/gettextize-Invocation.html#gettextize-Invocation However, there is one thing that gettextize can do, while autopoint can't: modify the infrastructure files such as configure.ac, like autoupdate. Perhaps Avahi's usage of gettextize might be for that. Like Santiago, I can only suggest to confirm with the Avahi developers. If they merely need the functionality of autopoint, then we would just recommend it, rather than adding an ad-hoc solution into gettextize. Thanks, -- Daiki Ueno
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli <invernom...@paranoici.org> writes: >> I don't think it is boring nor error prone -- it just means to >> concatenate two files. > > Well, not really just a file concatenation... More a job for sed or > awk, as I said. But this would be the case, if you automated the task. I actually pushed this to the git master: http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=e4ec2e69 It is only 5 lines and even smaller than a similar example quoted in the Autoconf manual: http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Installation-Directory-Variables.html#Installation-Directory-Variables > Please support these cases as well, at least by adding a > --same-copyright option (without arguments) that produces > a .pot file with > > # Copyright (C) YEAR THE PACKAGE'S COPYRIGHT HOLDER > > replaced by > > # This file is copyrighted by the PACKAGE package's copyright holders > # and by the translators listed below. > > Of course, PACKAGE should be replaced by the argument of the > --package-name option, where available. If I were going to address all such cases, I would rather add a single general-purpose --header-file=FILE option. That would be equivalent to my proposal using sed, and I don't think it worth doing since the sed snippet is fairly simple. Regards, -- Daiki Ueno
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli invernom...@paranoici.org writes: • I post-process the .pot template generated by xgettext and insert the correct copyright notices: this can be done by hand (boring and error prone!) or automatically, for instance, with some sed or awk trick I don't think it is boring nor error prone -- it just means to concatenate two files. As long as you use autotools, it would be automatically done by po/Makefile.in.in installed by autopoint. So, my question was, why it is not sufficient for your use-case? Is there any practical reason you have to call xgettext individually, e.g. your build system doesn't support post-processing for some reason? At this point I am really puzzled. The --copyright-holder option is currently inadequate to make sure the .pot template file has the correct copyright notices in place. The current behavior of --copyright-holder is useful for some use-cases, e.g., FSF-copyrighted packages (like coreutils, gettext), where translations are also attributed to the same copyright holder. In that case, it is natural to leave the responsibility to rewrite YEAR to the translators. Regards, -- Daiki Ueno
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli invernom...@paranoici.org writes: I would definitely prefer to see xgettext changed, rather than having to do sed or awk tricks to post-process its output. So, to me, (4) is the least preferred option. Sorry, I am not convinced. Again, I am reluctant to add a new option to xgettext for a niche feature, without good reason. Do you have any practical reason for that? My reasons for preferring (4) to (3) are: - we could give more control to users, for example, inserting arbitrary text other than copyright notice - we are already using sed in po/Makefile.in.in, as in en@quot rules - having multiple --copyright-foo options doesn't seem to play nicely with the feature supplying COPYRIGHT_HOLDER from autoconf (bug 764483) - that fits better in the Unix philosophy, which suggests to accomplish larger tasks by combining small tools Regards, -- Daiki Ueno
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli invernom...@paranoici.org writes: Besides that, the patch seems to only address point (B) of my original bug report (multiple copyright holders), but not point (A) or point (C) (YEAR and PACKAGE placeholders). Or am I misreading the patch? As (C) is trivial, I've pushed a fix: http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=3a08add5 However, I have not yet decided how to fix (A). A few options I have in mind are: 1. add --copyright-year option 2. extend --copyright-holder option so it can have a full copyright notice, if the argument is in the form Copyright (C) 3. add a new option, say --add-copyright, which takes an argument in the form YEAR COPYRIGHT_HOLDER. 4. don't change xgettext, but modify po/Makefile.in.in to insert copyright comments, using sed I think (1) is not very useful, particularly when multiple copyright holders are supplied, and (2) is a bit heuristic. So, I prefer (3) or (4), as both of them could allow users to specify it through po/Makevars, though (3) is a bit too specific. Suggestions would be appreciated. Regards, -- Daiki Ueno
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli invernom...@paranoici.org writes:
I'd definitely vote for 3, but, wait!, even better, I would add a new
option named --copyright-notices (or maybe there's a better name, I
don't know...), where all the copyright notices may be specified with
their own line breaks, as in:
I'm afraid it would break configurability through po/Makevars, since a
make variable including a multi-line argument cannot be used in a
portable Makefile.
By the way, if we chose (4), the patch would be like the attached, which
reads the file po/HEADER (if exists) and insert the content into POT
file. The file would look like:
# Copyright (C) 2001-2012 Python Software Foundation.
# Copyright (C) 2000 BeOpen.com.
# Copyright (C) 1995-2000 Corporation for National Research Initiatives.
# Copyright (C) 1991-1995 Stichting Mathematisch Centrum.
If this is sufficient, I would revert the multiple --copyright-holder
change, as I am reluctant to add new option to xgettext, which already
has too many options.
Regards,
--
Daiki Ueno
From c8f8099dca7976fa26d7ac671446144f1fe044c9 Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@gnu.org
Date: Tue, 25 Aug 2015 11:47:20 +0900
Subject: [PATCH] po: Insert HEADER file into POT file
* gettext-tools/po/Makefile.in.in ($(DOMAIN).pot-update): Add
insert-header.sed to prerequisites. Insert the contents of the file
HEADER.
(mostlyclean): Remove insert-header.sed.
---
gettext-runtime/po/ChangeLog | 6 ++
gettext-runtime/po/Makefile.in.in | 8 +++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/gettext-runtime/po/ChangeLog b/gettext-runtime/po/ChangeLog
index e5d8f0d..73ccaa2 100644
--- a/gettext-runtime/po/ChangeLog
+++ b/gettext-runtime/po/ChangeLog
@@ -1,3 +1,9 @@
+2015-08-25 Daiki Ueno u...@gnu.org
+
+ * Makefile.in.in ($(DOMAIN).pot-update): Add insert-header.sed to
+ prerequisites. Insert the contents of the file HEADER.
+ (mostlyclean): Remove insert-header.sed.
+
2015-07-10 Daiki Ueno u...@gnu.org
* gettext 0.19.5 released.
diff --git a/gettext-runtime/po/Makefile.in.in b/gettext-runtime/po/Makefile.in.in
index c36f1ad..f4267ab 100644
--- a/gettext-runtime/po/Makefile.in.in
+++ b/gettext-runtime/po/Makefile.in.in
@@ -150,7 +150,7 @@ stamp-po: $(srcdir)/$(DOMAIN).pot
# The determination of whether the package xyz is a GNU one is based on the
# heuristic whether some file in the top level directory mentions GNU xyz.
# If GNU 'find' is available, we avoid grepping through monster files.
-$(DOMAIN).pot-update: $(POTFILES) $(srcdir)/POTFILES.in remove-potcdate.sed
+$(DOMAIN).pot-update: $(POTFILES) $(srcdir)/POTFILES.in remove-potcdate.sed insert-header.sed
package_gnu=$(PACKAGE_GNU); \
test -n $$package_gnu || { \
if { if (LC_ALL=C find --version) 2/dev/null | grep GNU /dev/null; then \
@@ -195,6 +195,11 @@ $(DOMAIN).pot-update: $(POTFILES) $(srcdir)/POTFILES.in remove-potcdate.sed
;; \
esac
test ! -f $(DOMAIN).po || { \
+ if test -f $(srcdir)/HEADER; then \
+ sed -f insert-header.sed $(DOMAIN).po $(DOMAIN).1po \
+ rm -f $(DOMAIN).po \
+ mv $(DOMAIN).1po $(DOMAIN).po; \
+ fi; \
if test -f $(srcdir)/$(DOMAIN).pot; then \
sed -f remove-potcdate.sed $(srcdir)/$(DOMAIN).pot $(DOMAIN).1po \
sed -f remove-potcdate.sed $(DOMAIN).po $(DOMAIN).2po \
@@ -365,6 +370,7 @@ info dvi ps pdf html tags TAGS ctags CTAGS ID:
mostlyclean:
rm -f remove-potcdate.sed
+ rm -f insert-header.sed
rm -f stamp-poT
rm -f core core.* $(DOMAIN).po $(DOMAIN).1po $(DOMAIN).2po *.new.po
rm -fr *.o
--
2.4.3
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Daiki Ueno u...@gnu.org writes: By the way, after looking into the history and the documentation more closely, I realized that my argument on copyright notice was pointless. I'm sorry. I'm now in favor of adding support for multiple copyright holders, like the attached patch, which makes xgettext allow multiple --copyright-holder options. Sorry for the delay. I've landed the patch in upstream: http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=15363cca What else was remaining to close this bug? Regards, -- Daiki Ueno
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli invernom...@paranoici.org writes:
I am frankly having a hard time in seeing why the placeholder PACKAGE
should be replaced in one occurrence, but not in the other.
And in figuring out why the placeholder THE PACKAGE'S COPYRIGHT HOLDER
should be replaced, while the YEAR placeholder should be left untouched
in the *same* copyright notice.
I think it would be nice to fix them so those occurrences be replaced as
well.
By the way, after looking into the history and the documentation more
closely, I realized that my argument on copyright notice was pointless.
I'm sorry. I'm now in favor of adding support for multiple copyright
holders, like the attached patch, which makes xgettext allow multiple
--copyright-holder options.
It is not straightforward to support multiple copyright holders in
po/Makevars, but it might be sufficient to supply it as part of
XGETTEXT_OPTIONS in combination with COPYRIGHT_HOLDER.
Regards,
--
Daiki Ueno
From 7aba166af10a4b64aa07d7f5afc91bdd239beef2 Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@gnu.org
Date: Tue, 21 Jul 2015 13:51:31 +0900
Subject: [PATCH] xgettext: Allow multiple copyright holders
* gettext-tools/src/xgettext.c (default_copyright_holder): New constant,
renamed from copyright_holder.
(copyright_holder): Define as a variable.
(main): Allow multiple --copyright-holder options.
(construct_header): Support multiple --copyright-holder options.
---
gettext-tools/src/ChangeLog | 8 +
gettext-tools/src/xgettext.c | 70
2 files changed, 72 insertions(+), 6 deletions(-)
diff --git a/gettext-tools/src/ChangeLog b/gettext-tools/src/ChangeLog
index 6685505..74dd518 100644
--- a/gettext-tools/src/ChangeLog
+++ b/gettext-tools/src/ChangeLog
@@ -1,3 +1,11 @@
+2015-07-21 Daiki Ueno u...@gnu.org
+
+ * xgettext.c (default_copyright_holder): New constant, renamed
+ from copyright_holder.
+ (copyright_holder): Define as a variable.
+ (main): Allow multiple --copyright-holder options.
+ (construct_header): Support multiple --copyright-holder options.
+
2015-07-10 Daiki Ueno u...@gnu.org
* gettext 0.19.5 released.
diff --git a/gettext-tools/src/xgettext.c b/gettext-tools/src/xgettext.c
index 9f5d300..8e303c7 100644
--- a/gettext-tools/src/xgettext.c
+++ b/gettext-tools/src/xgettext.c
@@ -124,7 +124,8 @@ message_list_ty *exclude;
static int force_po;
/* Copyright holder of the output file and the translations. */
-static const char *copyright_holder = THE PACKAGE'S COPYRIGHT HOLDER;
+static const char *default_copyright_holder = THE PACKAGE'S COPYRIGHT HOLDER;
+static char *copyright_holder = NULL;
/* Package name. */
static const char *package_name = NULL;
@@ -540,11 +541,19 @@ main (int argc, char *argv[])
break;
case CHAR_MAX + 1:/* --copyright-holder */
-copyright_holder = optarg;
+if (copyright_holder == NULL)
+ copyright_holder = xstrdup (optarg);
+else
+ {
+size_t total_len = strlen (copyright_holder) + 2 + strlen (optarg);
+copyright_holder = xrealloc (copyright_holder, total_len);
+strcat (copyright_holder, \n);
+strcat (copyright_holder, optarg);
+ }
break;
case CHAR_MAX + 2:/* --foreign-user */
-copyright_holder = ;
+copyright_holder = xstrdup ();
break;
case CHAR_MAX + 3:/* --from-code */
@@ -3559,13 +3568,61 @@ Content-Transfer-Encoding: 8bit\n,
mp = message_alloc (NULL, , NULL, msgstr, strlen (msgstr) + 1, pos);
+ if (copyright_holder == NULL)
+copyright_holder = xstrdup (default_copyright_holder);
+
if (copyright_holder[0] != '\0')
-comment = xasprintf (\
+{
+ size_t copyright_comment_len;
+ char *copyright_comment;
+ const char *p;
+ char *q;
+ size_t count = 1;
+
+ p = copyright_holder;
+ while (*p != '\0')
+{
+ p = strchr (p, '\n');
+ if (p == NULL)
+break;
+ count++;
+ p++;
+}
+
+ copyright_comment_len =
+strlen (copyright_holder) + strlen (Copyright (C) YEAR \n) * count;
+ copyright_comment = XNMALLOC (copyright_comment_len, char);
+
+ p = copyright_holder;
+ q = copyright_comment;
+ while (*p != '\0')
+{
+ char *newline = strchr (p, '\n');
+
+ q = stpcpy (q, Copyright (C) YEAR );
+ if (newline != NULL)
+{
+ *newline = '\0';
+ q = stpcpy (q, p);
+ q = stpcpy (q, \n);
+ p = newline + 1;
+}
+ else
+{
+ q = stpcpy (q, p);
+ q = stpcpy (q, \n);
+ break;
+}
+}
+
+ comment = xasprintf (\
SOME DESCRIPTIVE TITLE.\n\
-Copyright (C) YEAR %s\n\
+%s\
This file is distributed under the same license as the PACKAGE package.\n\
FIRST AUTHOR EMAIL@ADDRESS
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli invernom...@paranoici.org writes: dist-hook: echo # Copyright (C) ... $(distdir)/po/hello.pot This would place the copyright notice at the end of the .pot file, wouldn't it? This is not necessarily what one would want to do. I just gave you an example how it could be done. It is easy to rewrite it to put the copyright notice at the top, by using a temporary file. What I really fail to understand is: if some placeholders are replaced by xgettext --copyright-holder=Python Software Foundation \ --package-name=myapplication --package-version=0.1 \ --language=python myapplication.py -o myapplication2.pot why other placeholders are not touched at all?!? First of all, I would repeat that xgettext prepares a template for translators, not a real content. If you want to put the real content there, you can easily adjust it by using an Automake hook. With the above example, the replaced placeholders (i.e., COPYRIGHT HOLDER, PACKAGE, VERSION) are common for all translations derived from the package source code. On the other hand, xgettext intentionally doesn't provide a way to touch some placeholders (YEAR, FULL NAME, LANGUAGE, etc), because it shall be replaced by translators. If you run: msginit -i myapplication2.pot -o ja.po then you will get ja.po with those placeholders properly replaced for translation. I think this is reasonable. If you are still not satisfied with the answer, I'm afraid I doubt I could convince you of that. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#682580: [bug-gettext] Bug#682580: xgettext: fails to properly replace some placeholders in output .pot (PACKAGE, YEAR, C. HOLDER) (fwd)
Francesco Poli invernom...@paranoici.org writes: On Tue, 14 Jul 2015 10:48:20 +0900 Daiki Ueno wrote: I noticed that xgettext does not properly replace all the relevant placeholders in the output .pot file, when told to do so through command-line options. I doubt if it is meaningful to have a real copyright notice in an auto-generated template file. Well, the auto-generated .pot file is auto-generated by extracting many strings from a number of copyrighted source code files. I think that, in most cases, this implies that the .pot file is copyrighted and has the same copyright owners and copyright years as the source files. As a consequence, I think it makes definitely sense for it to carry real copyright notices (the same that cover the source files, in most cases). Yes. However, xgettext is not intended for generating a real header entry, but for generating a template of a header entry. If one really wants to carry a real copyright notice in a POT file, she could easily do that from without xgettext, e.g., in the toplevel Makefile.am: dist-hook: echo # Copyright (C) ... $(distdir)/po/hello.pot Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772088: [bug-gettext] Bug#772088: gettext: msgunfmt segfaults (system-dependent messages) (fwd)
Santiago Vila sanv...@unex.es writes: Package: gettext Version: 0.19.3-2 The attached MO files (crash-*.mo) make msgunfmt segfault. This bug was found using American fuzzy lop[0], which was seeded with a MO file containing system-dependent messages (original.mo). [0] http://lcamtuf.coredump.cx/afl/ Thanks. I should have checked at all other places when fixing: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769901 Pushed a fix: http://git.sv.gnu.org/cgit/gettext.git/commit/?id=7c8a70bc and modified the msgunfmt-3 test to use your test data: http://git.sv.gnu.org/cgit/gettext.git/commit/?id=dada61cc Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769901: gettext: msgunfmt segfault
Jakub Wilk jw...@debian.org writes:
The attached (slightly corrupted) MO file crashes msgunfmt:
$ msgunfmt messages.mo
Segmentation fault
Thanks for the report. It seems like a long standing issue (I can
reproduce it even with 0.17).
I suspect there's a integer overflow somewhere.
Yes. I'm attaching a patch and a test-case.
Regards,
--
Daiki Ueno
From 2a760b57161a2b4769e0b1c74db243b213733ef3 Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@gnu.org
Date: Tue, 18 Nov 2014 12:11:22 +0900
Subject: [PATCH 1/2] read-mo: Check size_t overflow
* read-mo.c: Include xsize.h.
(get_string): Use xsum3 to avoid overflow, when checking length
and offset fields.
Reported by Jakub Wilk at:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769901.
---
gettext-tools/src/ChangeLog | 8
gettext-tools/src/read-mo.c | 4 +++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/gettext-tools/src/ChangeLog b/gettext-tools/src/ChangeLog
index d392ba7..e250ae1 100644
--- a/gettext-tools/src/ChangeLog
+++ b/gettext-tools/src/ChangeLog
@@ -1,3 +1,11 @@
+2014-11-18 Daiki Ueno u...@gnu.org
+
+ * read-mo.c: Include xsize.h.
+ (get_string): Use xsum3 to avoid overflow, when checking length
+ and offset fields.
+ Reported by Jakub Wilk at:
+ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=769901.
+
2014-10-28 Daiki Ueno u...@gnu.org
xgettext: Allow plural extraction from a single argument function
diff --git a/gettext-tools/src/read-mo.c b/gettext-tools/src/read-mo.c
index 9e0220c..c867236 100644
--- a/gettext-tools/src/read-mo.c
+++ b/gettext-tools/src/read-mo.c
@@ -38,6 +38,7 @@
#include message.h
#include format.h
#include gettext.h
+#include xsize.h
#define _(str) gettext (str)
@@ -121,8 +122,9 @@ get_string (const struct binary_mo_file *bfp, size_t offset, size_t *lengthp)
/* See 'struct string_desc'. */
nls_uint32 s_length = get_uint32 (bfp, offset);
nls_uint32 s_offset = get_uint32 (bfp, offset + 4);
+ size_t s_end = xsum3 (s_offset, s_length, 1);
- if (s_offset + s_length + 1 bfp-size)
+ if (size_overflow_p (s_end) || s_end bfp-size)
error (EXIT_FAILURE, 0, _(file \%s\ is truncated), bfp-filename);
if (bfp-data[s_offset + s_length] != '\0')
error (EXIT_FAILURE, 0,
--
2.1.0
From 7674ef72f25b2ff2d7ebfc271a14b0e6e9598473 Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@gnu.org
Date: Tue, 18 Nov 2014 12:29:32 +0900
Subject: [PATCH 2/2] tests: Add test for integer overflow when reading MO file
* msgunfmt-3: New file.
* Makefile.am (TESTS): Add new test.
(EXTRA_DIST): Add data file for msgunfmt-3.
---
gettext-tools/tests/ChangeLog | 7 +++
gettext-tools/tests/Makefile.am | 4 ++--
gettext-tools/tests/msgunfmt-3 | 9 +
gettext-tools/tests/overflow.mo | Bin 0 - 48 bytes
4 files changed, 18 insertions(+), 2 deletions(-)
create mode 100755 gettext-tools/tests/msgunfmt-3
create mode 100644 gettext-tools/tests/overflow.mo
diff --git a/gettext-tools/tests/ChangeLog b/gettext-tools/tests/ChangeLog
index d6d6788..cde4819 100644
--- a/gettext-tools/tests/ChangeLog
+++ b/gettext-tools/tests/ChangeLog
@@ -1,3 +1,10 @@
+2014-11-18 Daiki Ueno u...@gnu.org
+
+ tests: Add test for integer overflow when reading MO file
+ * msgunfmt-3: New file.
+ * Makefile.am (TESTS): Add new test.
+ (EXTRA_DIST): Add data file for msgunfmt-3.
+
2014-10-28 Daiki Ueno u...@gnu.org
xgettext: Allow plural extraction from a single argument function
diff --git a/gettext-tools/tests/Makefile.am b/gettext-tools/tests/Makefile.am
index 3df6e1f..910dde0 100644
--- a/gettext-tools/tests/Makefile.am
+++ b/gettext-tools/tests/Makefile.am
@@ -63,7 +63,7 @@ TESTS = gettext-1 gettext-2 gettext-3 gettext-4 gettext-5 gettext-6 gettext-7 \
msgmerge-properties-1 msgmerge-properties-2 \
msgmerge-update-1 msgmerge-update-2 msgmerge-update-3 \
msgmerge-update-4 \
- msgunfmt-1 msgunfmt-2 \
+ msgunfmt-1 msgunfmt-2 msgunfmt-3 \
msgunfmt-csharp-1 \
msgunfmt-java-1 \
msgunfmt-properties-1 \
@@ -145,7 +145,7 @@ TESTS = gettext-1 gettext-2 gettext-3 gettext-4 gettext-5 gettext-6 gettext-7 \
autopoint-1 autopoint-2 autopoint-3
EXTRA_DIST += init.sh init.cfg $(TESTS) \
- test.mo xg-c-1.ok.po mex-test2.ok \
+ test.mo overflow.mo xg-c-1.ok.po mex-test2.ok \
mm-ko.ascii.pot mm-ko.euc-kr.po mm-ko-comp.euc-kr.po \
mm-viet.comp.po mm-viet.pot mm-viet.out \
msguniq-a.in msguniq-a.inp msguniq-a.out \
diff --git a/gettext-tools/tests/msgunfmt-3 b/gettext-tools/tests/msgunfmt-3
new file mode 100755
index 000..a1b98d7
--- /dev/null
+++ b/gettext-tools/tests/msgunfmt-3
@@ -0,0 +1,9 @@
+#! /bin/sh
+. ${srcdir=.}/init.sh; path_prepend_ . ../src
+
+# Test invalid or incomplete input
+
+: ${MSGUNFMT=msgunfmt}
+LANGUAGE= LC_ALL=C ${MSGUNFMT} ../overflow.mo 2mu-3.err /dev/null
+test $? != 0 || exit 1
+grep ' is truncated' mu-3.err /dev/null || exit 1
diff --git a/gettext-tools/tests/overflow.mo b/gettext-tools/tests/overflow.mo
new file mode 100644
index
Bug#760856: [Pkg-ime-devel] Bug#760856: libskk: New upstream version and watch file update
Osamu Aoki os...@debian.org writes: Source: libskk Version: 1.0.0-1 Severity: normal Daiki, are you going to update Debian package? Or should I? Sorry, I'm afraid I will not be able to devote much time for Debian packaging. I'm also not sure if I still have the right to upload a package after the DMUA change. The watch file needs to be updated for its new web site: I've just released libskk 1.0.2 and ibus-skk 1.4.2. After this, tarballs should be available from the github releases page: https://github.com/ueno/libskk/releases/tag/1.0.2 https://github.com/ueno/ibus-skk/releases/tag/ibus-skk-1.4.2 Thanks, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754146: [bug-gettext] Bug#754146: gettext: fix FTBFS on ppc64el with autoreconf or libtool patch (provided) (fwd)
Mauricio Faria de Oliveira mauri...@linux.vnet.ibm.com writes: Just clarifying for a broader audience: Thanks for the clarification. On Debian, using autoreconf required a change to one upstream file [1] because the libtool macros are shipped with 'link_all_libdeps=no'. Therefore that patch [2] just added in *_LDADD the missing libdep listed in *_DEPENDENCIES (libgettextlib.la), plus libunistring in one case. It's reasonable for upstream not to consider it, since it is required due to a change downstream. So: Would be possible to release a gettext version using latest libtool so that I do not need to add any special hack in the Debian package? (Or maybe this is not even fixed in libtool yet?) This was fixed in libtool (as of [3]), and incorporated in v2.4.2.418. So, yes, probably we should skip the Makefile.am changes (in upstream). For the patch to libtool.m4, I'd also like to wait until a new libtool stable release, but if it takes long time and the change is trivial enough, I think it could be backported (like [1]). Footnotes: [1] http://git.savannah.gnu.org/cgit/gettext.git/commit/?id=73acab39 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742214: [Pkg-ime-devel] Bug#742214: libskk: fails to build with clang instead of gcc
Nicolas Sévelin-Radiguet nic...@free.fr writes: Source: libskk Version: 1.0.0-1 Severity: minor Tags: patch User: pkg-llvm-t...@lists.alioth.debian.org Usertags: clang-ftbfs Dear Maintainer, Your package fails to build with clang instead of gcc. [-Wreturn-type] The attached patch fixes it. Buildlogs and patch are here: https://github.com/nonas/debian-clang/tree/master/buildlogs/libskk Thanks. In upstream, we fixed it two years ago in 1.0.1, and thought I packaged it...seems not. Here is the relevant change: https://github.com/ueno/libskk/commit/83b62271854c245ae509115bf195fb9261c895cd Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714625: gedit: Crash gettext syntax highlight + Input Japanese characters
Sorry, this is a regression caused by my commit: https://git.gnome.org/browse/gtk+/commit/?id=7a9553cfb5d465df79161f61f7c01d872e90b983 Posted a fix: https://bugzilla.gnome.org/show_bug.cgi?id=703533 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686612: [Pkg-ime-devel] Bug#686612: Bug#686612: ibus-m17n: AltGr and Shift-non-ascii do not work
Tore Ferner tor...@pvv.org writes: In wheezy: Turning off Use system keyboard layout gives me an American keyboard - except that all default Norwegian AltGr-characters still works, both shifted and unshifted. Seems AltGr just bypasses ibus. It is more likely ibus rather than ibus-m17n which causes the difference. Which target application are you testing on? Perhaps the key snooper change might affect the behavior: https://github.com/ibus/ibus/commit/9ae13a3d This also suggests that AltGr should work, at least upstream, see bug BZ#652201: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/6.1_Technical_Notes/ibus-m17n.html I'm the one who worked on the bug. As far as I remember, RHEL6 ibus-m17n simply assumes that AltGr is mapped to Mod5. So, the assumption might not be true on Norwegian keyboard. Unfortunately there is no reliable mechanism to map such a virtual modifier to physical modifer in IBus and the upstream does not want IME to depend on X11. I'll consider again if this would be really useful. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686612: [Pkg-ime-devel] Bug#686612: ibus-m17n: AltGr and Shift-non-ascii do not work
Hi, Tore Ferner tor...@pvv.org writes: On a latin type2 qwerty keyboard (Norwegian): After selecting hi-phonetic in ibus, in Gnome-shell, expected characters according to /usr/share/m17n/hi-phonetic.mim are not produced for symbols accessed with AltGr. Most of mim maps designed to work under us keymap, so I guess it is not supposed to run under a Norwegian layout natively. But, It used to work in Squeeze. it looks a bit strange that it worked in Squeeze. Perhaps you could check Use system keyboard layout checkbox in ibus-setup? If it is not checked, IBus should use us keymap internally. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#685745: [Pkg-ime-devel] Bug#685745: ibus-skk: doesn't create user dictionary if not exists
KISE Hiroshi k...@fuyuneko.jp writes: ibus-skk use ~/.config/ibus-skk/user.dict as user dictionary, but it doesn't create user dictionary if not exists. Please create user dictionary if it dose not exists. Thanks, fixed in upstream: https://github.com/ueno/libskk/commit/3f84867d Will update the package soon. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675657: [Pkg-ime-devel] Bug#675657: Bug#675657: libskk: Please switch to vala 0.16
Osamu Aoki os...@debian.org writes: Daiki-san, are you busy now? I will do 1 day delayed team upload since this is IME Packaging Team pkg-ime-de...@lists.alioth.debian.org maintained. Although we are expecting freeze very soon, with some serious bugs in dpkg, I do not see it happen very quickly. Sorry, missed the previous mails. Thanks for taking care of this. BTW, I'm still unsure if ibus-skk rebuild is necessary, since the resulting libskk library interface should be the same as before. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674471: FTBFS: (armel, sparc) error when testing
tags 674471 + patch
thanks
Osamu Aoki os...@debian.org writes:
This package does not build on armel which is release architecture
(and sparc).
https://buildd.debian.org/status/fetch.php?pkg=libskkarch=armelver=0.0.12-1stamp=1333795311
**
ERROR:cdb-dict.c:23:cdb_dict: assertion failed (len == 2): (0 == 2)
/bin/bash: line 5: 27443 Aborted G_DEBUG=gc-friendly
G_SLICE=,always-malloc LIBSKK_DATA_PATH=.. /bin/bash ../libtool
--mode=execute ${dir}$tst
/libskk/cdb-dict: FAIL: cdb-dict
...
==
1 of 8 tests failed
Thanks. It seems to be an ARM alignment issue (patch attached). I'll
upload a new package soon.
From fbbea6190782da447caddc903cbc31a0d8676f38 Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@unixuser.org
Date: Fri, 25 May 2012 11:19:43 +0900
Subject: [PATCH] cdb: make sure that integer does not stride across 4-byte
alignments
Fixes Debian bug#674471.
---
libskk/cdb-dict.vala |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libskk/cdb-dict.vala b/libskk/cdb-dict.vala
index a5a49fa..db2c99b 100644
--- a/libskk/cdb-dict.vala
+++ b/libskk/cdb-dict.vala
@@ -51,7 +51,10 @@ namespace Skk {
}
static uint32 read_uint32 (uint8 *p) {
-return uint32.from_little_endian (*((uint32 *) p));
+// Make sure that Q does not stride across 4-byte
+// alignment on ARM (Debian bug#674471).
+uint8 q[4] = (uint8[]) p;
+return uint32.from_little_endian (*((uint32 *) q));
}
/**
--
1.7.10.1
Regards,
--
Daiki Ueno
Bug#661212: [Pkg-ime-devel] Bug#661212: Bug#661212: Bug#661212: ibus-m17n: Thai IM: last cluster lost when switching IM
Theppitak Karoonboonyanan t...@linux.thai.net writes:
I've tried applying the patch to 1.3.3-1 without the configuration parts.
(See the attached patch.) It works quite well for me when switching IMs.
However, the problem is it double-commits the preedit text when
focused out.
For example, when I type ที่ and then immediately switch to another
window, the preedit ที่ is committed twice and becomes ที่ที่.
Thanks for testing. Yes, I encountered the same problem, but it doesn't
happen always. I guess this is a timing problem between when ibus
handles focus-out and when m17n-lib handles focus-out. I'm attaching a
patch based on yours.
--- a/src/engine.c
+++ b/src/engine.c
@@ -34,6 +34,7 @@
guint preedit_background;
gint preedit_underline;
gint lookup_table_orientation;
+gint focus_out_behavior;
MInputMethod *im;
};
@@ -256,6 +257,7 @@
klass-preedit_background = INVALID_COLOR;
klass-preedit_underline = IBUS_ATTR_UNDERLINE_NONE;
klass-lookup_table_orientation = IBUS_ORIENTATION_SYSTEM;
+klass-focus_out_behavior = IBUS_ENGINE_PREEDIT_COMMIT;
engine_config = ibus_m17n_get_engine_config (engine_name);
g_free (engine_name);
@@ -492,10 +494,11 @@
klass-preedit_background, 0, -1);
ibus_text_append_attribute (text, IBUS_ATTR_TYPE_UNDERLINE,
klass-preedit_underline, 0, -1);
-ibus_engine_update_preedit_text ((IBusEngine *) m17n,
- text,
- m17n-context-cursor_pos,
- mtext_len (m17n-context-preedit) 0);
+ibus_engine_update_preedit_text_with_mode ((IBusEngine *) m17n,
+ text,
+ m17n-context-cursor_pos,
+ mtext_len (m17n-context-preedit) 0,
+ klass-focus_out_behavior);
}
}
@@ -676,7 +679,7 @@
{
IBusM17NEngine *m17n = (IBusM17NEngine *) engine;
-ibus_m17n_engine_process_key (m17n, Minput_focus_out);
+minput_reset_ic (m17n-context);
parent_class-focus_out (engine);
}
Regards,
--
Daiki Ueno
Bug#661618: [Pkg-ime-devel] Bug#661618: Bug#661618: FTBFS
Osamu Aoki os...@debian.org writes:
diff --git a/src/IBusChewingEngine.gob b/src/IBusChewingEngine.gob
index 69b13f9..da2c854 100644
--- a/src/IBusChewingEngine.gob
+++ b/src/IBusChewingEngine.gob
@@ -1041,13 +1041,13 @@ class IBus:Chewing:Engine from IBus:Engine{
/* Toggle Full - Half */
chewing_set_ShapeMode(self-context,
!chewing_get_ShapeMode(self-context));
}else if (strcmp(prop_name,chewing_settings_prop)==0){
-if (self-settings_prop-state==PROP_STATE_UNCHECKED){
+if
(ibus_property_get_state(self-settings_prop)==PROP_STATE_UNCHECKED){
gtk_widget_show_all(self-setting_dialog);
The above line did not exist in the current source. Thus this patch did
not apply cleanly. I kept this line by adding it as patch. (Just to be
safe side.) If this above line can be dropped, let me know.
Ah, sorry. The patch previously attached was based on the git master
since I didn't expected any change in the hunk. I'm attaching a patch
generated by quilt from the deb package.
BTW, just in case, I have notified this to the upstream on Friday.
Follow IBusProperty ABI change.
--- a/src/IBusChewingEngine-input-events.c
+++ b/src/IBusChewingEngine-input-events.c
@@ -291,12 +291,12 @@
/* Toggle Full - Half */
chewing_set_ShapeMode(self-context, !chewing_get_ShapeMode(self-context));
}else if (strcmp(prop_name,chewing_settings_prop)==0){
- if (self-settings_prop-state==PROP_STATE_UNCHECKED){
+ if (ibus_property_get_state(self-settings_prop)==PROP_STATE_UNCHECKED){
if (gtk_dialog_run(GTK_DIALOG(self-setting_dialog))==GTK_RESPONSE_OK){
self_save_config_all(self);
}
gtk_widget_hide(self-setting_dialog);
- self-settings_prop-state=PROP_STATE_UNCHECKED;
+ ibus_property_set_state(self-settings_prop, PROP_STATE_UNCHECKED);
}
}else{
G_DEBUG_MSG(3,[I3] property_activate(-, %s, %u) not recognized,prop_name, prop_state);
--- a/src/IBusChewingEngine.gob
+++ b/src/IBusChewingEngine.gob
@@ -1041,12 +1041,12 @@
/* Toggle Full - Half */
chewing_set_ShapeMode(self-context, !chewing_get_ShapeMode(self-context));
}else if (strcmp(prop_name,chewing_settings_prop)==0){
- if (self-settings_prop-state==PROP_STATE_UNCHECKED){
+ if (ibus_property_get_state(self-settings_prop)==PROP_STATE_UNCHECKED){
if (gtk_dialog_run(GTK_DIALOG(self-setting_dialog))==GTK_RESPONSE_OK){
self_save_config_all(self);
}
gtk_widget_hide(self-setting_dialog);
- self-settings_prop-state=PROP_STATE_UNCHECKED;
+ ibus_property_set_state(self-settings_prop, PROP_STATE_UNCHECKED);
}
}else{
G_DEBUG_MSG(3,[I3] property_activate(-, %s, %u) not recognized,prop_name, prop_state);
Regards,
--
Daiki Ueno
Bug#661618: [Pkg-ime-devel] Bug#661618: FTBFS
tags 661618 + patch
thanks
Moritz Muehlenhoff muehlenh...@univention.de writes:
/home/jmm/3/ibus-chewing-1.3.10+clean/src/IBusChewingEngine-input-events.c:294:25:
error: 'IBusProperty' has no member named 'state'
It seems that the field was removed by the commit:
https://github.com/ibus/ibus/commit/ee9c4fba
From 7031399a1af50ad4ed5e970b02a0803f64e4b46a Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@unixuser.org
Date: Fri, 2 Mar 2012 12:45:38 +0900
Subject: [PATCH] Don't access removed fields in IBusProperty.
See https://github.com/ibus/ibus/commit/ee9c4fba.
Use ibus_property_{get,set}_state().
---
src/IBusChewingEngine-input-events.c |4 ++--
src/IBusChewingEngine.gob|4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/src/IBusChewingEngine-input-events.c b/src/IBusChewingEngine-input-events.c
index 84a1d6f..90241d9 100644
--- a/src/IBusChewingEngine-input-events.c
+++ b/src/IBusChewingEngine-input-events.c
@@ -291,12 +291,12 @@ void ibus_chewing_engine_property_activate(IBusEngine *engine, const gchar *pro
/* Toggle Full - Half */
chewing_set_ShapeMode(self-context, !chewing_get_ShapeMode(self-context));
}else if (strcmp(prop_name,chewing_settings_prop)==0){
- if (self-settings_prop-state==PROP_STATE_UNCHECKED){
+ if (ibus_property_get_state(self-settings_prop)==PROP_STATE_UNCHECKED){
if (gtk_dialog_run(GTK_DIALOG(self-setting_dialog))==GTK_RESPONSE_OK){
self_save_config_all(self);
}
gtk_widget_hide(self-setting_dialog);
- self-settings_prop-state=PROP_STATE_UNCHECKED;
+ ibus_property_set_state(self-settings_prop, PROP_STATE_UNCHECKED);
}
}else{
G_DEBUG_MSG(3,[I3] property_activate(-, %s, %u) not recognized,prop_name, prop_state);
diff --git a/src/IBusChewingEngine.gob b/src/IBusChewingEngine.gob
index 69b13f9..da2c854 100644
--- a/src/IBusChewingEngine.gob
+++ b/src/IBusChewingEngine.gob
@@ -1041,13 +1041,13 @@ class IBus:Chewing:Engine from IBus:Engine{
/* Toggle Full - Half */
chewing_set_ShapeMode(self-context, !chewing_get_ShapeMode(self-context));
}else if (strcmp(prop_name,chewing_settings_prop)==0){
- if (self-settings_prop-state==PROP_STATE_UNCHECKED){
+ if (ibus_property_get_state(self-settings_prop)==PROP_STATE_UNCHECKED){
gtk_widget_show_all(self-setting_dialog);
if (gtk_dialog_run(GTK_DIALOG(self-setting_dialog))==GTK_RESPONSE_OK){
self_save_config_all(self);
}
gtk_widget_hide(self-setting_dialog);
- self-settings_prop-state=PROP_STATE_UNCHECKED;
+ ibus_property_set_state(self-settings_prop, PROP_STATE_UNCHECKED);
}
}else{
G_DEBUG_MSG(3,[I3] property_activate(-, %s, %u) not recognized,prop_name, prop_state);
--
1.7.7.6
Regards,
--
Daiki Ueno
Bug#661212: [Pkg-ime-devel] Bug#661212: Bug#661212: Bug#661212: ibus-m17n: Thai IM: last cluster lost when switching IM
tags 661212 + patch thanks Theppitak Karoonboonyanan t...@linux.thai.net writes: retitle 661212 ibus-m17n: uncommitted preedit text lost when switching IM thanks OK, proposed patch: https://github.com/ueno/ibus-m17n/commit/63d1e981 Though there I have added a config option for the focus out behavior, perhaps it might be sufficient for most ibus-m17n IMEs to always commit preedit text. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658575: ITP: libfep -- library to implement FEP (front end processor) on ANSI terminals
Package: wnpp Owner: Daiki Ueno u...@unixuser.org Severity: wishlist * Package name: libfep Version : 0.0.2 Upstream Author : Daiki Ueno u...@unixuser.org * URL or Web page : http://github.com/ueno/libfep * License : GPL-3+ and BSD-3-Clause Description : library to implement FEP (front end processor) on ANSI terminals libfep is a library to help implement input method FEP (front end processor) on ANSI compliant terminals. This package contains a programmable FEP server and a library to access the server. This package will be used by the next release of libskk package: http://blog.du-a.org/?p=957 apt source for a test package: http://du-a.org/packages/libfep/debian/ dget http://du-a.org/packages/libfep/debian/libfep_0.0.2-1.dsc -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654944: RFA: riece -- an IRC client for Emacs
retitle 654944 ITA: riece -- an IRC client for Emacs owner 654944 ! thanks Hi, I know there are still some people using this package and maybe I could take this since I'm the upstream :) Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650067: [Pkg-ime-devel] Bug#650067: Bug #650067: ibus-m17n: Thai IMs lack fallback when application doesn't support surrounding text
reassign 650067 ibus thanks BTW, this bug was fixed in ibus not ibus-m17n in upstream. Since ibus 1.4.1 with that fix will be released shortly, we could close this with new ibus package. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#658575: [Pkg-ime-devel] Bug#658575: ITP: libfep -- library to implement FEP (front end processor) on ANSI terminals
Osamu Aoki os...@debian.org writes: On Sat, Feb 04, 2012 at 06:52:40PM +0900, Daiki Ueno wrote: * Package name: libfep Is this just libskk specific? Or can this be for all ibus programs? Just curious. Currently, it is only used by libskk. But I plan to develop ibus-fep using it very soon. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657828: ibus: FTBFS
Osamu Aoki os...@debian.org writes: Daiki, you pointed me to: http://git.savannah.gnu.org/cgit/automake.git/commit/?id=4e4dae50 I also found related follow-up http://lists.gnu.org/archive/html/automake/2012-01/msg4.html I guess this is the cause of this new FTBFS phenomema. But I still do not understand * where is the bug? * what it takes to fix this error? Googling lead me to a similar bug report elsewhere. Basically it changes above mentioned part with == ldmlibexecdir = $(libexecdir)/@PACKAGE@ ldmlibexec_SCRIPTS = \ ibus-ui-gtk \ $(NULL) == It can eliminate autoreconf error but I am not sure this is what is needed. Ah, I didn't hit on that idea. IMO it is a reasonable workaround until the new automake is packaged. How about modifying the relevant part in debian/patches/use_pkglibexec.patch as follows? == # pkglibexec_SCRIPTS is not a valid prefix/primary combination with # older automake ibuslibexecdir = $(pkglibexecdir) ibuslibexec_SCRIPTS = \ ibus-ui-gtk \ $(NULL) == Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#657436: ibus: please add gobject-introspection support
Package: ibus
Version: 1.4.0-3
Severity: wishlist
Tags: patch
Dear Maintainer,
It seems that the ibus upstream is planning to replace its Python
binding with gobject-introspection:
https://code.google.com/p/ibus/issues/detail?id=1381
https://code.google.com/p/ibus/issues/detail?id=1384
However, the Debian ibus package does not provide introspection data.
I'm attaching a patch, which I tested locally with python:
$ python
from gi.repository import IBus
From c39c403e249df099a2ccf31ea5e3069694b127c7 Mon Sep 17 00:00:00 2001
From: Daiki Ueno u...@unixuser.org
Date: Thu, 26 Jan 2012 17:41:58 +0900
Subject: [PATCH] Add gobject-introspection support.
---
debian/control | 19 +--
debian/gir1.2-ibus-1.0.install |1 +
debian/libibus-1.0-dev.install |1 +
3 files changed, 19 insertions(+), 2 deletions(-)
create mode 100644 debian/gir1.2-ibus-1.0.install
diff --git a/debian/control b/debian/control
index 67ed88c..ef144a1 100644
--- a/debian/control
+++ b/debian/control
@@ -21,7 +21,9 @@ Build-Depends: debhelper (= 8.1.3~),
python-gobject-dev,
libgconf2-dev,
python-dbus (= 0.83.0),
- intltool (= 0.40.0)
+ intltool (= 0.40.0),
+ gobject-introspection,
+ libgirepository1.0-dev
Standards-Version: 3.9.2
Homepage: http://code.google.com/p/ibus/
Vcs-Git: git://git.debian.org/pkg-ime/ibus.git
@@ -62,7 +64,7 @@ Package: libibus-1.0-dev
Section: libdevel
Architecture: any
Multi-Arch: same
-Depends: libibus-1.0-0 (= ${binary:Version}), libglib2.0-dev, libdbus-1-dev, ${shlibs:Depends}, ${misc:Depends}
+Depends: libibus-1.0-0 (= ${binary:Version}), libglib2.0-dev, libdbus-1-dev, ${shlibs:Depends}, ${misc:Depends}, gir1.2-ibus-1.0 (= ${binary:Version})
Replaces: libibus-dev
Description: Intelligent Input Bus - development file
IBus is an Intelligent Input Bus. It is a new input framework for the Linux
@@ -115,3 +117,16 @@ Description: Intelligent Input Bus - development documentation
It also may help developers to develop input method easily.
.
This package contains the reference manual.
+
+Package: gir1.2-ibus-1.0
+Section: introspection
+Architecture: any
+Depends: ${shlibs:Depends}, ${gir:Depends}, ${misc:Depends}
+Description: Intelligent Input Bus - introspection data
+ IBus is an Intelligent Input Bus. It is a new input framework for the Linux
+ OS. It provides full featured and user friendly input method user interface.
+ It also may help developers to develop input method easily.
+ .
+ This package contains the GObject introspection data which are needed
+ for developing the IBus applications in various programming languages
+ with GObject introspection support.
diff --git a/debian/gir1.2-ibus-1.0.install b/debian/gir1.2-ibus-1.0.install
new file mode 100644
index 000..f8f1abe
--- /dev/null
+++ b/debian/gir1.2-ibus-1.0.install
@@ -0,0 +1 @@
+usr/lib/*/girepository-1.0/IBus-1.0.typelib usr/lib/girepository-1.0
diff --git a/debian/libibus-1.0-dev.install b/debian/libibus-1.0-dev.install
index 481baf2..a5258d1 100644
--- a/debian/libibus-1.0-dev.install
+++ b/debian/libibus-1.0-dev.install
@@ -3,3 +3,4 @@ debian/tmp/usr/lib/*/libibus-1.0.so
debian/tmp/usr/lib/*/libibus-1.0.a
debian/tmp/usr/lib/*/pkgconfig/*
debian/tmp/usr/share/vala/*
+debian/tmp/usr/share/gir-1.0/IBus-1.0.gir
--
1.7.8.3
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-rc7-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages ibus depends on:
ii gconf2 3.2.3-1
ii libc62.13-24
ii libgconf2-4 3.2.3-1
ii libglib2.0-0 2.30.2-6
ii libgtk2.0-0 2.24.8-3
ii libibus-1.0-01.4.0-3
ii librsvg2-common 2.34.2-2
ii libx11-6 2:1.4.4-4
ii python 2.7.2-10
ii python-ibus 1.4.0-3
ii python-notify0.1.1-3
ii python-xdg 0.19-3
Versions of packages ibus recommends:
ii ibus-clutter none
ii ibus-gtk 1.4.0-3
ii ibus-gtk3 1.4.0-3
ii ibus-qt4 none
ii im-config [im-switch] 0.10
ibus suggests no packages.
-- no debconf information
--
Daiki Ueno
Bug#657436: [Pkg-ime-devel] Bug#657436: ibus: please add gobject-introspection support
Osamu Aoki os...@debian.org writes: On Thu, Jan 26, 2012 at 05:53:31PM +0900, Daiki Ueno wrote: However, the Debian ibus package does not provide introspection data. You mean we have to have this for which package. We generally follow released tarballs. I know. Are you suggesting we should start tracking upstream VCS for ibus, ibus-pinyin, ... Nope, the gobject introspection data is generally useful no matter how it is currently used. Since it is generated by default when libgirepository1.0-dev is available when building ibus, I don't see any reason not to distribute it. I am wondering if you can be a maintainer for all ibus family. I'm ok with that. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652917: ITP: libskk -- library to deal with Japanese kana-kanji conversion method
Package: wnpp Owner: Daiki Ueno u...@unixuser.org Severity: wishlist * Package name: libskk Version : 0.0.4 Upstream Author : Daiki Ueno u...@unixuser.org * URL or Web page : http://github.com/ueno/libskk * License : GPL-3+ Description : library to deal with Japanese kana-kanji conversion method libskk is a library that provides GObject-based interface of Japanese input methods. Currently it supports SKK (Simple Kana Kanji) with various typing rules including romaji-to-kana, AZIK, ACT, TUT-Code, T-Code, and NICOLA. This library will be used by ibus-skk from the next release. apt source for a test package: http://du-a.org/packages/libskk/debian/ -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
Werner LEMBERG w...@gnu.org writes:
I've revised all patches, updated the documentation, normalized the
import of gnulib's wcwidth, fixed a buglet in the new `.class' request
(each call caused insertion of an empty line), and it seems that
everything works fine!
Thanks! I confirmed the current CVS code working fine.
The only thing which I consider bad is that there is `(' at the line
end. Can this be improved by adjusting the calls to .cflags?
Hmm, I tried to add `(' to CJKpostpunct class, but it did not help.
リストでは合計実行時間、呼び出し回 数、そのルーチン自身で消費した時間 (
Groff adds a space between (non-punct) Japanese characters instead of
breaking the line. The expected result would be something like:
リストでは合計実行時間、呼び出し回数、そのルーチン自身で消費した時間
(...
or:
リストでは合計実行時間、呼び出し回数、そのルーチン自身で消費した時
間 (...
Perhaps assigning IGNORE_HCODE to whole CJK range is not perfectly
enough to control the line breaking rule.
Regards,
--
Daiki Ueno
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
Werner LEMBERG w...@gnu.org writes:
Any progress on the docs?
Please find below a patch to the docs. Sorry for the delay.
diff --git a/NEWS b/NEWS
index c5028c4..8b5f17e 100644
--- a/NEWS
+++ b/NEWS
@@ -24,6 +24,10 @@ o There is a new warning category `file', enabled by default. The `mso'
request emits warnings in this category when the requested macro file does
not exist.
+o The new `class' request assignes a short name to a set of
+ characters, which can be referred to in `cflags' request to control
+ line-breaking and hyphenation rules in CJK languages.
+
Tbl
---
diff --git a/doc/groff.texinfo b/doc/groff.texinfo
index ae2ac6e..4a4f318 100644
--- a/doc/groff.texinfo
+++ b/doc/groff.texinfo
@@ -8726,6 +8726,7 @@ special symbols (Greek, mathematics).
* Font Families::
* Font Positions::
* Using Symbols::
+* Character Classes::
* Special Fonts::
* Artificial Fonts::
* Ligatures and Kerning::
@@ -9122,7 +9123,7 @@ this is font 1 again
@c -
-...@node Using Symbols, Special Fonts, Font Positions, Fonts and Symbols
+...@node Using Symbols, Character Classes, Font Positions, Fonts and Symbols
@subsection Using Symbols
@cindex using symbols
@cindex symbols, using
@@ -9458,7 +9459,9 @@ width, depth, and height, nothing else. All manipulations with the
modified with the @code{cflags} request. The first argument is the sum
of the desired flags and the remaining arguments are the characters or
symbols to have those properties. It is possible to omit the spaces
-between the characters or symbols.
+between the characters or symbols. Also you can use the character class
+references here with the escape @code{\C'[...@var{class}]'} (see
+...@ref{character Classes} for more details).
@table @code
@item 1
@@ -9639,7 +9642,56 @@ The request @code{rfschar} removes glyph definitions defined with
@c -
-...@node Special Fonts, Artificial Fonts, Using Symbols, Fonts and Symbols
+...@node Character Classes, Special Fonts, Using Symbols, Fonts and Symbols
+...@subsection Character Classes
+...@cindex character classes
+...@cindex classes, character
+
+A @dfn{class} (aka ``character class'') is a set of characters,
+grouped by some user aspect. The request @code{class} defines classes
+so that other requests can refer to characters belonging to a class,
+with a short class name.
+
+Classes are particularly useful for East Asian languages such as
+Chinese, Japanese, and Korean, where there is a much larger set of
+characters than in European languages.
+
+A @code{class} request takes a class name followed by a list of
+characters. For example:
+
+...@example
+.class [prepunct] , : ; @}
+...@endexample
+
+To access the contents of a class, use the escape
+...@code{\c'[...@var{class}]'}. With the escape, you can define nested
+classes. Also, you can use the character range notation (a starting
+character code point, followed by a @samp{-} and an ending character
+code point), to avoid enumerating characters explicitly. Here is more
+complex example:
+
+...@example
+.class [CJKprepunct] \C'[prepunct]' \[u2013]-\[u2016] ...
+...@endexample
+
+The class @samp{CJKprepunct} contains the contents of the class
+...@samp{prepunct}, i.e. @samp{, : ; @}}, and characters in the range
+between @code{U+2013} and @code{U+2016}.
+
+Typical usage of the @code{class} request is to control line-breaking
+and hyphenation rules together with the @code{cflags}. For example,
+to inhibit line-break before the characters belonging to the
+...@samp{cjkprepunct}, you can write:
+
+...@example
+.cflags 2 \C'[CJKprepunct]'
+...@endexample
+
+See the @code{cflags} request in @ref{Using Symbols}, for more details.
+
+...@c -
+
+...@node Special Fonts, Artificial Fonts, Character Classes, Fonts and Symbols
@subsection Special Fonts
@cindex special fonts
@cindex fonts, special
diff --git a/man/groff_diff.man b/man/groff_diff.man
index 115c6d2..3bdfa47 100644
--- a/man/groff_diff.man
+++ b/man/groff_diff.man
@@ -1093,6 +1093,17 @@ This is useful for removing the newline from the end of diversions
that are to be interpolated as strings.
.
.TP
+.BI .class\ name\ c1\ c2\|.\|.\|.\
+Assign a short name
+.IR name
+to a set of characters
+.IR c1 ,
+.IR c2 ,\|.\|.\|.\
+so that they can be referred to from the other requests easily.
+This is useful to assign properties to a large set of characters (using
+.BR .cflags ).
+.
+.TP
.BI .close\ stream
Close the stream named
.IR stream ;
Regards,
--
Daiki Ueno
Bug#552201: [Groff] Re: Bug#552201: groff-base: Japanese manpages are shown with too wide spaces
Thanks Werner and Colin for the insightful comments. Werner LEMBERG w...@gnu.org writes: However, a very important piece is still missing: documentation! I won't commit the changes otherwise. I'm now preparing the documentation. One question: the `classes' keyword for font files, ... What is the keyword supposed to work? I didn't notice that since it is currently not used in any font file and seems not to affect the run-time behavior. Perhaps a wreck of the original patch? I second that; it's not necessary to do that so I'll omit these changes to nroff. Good to know that man-db already has the hook to load locale macros :) I think that the (current) contents of ja.tmac is essentially universal, not restricted to Japanese. Yes and probably CJK languages can share a single .tmac for kinsoku processing, since the kinsoku rules for those languages are not likely to overlap each other. I'm now trying to extend current ja.tmac to support Chinese and Korean: http://ueno.fedorapeople.org/groff/make-cjk-tmac/ Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#594510: emacs23-common: OpenPGP-signed message composition uses micalg=pgp-rmd160 instead of micalg=pgp-ripemd160
Rob Browning r...@defaultvalue.org writes: but the declaration for RIPEMD160 is wrong, according to the registry in RFC 4880. It should be: (defconst epg-digest-algorithm-alist #3#)) ((1 . MD5) (2 . SHA1) (3 . RIPEMD160) (8 . SHA256) (9 . SHA384) (10 . SHA512)) Thanks. Fixed in r102553. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600834: gtkpod: Quote args of tr
Package: gtkpod
Version: 0.99.14-3
Severity: normal
In /usr/share/gtkpod/scripts/gtkpod-convert-common.sh:
filetype=`echo ${infile_extension}| tr [:upper:] [:lower:]`
where [:upper:] and [:lower:] should be quoted. Otherwise, if
${infile_extension} contains a and there is a file named p in the
current directory, you will get wrong result. Try:
$ touch p
$ dash -c 'echo aaa | tr [:lower:] [:upper:]'
ppp
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages gtkpod depends on:
ii gtkpod-data 0.99.14-3architecture-independent files for
ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit
ii libc6 2.11.2-6 Embedded GNU C Library: Shared lib
ii libcairo2 1.8.10-6 The Cairo 2D vector graphics libra
ii libcurl3-gnutls 7.21.2-1 Multi-protocol file transfer libra
ii libdbus-1-3 1.2.24-3 simple interprocess messaging syst
ii libflac81.2.1-3 Free Lossless Audio Codec - runtim
ii libfontconfig1 2.8.0-2.1generic font configuration library
ii libfreetype62.4.2-2 FreeType 2 font engine, shared lib
ii libgconf2-4 2.28.1-5 GNOME configuration database syste
ii libglade2-0 1:2.6.4-1library to load .glade files at ru
ii libglib2.0-02.24.2-1 The GLib library of C routines
ii libgnomevfs2-0 1:2.24.3-1 GNOME Virtual File System (runtime
ii libgpod40.7.93-0.3 library to read and write songs an
ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface
ii libhal1 0.5.14-3 Hardware Abstraction Layer - share
ii libid3tag0 0.15.1b-10 ID3 tag reading library from the M
ii libpango1.0-0 1.28.3-1 Layout and rendering of internatio
ii libvorbis0a 1.3.1-1 The Vorbis General Audio Compressi
ii libvorbisfile3 1.3.1-1 The Vorbis General Audio Compressi
ii libxml2 2.7.7.dfsg-4 GNOME XML library
Versions of packages gtkpod recommends:
ii id3v2 0.1.12-2 A command line id3v2 tag editor
ii vorbis-tools 1.4.0-1several Ogg Vorbis tools
Versions of packages gtkpod suggests:
pn faacnone (no description available)
pn faadnone (no description available)
ii lame3.98.4-0.0 LAME Ain't an MP3 Encoder
pn mp3gain none (no description available)
ii perl5.10.1-15Larry Wall's Practical Extraction
ii python 2.6.6-3+squeeze1 interactive high-level object-orie
-- no debconf information
--
Daiki Ueno
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591052: ibus-skk: Please support single 'n' before okurigana
KISE Hiroshi k...@fuyuneko.jp writes: I type 'KanJi' for Japanese 'kanjiru' (feeling), but ibus-skk dose not start conversion. OK: KannJi OK: Kan'Ji NG: KanJi Please support single 'n' before okurigana. Thanks for pointing this out. Yamashita-san fixed the bug: http://github.com/ueno/ibus-skk/commit/4d0d4d8037f86f7a3afdf9480b8d5f3ad4a4c685 This change will be included in the next upstream release. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590188: ibus-skk: Please support skk-purge-from-jisyo
KISE Hiroshi k...@fuyuneko.jp writes: Please support skk-purge-from-jisyo like function and bind X key. I just implemented it: http://github.com/ueno/ibus-skk/commit/7a94e150f302bc3ffb238022ab17646996438ae5 This change will be go in the next upstream release but you can try it by replacing skk.py on your system. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590191: ibus-skk: Please exit register mode when input empty strings
KISE Hiroshi k...@fuyuneko.jp writes: Please exit register mode when input empty strings like type Ctrl-g. And do not register empty strings in user-jisyo. (I assume that you mean Return where Ctrl-g, which always aborts the register mode) I just added a check for empty string: http://github.com/ueno/ibus-skk/commit/c8db12a03b4f7065fa66a6ad3288ca4174d2f605 This change will be go in the next upstream release but you can try it by replacing skk.py on your system. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583784: ibus-skk: fails to convert okuri-gana using skksearch with dictionary SKK-JISYO.JIS3_4
KISE Hiroshi k...@fuyuneko.jp writes: I start skk-mode (Ctrl+Space), type OkuRi on bash command-line. I expected black triangleOKURI (OKU is kanji, RI is hiragana) but iwhite triangleOKU*r (OKU is hiragana). Could you restart ibus-daemon with debug output enabled: $ ibus-daemon -r --verbose and then try again? I guess you will see some python exceptions there. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573636: diakonos fails to start
Evgeni Golov evg...@debian.org writes: You are using dpatch without having dpatch as build-depend. When you have dpatch as b-d, why not use /usr/share/dpatch/dpatch.make and it's magic targets? Ah, I didn't know that. Thanks for the tip. *However* I'd not use dpatch at all here. Maintainer already has direct changes to files in his .diff.gz (lib/diakonos.rb and lib/diakonos/help.rb) and I think forcing him to some patch system he is not (yet) using is the wrong way *here* (don't understand me wrong, I'm all for patch systems [even if I prefer quilt over dpatch] but here we are not the maintainer and should adapt his workflow). Yes, I used dpatch just to make it clear that the shebang change is Debian specific. I have no strong opinion on whether/which patch systems are used here. PS: if you want, i can upload the patch/NMU after you fixed the point(s) above :) Thanks, but not really for now. I also think that it would be definitely better for the bug to be fixed by the maintainer :-) Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574110: ITP: m17n-im-config -- an input method configuration library for m17n-lib
Package: wnpp Owner: Daiki Ueno u...@unixuser.org Severity: wishlist * Package name: m17n-im-config Version : 0.9.0 Upstream Author : Kenichi Handa ha...@m17n.org : Mikiko Nishikimi nisik...@m17n.org : Naoto Takahashi ntaka...@m17n.org : Satoru Tomura tom...@m17n.org * URL or Web page : http://www.m17n.org * License : LGPL-2.1+ Description : an input method configuration library for m17n-lib A preliminary package can be found at: http://www.unixuser.org/~ueno/software/debian/m17n-im-config/ Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570727: fails when comparing minimal trees on i386
tags 570727 +patch
thanks
Hi,
The problem seems to be caused by id() calculation bug in the C
extension part of xmldiff.
xmldiff constructs a tuple like this:
#define KEYSHAPE (i,i)
PyObject *node1, ...;
key = Py_BuildValue(KEYSHAPE, (size_t)node1, ...) ;
and its Python part refers to the tuple as (id(node1), ...).
This is problematic because the return value of id() would either be an
Int (fixed size) or a Long (arbitrary precision) object. I think the
original problem can also observed on 64bit systems, but more likely on
32bit systems.
The attached patch will fix the problem (I'll notify the upstream
shortly).
pgpBDfsaFYqHH.pgp
Description: PGP signature
diff -u xmldiff-0.6.8/debian/changelog xmldiff-0.6.8/debian/changelog
--- xmldiff-0.6.8/debian/changelog
+++ xmldiff-0.6.8/debian/changelog
@@ -1,3 +1,10 @@
+xmldiff (0.6.8-4.2) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix id() calculation in extensions/maplookup.c (Closes: #570727)
+
+ -- Daiki Ueno u...@unixuser.org Mon, 15 Mar 2010 17:16:23 +0700
+
xmldiff (0.6.8-4.1) unstable; urgency=low
* Non-maintainer upload.
only in patch2:
unchanged:
--- xmldiff-0.6.8.orig/extensions/maplookup.c
+++ xmldiff-0.6.8/extensions/maplookup.c
@@ -40,12 +40,6 @@
/*** functions specific to the fmes algorithm */
-#if __WORDSIZE == 64
-#define KEYSHAPE (l,l)
-#else
-#define KEYSHAPE (i,i)
-#endif
-
static short N_ISSUE = 5 ;
/* function to init objects for the next functions
@@ -162,11 +156,17 @@
{
PyObject *key ;
couple = PyList_GET_ITEM(_mapping, i) ;
-key = Py_BuildValue(KEYSHAPE, (size_t)node1, (size_t)PyTuple_GET_ITEM(couple, 0)) ;
+ key = PyTuple_New(2);
+ Py_INCREF(key);
+ PyTuple_SET_ITEM(key, 0, PyLong_FromVoidPtr(node1));
+ PyTuple_SET_ITEM(key, 1, PyLong_FromVoidPtr(PyTuple_GET_ITEM(couple, 0)));
if (PyDict_GetItem(_dict1, key) != NULL)
{
Py_DECREF(key) ;
-key = Py_BuildValue(KEYSHAPE, (size_t)node2, (size_t)PyTuple_GET_ITEM(couple, 1)) ;
+ key = PyTuple_New(2);
+ Py_INCREF(key);
+ PyTuple_SET_ITEM(key, 0, PyLong_FromVoidPtr(node2));
+ PyTuple_SET_ITEM(key, 1, PyLong_FromVoidPtr(PyTuple_GET_ITEM(couple, 1)));
if (PyDict_GetItem(_dict2, key) != NULL)
{
seq_num += 1 ;
Sent from Thailand Mini-DebCamp 2010 BSP:
http://wiki.debian.org/DebianThailand/MiniDebCamp2010/BSP
Regards,
--
Daiki Ueno
Bug#573636: diakonos fails to start
tags 573636 +patch
thanks
Hi,
Here is a patch following Evgeni's suggestion. I've confirmed that it
actually fixed the startup failure.
pgpupE07OmUcd.pgp
Description: PGP signature
diff -u diakonos-0.8.12/debian/changelog diakonos-0.8.12/debian/changelog
--- diakonos-0.8.12/debian/changelog
+++ diakonos-0.8.12/debian/changelog
@@ -1,3 +1,11 @@
+diakonos (0.8.12-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Depend on ruby1.9.1 and don't use #!/usr/bin/env ruby since diakonos
+only works with ruby1.9.1 (Closes: #573636).
+
+ -- Daiki Ueno u...@unixuser.org Tue, 16 Mar 2010 10:08:49 +0700
+
diakonos (0.8.12-1) unstable; urgency=medium
* new upstream version, see upstream changelog, amongst the upstream changes
diff -u diakonos-0.8.12/debian/control diakonos-0.8.12/debian/control
--- diakonos-0.8.12/debian/control
+++ diakonos-0.8.12/debian/control
@@ -11,7 +11,7 @@
Package: diakonos
Architecture: all
-Depends: ${misc:Depends}, ruby (=1.9.1)
+Depends: ${misc:Depends}, ruby1.9.1
Homepage: http://purepistos.net/diakonos/
Description: Customizable, usable console-based text editor
an editor made it with the intention of being easier to configure and use than
diff -u diakonos-0.8.12/debian/rules diakonos-0.8.12/debian/rules
--- diakonos-0.8.12/debian/rules
+++ diakonos-0.8.12/debian/rules
@@ -1,12 +1,22 @@
#!/usr/bin/make -f
#export DH_VERBOSE=1
-clean:
+clean: clean-patched unpatch
+clean-patched:
dh_testdir
dh_testroot
dh_clean
-build:
+build: patch
+
+patch: patch-stamp
+patch-stamp:
+ dpatch apply-all
+ dpatch cat-all patch-stamp
+
+unpatch:
+ dpatch deapply-all
+ rm -rf patch-stamp debian/patched
install:
only in patch2:
unchanged:
--- diakonos-0.8.12.orig/debian/patches/00list
+++ diakonos-0.8.12/debian/patches/00list
@@ -0,0 +1,2 @@
+01_no-env-shebang
+
only in patch2:
unchanged:
--- diakonos-0.8.12.orig/debian/patches/01_no-env-shebang.dpatch
+++ diakonos-0.8.12/debian/patches/01_no-env-shebang.dpatch
@@ -0,0 +1,16 @@
+#! /bin/sh /usr/share/dpatch/dpatch-run
+## 01_no-env-shebang.dpatch by Daiki Ueno u...@unixuser.org
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: don't use /usr/bin/env for shebang
+
+...@dpatch@
+
+--- diakonos-0.8.12/bin/diakonos~ 2010-03-16 10:35:49.0 +0700
diakonos-0.8.12/bin/diakonos 2010-03-16 10:36:03.0 +0700
+@@ -1,4 +1,4 @@
+-#!/usr/bin/env ruby
++#!/usr/bin/ruby1.9.1
+
+ require 'diakonos'
+
Sent from Thailand Mini-DebCamp 2010 BSP:
http://wiki.debian.org/DebianThailand/MiniDebCamp2010/BSP
Regards,
--
Daiki Ueno
Bug#570695: Fails with absolute symlinks
tags 570695 +patch thanks Hi, The attached patch will fix the problem (I've already sent it to the upstream). Sent from Thailand Mini-DebCamp 2010 BSP: http://wiki.debian.org/DebianThailand/MiniDebCamp2010/BSP pgpUmELQUe6vb.pgp Description: PGP signature diff -u makejail-0.0.5/makejail makejail-0.0.5/makejail --- makejail-0.0.5/makejail +++ makejail-0.0.5/makejail @@ -353,7 +353,14 @@ moveIndent(1) addFileToJail(checkDir) moveIndent(-1) - fileInChroot=%s%s % (config.chroot,fileName) + # The directory part of fileName may be a symlink to an + # absolute pathname. For example, fileName is + # lib64/ld-linux.so.2 where lib64 is a symlink to /lib. + # In that case it should be resolved before constructing + # fileInChroot. See http://bugs.debian.org/570695. + fileDir, baseName = os.path.split(fileName) + fileInChroot=os.path.join(config.chroot,os.path.realpath(fileDir)[1:], + baseName) if os.path.exists(fileInChroot): if fileIsNewer(fileName,fileInChroot): debug( File %s is newer than the %s, overwriting % (fileName,fileInChroot)) @@ -373,7 +380,9 @@ absoluteLinkTarget=%s/%s % (fileDir,linkTarget) newFiles=addFileToJail(absoluteLinkTarget) missingFiles=missingFiles+newFiles - newWorkingDir=%s/%s % (config.chroot,fileDir[1:]) + # newWorkingDir may be a symlink to an absolute + # pathname. See the above comment. + newWorkingDir=%s/%s % (config.chroot,os.path.realpath(fileDir)[1:]) os.chdir(newWorkingDir) debug( Creating '%s' as a symlink to '%s' (pwd=%s) % (fileName[1:],linkTarget,newWorkingDir)) os.symlink(linkTarget,os.path.split(fileName)[1]) diff -u makejail-0.0.5/debian/changelog makejail-0.0.5/debian/changelog --- makejail-0.0.5/debian/changelog +++ makejail-0.0.5/debian/changelog @@ -1,3 +1,11 @@ +makejail (0.0.5-8.1) unstable; urgency=low + + * Non-maintainer upload. + * Fix pathname handling when the directory components include absolute +symlink (Closes: #570695). + + -- Daiki Ueno u...@unixuser.org Sun, 14 Mar 2010 18:33:38 +0700 + makejail (0.0.5-8) unstable; urgency=low [ Changes by Florian Grandel jerico@gmail.com ] Regards, -- Daiki Ueno
Bug#573635: Please add Daiki Ueno to DM
Package: debian-maintainers Severity: normal Please accept my application as a DM. The jetring changeset is attached below. pgp2Gf8AWS520.pgp Description: PGP signature Comment: Add Daiki Ueno u...@unixuser.org as a Debian Maintainer Recommended-By: NIIBE Yutaka gni...@fsij.org Agreement: http://lists.debian.org/debian-newmaint/2009/12/msg00046.html Advocates: http://lists.debian.org/debian-newmaint/2010/02/msg00011.html Date: Fri, 12 Mar 2010 22:32:54 +0700 Action: import Data: -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.10 (GNU/Linux) mQINBEpn7i4BEACh0wFe2B53UlIxWOQ3wrK3TIyHpmz9zyMCkdIP7x1b74Z/SxZA 7N8uOk5BQh3GLBnYThJl3MSWOAgpbouyI5Eh9f+yZ27AoBkQcd8JeHckbLvXCxG8 GPOn1cqSBUsus+6tuG86LI3rudJSKsFZ2uH0amRfJSBBnybrosy5dTn55GIJ3Bbq WdaTP7uNFWRMzi6DA49m880hJ2qunkuAOX/q8kvKpfRuJCdme9kXZc1l88FqGUEl dCVYpG+SjdCFP9CmZJRYhF6UuRHSZXyJTw1WMmop7gYj2F3QTsodnf1e9eDju/yW pzmPB4WACtrrO7wzPlufselFNIrHwx6tykvzflaYTg2brn9opmZTAM7eYXhBk8AE vOXCg1q4UXiSGtFpowBUVtoOGQHlSC218OnQyaMEsC7Cagb1EQqZNbXnvcMVzMIc XcKHFSAQrk5+IfNTQOok8FIWXWm8TYVDqVIpWEKDgHj0PwcPWtpkhjlgIP01a5uv rvv0w1Tq2NcjLppyYynoEvEbGWojku4lyCUWdWAL9n5h3IClyBCqdH8OMtdL3Wib GIlkbOcWXfsR+FURCv5eswMRAlZKuzLf6YyDzpZVWyOoe+Qc+S4Dl8J+WeY7PquN JwGdtLklSi0436VYKup4kgoT3iAHYVOBt0K03nDtgnsm2UxiER+e190YVwARAQAB tB5EYWlraSBVZW5vIDx1ZW5vQHVuaXh1c2VyLm9yZz6JAjcEEwECACECGwMCHgEC F4AFAkpn/hcFCwkIBwMFFQoJCAsFFgIDAQAACgkQ1gWEjtfmmHF2fg/+P4RPIR5L EO98RRXacBjc41s6TRmBX1FVvXb8JW3rEoZmPBVwEpBjbUketmVVs/c0GHFnQ1JF fho+gKgjwj6Hpkk527z4HVpcnb/CZd7XgFa9WuFfFk7iw6caGfe92RvtPt7JVgHR D/DphGYMqq0rHX4vy0ej2qcWx3RC8+oH0fQCVTDXGKWR37Zbs0hhcXmDL0rTxCkC e1Nn/L1FABeLFx/8mOuJd3kXz/IIaIPdLTWwVD6xPLc9UU12MSvDRjT4qlNr93Ua VF/Bthu2PARjtITl437l1trGylNJlW+YO4XDuisR5vMPHJUM2bljLImP5gIkk7Kx 0HQWaqt5sCCCPIHrgmilhT23lnNOn3xXa7qHBX+N21TmdTSfo5oLRruSr9F15hvV pwleBvvSNB0kIzqbWC1NJUOgsQ2laU+houjXABPCrH8uOyCt5fNPgJWERIEWuNz/ E//8dsq9S7xYMEWIIR3JYcjMbAJBfaTlWGtGafhV4GL8rca5zNXp5402NF73P98e ougyEa/DCbZ2LoJSxXf9o1zyMsABSEKXDrGkryGwRuCSSfau1L9j4HMjRzsRItyN XVeIk3M/wUJGCWI11ZTwoFdv33Xc8h30erv06Xqgec8CjdguFihyPomXGp+1rwWi d9hRvSqXgSH+5yqSFIFjmD+OTBQ3OcgZ0cuIRgQQEQIABgUCSmf0VQAKCRAEHjmv cdX0OqhNAKCYie3h8sHVDEPRY5NqWLwN49EBKgCgxq4BW0x2jvvX46w7gsjbt3av ftiJAjYEEwECACAFAkpn7i4CGwMGCwkIBwMCBBUCCAMEFgIDAQIeAQIXgAAKCRDW BYSO1+aYcW7BD/9MZlShtf9dY5MlDiK2ieQgqfVaYWAM/qMeWDqXCYguQ1b27YsX J26zlDi+hXm/Ebk0pj5j7mUqnGHc16XCEDVLIQqNqJSWGVvEFy6USLRxVpcLDYha Ml8SblFVI/u6Jb1ZyjSZBachn/5IwF+PmwrwQOYgmApovgRYauvW6S482yq5QsIG mJRduvhdj7Grgb8ShKuPMXWmeNTmwgukMgIIm60AsUFsxjKrt08tT/iCsgk5nh5W 7sXbr2JYnsSNOCpsIQrK/7l9EurGHrd8JUOvPIGE88ObO+MiRMV8e7FPMSVQKF0S YrJwLEpy/e2twDCrxN3lhNJ7yEZ0mXaOIDlesTJmtd61MwHh5PU6CG9sCYb3Ucc5 mz3qANFkDrIHJjBKRWTgVuSBQ4XLet++Q8t28kr+SE9Tet7kkA4tG4exTqoO26FC ME3b+rW4lyu15dTCtWBMkL9gC9t84MWHqxSyS1M0o0oVdbZOundhCQiQZt7CCN+B AbmuYWQcxC5P8MShrxmd1YUjrMKQKuEFOa3mhFUNm3xAdDeoGI2qV2/RbnnJIfEx 91Vls6sKjhRfRiSX002sPo/Xj4ictEOFvyvBJH3ASwk0T477E2s1+knwJ3Bx GET8wL4HAWzs4wzH8iuecKebl2/tX4/AlcFQWyr7/RDlq3+MPtP/hci1FohGBBAR AgAGBQJLf/yZAAoJEF3iSZZbA1iivooAnRQzkNcbR/uNeWCSyaGVA9+mKCkyAJ9k UrH5csWNnnu6ZYCfIhOgJCJUA4hGBBMRAgAGBQJLeQrIAAoJEFuz9RlYFnkaJw4A nA0JilrQwv127o7YxX8e1PrcwIjpAKCB71fTcFLpCo2IZCDotlS+785Q4YhGBBMR AgAGBQJLeRcnAAoJEHIbrb5pEVAkRjgAn3FZk6tzl8JgQLV0Yz74GBvUfvtiAJ4p Z+5KmSqUUqS1GgJikf1iZFqBSYhWBBARCwAGBQJLf/yZAAoJEPKthaweQrNnRKYA 33wcNieRecbrbfHiJVYSkzWwKB/uNXbjDeTjUxgA30Hps0sqyqq1SRDsPPP0bJ3f vD3GECJ7ih1uqEa5Ag0ES2tPvAEQAKNGc0pemIP+1tVKIXduJxml/gLUkUgO+8kd BkS4rflKp4B7+1SkwDBsF+BbmwTFSgHcLLWUQrYGLWQ7sZT62R0IeGLqOtwtiIyD tBdq9hn95tgdV+FVja8aE4lXPiqbT9a9BhPc6klKqsPWNP4BtGkPEWT2HYIE/DWu gGuHxOpgrIg4E9KzAvA/TkgqT2HtLBCeX+y1dFyEsxVoysovfdXZullIjg21iElA bNfs8dWy/glgEJcJ4VGEAnAsvJJ8YzcNd0AKGw6O0ahv+xbzgq/lgzrmwfGaGK3g 0LmjkjFVCe29ho6xNp8X0o4Lx6Ciy0+wBHFQ02KEZi8nlYvw1LbBBUxayJEwr79C wro8QxefLir36Uw8YFmm4aJxRfrxEggnKcBodq12isDSEVINAhXFuENNB2sGea19 LHfdh30uVpb6gXPeg22xQ/nslAy+fv9FgxKF5Gq2WFI44dBX8N05GjYHW6F3YOW5 k7OxXPzyj/Z5n12E7wCs2FBGlaBzHt2r6QjsXJQfQh2vDb2oPchP8+cQ5MXziuiX QcRqA/WjNUHfaSskgNFCV5OZ1OiC1Pr0Vgsecr19iuTWbc9xzdNZv/U8Jxxw3QPZ EkKXaSvLnAl3HqDZuLvCDi3ClEmyGLmNEQ8kAAY3LkwoD6iifoPqBvDA0/fG7P// 0FTQBQNhABEBAAGJAh8EGAECAAkFAktrT7wCGwwACgkQ1gWEjtfmmHEwrBAAn6OC 3rA4wIvHXOxGLenEZBCrsWZUk0lhnXYkSna4sLWH0TTxX5pBdl7uluiciVe/N4iE 6XpHVKbP8qbKiXL0L1MiG0yGRmuzGhyuJoszsjEh8K7LSKcW+/1sSiAII1XEWmNX UM+xwxVREpCCNs1Bwp7PIo5SrjsgKrx43nCZrvaaXFFVHFRMeLndKiR9v1i6uFUe txbH8RIxHvMdILCO19Dr1zvv5ohMnChxVrGVRVBgIJq8I4HWBgOOd/kXXuD7MYYL Dt03y+DgHTjyjKDxGJKcCY3aW3iJ9+o8BVNTyuLENEaSCnFiIyQYJ1qofBK76a4J rzkAz2v1YrpYi5FASOHY82xOT6W1qZMt8VQLSw6kb7wt60PWEjcFZKl+BPmdydRF yeZqeyJVPQbLve89d/5MfCdji8BjmjRf3ezazJ8NftlGuEuDQwEq7P94gFEsMVrC SOl77eYNgxWjVLUOmDti3wi+UMVCVZGUhK6iCAzjzolA1+N1LRmISTWYiNrjDxFg MnYWTqFyhHvnh+Fm1QuBfMTQREZpN+kWUa7iNpabJaKR1rP6h/kBHT2YuXoqEIO6 onUt+miSB15Qg7DF7/rvFPnDIZYr3t+MkaPlmjpXEUV/psdnytVWFcGxHdY0NA+R /e4eeyThgRet5M+0+9Duynj/ACpfWq/dxXbWRfY= =gczL -END PGP
Bug#565845: [DRE-maint] Bug#565845: libgpgme-ruby1.9: Please drop the dependency on ruby 1.9.0
Lucas Nussbaum lu...@lucas-nussbaum.net writes: It FTBFi wity Ruby 1.9.1: gpgme_n.c:269: error: ‘struct RArray’ has no member named ‘ptr’ So the simplest solution is just to drop the 1.9 package until upstream fixes it. I'm the upstream :-) The bug was fixed in 1.0.7: http://rubyforge.org/frs/shownotes.php?release_id=37205 So the latest 1.0.8 should build against ruby1.9.1. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#562137: ITP: ibus-skk -- a Japanese SKK input engine for IBus
Package: wnpp Owner: Daiki Ueno u...@unixuser.org Severity: wishlist * Package name: ibus-skk Version : 0.0.2 Upstream Author : Daiki Ueno u...@unixuser.org * URL or Web page : http://github.com/ueno/ibus-skk/ * License : GPL Description : a Japanese SKK input engine for IBus IBus is an Intelligent Input Bus. It is a new input framework for Linux OS. It provides full featured and user friendly input method user interface. It also may help developers to develop input method easily. IBus-SKK is an input engine for Japanese, based on IBus, supporting the SKK input method. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#542892: ohcount: #!/usr/bin/env ruby in /usr/bin/ohcount
Package: ohcount Version: 2.0.1-1 Severity: normal Hi, On my environment where custom ruby binary is installed in /usr/local/bin, ohcount fails with: /usr/bin/ohcount:9:in `require': no such file to load -- ohcount (LoadError) from /usr/bin/ohcount:9:in `rescue in main' from /usr/bin/ohcount:2:in `main' This is because /usr/bin/ohcount uses #!/usr/bin/env ruby trick. There are similar bugs in Debian (#344246, #344988, #416775, etc), and they seem to have been resolved by simply replacing it with #!/usr/bin/ruby1.8. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ohcount depends on: ii libc62.9-25 GNU C Library: Shared libraries ii libdifflcs-ruby 1.1.2-1 An implementation of the McIlroy-H ii libruby1.8 1.8.7.174-2 Libraries necessary to run Ruby 1. ii ruby 4.2 An interpreter of object-oriented ii ruby1.8 1.8.7.174-2 Interpreter of object-oriented scr ohcount recommends no packages. ohcount suggests no packages. -- debconf-show failed -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538947: gnupg2: Please add gnupg-agent dependencry
Package: gnupg2 Version: 2.0.11-1 Severity: normal As the use of gpg-agent is mandatory in GnuPG 2, the gpg2 command fails if gnupg-agent is not installed: $ gpg2 --no-use-agent --armor --symmetric gpg: WARNING: --no-use-agent is an obsolete option - it has no effect can't connect to `/home/ueno/.gnupg/S.gpg-agent': No such file or directory can't connect server: `ERR 33554701 can't exec `/usr/bin/gpg-agent': No such file or directory' gpg: can't connect to the agent: IPC connect call failed gpg: problem with the agent: No agent running gpg: error creating passphrase: Operation cancelled gpg: symmetric encryption of `[stdin]' failed: Operation cancelled Maybe gnupg-agent should be Depends: rather than to Recommends:? Regards, -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg2 depends on: ii libbz2-1.0 1.0.5-3 high-quality block-sorting file co ii libc6 2.9-21GNU C Library: Shared libraries ii libcurl3-gnutls7.19.5-1 Multi-protocol file transfer libra ii libgcrypt111.4.4-3 LGPL Crypto library - runtime libr ii libgpg-error0 1.6-1 library for common error values an ii libksba8 1.0.7-1 X.509 and CMS support library ii libreadline5 5.2-5 GNU readline and history libraries ii zlib1g 1:1.2.3.3.dfsg-14 compression library - runtime Versions of packages gnupg2 recommends: ii gnupg-agent 2.0.11-1 GNU privacy guard - password agent ii libldap-2.4-2 2.4.15-1.1 OpenLDAP libraries Versions of packages gnupg2 suggests: ii gnupg-doc 2003.04.06+dak1-1 GNU Privacy Guard documentation ii xloadimage 4.1-16.1 Graphics file viewer under X11 -- no debconf information -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#538228: libgpgme-ruby: Please update debian/copyright
Package: libgpgme-ruby Version: 1.0.6-1 Severity: normal Hi, I recently changed the license of libgpgme-ruby to LGPL-2.1 from GPL-2. Could you please update debian/copyright in the future releases? I'll release 1.0.7 shortly. Thanks, -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-686-bigmem (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgpgme-ruby depends on: ii libgpgme-ruby1.8 1.0.6-1GPGME bindings for the Ruby langua libgpgme-ruby recommends no packages. libgpgme-ruby suggests no packages. -- no debconf information -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537211: ITP: libusb-ruby -- libusb binding for Ruby
Package: wnpp Owner: Daiki Ueno u...@unixuser.org Severity: wishlist * Package name: libusb-ruby Version : 0.2 Upstream Author : Tanaka Akira * URL or Web page : http://www.a-k-r.org/ruby-usb/ * License : LGPL Description : libusb binding for the Ruby language ruby-usb is a libusb binding library for Ruby. It provides both direct (non-rubyish) binding and rubyish interface, while the latter is work in progress. A preliminary package which I created can be found at: http://www.unixuser.org/~ueno/software/debian/libusb-ruby/ Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503302: easypg: please support variables for --symmetric and --cipher-algo
2008/10/27 Tatsuya Kinoshita [EMAIL PROTECTED]: To encrypt *a new file*, epa-file.el asks recipients, while alpaca.el doesn't ask recipients, because alpaca.el always use the gpg -c option. My wish is use gpg -c for new file option, and setting epa-file-encrypt-to to seems to work like so. OK, I'll consider a new option which would call `epa-file-default-encrypt-to' for that purpose, with an appropriate docstring. Thanks for the new variable. Alternatively, the problem is fixed by defining epa-file-encrypt-to with defcustom, which forces users to set the variable with setq-default. BTW, alpaca.el also uses the gpg option --cipher-algo AES for encryption by default. If the alpaca-cipher variable is set to AES256, --cipher-algo AES256 is used. Meanwhile epa-file.el seems to use the gpg default (3DES or CAST5), and I haven't found an easy way to customize it... Is it not sufficient to set cipher-algo AES256 in ~/.gnupg/gpg.conf? Although ~/.gnupg/gpg.conf works, I hope an Emacs Lisp variable for --cipher-algo will be defined. If it exists, cipher-algo can temporally be switched in Emacs easily. Could you please consider it? Well, that is a design issue which I intentionally didn't make it so flexible. I think such a low-level option better be configured in the central point -- ~/.gnupg/gpg.conf. Do you have any real problem with this? Otherwise, I won't change this. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#503302: easypg: please support variables for --symmetric and --cipher-algo
2008/10/27 Tatsuya Kinoshita [EMAIL PROTECTED]: Do you have any real problem with this? Otherwise, I won't change this. Though I haven't encountered a real problem, I can imagine a situation: I asked if there is a real problem (not a imaginary use-case). Do you have a friend who is just troubled with this? Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#481082: ITP: crypt++el -- Emacs-Lisp Code for handling compressed and encrypted files
Hi, In [EMAIL PROTECTED] Christoph Martin [EMAIL PROTECTED] wrote: I intend to reintroduce crypt++el into Debian because I think we still need it. The mentioned alternatives jka-compr and easypg do not provide all the features which crypt++.el provides. I'm a bit curious about what features are missing in jka-compr and easypg, but present in crypt++.el. EasyPG is now a part of development version of Emacs (version 23), and I'd love to improve it. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#477979: update-manager: trailing garbage of translated Not all updates can be installed message
Package: update-manager Version: 0.68.debian-3 Severity: normal Tags: l10n, patch Hello, I've always seen bare %s under translated Not all updates can be installed message. This is caused by the translation not up to date with the latest msgid of that message (which no longer contains %s). Here is a list of PO files which need update. bg.po bn.po da.po id.po ja.po lt.po ms.po nb.po nl.po oc.po The attached is a patch to fix this. not-all-updates-can-be-installed.diff.gz Description: Binary data -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.24-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages update-manager depends on: ii gconf2 2.22.0-1GNOME configuration database syste ii libgnome2-perl 1.042-1 Perl interface to the GNOME librar ii python 2.5.2-1 An interactive high-level object-o ii python-dbus 0.82.4-2simple interprocess messaging syst ii python-glade22.12.1-1GTK+ bindings: Glade support ii python-gnome22.22.0-1Python bindings for the GNOME desk ii python-support 0.7.7 automated rebuilding support for P ii python-vte 1:0.16.13-1 Python bindings for the VTE widget ii software-properties-gtk 0.60.debian-1.1 manage the repositories that you i ii synaptic 0.61+nmu1 Graphical package manager ii update-manager-core 0.68.debian-3 APT update manager core functional update-manager recommends no packages. -- no debconf information -- Daiki Ueno
Bug#451484: Prompts for password twice when find-file symlink to encrypted file
Hello, I'm sorry for late response. In [EMAIL PROTECTED] Trent W. Buck [EMAIL PROTECTED] wrote: When I attempt to open a file foo.gpg, where foo.gpg is a symlink to bar.gpg, I am prompted for a passphrase twice. AFAICT it doesn't matter what I type the first time. I think the first prompt is superfluous and should be avoided. This happens even with -q. I can't reproduce the problem with this recipe. Perhaps you meant the following, didn't you? (0) you were using symmetric encryption (1) you opened foo.gpg, and easypg asked you the passphrase for bar.gpg (2) then you opened bar.gpg, and easypg asked you the passphrase for bar.gpg If my guess is correct, the attached patch (already installed in the upstream CVS) will fix the problem. epa-file.el.diff Description: Binary data Regards, -- Daiki Ueno
Bug#433988: ChangeLogReader: failed to generate... ... ...divided by 0
In [EMAIL PROTECTED] A. Costa [EMAIL PROTECTED] wrote: 1) docs a) vague SYNOPSIS --help b) examples (wishlist) 2) needlessly obscure error message 3) exit code 0 Okay. I uploaded treil-1.3 which probably fixes 1.a (--help), 2, and 3. In addition, I added a new option -v and if it is not specified, treil doesn't display detailed information so that users don't come up with unexpected usage. Regards, -- Daiki Ueno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433988: ChangeLogReader: failed to generate... ... ...divided by 0
In [EMAIL PROTECTED]
A. Costa [EMAIL PROTECTED] wrote:
Let's throw a changelog at 'treil':
% gunzip /usr/share/doc/treil/changelog.Debian.gz /tmp/chl
% treil -R ChangeLogReader /tmp/chl /tmp/chl.png ; echo $?
Reader: ChangeLogReader
Writer: CairoPNGWriter
failed to generate `/tmp/chl.png': divided by 0
/usr/lib/ruby/1.8/treil/reader.rb:107:in `/'
/usr/lib/ruby/1.8/treil/reader.rb:107:in `set_background_by_timestamp'
/usr/lib/ruby/1.8/treil/reader.rb:323:in `read'
/usr/bin/treil:111
0
# do ten of 'em
% export TMPIN=/tmp/chlog.log ; for f in `locate hangelog.Debian.gz |
head`; do gunzip $f $TMPIN ; treil -R ChangeLogReader $TMPIN $TMPIN.png
; echo $? ; done
{ ...output is the same as the previous example, times ten. }
...perhaps the file format of the above changelogs aren't the
kind 'treil' can use?
This is not a bug. Your usage is wrong.
ChangeLogReader (and other readers) takes directories rather than files.
i.e. it is a fallback reader in case they are not version controlled.
In any event the exit code of '0' seems inappropriate.
Perhaps.
Regards,
--
Daiki Ueno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#416775: rubygems: #!/usr/bin/env ruby in /usr/bin/gem
Package: rubygems Version: 0.9.0-6 Severity: normal On my environment, /usr/bin/gem fails as follows. $ gem /usr/bin/gem:9:in `require': no such file to load -- rubygems (LoadError) from /usr/bin/gem:9 zsh: exit 1 gem This is because /usr/bin/gem uses #!/usr/bin/env trick and I have another ruby executable installed in /usr/local/bin. I found a couple of similar bugs: #344246 and #344988 -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.20 Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Versions of packages rubygems depends on: ii libgems-ruby1.8 0.9.0-6libraries to use RubyGems, a packa ii ruby 1.8.2-1An interpreter of object-oriented rubygems recommends no packages. -- no debconf information -- Daiki Ueno -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412896: Error when trying to sign an e-mail: Problem with non-ASCII chars in passphrase
In [EMAIL PROTECTED] Reiner Steib [EMAIL PROTECTED] wrote: I have created a test gpg key and played with the passphrase, and one that triggered the error was MitPara§. MitDollar$, on the other hand, worked fine. This problem has been discussed in March 2006: http://thread.gmane.org/gmane.emacs.gnus.general/62428/focus=62441 (BTW, Frank I've Cc-ed you in this thread.) It was later discussed on emacs-devel, and I believe it was fixed. http://thread.gmane.org/gmane.emacs.gnus.general/63023/focus=63685 I don't know if the patch (which was not the right fix according to Daiki) has been applied and what would be the right fix. Should we simply document that non-ascii characters don't work / may cause problems? Perhaps pgg-passphrase-coding-system should be set correctly? (setq pgg-passphrase-coding-system 'iso-8859-1) It once had taken the default value from locale-coding-system, but Richard told me locale-coding-system should be only used for display. Regards, -- Daiki Ueno
Bug#383417: cdb_seek returns incorrect data length
Package: tinycdb
Version: 0.74-1
Tags: patch
If dlenp arg of cdb_seek point to the integer variable whose value is 0,
cdb_seek does not set dlenp correctly. This behavior is not documented
and I think it is unintended. Due to this, the dbskkd-cdb package
compiled with gcc-4.0 does not work well.
To reproduce
$ echo +3,5:one-Hello\n | cdbmake test.cdb test.cdb.tmp
$ gcc -o testcdb testcdb.c -lcdb
$ ./testcdb ./test.cdb one
dlen = 0 # - it should be 5
$ cat testcdb.c
#include stdio.h
#include string.h
#include assert.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include cdb.h
int main (int argc, char **argv)
{
int fd, ret;
const char *key;
unsigned klen, dlen = 0; // if dlen = 1, it works as expected
assert (argc == 3);
fd = open (argv[1], O_RDONLY);
if (fd == -1)
{
perror (open);
return 1;
}
key = argv[2];
klen = strlen (key);
ret = cdb_seek (fd, key, klen, dlen);
if (ret == -1)
return 1;
else if (ret == 0)
printf (not found);
else
printf (dlen = %d\n, dlen);
return 0;
}
Here is a patch to fix it
--- cdb_seek.c~ 2006-08-17 15:02:16.0 +0900
+++ cdb_seek.c 2006-08-17 15:02:43.0 +0900
@@ -75,7 +75,7 @@
/* read the key from file and compare with wanted */
unsigned l = klen, c;
const char *k = (const char*)key;
- if (*dlenp)
+ if (dlenp)
*dlenp = cdb_unpack(rbuf + 4); /* save value length */
for(;;) {
if (!l) /* the whole key read and matches, return */
Regards,
--
Daiki Ueno
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
