Bug#341674: ITP: QwikWeb -- Communication tool which integrates mail and wiki
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: QwikWeb Version : 0.7.1 Upstream Author : Kouichirou Eto 2005 at eto.com * URL : http://qwik/jp * License : GNU GPL Description : Communication tool which integrates mail and wiki QwikWeb is a web-based application tool which integrates mailing list and WikiWikiWeb. For mailing list, it uses QuickML, user friendly list which requires no administrator. Its Wiki has many useful plug-ins, such as scheduling, Post-It, map and counter. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#335564: Rebuilding fam in GCC 4.0 environment
To rebuild fam-2.7.0, I need a patch (attached) for realloc and free. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-1 Versions of packages libfam0 depends on: ii libc6 2.3.5-8.1 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-4 GCC support library ii libstdc++64.0.2-4The GNU Standard C++ Library v3 Versions of packages libfam0 recommends: ii fam 2.7.0-8File Alteration Monitor -- no debconf information 08_stdlib.patch Description: Binary data
Bug#387269: lintian: [checks/files] extra-license-file: Exception for Ruby script
Package: lintian
Version: 1.23.24
Severity: minor
There are cases where Ruby scripts generate some license text,
and the file name contains license. I encountered this
particular case when I package qwikWeb (written in Ruby).
Here is a patch.
--- lintian-1.23.24/checks/files~ 2006-09-04 06:56:29.0 +0900
+++ lintian-1.23.24/checks/files2006-09-13 18:23:44.0 +0900
@@ -502,7 +502,7 @@
# because a package had a HTML form for licenses called like that.
# Another exception is made for various picture formats since
# those are likely to just be simply pictures.
- and not $file =~
m/\.(el|c|h|py|cc|pl|pm|html|php|xpm|png|jpe?g|gif|svg)$/
+ and not $file =~
m/\.(el|c|h|py|cc|pl|pm|rb|html|php|xpm|png|jpe?g|gif|svg)$/
and not defined $link) {
tag extra-license-file, $file;
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339683: Bug forwarded
tag 339683 + wontfix thanks The upstream auther said, it's not a bug, but a feature. For use of xrdb, he recommended use of [EMAIL PROTECTED] option. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#339683: Bug forwarded
forwarded 339683 [EMAIL PROTECTED] thanks After packaging new release of 2.6.1, I have checked that this bug has not yet been fixed. So, I have forwarded this bug report again, this time in Japanese (my translation). Hopefully, it will be fixed soon. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400556: gauche: ..*** ERROR: unbound variable: slib:features
Arnt Karlsen wrote: Setting up gauche (0.8.8-1) ... *** ERROR: unbound variable: slib:features With newer slib, it uses slib:features. It used to be *features*. We need to change Gauche-0.8.8/lib/slib.scm.in. Besides, I think that the fix of Bug#388474 is wrong. Instead, we should require slib at build-time and produce slibcat at build-time (Not at installation time). There is a case where slib is not yet installed when gauche is installed. In this case, slibcat is not produced at all. Following is my proposed change. It works for me. * debian/patches/04_slib_fix.patch: New file. * debian/control (Build-Conflicts): slib removed. (Build-Depends): slib. * debian/rules: Don't make install, but make install-pkg, install-doc, and slibcat-in-place. * debian/gauche.prerm, debian/gauche.postinst: Don't touch slibcat. -- NIIBE Yutaka [EMAIL PROTECTED] Tue, 5 Dec 2006 12:00:54 +0900 diff -u gauche-0.8.8/debian/control gauche-0.8.8/debian/control --- gauche-0.8.8/debian/control +++ gauche-0.8.8/debian/control @@ -3,8 +3,7 @@ Priority: optional Maintainer: Hatta Shuzo [EMAIL PROTECTED] Uploaders: YAEGASHI Takeshi [EMAIL PROTECTED] -Build-Depends: debhelper ( 4.0.0), texinfo, libgdbm-dev, autoconf -Build-Conflicts: slib +Build-Depends: debhelper ( 4.0.0), texinfo, libgdbm-dev, autoconf, slib Standards-Version: 3.7.2.2 Package: gauche diff -u gauche-0.8.8/debian/rules gauche-0.8.8/debian/rules --- gauche-0.8.8/debian/rules +++ gauche-0.8.8/debian/rules @@ -61,7 +61,8 @@ dh_testroot dh_clean -k dh_installdirs - $(MAKE) -C build-tree install DESTDIR=$(CURDIR)/debian/tmp + $(MAKE) -C build-tree DESTDIR=$(CURDIR)/debian/tmp \ + slibcat-in-place install-pkg install-doc dh_install --sourcedir=debian/tmp cat debian/gauche-dev.install debian/gauche-gdbm.install | \ while read i; do rm -rf debian/gauche$$i; done diff -u gauche-0.8.8/debian/gauche.prerm gauche-0.8.8/debian/gauche.prerm --- gauche-0.8.8/debian/gauche.prerm +++ gauche-0.8.8/debian/gauche.prerm @@ -20,10 +20,6 @@ case $1 in remove|upgrade|deconfigure) # install-info --quiet --remove /usr/info/gauche.info.gz - SLIBCAT=`gauche-config --syslibdir`/slibcat - if [ -e $SLIBCAT ] ; then - rm -f $SLIBCAT - fi ;; failed-upgrade) ;; diff -u gauche-0.8.8/debian/gauche.postinst gauche-0.8.8/debian/gauche.postinst --- gauche-0.8.8/debian/gauche.postinst +++ gauche-0.8.8/debian/gauche.postinst @@ -25,9 +25,6 @@ case $1 in configure) - if [ -e /usr/share/slib/require.scm ]; then - /usr/bin/gosh -uslib -e (load (in-vicinity (library-vicinity) \mklibcat\)) -e (exit 0) -fi ;; only in patch2: unchanged: --- gauche-0.8.8.orig/debian/patches/04_slib_fix.patch +++ gauche-0.8.8/debian/patches/04_slib_fix.patch @@ -0,0 +1,11 @@ +--- Gauche-0.8.8.orig/lib/slib.scm.in 2005-07-12 10:01:07.0 +0900 Gauche-0.8.8/lib/slib.scm.in 2006-12-04 14:09:18.0 +0900 +@@ -115,7 +115,7 @@ + ;;; *FEATURES* should be set to a list of symbols describing features + ;;; of this implementation. Suggestions for features are: + +-(define *features* ++(define slib:features + '( + source ;can load scheme source files + ;(slib:load-source filename) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494428: gonzui: incompatible with libdb-ruby 0.6.4
Michael Schutte wrote: severity 494428 important [...] libdb-ruby has migrated, I’m thus raising the severity of this issue. Yutaka, Yasuhiro, I’ll prepare an NMU to include the patch submitted in the original message if you do not object. Please go ahead, and do NMU. Now, I am talking to one of upstream developers. While development of upstream is almost dead, I think that this change should be incorporated not only for Debian. I could not say when it will be done, but I will do my best. Regards, -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490717: gauche-c-wrapper: ldconfig isn't used anymore
Hello, After updating to Version: 0.5.4-1 of gauche-c-wrapper /usr/share/gauche/site/lib/c-wrapper/config.scm line 34 reads: (let ((ldconfig-cmd )) = ldconfig isn't used anymore. I still suggest the fix above. This is not intentional. I uploaded 0.5.4-1 before reading your bug report of #490717. I see the problem of #490717. I am going to do following: (1) Forward your bug report and fix to upstream. (2) Put a workaround in debian/rules (supplying LDCONFG variable for configure), so that the diff will be small. (3) If it will be fixed in upstream in future, we can remove the workaround of debian/rules. Regards, -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490717: Bug report forwarded to upstream
forwarded 490717 [EMAIL PROTECTED] thanks -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489844: FTBFS not fixed
reopen 489844 thanks No, sigscheme_0.8.3-3 doesn't fix FTBFS(es). -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#462492: ITP: Foreign Function Interface for Gauche to C-based libraries
retitle 462492 ITP: Foreign Function Interface for Gauche to C-based libraries owner 462492 NIIBE Yutaka [EMAIL PROTECTED] thanks I'll package it soon. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461161: samidare: newer version 0.4 is avaiable
Package: samidare Version: 0.3-1 Severity: wishlist At http://www.a-k-r.org/samidare/ we have version 0.4 now. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379016: htree 0.6 has been released
NIIBE Yutaka wrote: We have now version 0.6 at: http://www.a-k-r.org/htree/ Please update the package. If you don't have time, I would like to take over. For your reference, I have NMU version of htree 0.6 at my site: http://www.gniibe.org/oitoite/debian/20080117/ I would like to take over maintainer-ship in a year or so, if you won't have any activity any more. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#461663: ITP: ngetty -- one single daemon for all consoles
retitle 461663 ITP: ngetty -- one single daemon for all consoles owner 461663 NIIBE Yutaka [EMAIL PROTECTED] thanks I'll package it in a week or so. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#411710: ITP: libqrencode -- A C library for encoding data in a QR Code symbol
retitle 411710 ITP: libqrencode -- A C library for encoding data in a QR Code symbol owner 411710 NIIBE Yutaka [EMAIL PROTECTED] thanks I will package it in a month or so. If not, please do it. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463666: ITP: tomoe -- Tomoe - A handwriting recognition engine
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: tomoe Version : 0.6.0 Upstream Author : Takuro Ashie [EMAIL PROTECTED] HIGUCHI Daisuke [EMAIL PROTECTED] Juernjakob Harder [EMAIL PROTECTED] Hiroyuki Ikezoe [EMAIL PROTECTED] * URL : http://tomoe.sourceforge.jp/cgi-bin/en/blog/index.rb * License : GPL and LGPL Programming Lang: C Description : Tomoe - Tegaki Online MOji recognition Engine - is a software which provides a handwriting recognition engine and its user interface on open source desktop environment. Here, Tegaki means Handwriting and Moji means Letter in Japanese. It consists of following modules: Handwriting recognition engine library User interface widget library for handwriting recognition uim module SCIM module -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415218: treil wanna call an undefined method
Hi there, Sorry for not responding to your bug report earlier. Daniel Roschka wrote: Package: treil Version: 0.1-2 Severity: important Whenever I try to use treil to make an image of my homedir, I get the following error message: [EMAIL PROTECTED]:~$ treil -o test.png /home/foo du: Value too large for defined data type /usr/bin/treil-draw:38:in `initialize': undefined method `width' for nil:NilClass (NoMethodError) from /usr/bin/treil-draw:207:in `new' from /usr/bin/treil-draw:207 I dunno why this happens, first I thought that the reason could be the number of files, but /usr/src/linux works and should contain even more files. I hope there will be a fix in the near future. :-) I have tracked down this problem. I think that the error is from file system, that is, some of your files are very large to be represented by 32-bit size. Part of the problem has been fixed in newer version, because treil no longer access file system by fts_open/etc. by itself, but uses Ruby's opendir/etc. However, I think that treil still has problem for too big file. It is reported by #459855, which is not yet fixed. Fix is not that difficult and I am discussing upstream right now. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444704: ITA: ttyrec -- A tty recorder
retitle 444704 ITA: ttyrec -- A tty recorder thanks I adopt this package. I have sent two fixes for this package and frustrated that the previous maintainer was not responsible. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452026: (no subject)
retitle 452026 ITA: golly -- Game of Life simulator using hashlife algorithm thanks I will do the packaging soon. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#311834: ITP: kahua -- Web application framework written in Gauche, a Scheme interpreter
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: kahua Version : 0.3.2 Upstream Author : Nobuo Yamashita [EMAIL PROTECTED] * URL : http://www.kahua.org/ * License : BSD Description : Web application framework written in Gauche, a Scheme interpreter Kahua is a web application framework based on S-expression and continuation. It has features of content management system, session management, and object database. It is fully extensible by Scheme. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295877: gauche-gtk: FTBFS: /bin/sh: m: command not found
Your package is failing to build on all arches. Here is an extract from the build log: cd src; /usr/bin/make install make[2]: Entering directory `/build/buildd/gauche-gtk-0.4.1/src' m 444 -T /build/buildd/gauche-gtk-0.4.1/debian/gauche-gtk`/usr/bin/gauche- config --sysincdir` /bin/sh: m: command not found make[2]: [install] Error 127 (ignored) Thanks for the report. It is because gauche-gtk has build dependency to gauche (= 0.8.3). I forgot to add the build dependency in debian/control file, and newer gauche has not yet been uploaded (for unknown reason for me). I've asked one of gauche maintainers (Takeshi YAEGASHI) to upload new gauche-gtk package again (with correct buld dependency) after newer gauche upload. So, once newer gauche will be available on buildd, this failure will be solved. Just FYI, newer gauche is available at: deb http://people.debian.org/~yaegashi/gauche/sid ./ deb-src http://people.debian.org/~yaegashi/gauche/sid ./ -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#280884: Update: M32R support
Here is update against Version: 2.15-5.
With help of Hirokazu Takata, we now have four patches for M32R.
I've updated 123_m32r_gotoff.dpatch to fix a bug which introduced
in original 123_m32r_gotoff.dpatch.
I've updated the patch of debian/rules, to fix a bug which
introduced by the patch sent the other day (NEWS and README.Debian).
* debian/patches/126_m32r_support_no_bitinst.dpatch: New file.
* debian/patches/125_m32r_fix_infinite_loop.dpatch: New file.
* debian/patches/124_pcrel.dpatch: New file.
* debian/patches/123_m32r_gotoff.dpatch: New file.
* debian/rules (configure-multi-stamp): Support m32r-linux.
* debian/rules: Run 'make check' only if build == host.
--- binutils-2.15/debian/patches/00list
+++ binutils-2.15/debian/patches/00list
@@ -17,0 +18,5 @@
+123_m32r_gotoff
+124_m32r_pcrel
+125_m32r_fix_infinite_loop
+126_m32r_support_no_bitinst
+127_config_update
--- binutils-2.15/debian/rules
+++ binutils-2.15/debian/rules
@@ -89,7 +89,9 @@
$(checkdir)
-rm -fr builddir-multi builddir-single builddir-hppa64
-find . -name \*.gmo -o -name \*~ | xargs rm -f
+ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
-rm -f $(pwd)/test-summary
+endif
-rm -fr $(d_bin) $(d_dev) $(d_mul) $(d_doc) $(d_hppa64)
-rm -rf debian/patched debian/tmp debian/files debian/substvars
-rm -f gas/doc/as.info
@@ -115,11 +117,13 @@
$(MAKE) -C builddir-single/bfd headers
$(MAKE) -C builddir-single \
CFLAGS=$(CFLAGS)
+ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
-$(MAKE) -C builddir-single -k \
CFLAGS=$(CFLAGS) check
cat builddir-single/binutils/binutils.sum \
builddir-single/gas/testsuite/gas.sum \
builddir-single/ld/ld.sum $(pwd)/test-summary
+endif
touch build-single-stamp
@@ -135,7 +139,7 @@
mkdir builddir-multi
cd builddir-multi \
env CC=$(CC) ../configure $(CONFARGS) \
-
--enable-targets=alpha-linux,arm-linux,hppa-linux,i386-gnu,i386-linux,ia64-linux,m68k-linux,m68k-rtems,mips-linux,mipsel-linux,mips64-linux,mips64el-linux,powerpc-linux,powerpc64-linux,s390-linux,s390x-linux,sh-linux,sparc-linux,sparc64-linux,x86_64-linux
+
--enable-targets=alpha-linux,arm-linux,hppa-linux,i386-gnu,i386-linux,ia64-linux,m68k-linux,m68k-rtems,mips-linux,mipsel-linux,mips64-linux,mips64el-linux,powerpc-linux,powerpc64-linux,s390-linux,s390x-linux,sh-linux,sparc-linux,sparc64-linux,x86_64-linux,m32r-linux
$(MAKE) -C builddir-multi configure-host
touch configure-multi-stamp
@@ -376,8 +380,11 @@
ln -sf $(p_bin) $(d_hppa64)/usr/share/doc/$(p_hppa64)
endif
- $(install_file) $(pwd)/test-summary binutils/NEWS \
- debian/README.Debian $(d_bin)/usr/share/doc/$(p_bin)/
+ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE))
+ $(install_file) $(pwd)/test-summary $(d_bin)/usr/share/doc/$(p_bin)/
+endif
+ $(install_file) binutils/NEWS debian/README.Debian \
+ $(d_bin)/usr/share/doc/$(p_bin)/
$(install_file) binutils/ChangeLog
$(d_bin)/usr/share/doc/$(p_bin)/changelog
--- binutils-2.15.orig/debian/patches/123_m32r_gotoff.dpatch
+++ binutils-2.15/debian/patches/123_m32r_gotoff.dpatch
@@ -0,0 +1,667 @@
+#!/bin/sh -e
+## 123_m32r_gotoff.dpatch
+##
+## All lines beginning with `## DP:' are a description of the patch.
+## DP: Description: Identify this version of binutils as being from Debian.
+## DP: Author: Kazuhiro Inaoka [EMAIL PROTECTED]
+## DP: Upstream status: included
+## DP: Date: 2004-06-25
+
+if [ $# -ne 1 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+
+patch_opts=${patch_opts:--f --no-backup-if-mismatch}
+
+case $1 in
+ -patch) patch $patch_opts -p1 $0;;
+ -unpatch) patch $patch_opts -p1 -R $0;;
+*)
+echo 2 `basename $0`: script expects -patch|-unpatch as
argument
+exit 1;;
+esac
+
+exit 0
+
[EMAIL PROTECTED]@
+
+--- binutils-2.15/gas/config/tc-m32r.c 2004-06-09 15:45:26.0 +0900
binutils-040909/gas/config/tc-m32r.c 2004-06-26 01:11:09.0
+0900
+@@ -489,6 +489,69 @@
+ { NULL, NULL, 0 }
+ };
+
++#define GOT_NAME _GLOBAL_OFFSET_TABLE_
++symbolS * GOT_symbol;
++
++static inline int
++m32r_PIC_related_p (symbolS *sym)
++{
++ expressionS *exp;
++
++ if (! sym)
++return 0;
++
++ if (sym == GOT_symbol)
++return 1;
++
++ exp = symbol_get_value_expression (sym);
++
++ return (exp-X_op == O_PIC_reloc
++ || exp-X_md == BFD_RELOC_M32R_26_PLTREL
++ || m32r_PIC_related_p (exp-X_add_symbol)
++ || m32r_PIC_related_p (exp-X_op_symbol));
++}
++
++static inline int
++m32r_check_fixup (expressionS *main_exp, bfd_reloc_code_real_type *r_type_p)
++{
++ expressionS *exp = main_exp;
++
++ if
Bug#297080: gauche-gl: Gauche-gl in testing installs for different version than others / gauche
On Sun, 27 Feb 2005 00:50:36 +0200 Harri Haataja [EMAIL PROTECTED] wrote: All other packages seem to fill 0.7.4.2, but gauche-gl uses 0.8.3. I suppose this is some kind of an api version mixup in the builds. I'm afraid I can't figure out what, if anything, README.Debian is saying about this. Any way, it would be nice to be able to load the extension like the docs say. Or at least have this and a workaround explained in the docs. Sorry for your inconvenience. Let me explain the sisutation. YAEGASHI Takeshi has tried to upload newer gauche 0.8.3, and we talked that the impact will be minimum when we upload together newer gauche and packages which depends on gauche at the same time. I built gauche-gl and gauche-gtk with newer gauche (0.8.3), and asked Takeshi to upload them. However, with new upload policy, newer gauche has put into new queue because of the change of packaging (split to -dbm, -dev, and -doc packages), while only gauche-gtk and gauche-gl went normally. So, we intended less impact, but in fact, caused the mess. I should have waited the newer gauche upload, and I should have specified build dependency and/or dependency to newer gauche. I wish the newer gauche will be available soon. Then, this bug will be closed. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295877: gauche-gtk: FTBFS: /bin/sh: m: command not found
On Mon, 07 Mar 2005 04:49:33 +0200 Lars Wirzenius [EMAIL PROTECTED] wrote: With regard to bug #295877: gauche-gtk is missing versioned build dependencies on gauche-dev (= 0.8.3-1) and possibly on gauche (= 0.8.3-1). gauche has been split into several packages and is waiting for NEW package processing (see http://ftp-master.debian.org/new.html). I've verified that those two packages are sufficient to get gauche-gtk to build (but since I don't know the package, I can't test they work). gauche-gtk's control file must be updated to add those build dependencies, and a new package uploaded. Preferably this should be done, I think, before gauche gets out from the NEW queue so that buildds can rebuild gauche-gtk as soon as things are ready. Thanks for your suggestion. Adding the dependency of gauche-dev (= 0.8.3-1), I've prepared gauche-gtk and gauche-gl at: http://www.gniibe.org/oitoite/debian/20050307/ Dependency to gauche-dev is enough, as gauche-dev depends on gauche. This message is Cc:-ed to my sponsor, Takeshi Yaegashi. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422048: GPL Cver 2.11a Multi-dimensional arrays.
Ahmed El-Mahmoudy wrote: Package: gplcver Version: 2.11a-3 Hello, I was trying GPL Cver 2.11a on a verilog module that has multi-dimensional arrays (the module is attached with this email), and it gave the error below: I think that multi-dimensional arrays is not the supported feature of current GPL Cver. This is new feature of Verilog 2001 standard, while GPL Cver supports Verilog 1995 and some of Verilog 2001. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#444108: ITP: verilog-mode -- Emacs mode for editing Verilog HDL
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: verilog-mode Version : 357 Upstream Author : Michael McNamara [EMAIL PROTECTED] * URL : http://www.verilog.com * License : GPL Programming Lang: Emacs Lisp Description : Emacs mode for editing Verilog HDL The emacs major mode for editing code of Verilog HDL. Supports syntax highlighting, automatic indentation. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#437859: The cause of this bug -- BSD pty
I think that the cause of this bug is the use of BSD pty. Currently in debian/rules, ttyrec is compiled for BSD standard (deprecated, I think). I think following patch should apply for Debian build. -- --- rules.orig 2007-08-25 16:16:16.0 +0900 +++ rules 2007-08-25 16:04:24.0 +0900 @@ -19,7 +19,7 @@ build-stamp: dh_testdir - $(MAKE) + $(MAKE) CFLAGS=-O2 -Wall -DSVR4 uudecode debian/sample1.tty.uue -- Then, it works for UNIX98 pty standard. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379016: htree 0.6 has been released
We have now version 0.6 at: http://www.a-k-r.org/htree/ Please update the package. If you don't have time, I would like to take over. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409154: What is the status on libapache2-mod-auth-openid for debian?
Daniel Kahn Gillmor wrote: I see that in february, this ITP for libapache2-mod-auth-openid was claimed to be fixed by a package in the NEW queue, but now (nearly 6 months later) nothing has even shown up in unstable or experimental. What's the status on this package? I once built the package and uploaded. But we found license problem. This software is licensed under GPL, and it depends on OpenSSL library, which is incompatible to GPL. If we could consider OpenSSL is system library, it can be distributed. I will contact about this issue to the author. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409154: What is the status on libapache2-mod-auth-openid for debian?
Just a quick replay, Daniel Kahn Gillmor wrote: Would you mind publishing your packaging details? I'd be willing to try to switch TLS implementations if that's a possiblity. i'd very much like to see this functionality be easily accessible in debian. Here it is: http://www.gniibe.org/oitoite/libapache-mod-auth-openid/ That's for your reference. I think that distribution of this diff is OK, and people can build the binary package by themselves. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#282913: cross build
configure complains bitterly that using --host is the wrong way to do cross-compilation, and that it will automatically detect an attempt at cross-compilation. Err... I see. The configure warns when we specify --host for native build. We need to handle native build case. It's not true that it will automatically detect cross compilation. When we don't specify --host for cross compilation (just specify CC variable), it compilains: checking whether the C compiler works... configure: error: cannot run C compiled programs. If you meant to cross compile, use `--host'. Well, specifying --host itself is right way. But yes, there are many misunderstandings in the past between --host and --build. Configure warns when --host is specified on native build. I think that we can ignore this warning. Specifying --build along with --host can kill this warning. Following change works both of native and cross build. Note: There are three things: host, build, and target. HOST: The machine where the executable will run. BUILD: The machine where the executable is about to be built. TARGET: The machine where the executable will target. (Only valid for development tool, such as compiler, assembler, linker.) diff -u popt-1.10/debian/rules popt-1.10/debian/rules --- popt-1.10/debian/rules +++ popt-1.10/debian/rules @@ -6,6 +6,7 @@ #export DH_VERBOSE=1 DEB_HOST_GNU_TYPE := $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +DEB_BUILD_GNU_TYPE := $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) # shared library versions, option 1 source = $(shell grep ^Source: debian/control|head -1|sed 's/Source: \(.*\)/\1/g') @@ -49,8 +50,8 @@ ln mkinstalldirs $(objdir) # Add here commands to configure the package. cd $(objdir) \ - ../configure --prefix=/usr --mandir=/usr/share/man --enable-shared - # --host=$(DEB_HOST_GNU_TYPE) + ../configure --prefix=/usr --mandir=/usr/share/man --enable-shared \ + --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) touch $@ configure-udeb-stamp: @@ -64,8 +65,8 @@ ln mkinstalldirs $(objdir_udeb) # Add here commands to configure the package. cd $(objdir_udeb) \ - ../configure --prefix=/usr --mandir=/usr/share/man --enable-shared - # --host=$(DEB_HOST_GNU_TYPE) + ../configure --prefix=/usr --mandir=/usr/share/man --enable-shared \ + --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) touch $@ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405921: NMU uploaded
Andreas Barth wrote: I uploaded an NMU of your package. Please see this as help to get the package into a releaseable condition for etch. Please find the used diff below. Thank you for your help. But... For the record, let me explain the situation. There are two different code bases: 1.2: etch (testing) 1.2+cvs20061228: unstable The bug #405921 is in 1.2+cvs20061228 (unstable), but not in 1.2. -Build-Depends: debhelper (= 4.0.0), ruby, ruby1.8-dev (= 1.8.1), libdb4.2-ruby1.8, libzlib-ruby1.8, libwebrick-ruby1.8, libiconv-ruby1.8, libstrscan-ruby1.8 +Build-Depends: debhelper (= 4.0.0), ruby, ruby1.8-dev (= 1.8.1), libdb4.2-ruby1.8, libzlib-ruby1.8, libwebrick-ruby1.8, libiconv-ruby1.8, libstrscan-ruby1.8, ruby, flex 1.2-1 is fine for testing. In version 1.2, its Build-Depends is correct. It includes ruby, and its build doesn't require flex. Please check the autobuilder log of 1.2-1. It's fine for all eleven architectures. http://buildd.debian.org/build.php?pkg=gonzui For 1.2+cvs20061228, it was fixed before your non maintainer upload. I think that you did it at the same time. So, 1.2-1.1 for testing is not needed. It does no harm, so, it's OK etch has 1.2-1.1. Thanks for your cooperation, -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406156: ITP: libescape-ruby -- HTML/URI/shell escaping utilities for Ruby
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: libescape-ruby Version : 0.1 Upstream Author : Tanaka Akira [EMAIL PROTECTED] * URL : http://www.a-k-r.org/escape/ * License : BSD Programming Lang: Ruby Description : HTML/URI/shell escaping utilities for Ruby For Ruby programmers, this utility named 'escape' provides several escaping functions for HTML/URI/shell. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406158: ITP: wfo -- wfo
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: wfo Version : 0.1 Upstream Author : Tanaka Akira [EMAIL PROTECTED] * URL : http://www.a-k-r.org/wfo/ * License : GPL Programming Lang: Ruby Description : wfo wfo is a offline frontend for wikis and blogs. You can checkout a wiki page to a local file, edit the file, and commit to the page. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379016: Please update htree
Kitame-san, Could you please update htree package? I'm about to package a utility named 'wfo', and it requires newer version of htree. If you don't have time, could you please consider to add me as co-maintainer of htree? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406159: ITP: treil -- tree structure into tile
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: treil Version : 0.1 Upstream Author : Daiki Ueno [EMAIL PROTECTED] * URL : http://www.unixuser.org/~ueno/software/treil/ * License : GPL Programming Lang: Ruby Description : tree structure into tile Treil is a utility which produces an image of tiles from tree structure. For example, Linux directory tree can be shown as an image of tiles, by: $ treil -o linux.png /usr/src/linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406164: samidare: New version is available in upstream
Package: samidare Version: 0.0.20040611-2 Severity: wishlist At upstream, we have new version available with tag: samidare-0_3 Could you please update? If you don't have time, please consider to add me as co-maintainer. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379016: Please update htree
Specifically, we have now version 0.5 at: http://www.a-k-r.org/htree/ Please update the package. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404539: ITP: glrr -- Utility functions for glib, gobject, and gtk+ of Grift
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: glrr Version : 20050529 Upstream Author : AOSASA Shigeru [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/grift/ * License : BSD Programming Lang: C Description : Utility functions for glib, gobject, and gtk+ of Grift Grift is a library that provides a framework for developing a UI-independent application. This libraries are needed for g-inspector, GTK+ debugging tool. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404541: ITP: glrr-widgets -- Miscellaneous gtk+ widgets for Grift
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: glrr-widgets Version : 20050529 Upstream Author : AOSASA Shigeru [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/grift/ * License : BSD Programming Lang: C Description : Miscellaneous gtk+ widgets for Grift Grift is a library that provides a framework for developing a UI-independent application. This libraries are needed for g-inspector, GTK+ debugging tool. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404549: ITP: ginspector -- GTK+ inspect tool for debugging
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: ginspector Version : 20050529 Upstream Author : AOSASA Shigeru [EMAIL PROTECTED] * URL : http://sourceforge.net/projects/g-inspector/ * License : BSD Programming Lang: C Description : GTK+ inspect tool for debugging G-Inspector inspects running GTK+ application and its objects, shows object hierarchy and how windows are constructed. It handles Glib objects too. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404628: ITP: gplcver -- Verilog Simulator
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: gplcver Version : 2.11a Upstream Author : Pragmatic C Software Corp. [EMAIL PROTECTED] * URL : http://www.pragmatic-c.com/gpl-cver * License : GPL Programming Lang: C Description : Verilog Simulator Cver is a full 1995 IEEE P1364 standard Verilog simulator. It also implements some of the 2001 P1364 standard features. All three PLI interfaces (tf_, acc_, and vpi_) are implemented as defined in the IEEE 2001 P1364 LRM. GPL Cver is an older version of Cver that is released under the GNU General Public License. A newer and faster commercial version of Cver is available from Pragmatic C Software Corp. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404665: gtkwave: Wave help dialog display and clicking logfile viewer
Package: gtkwave
Version: 1.3.81-1
Severity: normal
Tags: patch
Since gtkwave uses GtkText widget (I think it's obsolete), and it
emits warnings like:
(gtkwave:30510): Gdk-CRITICAL **: gdk_text_width: assertion `font !=
NULL' failed
It's not just warnings. The display of Wave help dialog and
clicking on logfile viewer don't work well.
Here is a patch to kill these warnings and fix problems. It enables
us to compile gtkwave without -DGTK_ENABLE_BROKEN.
The changes consist of Debian independent part and Debian specific
part.
Independent part are changes of help.c, status.c, and logfile.c, which
replaces uses of GtkText widget by ones of GtkTextView widget.
Specific part is new Makefile_GTK2_new.in without -DGTK_ENABLE_BROKEN,
and change of debian/rules wich uses Makefile_GTK2_new.in.
I put these changes of mine into public domain.
--- gtkwave-1.3.81.orig/src/help.c
+++ gtkwave-1.3.81/src/help.c
@@ -22,14 +22,28 @@
static GtkWidget *text;
static GtkWidget *vscrollbar;
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+static GtkTextIter iter;
+static GtkTextTag *bold_tag;
+#endif
+
void help_text(char *str)
{
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+gtk_text_buffer_insert (GTK_TEXT_VIEW (text)-buffer, iter, str, -1);
+#else
gtk_text_insert (GTK_TEXT (text), NULL, text-style-black, NULL, str, -1);
+#endif
}
void help_text_bold(char *str)
{
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+gtk_text_buffer_insert_with_tags (GTK_TEXT_VIEW (text)-buffer, iter,
+ str, -1, bold_tag, NULL);
+#else
gtk_text_insert (GTK_TEXT (text), NULL, text-style-fg[GTK_STATE_SELECTED],
text-style-bg[GTK_STATE_SELECTED], str, -1);
+#endif
}
static void
@@ -50,7 +64,14 @@
/* Put a text widget in the upper left hand corner. Note the use of
* GTK_SHRINK in the y direction */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+text = gtk_text_view_new ();
+gtk_text_buffer_get_start_iter (gtk_text_view_get_buffer(GTK_TEXT_VIEW
(text)), iter);
+bold_tag = gtk_text_buffer_create_tag (GTK_TEXT_VIEW (text)-buffer, bold,
+ weight, PANGO_WEIGHT_BOLD, NULL);
+#else
text = gtk_text_new (NULL, NULL);
+#endif
gtk_table_attach (GTK_TABLE (table), text, 0, 14, 0, 1,
GTK_FILL | GTK_EXPAND,
GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
@@ -58,7 +79,11 @@
gtk_widget_show (text);
/* And a VScrollbar in the upper right */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+vscrollbar = gtk_vscrollbar_new (GTK_TEXT_VIEW (text)-vadjustment);
+#else
vscrollbar = gtk_vscrollbar_new (GTK_TEXT (text)-vadj);
+#endif
gtk_table_attach (GTK_TABLE (table), vscrollbar, 15, 16, 0, 1,
GTK_FILL, GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
gtk_widget_show (vscrollbar);
@@ -67,7 +92,11 @@
gtk_signal_connect (GTK_OBJECT (text), realize,
GTK_SIGNAL_FUNC (help_realize_text), NULL);
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+gtk_text_view_set_wrap_mode(GTK_TEXT_VIEW(text), GTK_WRAP_WORD);
+#else
gtk_text_set_word_wrap(GTK_TEXT(text), TRUE);
+#endif
return(table);
}
--- gtkwave-1.3.81.orig/src/status.c
+++ gtkwave-1.3.81/src/status.c
@@ -20,11 +20,20 @@
static GtkWidget *text=NULL;
static GtkWidget *vscrollbar;
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+static GtkTextIter iter;
+static GtkTextTag *bold_tag;
+#endif
+
void status_text(char *str)
{
if(text)
{
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+ gtk_text_buffer_insert (GTK_TEXT_VIEW (text)-buffer, iter, str, -1);
+#else
gtk_text_insert (GTK_TEXT (text), NULL, text-style-black, NULL, str,
-1);
+#endif
}
else
{
@@ -95,7 +104,14 @@
/* Put a text widget in the upper left hand corner. Note the use of
* GTK_SHRINK in the y direction */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+text = gtk_text_view_new ();
+gtk_text_buffer_get_start_iter (gtk_text_view_get_buffer(GTK_TEXT_VIEW
(text)), iter);
+bold_tag = gtk_text_buffer_create_tag (GTK_TEXT_VIEW (text)-buffer, bold,
+ weight, PANGO_WEIGHT_BOLD, NULL);
+#else
text = gtk_text_new (NULL, NULL);
+#endif
gtk_table_attach (GTK_TABLE (table), text, 0, 14, 0, 1,
GTK_FILL | GTK_EXPAND,
GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
@@ -103,7 +119,11 @@
gtk_widget_show (text);
/* And a VScrollbar in the upper right */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+vscrollbar = gtk_vscrollbar_new (GTK_TEXT_VIEW (text)-vadjustment);
+#else
vscrollbar = gtk_vscrollbar_new ((GTK_TEXT (text))-vadj);
+#endif
gtk_table_attach (GTK_TABLE (table), vscrollbar, 15, 16, 0, 1,
GTK_FILL, GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
gtk_widget_show (vscrollbar);
---
Bug#404741: gtkwave: New upstream version available
Package: gtkwave Version: 1.3.81-1 Severity: wishlist At http://home.nc.rr.com/gtkwave/, version 3.0.18 is available. The feature I like is that Signal Search Tree is on main window. Thanks, -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404665: Acknowledgement (gtkwave: Wave help dialog display and clicking logfile viewer)
The upstream maintainer, Anthony J Bybell [EMAIL PROTECTED], kindly
pointed out my fix is not enough for vadjustment.
Here, I attach updated patch. I put it into public domain.
--- gtkwave-1.3.81.orig/src/help.c
+++ gtkwave-1.3.81/src/help.c
@@ -22,14 +22,28 @@
static GtkWidget *text;
static GtkWidget *vscrollbar;
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+static GtkTextIter iter;
+static GtkTextTag *bold_tag;
+#endif
+
void help_text(char *str)
{
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+gtk_text_buffer_insert (GTK_TEXT_VIEW (text)-buffer, iter, str, -1);
+#else
gtk_text_insert (GTK_TEXT (text), NULL, text-style-black, NULL, str, -1);
+#endif
}
void help_text_bold(char *str)
{
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+gtk_text_buffer_insert_with_tags (GTK_TEXT_VIEW (text)-buffer, iter,
+ str, -1, bold_tag, NULL);
+#else
gtk_text_insert (GTK_TEXT (text), NULL, text-style-fg[GTK_STATE_SELECTED], text-style-bg[GTK_STATE_SELECTED], str, -1);
+#endif
}
static void
@@ -50,7 +64,14 @@
/* Put a text widget in the upper left hand corner. Note the use of
* GTK_SHRINK in the y direction */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+text = gtk_text_view_new ();
+gtk_text_buffer_get_start_iter (gtk_text_view_get_buffer(GTK_TEXT_VIEW (text)), iter);
+bold_tag = gtk_text_buffer_create_tag (GTK_TEXT_VIEW (text)-buffer, bold,
+ weight, PANGO_WEIGHT_BOLD, NULL);
+#else
text = gtk_text_new (NULL, NULL);
+#endif
gtk_table_attach (GTK_TABLE (table), text, 0, 14, 0, 1,
GTK_FILL | GTK_EXPAND,
GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
@@ -58,7 +79,14 @@
gtk_widget_show (text);
/* And a VScrollbar in the upper right */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+GtkTextViewClass *tc = (GtkTextViewClass *)GTK_OBJECT_GET_CLASS(GTK_OBJECT(text));
+
+tc-set_scroll_adjustments(GTK_TEXT_VIEW (text), NULL, NULL);
+vscrollbar = gtk_vscrollbar_new (GTK_TEXT_VIEW (text)-vadjustment);
+#else
vscrollbar = gtk_vscrollbar_new (GTK_TEXT (text)-vadj);
+#endif
gtk_table_attach (GTK_TABLE (table), vscrollbar, 15, 16, 0, 1,
GTK_FILL, GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
gtk_widget_show (vscrollbar);
@@ -67,7 +95,11 @@
gtk_signal_connect (GTK_OBJECT (text), realize,
GTK_SIGNAL_FUNC (help_realize_text), NULL);
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+gtk_text_view_set_wrap_mode(GTK_TEXT_VIEW(text), GTK_WRAP_WORD);
+#else
gtk_text_set_word_wrap(GTK_TEXT(text), TRUE);
+#endif
return(table);
}
--- gtkwave-1.3.81.orig/src/status.c
+++ gtkwave-1.3.81/src/status.c
@@ -20,11 +20,20 @@
static GtkWidget *text=NULL;
static GtkWidget *vscrollbar;
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+static GtkTextIter iter;
+static GtkTextTag *bold_tag;
+#endif
+
void status_text(char *str)
{
if(text)
{
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+ gtk_text_buffer_insert (GTK_TEXT_VIEW (text)-buffer, iter, str, -1);
+#else
gtk_text_insert (GTK_TEXT (text), NULL, text-style-black, NULL, str, -1);
+#endif
}
else
{
@@ -95,7 +104,14 @@
/* Put a text widget in the upper left hand corner. Note the use of
* GTK_SHRINK in the y direction */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+text = gtk_text_view_new ();
+gtk_text_buffer_get_start_iter (gtk_text_view_get_buffer(GTK_TEXT_VIEW (text)), iter);
+bold_tag = gtk_text_buffer_create_tag (GTK_TEXT_VIEW (text)-buffer, bold,
+ weight, PANGO_WEIGHT_BOLD, NULL);
+#else
text = gtk_text_new (NULL, NULL);
+#endif
gtk_table_attach (GTK_TABLE (table), text, 0, 14, 0, 1,
GTK_FILL | GTK_EXPAND,
GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
@@ -103,7 +119,14 @@
gtk_widget_show (text);
/* And a VScrollbar in the upper right */
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+GtkTextViewClass *tc = (GtkTextViewClass *)GTK_OBJECT_GET_CLASS(GTK_OBJECT(text));
+
+tc-set_scroll_adjustments(GTK_TEXT_VIEW (text), NULL, NULL);
+vscrollbar = gtk_vscrollbar_new (GTK_TEXT_VIEW (text)-vadjustment);
+#else
vscrollbar = gtk_vscrollbar_new ((GTK_TEXT (text))-vadj);
+#endif
gtk_table_attach (GTK_TABLE (table), vscrollbar, 15, 16, 0, 1,
GTK_FILL, GTK_FILL | GTK_SHRINK | GTK_EXPAND, 0, 0);
gtk_widget_show (vscrollbar);
--- gtkwave-1.3.81.orig/src/logfile.c
+++ gtkwave-1.3.81/src/logfile.c
@@ -30,14 +30,28 @@
static GdkFont *font = NULL;
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+static GtkTextIter iter;
+static GtkTextTag *bold_tag;
+#endif
+
void log_text(GtkWidget *text, GdkFont *font, char *str)
{
+#if defined(WAVE_USE_GTK2) !defined(GTK_ENABLE_BROKEN)
+gtk_text_buffer_insert (GTK_TEXT_VIEW (text)-buffer, iter, str, -1);
+#else
gtk_text_insert (GTK_TEXT (text), font, text-style-black, NULL, str, -1);
+#endif
}
void log_text_bold(GtkWidget *text, GdkFont *font, char *str)
{
+#if defined(WAVE_USE_GTK2)
Bug#404768: ITP: liblangscan-ruby -- Ruby module for scanners for programming languages
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: liblangscan-ruby Version : 1.2+cvs20061228 Upstream Author : Kenichi Ishibashi bashi at dream.ie.ariake-nct.ac.jp * URL : http://gonzui.sourceforge.net/ * License : GPL Programming Lang: Ruby Description : Ruby module for scanners for programming languages LangScan is a set of scanners. It supports following languages: C, C++, C#, CSS, D, Eiffel, Emacs Lisp, Java, Javascript, Lua, OCaml, Perl, PHP, Python, Ruby, Scheme, Bourne Shell, and others. LangScan is used by source code search engine Gonzui. The package 'gonzui' offered this module once, but it's now different module. Thus, ITP. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404230: gauche-gl: crash in finalizers
Jens Thiele (karme) wrote: I think the finalizers of the glu objects (nurbs, quadric, tesselator) are wrong: Thanks. It's confirmed and forwarded. Original Message Subject: Re: [Gauche-devel] [Fwd: Bug#404230: gauche-gl: crash in finalizers] Date: Fri, 22 Dec 2006 20:18:26 -1000 (HST) From: Shiro Kawai [EMAIL PROTECTED] Reply-To: Discussion about Gauche development [EMAIL PROTECTED] To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] Thank you. This part of code is actually very old (we no longer call GC_REGISTER_FINALIZER directly). I'll update this part for the next gauche-gl release. --shiro From: NIIBE Yutaka [EMAIL PROTECTED] Subject: [Gauche-devel] [Fwd: Bug#404230: gauche-gl: crash in finalizers] Date: Sat, 23 Dec 2006 13:40:17 +0900 Here is a bug report for gauche-gl 0.4.2. It can be reproduced on Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#404782: ITP: libwebapp-ruby -- easy-to-use CGI/FastCGI/mod_ruby/WEBrick interface
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: libwebapp-ruby Version : 0.0.20061228 Upstream Author : Tanaka Akira [EMAIL PROTECTED] * URL : http://cvs.m17n.org/~akr/webapp/ * License : BSD Programming Lang: Ruby Description : easy-to-use CGI/FastCGI/mod_ruby/WEBrick interface Webapp is a library to ease web application development in Ruby. It has very easy-to-use API, and you can debug web application as usual command (CLI). Features include: path_info aware relative URI generation automatic Content-Type generation HTML form parameter validation by HTML form -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#379016: Please update htree
severity 379016 important thanks NIIBE Yutaka wrote: Specifically, we have now version 0.5 at: http://www.a-k-r.org/htree/ Please update the package. I have a package named wfo (in new queue) which depends on new htree: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406158 So, this bug is important now. I will need to do NMU upload of htree when wfo will be in Debian. Don't you mind? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409154: ITP: libapache2-mod-auth-openid -- OpenID authentication module for Apache2
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: libapache2-mod-auth-openid Version : 0.0 Upstream Author : bmuller [EMAIL PROTECTED] * URL : http://www.butterfat.net/wiki/Projects/ModAuthOpenID * License : GPL Programming Lang: C++ Description : OpenID authentication module for Apache2 mod_auth_openid is an authentication module for Apache2. It handles the functions of an OpenID consumer as specified in the OpenID 1.1 specification. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#409160: ITP: libopkele -- OpenID support library
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: libopkele Version : 0.1.1 Upstream Author : Klever Group (http://www.klever.net/) * URL : http://kin.klever.net/libopkele/ * License : MIT Programming Lang: C++ Description : OpenID support library libopkele is a c++ implementation of an OpenID decentralized identity system. It provides OpenID protocol handling, leaving authentication and user interaction to the implementor. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428130: LOAD_PATH
I think that the problem is modifying the variable LOAD_PATH (in treil.rb). When ruby tries to load cairo.rb, it loads cairo.so, that's the issue. Commenting out that line, it works fine for me. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329739: linux-2.6: M32R support
Package: linux-2.6 Severity: wishlist Tags: patch Could you please include following changes in the next release? I've just joined the debian-kernel mailing list, and I learned recent direction of debian-kernel. If I understand correctly, linux-2.6 is the source package of all images (and source) for Linux kernel. With this patch, M32R kernel will be able to be built well. Thanks, -- NIIBE Yutaka, at University of Oldenburg this week * debian/arch/defines, debian/arch/m32r/*: Added M32R support. -- NIIBE Yutaka [EMAIL PROTECTED] Fri, 23 Sep 2005 13:54:21 +0900 --- linux-2.6-2.6.12/debian/arch/defines +++ linux-2.6-2.6.12/debian/arch/defines @@ -13,6 +13,7 @@ powerpc s390 sparc + m32r [alpha] #enabled: False --- linux-2.6-2.6.12.orig/debian/arch/m32r/Makefile.inc +++ linux-2.6-2.6.12/debian/arch/m32r/Makefile.inc @@ -0,0 +1,3 @@ +# +# Variables +# --- linux-2.6-2.6.12.orig/debian/arch/m32r/defines +++ linux-2.6-2.6.12/debian/arch/m32r/defines @@ -0,0 +1,10 @@ +[base] +flavours: + mappi2 + m32700ut-smp + +[mappi2] +class: mappi2 with vdec2 instruction set + +[m32700ut-smp] +class: m32700ut SMP version --- linux-2.6-2.6.12.orig/debian/arch/m32r/config +++ linux-2.6-2.6.12/debian/arch/m32r/config @@ -0,0 +1,351 @@ +CONFIG_M32R=y +# CONFIG_UID16 is not set +CONFIG_GENERIC_ISA_DMA=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_EXPERIMENTAL=y +CONFIG_CLEAN_COMPILE=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 +CONFIG_LOCALVERSION= +CONFIG_SWAP=y +CONFIG_SYSVIPC=y +# CONFIG_POSIX_MQUEUE is not set +CONFIG_BSD_PROCESS_ACCT=y +# CONFIG_BSD_PROCESS_ACCT_V3 is not set +CONFIG_SYSCTL=y +# CONFIG_AUDIT is not set +CONFIG_HOTPLUG=y +CONFIG_KOBJECT_UEVENT=y +CONFIG_IKCONFIG=y +CONFIG_IKCONFIG_PROC=y +# CONFIG_CPUSETS is not set +CONFIG_EMBEDDED=y +# CONFIG_KALLSYMS is not set +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_BASE_FULL=y +# CONFIG_FUTEX is not set +# CONFIG_EPOLL is not set +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SHMEM=y +CONFIG_CC_ALIGN_FUNCTIONS=0 +CONFIG_CC_ALIGN_LABELS=0 +CONFIG_CC_ALIGN_LOOPS=0 +CONFIG_CC_ALIGN_JUMPS=0 +# CONFIG_TINY_SHMEM is not set +CONFIG_BASE_SMALL=0 +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_OBSOLETE_MODPARM=y +# CONFIG_MODVERSIONS is not set +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y +CONFIG_STOP_MACHINE=y +# CONFIG_PCI is not set +# CONFIG_ISA is not set +# CONFIG_PCCARD is not set +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_STANDALONE=y +CONFIG_PREVENT_FIRMWARE_BUILD=y +CONFIG_FW_LOADER=y +# CONFIG_PARPORT is not set +# CONFIG_BLK_DEV_FD is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +CONFIG_BLK_DEV_LOOP=y +# CONFIG_BLK_DEV_CRYPTOLOOP is not set +CONFIG_BLK_DEV_NBD=y +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=4096 +# CONFIG_BLK_DEV_INITRD is not set +CONFIG_INITRAMFS_SOURCE= +# CONFIG_CDROM_PKTCDVD is not set +CONFIG_IOSCHED_NOOP=y +# CONFIG_IOSCHED_AS is not set +CONFIG_IOSCHED_DEADLINE=y +CONFIG_IOSCHED_CFQ=y +CONFIG_ATA_OVER_ETH=m +CONFIG_IDE=y +CONFIG_BLK_DEV_IDE=y +# CONFIG_BLK_DEV_IDE_SATA is not set +CONFIG_BLK_DEV_IDEDISK=y +# CONFIG_IDEDISK_MULTI_MODE is not set +CONFIG_BLK_DEV_IDECD=m +# CONFIG_BLK_DEV_IDETAPE is not set +# CONFIG_BLK_DEV_IDEFLOPPY is not set +# CONFIG_BLK_DEV_IDESCSI is not set +# CONFIG_IDE_TASK_IOCTL is not set +CONFIG_IDE_GENERIC=y +# CONFIG_IDE_ARM is not set +# CONFIG_BLK_DEV_IDEDMA is not set +# CONFIG_IDEDMA_AUTO is not set +# CONFIG_BLK_DEV_HD is not set +CONFIG_SCSI=m +CONFIG_SCSI_PROC_FS=y +CONFIG_BLK_DEV_SD=m +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +CONFIG_BLK_DEV_SR=m +# CONFIG_BLK_DEV_SR_VENDOR is not set +CONFIG_CHR_DEV_SG=m +CONFIG_CHR_DEV_SCH=m +CONFIG_SCSI_MULTI_LUN=y +# CONFIG_SCSI_CONSTANTS is not set +# CONFIG_SCSI_LOGGING is not set +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +# CONFIG_SCSI_ISCSI_ATTRS is not set +# CONFIG_SCSI_SATA is not set +# CONFIG_SCSI_DEBUG is not set +# CONFIG_MD is not set +CONFIG_NET=y +CONFIG_PACKET=y +# CONFIG_PACKET_MMAP is not set +CONFIG_UNIX=y +# CONFIG_NET_KEY is not set +CONFIG_INET=y +# CONFIG_IP_MULTICAST is not set +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +# CONFIG_IP_PNP_BOOTP is not set +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_ARPD is not set +# CONFIG_SYN_COOKIES is not set +# CONFIG_INET_AH is not set +# CONFIG_INET_ESP is not set +# CONFIG_INET_IPCOMP is not set +# CONFIG_INET_TUNNEL is not set +CONFIG_IP_TCPDIAG=y +# CONFIG_IP_TCPDIAG_IPV6 is not set +# CONFIG_IPV6 is not set +# CONFIG_NETFILTER is not set +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set +# CONFIG_ATM is not set +# CONFIG_BRIDGE is not set +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set
Bug#329739: linux-2.6: M32R support
On Fri, 23 Sep 2005 08:22:31 +0200 Sven Luther [EMAIL PROTECTED] wrote: Is m32r a separate architecture at all ? Yes. Original architecture by Mitsubishi, it's now Renesas Technology. Debian doesn't yet have archive support for it, does it ? Yes, we have. I mean, dpkg and other tools support M32R already. But the infrastructure is not yet ready, say, we cannot 'apt-get' from Debian site. We have a daily running build daemon for M32R, but we don't have a machine connected to Internet for Debian Developers to test or work (not yet). FWIW, here is the list I sent for M32R: http://hikaru.fsij.org/~gniibe/PatchesSent.html I'd like to setup a M32R machine for Debian Developers, but I don't have enough knowledge yet (LDAP? or something like that). Any help is appreciated. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329739: linux-2.6: M32R support
Thank you for giving me URL references. I think that the criteria looks fair enough. On Fri, 23 Sep 2005 09:09:55 +0200 Sven Luther [EMAIL PROTECTED] wrote: Cool, any relationship to the other ones, or some site with general description of it ? What is it used for ? Some sort of embedded thingy (you speak about cross compiling, i personally don't believe in that, real men do native compilation, and even m68k is handling that, but hey ... :). Thank you for your interests. The hardware architecture is basically like 32-bit MIPS, with five stage pipe line. It's like ARM or SuperH, it only has sixteen registers. Instructions format is 16-bit and 32-bit, which should be aligned to 32-bit. It is used for embedded system, such as digital camera by Fuji Film, mobile phone, some factory automation system, and so on. Well, I speak about cross compiling, because every man have to go through that way at least once, to be real man. I mean, to reach the status of native compilation. :-) -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#329820: gcc-3.4: DEB_VERSION when binary-only NMU
Package: gcc-3.4
Version: 3.4.4-8
Severity: wishlist
Tags: patch
It would be good if gcc-3.4 supports binary-only NMU for porters.
Suppose that the version of gcc-3.4 is 3.4.4-8. If we do binary-only
NMU, say, for the port m32r-linux-gnu with version 3.4.4-8.0.1,
gcc-m32r-linux-gnu package will depend on gcc-3.4-base (= 3.4.4-8.0.1).
It means, we cannot do binary-only NMU (virtually).
How about following patch (or something like that)?
-- System Information:
Debian Release: testing/unstable
Kernel: Linux 2.6.11
Versions of packages gcc-3.4 depends on:
ii binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii cpp-3.4 3.4.4-8 The GNU C preprocessor
ii gcc-3.4-base 3.4.4-8 The GNU Compiler Collection (base
ii libc62.3.5-6 GNU C Library: Shared libraries an
ii libgcc1 1:4.0.1-8 GCC support library
Versions of packages gcc-3.4 recommends:
ii libc6-dev 2.3.5-6GNU C Library: Development Librari
* debian/rules.conf (DEB_VERSION): Support binary-only NMU.
* debian/rules.patch (DEB_VERSION): Likewise.
-- NIIBE Yutaka [EMAIL PROTECTED] Fri, 23 Sep 2005 22:31:00 +0900
--- gcc-3.4-3.4.4/debian/rules.conf
+++ gcc-3.4-3.4.4/debian/rules.conf
@@ -124,7 +124,7 @@
SOURCE_VERSION := $(shell dpkg-parsechangelog | awk '/^Version:/ {print $$NF}')
DEB_VERSION := $(shell echo $(SOURCE_VERSION) \
- | sed -e 's/.*://' -e 's/ds[0-9]*//')
+ | sed -e 's/.*://' -e 's/ds[0-9]*//' -e
's/\.[0-9][^.-]*\.[0-9][^.-]*$$//')
# epoch used for gcc versions up to 3.3.x, now used for some remaining
# libraries: libgcc1, libobjc1, libffi2, libffi2-dev, libg2c0
EPOCH := 1
--- gcc-3.4-3.4.4/debian/rules.patch
+++ gcc-3.4-3.4.4/debian/rules.patch
@@ -192,8 +192,8 @@
# debian/rules.conf isn't yet sourced
SOURCE_VERSION := $(shell dpkg-parsechangelog | awk '/^Version:/ {print $$NF}')
-DEB_VERSION := $(shell echo $(SOURCE_VERSION) | sed 's/ds[0-9]*//')
-
+DEB_VERSION := $(shell echo $(SOURCE_VERSION) \
+ | sed -e 's/.*://' -e 's/ds[0-9]*//' -e
's/\.[0-9][^.-]*\.[0-9][^.-]*$$//')
$(patch_stamp)-%: $(patchdir)/%.dpatch
if [ -x $ ]; then true; else chmod +x $; fi
if [ -f $@ ]; then \
Bug#329820: Acknowledgement (gcc-3.4: DEB_VERSION when binary-only NMU)
The patch I sent yesterday was wrong. Here is update. The intention of this patch is that supporting binary only NMU by porters. -- gcc-binary-only-nmu-20050924.patch Description: Binary data
Bug#329893: gcc-3.4: M32R libffi update for 3.4.4
Package: gcc-3.4 Version: 3.4.4-8 Severity: wishlist Tags: patch We need a update for M32R's libffi patch, because the one which is included in Debian gcc-3.4 source package is old. I got update from M32R's libffi author, Kazuhiro Inaoka. Could you please apply following patch? It looks big, but only inherent change is the change of FFI_CLOSURES, others are caused by source change between 3.4.1 and 3.4.4. * debian/patches/m32r-libffi.dpatch: Updated to 3.4.4. -- NIIBE Yutaka [EMAIL PROTECTED] Sat, 24 Sep 2005 17:53:46 +0900 --- gcc-3.4-3.4.4/debian/patches/m32r-libffi.dpatch +++ gcc-3.4-3.4.4/debian/patches/m32r-libffi.dpatch @@ -63,351 +63,58 @@ --- gcc-3.4.1/libffi/Makefile.in.orig 2004-11-12 16:52:34.0 +0900 +++ gcc-3.4.1/libffi/Makefile.in 2004-11-12 16:57:15.0 +0900 -@@ -95,26 +95,7 @@ AUTOMAKE_OPTIONS = cygnus - - SUBDIRS = include testsuite - --EXTRA_DIST = LICENSE ChangeLog.v1 \ -- src/alpha/ffi.c src/alpha/osf.S src/alpha/ffitarget.h \ -- src/arm/ffi.c src/arm/sysv.S src/arm/ffitarget.h \ -- src/mips/ffi.c src/mips/n32.S src/mips/o32.S \ -- src/mips/ffitarget.h \ -- src/m68k/ffi.c src/m68k/sysv.S src/m68k/ffitarget.h \ -- src/pa/ffi.c src/pa/linux.S src/pa/ffitarget.h \ -- src/powerpc/ffi.c src/powerpc/sysv.S \ -- src/powerpc/linux64.S src/powerpc/linux64_closure.S \ -- src/powerpc/ppc_closure.S src/powerpc/asm.h \ -- src/powerpc/aix.S src/powerpc/darwin.S \ -- src/powerpc/aix_closure.S src/powerpc/darwin_closure.S \ -- src/powerpc/ffi_darwin.c src/powerpc/ffitarget.h \ -- src/s390/ffi.c src/s390/sysv.S src/s390/ffitarget.h \ -- src/sh/ffi.c src/sh/sysv.S src/sh/ffitarget.h \ -- src/sh64/ffi.c src/sh64/sysv.S src/sh64/ffitarget.h \ -- src/sparc/v8.S src/sparc/v9.S src/sparc/ffitarget.h \ -- src/sparc/ffi.c \ -- src/x86/ffi.c src/x86/sysv.S src/x86/win32.S \ -- src/x86/ffi64.c src/x86/unix64.S src/x86/ffitarget.h -+EXTRA_DIST = LICENSE ChangeLog.v1 src/alpha/ffi.c src/alpha/osf.S src/alpha/ffitarget.h src/arm/ffi.c src/arm/sysv.S src/arm/ffitarget.h src/mips/ffi.c src/mips/n32.S src/mips/o32.Ssrc/mips/ffitarget.h src/m32r/ffi.c src/m32r/sysv.S src/m32r/ffitarget.h src/m68k/ffi.c src/m68k/sysv.S src/m68k/ffitarget.h src/pa/ffi.c src/pa/linux.S src/pa/ffitarget.h src/powerpc/ffi.c src/powerpc/sysv.S src/powerpc/linux64.S src/powerpc/linux64_closure.S src/powerpc/ppc_closure.S src/powerpc/asm.h src/powerpc/aix.S src/powerpc/darwin.S src/powerpc/aix_closure.S src/powerpc/darwin_closure.S src/powerpc/ffi_darwin.c src/powerpc/ffitarget.hsrc/s390/ffi.c src/s390/sysv.S src/s390/ffitarget.h src/sh/ffi.c src/sh/sysv.S src/sh/ffitarget.h src/sh64/ffi.c src/sh64/sysv.S src/sh64/ffitarget.h src/sparc/v8.S src/sparc/v9.S src/sparc/ffitarget.h src/sparc/ffi.c src/x86/ffi.c src/x86/sysv.S src/x86/win32.Ssrc/x86/ffi64.c src/x86/unix64.S src/x86/ffitarget.h - - - VPATH = @srcdir@:@srcdir@/src:@srcdir@/src/@TARGETDIR@ -@@ -122,41 +103,7 @@ VPATH = @srcdir@:@srcdir@/src:@srcdir@/s - # Work around what appears to be a GNU make bug handling MAKEFLAGS - # values defined in terms of make variables, as is the case for CC and - # friends when we are called from the top level Makefile. --AM_MAKEFLAGS = \ -- AR_FLAGS=$(AR_FLAGS) \ -- CC_FOR_BUILD=$(CC_FOR_BUILD) \ -- CFLAGS=$(CFLAGS) \ -- CXXFLAGS=$(CXXFLAGS) \ -- CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD) \ -- CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET) \ -- INSTALL=$(INSTALL) \ -- INSTALL_DATA=$(INSTALL_DATA) \ -- INSTALL_PROGRAM=$(INSTALL_PROGRAM) \ -- INSTALL_SCRIPT=$(INSTALL_SCRIPT) \ -- JC1FLAGS=$(JC1FLAGS) \ -- LDFLAGS=$(LDFLAGS) \ -- LIBCFLAGS=$(LIBCFLAGS) \ -- LIBCFLAGS_FOR_TARGET=$(LIBCFLAGS_FOR_TARGET) \ -- MAKE=$(MAKE) \ -- MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS) \ -- PICFLAG=$(PICFLAG) \ -- PICFLAG_FOR_TARGET=$(PICFLAG_FOR_TARGET) \ -- RUNTESTFLAGS=$(RUNTESTFLAGS) \ -- SHELL=$(SHELL) \ -- exec_prefix=$(exec_prefix) \ -- infodir=$(infodir) \ -- libdir=$(libdir) \ -- prefix=$(prefix) \ -- AR=$(AR) \ -- AS=$(AS) \ -- CC=$(CC) \ -- CXX=$(CXX) \ -- LD=$(LD) \ -- LIBCFLAGS=$(LIBCFLAGS) \ -- NM=$(NM) \ -- PICFLAG=$(PICFLAG) \ -- RANLIB=$(RANLIB) \ -- DESTDIR=$(DESTDIR) -+AM_MAKEFLAGS =AR_FLAGS=$(AR_FLAGS) CC_FOR_BUILD=$(CC_FOR_BUILD) CFLAGS=$(CFLAGS) CXXFLAGS=$(CXXFLAGS) CFLAGS_FOR_BUILD=$(CFLAGS_FOR_BUILD) CFLAGS_FOR_TARGET=$(CFLAGS_FOR_TARGET)INSTALL=$(INSTALL) INSTALL_DATA=$(INSTALL_DATA) INSTALL_PROGRAM=$(INSTALL_PROGRAM) INSTALL_SCRIPT=$(INSTALL_SCRIPT) JC1FLAGS=$(JC1FLAGS) LDFLAGS=$(LDFLAGS)LIBCFLAGS=$(LIBCFLAGS) LIBCFLAGS_FOR_TARGET=$(LIBCFLAGS_FOR_TARGET) MAKE=$(MAKE) MAKEINFO=$(MAKEINFO) $(MAKEINFOFLAGS) PICFLAG
Bug#326889: ITP: sigscheme -- A Scheme Interpreter
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: sigscheme Version : 0.1.0 Upstream Author : Kazuki Ohta [EMAIL PROTECTED] * URL : http://mover.cool.ne.jp/others/sigscheme/sigscheme-0.1.0.tar.gz * License : BSD Description : A Scheme Interpreter SigScheme is a Scheme interpreter, which targets embedded program. SigScheme is used as extention engine for uim, universal input method system. It conforms to R5RS, some of SRFI-s. It's early development stage, but it is useful. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#327062: ITP: scim-sinhala -- Input Method plug-in for Sinhala
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka [EMAIL PROTECTED] * Package name: scim-sinhala Version : 0.0.0 Upstream Author : Kazuki Ohta [EMAIL PROTECTED] * URL : http://osdn.dl.sourceforge.jp/scim-imengine/16422/scim-sinhala-0.0.0.tar.gz * License : GPL Version 2 Description : Input Method plug-in for Sinhala scim-sinhala is the input method plug-in for Sinhala language. Homepage: http://scim-imengine.sourceforge.jp/index.cgi?cmd=view;name=SCIMSinhala -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#291792: ITP: gonzui -- a source code search engine
Package: wnpp Severity: wishlist * Package name: gonzui Version : 0.2 Upstream Author : Satoru Takabayashi [EMAIL PROTECTED] * URL : http://namazu.org/~satoru/gonzui/ * License : GPL v2 Description : a source code search engine Gonzui is a source code search engine for accelerating open source software development. Gonzui supports C, Java, and Ruby (as of version 0.2). It consists of indexer with programming languages semantics, web interface of search engine, and colorful pretty printer for souce code. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#341674: Status of qwikweb
Junichi Uekawa wrote: You've been sitting on this ITP for half-an-year, unless you already have got a package to upload, please give up and hand the package over to someone responsible. It just need some time, that's the situation. I mean, I am responsible. After I submitted ITP, it found that Eto Yasuo already had his effort on packaging Qwik for Debian. At that time, he didn't have intention to be maintainer of the package, but just keep it non-official. We discussed, together with upstream, and the effort has been included to upstream. You can check it: svn://rubyforge.org//var/svn/qwik/qwik Yasuo now considers to be DD, and he should be maintainer of this package. It's almost ready to upload, we are discussing about the policy (of branching or versioning of Debian version) at upstream, with upstream author. I've requested two things to Yasuo: * At the time of release, include a phrase (Closes: #341674) * Adding Uploader field In short, it's about to be uploaded. Enjoy, -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#369183: gauche: Don't quote CC
Package: gauche Version: 0.8.7-3 Severity: important gauche-gl package cannot be built with new version 0.8.7. It is because new version quotes much more than needed. Could you please consider to include following patch in gauche? This problem has been reported to upstream already. You can reproduce this bug when you get gauche-gl package and build it. --- Gauche-0.8.7/lib/gauche/package/compile.scm~2006-05-26 13:23:15.0 +0900 +++ Gauche-0.8.7/lib/gauche/package/compile.scm 2006-05-28 09:36:42.0 +0900 @@ -87,7 +87,7 @@ (run #`',GOSH' genstub ,stubfile)) (define (do-compile cc cfile ofile cppflags cflags) - (run #`',cc' -c ,cppflags ,INCDIR ,cflags ,CFLAGS -o ',ofile' ',cfile')) + (run #`,cc -c ,cppflags ,INCDIR ,cflags ,CFLAGS -o ',ofile' ',cfile')) (define (gauche-package-link sofile ofiles . args) (let-keywords* args ((ldflags #f) @@ -100,7 +100,7 @@ (unless (and (file-exists? sofile) (every (cut file-mtime? sofile ) ofiles)) (let1 all-ofiles (string-join (map (lambda (f) #`',f') ofiles) ) - (run #`',(or ld CC)' ,(or ldflags \\) ,LIBDIR ,LDFLAGS ,sofile ,all-ofiles ,LIBS ,(or libs \\))) + (run #`,(or ld CC) ,(or ldflags \\) ,LIBDIR ,LDFLAGS ,sofile ,all-ofiles ,LIBS ,(or libs \\))) (define (gauche-package-compile-and-link module-name files . args) (let ((head.c #`,|module-name|_head.c) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#434826: ITP: eresi -- ERESI Reverse Engineering Software Interface
Hello, How's it going? If you are busy, I would like to package it up, because I would like to use newer elfsh. Could you please let me know the status of your packaging? -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472722: ITA: samidare -- web page updates checker
retitle 472722 ITA: samidare -- web page updates checker owner 472722 NIIBE Yutaka [EMAIL PROTECTED] thanks I'm adopting it, because we are users of this package, that is, our web site depends on this. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472715: ITA: htree -- HTML/XML tree library for Ruby
retitle 472715 ITA: htree -- HTML/XML tree library for Ruby owner 472715 NIIBE Yutaka [EMAIL PROTECTED] thanks -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#612554: sh4: FTBFS: test fail
Thanks for your attention. 2011-02-09 15:36, Nobuhiro Iwamatsu wrote: gauche FTBFS on sh4. http://buildd.debian-ports.org/fetch.php?pkg=gauchearch=sh4ver=0.9-19stamp=1297164204file=logas=raw I saw this morning. sh4 needs -mieee option for NaN (fpu) support. Yes. I know. It's like Alpha. Could you apply this patch? Sure. I will soon in 0.9-20. BTW, I found that sh4 porterboxes are now available. Congratulation! -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#614517: ITP: libgit2 -- Git core methods library
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka gni...@fsij.org * Package name: libgit2 Version : 0.3.0 Upstream Author : Vicent Mart«¿ vic...@github.com * URL : http://libgit2.github.com/ * License : GPL2 with linking exemption Programming Lang: C Description : Git core methods library libgit2 is a portable, pure C implementation of the Git core methods provided as a re-entrant linkable library with a solid API, allowing you to write native speed custom Git applications in any language with bindings. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582797: libanthy0: Pulls in 13 MB of data despite it seems to need it only in some cases
Hello, Harshula, 2011-02-23 00:05, Harshula wrote: This whole issue is about dependencies and package sizes. Thanks for your message. The relevant m17n dependencies are: libm17n-0 Depends on libanthy0 libm17n-0 Depends on m17n-db m17n-db Recommends anthy 1) Upstream agreed to modify m17n-lib API to include a flag with each input method in the list returned to the caller that states whether all the dependencies of the input method are satisfied. It's been committed to CVS. This allows m17n-db to only Recommend anthy instead of Depend on it. I agree this part. Further, I think that m17n-db should *not* Recommends or Suggests anthy. That's because there is no real reason why m17n-db/libm17n-0 depends or recommends (or even Suggests) anthy. I would like to add some points here. I think that the solution is not including a demonstration module of anthy in libm17n-0. Note that _no_ major functionality in libm17n-0 uses anthy at all, and _no_ users expect to use anthy through libm17n. Only a demonstration module of libm17n uses anthy. I am talking about: /usr/lib/m17n/1.0/libmimx-anthy.so This module is written as a demonstration by Ken'ichi, and only used (potentially) by /usr/bin/m17n-edit in m17n-lib-bin package, which is also for demonstration purpose and not-for-real-use. If it is difficult to split up libm17n-0 to libm17n-0 and (for example) libm17n-0-module-anthy, I think that drop Build-Depends on anthy-dev for m17n-lib would be short term solution. 2) libm17n-0 Depends on libanthy0 and libanthy0 Depends on anthy-common which is 13MBs. Yes. I understand the problem. I understand dependency should be minimized for users benefit. 3) According to http://bugs.debian.org/512204 the anthy and anthy-common split was created because libanthy0 doesn't need all the files in both anthy and anthy-common. The question I have for you is, does libanthy0 need all the 13MBs of files in anthy-common? Unfortunately yes it does. Yes, it would be better, say, to split up dependency. I have tried (and still am trying) to minimize libanthy0 dependency of its dictionaries, but it is mostly hard-coded and need major re-work/re-design. Eventually, this will be improved, but it will takes time. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582797: libanthy0: Pulls in 13 MB of data despite it seems to need it only in some cases
2011-02-24 10:57, Harshula wrote: Perhaps you are confusing the m17n ispell module with the anthy module. No, I am talking about Anthy module. Well, let me explain my background. My native language is Japanese. I developed Egg v4 input method for GNU Emacs around 1997, and enhanced it to support Anthy around 2001. When I use Emacs, I use japanese-egg-anthy input method, and this is mostly used. For Desktop, I have been using scim-anthy, but recently moved to ibus-anthy. Until last September (for approximately ten years), I was a colleague of Ken'ichi Handa, who develops m17nlib. My first experience with him was about 20 years ago, for enhancement of GNU Emacs. Yes, that's also work to support multilingual text. For Anthy, I managed to arrenge some fund for development of Anthy around 2001, and have kept supporting its development since then. But the development became mostly dead around 2007. Then, I decided to maintain upstream anthy since last summer. m17n anthy is available to desktop users via IBus. It is just available, like m17n-edit. But it is not for real use, seriously. No one use that, except by accident. From viepoint of Anthy, it is not recommended, because features supported by m17n Anthy is minimum and not well integrated to desktop usage. anthy description: Japanese input method with Anthy as a kana-kanji converter. Typed roma-ji is at first converted to Hiragana, and Space key converts the Hiragana sequences to Kanji-Hiragana mixed sequence. IMHO, this description would be better to include: This is a demonstration purpose (not for real use). Since I'd understand some reason why m17n-lib has to claim This library support Japanese too, I don't say more. Upstream may move the libmimx-*.so out of m17n-lib into m17n-db. Discussions are still ongoing. Good. Partly, I'd agree. It makes sence to move m17n-lib modules/plugins out of m17n-lib and put them, say, independent package, m17n-modules or something. It would be decision by upstream, but this could be also done by package maintainer independently. It sounds somewhat odd to me to include modules into m17n-db, since it is not data, but program. If you will request upstream change for moving modules/plugins out of m17n-lib, it would also make sence to suggest rename of modules. Name starts by 'lib' would be better to be changed, as it is plugin module dynamically loaded, not linked to executable at compile time. If you will request upstream change for this matter, could you please include me? That's easy way to communicate. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#615930: ITP: scute -- OpenPGP smartcard plugin for Mozilla Network Security Services
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka gni...@fsij.org * Package name: scute Version : 1.4.0 Upstream Author : Marcus Brinkmann mar...@g10code.com * URL : http://www.scute.org/ * License : GPLv2+ with exception for Mozilla Programming Lang: C Description : OpenPGP smartcard plugin for Mozilla Network Security Services Scute is a PKCS #11 implementation for the GnuPG Agent using the GnuPG Smart Card Daemon which enables you to use your OpenPGP smart card for client authentication with SSL in Mozilla. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599239: gauche-gtk: FTBFS against gdk-pixbuf 2.22.0-1 (experimental)
severity 599239 wishlist tags 599239 experimental thanks 2010-10-06, Mathieu Trudel-Lapierre wrote: It appears that if built against gdk-pixbuf as it is in experimental (basically with gdk-pixbuf headers separate from the gtk2.0 files), gauche-gtk does not complete build as it fails to analyze headers. Thanks for your information and the patch. But, I am changing status of the bug report in Debian, as it can build cleanly in the current environment. After gtk change, I will fix. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539356: audit: inode with != operator
Package: audit
Version: 1.7.13-1
Severity: normal
I sent a bug report to upstream (linux-au...@redhat.com), but it seems
it doesn't work. So, I am filing the bug report into Debian BTS.
I am using audit-1.7.13 on Debian. Using the tool auditctl, I got an
error when I tried to specify inode with != operator.
# auditctl -a exit,always -F devmajor=9 -F perm=wa -F 'inode!=67437'
Field (inode) only takes = or != operators
It's something weird, I am using the != operator...
Looking the source code, I found a function audit_rule_fieldpair in
deprecated.c and another function audit_rule_fieldpair_data in libaudit.c.
It seems that the != operator was AUDIT_NEGATE but now is
AUDIT_NOT_EQUAL, internally. If this assumption is correct, I think
that we need a fix like following:
--- audit-1.7.13/lib/libaudit.c~2009-04-22 03:47:20.0 +0900
+++ audit-1.7.13/lib/libaudit.c 2009-07-30 14:33:44.0 +0900
@@ -1096,7 +1096,7 @@
/* fallthrough */
default:
if (field == AUDIT_INODE) {
- if (!(op == AUDIT_NEGATE || op == AUDIT_EQUAL))
+ if (!(op == AUDIT_NOT_EQUAL || op ==
AUDIT_EQUAL))
return -13;
}
Thanks,
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#503638: libccid: USB-ICC version A (T=0) support
Package: libccid
Version: 1.3.8-1
Severity: normal
Hi, there.
I think that current implementation for ICCD version A does not work
well. While I am implementing ICCD device, I found some problems.
(Note that I don't have any ICCD version A device other than my own
development device. So, my understanding/interpretation of protocol
would be wrong.)
Here is a patch to discuss issues.
(1) Function CCID_Receive() should change the value pointed by rx_length.
--- ccid-1.3.8.orig/src/commands.c
+++ ccid-1.3.8/src/commands.c
@@ -1121,6 +1121,7 @@
return IFD_COMMUNICATION_ERROR;
}
+ *rx_length = r;
return IFD_SUCCESS;
}
This is needed to let the caller length of actual data received.
(2) Function CmdXfrBlockCHAR_T0() should handle length of received
packet correctly.
(3) It is better for Function CmdXfrBlockCHAR_T0() to check status
before calling CCID_Transmit().
@@ -1727,6 +1728,8 @@
if (ICCD_A == ccid_descriptor-bInterfaceProtocol)
{
unsigned char pcbuffer[SIZE_GET_SLOT_STATUS];
+ unsigned int orig_rcv_len = *rcv_len;
+ unsigned int data_rcvd_len;
/* Command to send to the smart card (must be 5 bytes) */
memset(cmd, 0, sizeof(cmd));
@@ -1743,6 +1746,11 @@
snd_len -= 5;
}
+ /* wait for ready */
+ return_value = CmdGetSlotStatus(reader_index, pcbuffer);
+ if (return_value != IFD_SUCCESS)
+ return return_value;
+
/* at most 5 bytes */
return_value = CCID_Transmit(reader_index, 5, cmd, 0, 0);
if (return_value != IFD_SUCCESS)
@@ -1762,14 +1770,27 @@
}
else
{
- if ((0x20 == pcbuffer[0]) (*rcv_len 2))
- /* we will just read SW1-SW2 */
- *rcv_len = 2;
+ return_value = CCID_Receive(reader_index, rcv_len,
rcv_buf, NULL);
+ if (return_value != IFD_SUCCESS)
+ DEBUG_CRITICAL(CCID_Receive failed);
+
+ if ((0x20 == pcbuffer[0])) /* ... was SW1-SW2 */
+ return return_value;
+
+ /* wait for ready */
+ return_value = CmdGetSlotStatus(reader_index, pcbuffer);
+ if (return_value != IFD_SUCCESS)
+ return return_value;
+
+ data_rcvd_len = *rcv_len;
+ rcv_buf += *rcv_len;
+ *rcv_len = orig_rcv_len;
return_value = CCID_Receive(reader_index, rcv_len,
rcv_buf, NULL);
if (return_value != IFD_SUCCESS)
DEBUG_CRITICAL(CCID_Receive failed);
+ *rcv_len += data_rcvd_len;
return return_value;
}
@@ -1778,15 +1799,28 @@
if (return_value != IFD_SUCCESS)
return return_value;
- if ((0x20 == pcbuffer[0]) (*rcv_len 2))
- /* we will just read SW1-SW2 */
- *rcv_len = 2;
+ return_value = CCID_Receive(reader_index, rcv_len, rcv_buf,
NULL);
+ if (return_value != IFD_SUCCESS)
+ DEBUG_CRITICAL(CCID_Receive failed);
+
+ if ((0x20 == pcbuffer[0])) /* ... was SW1-SW2 */
+ return return_value;
+
+ /* wait for ready */
+ return_value = CmdGetSlotStatus(reader_index, pcbuffer);
+ if (return_value != IFD_SUCCESS)
+ return return_value;
+
+ data_rcvd_len = *rcv_len;
+ rcv_buf += *rcv_len;
+ *rcv_len = orig_rcv_len;
/* read SW1-SW2 */
return_value = CCID_Receive(reader_index, rcv_len, rcv_buf,
NULL);
if (return_value != IFD_SUCCESS)
DEBUG_CRITICAL(CCID_Receive failed);
+ *rcv_len += data_rcvd_len;
return return_value;
}
-- System Information:
Debian Release: lenny/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages libccid depends on:
ii libc62.7-15 GNU C Library: Shared libraries
ii libpcsclite1 1.4.102-1 Middleware to access a smart card
ii libusb-0.1-4 2:0.1.12-13 userspace USB programming library
Versions of packages libccid recommends:
ii pcscd 1.4.102-1 Middleware to access a
Bug#514573: unclear dialog on exit with changes
Joey Hess wrote: Package: golly Version: 1.4-1 Severity: normal Draw on the board and close golly. It will prompt with a dialog box, which reads: If you don't save, your changes will be lost. No Cancel Yes This is ambiguous. Is it asking if I want to save changes? Or is it asking if I want to exit *without* saving changes? To fix the wording, you could probably tack on Save now? to the end of the message. In my environment, window manager displays the message Save the changes to untitled? at the title bar. This might be confusing for some window manager, perhaps. (BTW, if No or Yes is selected, golly will throw a segmentation fault when it exits in this situation.) I couldn't reproduce this segmentation fault. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568981: ITP: gfarm -- a reference implementation of the Grid Datafarm
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka gni...@fsij.org * Package name: gfarm Version : 2.3.0 Upstream Author : Osamu Tatebe tat...@cs.tsukuba.ac.jp * URL : http://datafarm.apgrid.org/ * License : BSD, LGPL, CDDL Programming Lang: C Description : a reference implementation of the Grid Datafarm The Gfarm filesystem is a distributed filesystem consisting of the local storage of commodity PCs. PCs in a local area network, compute nodes in a single cluster, multiple clusters in wide area, comprise a large-scale, high-performance shared network filesystem. The Gfarm filesystem solves performance and reliability problems in NFS and AFS by means of multiple file replicas. It not only prevents performance degradation due to access concentration, but also supports fault tolerance and disaster recovery. Older version has packaged for Debian in the past and .deb seemed distributed once. In fact, source code contains debian/ directory, but it outdated completely. Thus, I am packaging now, and push it into Debian. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#580948: ttf-ipafont: upgrade failure from 00203-13 to 00203-14
Package: ttf-ipafont Version: 00203-14 Severity: normal The following change in 00203-14 breaks upgrading. * split to ttf-ipafont-uigothic, ttf-ipafont-gothic and ttf-ipafont-mincho package and ttf-ipafont depends it. I think that it is needed to set Breaks: and Replaces: fields in control file. I mean, adding those two fields for ttf-ipafont-uigothic, ttf-ipafont-gothic, and ttf-ipafont-mincho. -- Breaks: ttf-ipafont (= 00203-13) Replaces: ttf-ipafont (= 00203-13) -- -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages ttf-ipafont depends on: ii ttf-ipafont-gothic00203-14 Japanese TrueType font, IPAfont Go ii ttf-ipafont-mincho00203-14 Japanese TrueType font, IPAfont Mi ii ttf-ipafont-uigothic 00203-14 Japanese TrueType font, IPAfont UI -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543857: ITA: pth -- The GNU Portable Threads
retitle 543857 ITA: pth -- The GNU Portable Threads thanks I adopt this package, as this package is useful for users who want to use cooperative threads. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494599: ITA: rxp -- A validating XML parser
I am adopting rxp. Original Message Subject: ITA: rxp -- A validating XML parser Date: Tue, 11 May 2010 14:32:20 +0900 From: NIIBE Yutaka gni...@fsij.org Organization: Free Software Initiative of Japan To: cont...@bugs.debian.org unarchive 494599 reopen 494599 retitle 494599 ITA: rxp -- A validating XML parser owner 494599 gni...@fsij.org thanks I adopt this package, because my wnpp package tomoe Build-Depends on this. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#494599: ITA: rxp -- A validating XML parser
reopen 494599 retitle 494599 ITA: rxp -- A validating XML parser owner 494599 gni...@fsij.org thanks I adopt this package, because my wnpp package tomoe Build-Depends on this. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575351: -fexceptions and unwind
Package: gcc-4.4-hppa-linux-gnu
Severity: normal
I think that I found (when debugging Boehm GC) a gcc bug on hppa.
Attached is a testcase program, test-pthread-cancel.c.
I test it on paer.debian.org, where the kernel is:
Linux version 2.6.32-3-parisc64 (Debian 2.6.32-9) (m...@debian.org) (gcc
version 4.3.4 (GCC) ) #1 Thu Feb 25 13:08:44 UTC 2010
$ gcc -pthread test-pthread-cancel.c
$ ./a.out
clean it up
$ gcc -pthread test-pthread-cancel.c -fexceptions
$ ./a.out
$
# No output
On i486-pc-linux-gnu, we see output for both cases (with/without
-fexceptions).
It seems that signal handling has been changed after
gcc-4.4.3/gcc/config/pa/linux-unwind.h was written.
We can see the value 0x3419 at the register rp, but not at
the register sp.
--- test-pthread-cancel.c
#include pthread.h
#include time.h
#include stdio.h
static void
clean(void *arg)
{
puts (clean it up);
}
static void *
f(void *arg)
{
struct timespec t;
t.tv_sec = 0;
t.tv_nsec = 1000;
pthread_cleanup_push (clean, NULL);
while (1)
nanosleep (t, NULL);
pthread_cleanup_pop(1);
}
int
main (int argc, char argv[])
{
struct timespec t;
t.tv_sec = 0;
t.tv_nsec = 1;
pthread_t tid;
pthread_create (tid, NULL, f, NULL);
nanosleep (t, NULL);
pthread_cancel (tid);
pthread_join (tid, NULL);
}
---
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575351: This is not the bug of GCC but glibc
No, this is not the bug of GCC. Alhough config/pa/linux-unwind.h
looks incorrect at first glance (TRAMP_SIZE is 9), it runs correctly
(because of padding).
In fact, following program runc correctly on hppa too, we see
clean it up.
$ gcc -fexceptions -save-temps func.c test-pthread-cancel-3.c -pthread
$ ./a.out
I think that the bug is in GNU C library port of hppa.
-- func.c
void func (void)
{
for (;;);
}
-- test-pthread-cancel-3.c
#include pthread.h
#include time.h
static void
clean(void *arg)
{
write (1, clean it up\n, 12);
}
extern void func(void);
static void *
f(void *arg)
{
pthread_cleanup_push (clean, NULL);
pthread_setcanceltype (PTHREAD_CANCEL_ASYNCHRONOUS, NULL);
for (;;)
func ();
pthread_setcanceltype (PTHREAD_CANCEL_DEFERRED, NULL);
pthread_cleanup_pop(1);
}
int
main (int argc, char argv[])
{
struct timespec t;
t.tv_sec = 1;
t.tv_nsec = 0;
pthread_t tid;
pthread_create (tid, NULL, f, NULL);
nanosleep (t, NULL);
pthread_cancel (tid);
pthread_join (tid, NULL);
}
--
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575351: [HPPA] This is not the bug of GCC but glibc
I am looking the file: eglibc-2.10.2/ports/sysdeps/unix/sysv/linux/hppa/nptl/sysdep-cancel.h It doesn't have any cfi directives. I think that it is the cause of this problem. When adding cfi directives, it would be good to add nocancel version of functions. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570912: ITP: gfarm2fs -- FUSE program to mount the Gfarm file system
Package: wnpp Severity: wishlist Owner: NIIBE Yutaka gni...@fsij.org * Package name: gfarm2fs Version : 1.1.1 Upstream Author : Osamu Tatebe tat...@cs.tsukuba.ac.jp * URL : http://datafarm.apgrid.org/ * License : BSD Programming Lang: C Description : FUSE program to mount the Gfarm file system I have packaged the Gfarm filesystem (it's now in NEW queue), and this is a program for FUSE to mount the Gfarm file system. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578337: libgc: Fixing FTBFS (7.1)
Package: libgc Version: 7.1 Severity: important Hi, This message is to share the effort of fixing FTBFS of libgc. I maintain Gauche in Debian: http://packages.qa.debian.org/g/gauche.html Gauche comes with its own libgc 7.1, and I managed to build it successfully for all architectures. I am speaking version 0.9-11 of gauche package. (1) libatomic-ops-dev I use libatomic-ops-dev package. This update is needed for s390, mipsel, and sh4. (2) Changes from upstream I pick up some important fix from upstream. gauche-0.9/debian/patches/05_libgc_fix.patch This is needed for hppa, sparc, and sparc64. (3) Bug fixes for upstream I found two bugs. Please check the GC mailing list of this month. gauche-0.9/debian/patches/12_libgc_fix__EXCEPTIONS.patch gauche-0.9/debian/patches/14_libgc_fix_threadlocal.patch This is needed for ia64. I would be happy to co-maintain libgc package for Debian, if needed. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#558992: third try
2010-01-19 09:43, Joey Hess wrote:
Attached patched fixes that.
Thanks for your patch.
I think that the bug is exiting at the SIGCHLD handler.
IIUC, all we need is to stop exiting there.
I am testing following patch.
--- ttyrec-1.0.8.orig/ttyrec.c 2010-04-27 10:22:52.0 +0900
+++ ttyrec-1.0.8/ttyrec.c 2010-04-27 11:12:35.0 +0900
@@ -209,14 +209,10 @@
union wait status;
#endif /* !SVR4 */
register int pid;
- register int die = 0;
while ((pid = wait3((int *)status, WNOHANG, 0)) 0)
if (pid == child)
- die = 1;
-
- if (die)
- done();
+ break;
}
struct linebuf {
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#579388: ttyrec: replay for Emacs23 session stops for TERM=xterm
Package: ttyrec Version: 1.0.8-4 Severity: important To reproduce: (1) Run ttyrec (2) Run emacs23 $ emacs -q -nw (3) exit emacs23, exit ttyrec session (4) Run ttyplay with the output of (1) Then, ttyplay stops. Type '1' to proceed. The output in question is: ESC [ 0 c which requests terminal version information. My gnome-terminal responds: ESC [ 1; 2205; 0 c and the character '0' stops ttyplay. When I remove corresponding record in the ttyrecord file, ttyplay goes well. According to the site: http://invisible-island.net/xterm/ctlseqs/ctlseqs.html CSI P s c Send Device Attributes (Secondary DA) I think that ttyrec should recognize those query strings and should not put such output into ttyrecord file. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ttyrec depends on: ii libc6 2.10.2-2 GNU C Library: Shared libraries ttyrec recommends no packages. ttyrec suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
Hi there, I think that I am catching a bug for threads and fork. I found it when debugging FTBFS of Gauche, a Scheme interpreter. As I think that the Debian bug #561203 has same cause, I am CC:-ing to the BTS too. Please send Cc: to me, I am not on linux-parisc list. Here, I am talking uniprocessor system case. I assume that PARISC has virtually indexed, physically tagged, write back cache, I call it VIPT-WB. I am reading the source in Debian: linux-source-2.6.32/kernel/fork.c linux-source-2.6.32/mm/memory.c linux-source-2.6.32/arch/parisc/include/asm/pgtable.h To have same semantics as other archs, I think that VIPT-WB cache machine should have cache flush at ptep_set_wrprotect, so that memory of the page has up-to-date data. Yes, it will be huge performance impact for fork. But I don't find any good solution other than this yet. Well, I will need to write to linux-arch. Let me explain our case. As I couldn't catch the scene, but the result, it includes imagination and interpretation of mine. Correct me if I'm wrong. (1) We have process A with threads. One of threads calls fork(2) (in fact, it's clone(2) without CLONE_VM) when other threads are still live. Let's call this thread A-1. (2) As a result of clone(2), we have process B. (3) The memory of process A are copied to process B by dup_mmap (fork.c) by A-1 with the context of process A. There, flush_cache_dup_mm is called. In case of single thread, flush_cache_dup_mm is enough. All data in cache go to memory. But we have other threads, in this case. (4) From dup_mmap, copy_page_range (memory.c) is called. Note that there is a possibility of sleep in copy_page_range. Allocation of page in pud_alloc, pmd_alloc, or pte_alloc_map_lock may need the A-1 thread to be scheduled off (and wakes up the swapper or other processes). (5) Suppose the A-1 thread sleeps in copy_page_range, and another thread of A-2 of process A is waken up, and touches memory. Then we have data only in cache, memory has stale data. (6) A-2 thread sleeps, and A-1 thread is waken up to continue copy_page_range - copy_*_range - copy_one_pte. (7) From copy_one_pte, A-1 thread call ptep_set_wrprotect as this is COW mapping. (*) (8) A-1 thread sleeps again in copy_page_range and process B is waken up. (9) Process B does read-access on memory, which gets *NEW* data in cache (if process space identifier color is same). Process B does write-access on memory which causes memory fault, as it's COW memory. Note: Process B sees *NEW* data because it's VIPT-WB cache. It shares same memory in this situation. (10) New page is allocated and memory contents are copied, with stale data. I assume that kernel access to the memory is by different cache line and does not see cache data of A-2. (11) After falut, process B gets *OLD* data on memory. (*) When we make COW memory mapping between process A and process B, we assume memory were up-to-date. As this assumption is incorrect, I think that we need to flush cache data to memory here. If you have more interest or like ASCII art, please keep reading. In our Gauche case, we saw this problem on the linked list handling of pthread implementation (NPTL). We have two linked list heads, used and cache. Initially, situation of process A is like this: +-+ | | used v ELEM| +-+ +-+ +-+ +-+ | | ---| ---| ---| + +-+ +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ +-+ | | cache v | +-+ +-+ | | ---| + +-+ +-+ This is in memory | | +-+ A-2 thread removes ELEM during fork. This is Process A's final situation, and what Process B sees initially. +-+ | | used v | +-+ +-+ +-+ | | ---| ---| + +-+ +-+ +-+ | | | | +-+ +-+ +---+ | ELEM | | +-+ | | +--| -+| | | +-+ || | | | | || cache v | +-+ ||This is in cache +-+ || +-+ | | ++--| -+ +-+ +-+ | | +-+ Process B scans through linked list with cache and update data in linked list. After
Bug#561203: threads and fork on machine with VIPT-WB cache
Thanks for your quick reply. James Bottomley wrote: In COW breaking, the page table entry is copied, so A and B no longer have page table entries at the same physical location. If the COW is intact, A and B have the same physical page, but it's also accessed by the same virtual address, hence no aliasing. Let me explain more. In the scenario, I assume: No aliasing between A and B. We have aliasing between kernel access and user access. Before COW breaking A and B share same data (with no aliasing same space identifier color), and B sees data in cache, while memory has stale data. At COW breaking, kernel copies the memory, it doesn't see new data in cache because of aliasing. Isn't it possible? -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
NIIBE Yutaka wrote:
To have same semantics as other archs, I think that VIPT-WB cache
machine should have cache flush at ptep_set_wrprotect, so that memory
of the page has up-to-date data. Yes, it will be huge performance
impact for fork. But I don't find any good solution other than this
yet.
I think we could do something like (only for VIPT-WB cache machine):
- static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned
long address, pte_t *ptep)
+ static inline void ptep_set_wrprotect(struct vm_area_struct *vma,
struct mm_struct *mm, unsigned long addr, pte_t *ptep)
{
pte_t old_pte = *ptep;
+ if (atomic_read(mm-mm_users) 1)
+ flush_cache_page(vma, addr, pte_pfn(old_pte));
set_pte_at(mm, addr, ptep, pte_wrprotect(old_pte));
}
Here, we can add condition for the call of flush_cache_page
to avoid big performance impact for non threads case.
--
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
Thanks a lot for the discussion. James Bottomley wrote: So your theory is that the data the kernel sees doing the page copy can be stale because of dirty cache lines in userspace (which is certainly possible in the ordinary way)? Yes. By design that shouldn't happen: the idea behind COW breaking is that before it breaks, the page is read only ... this means that processes can have clean cache copies of it, but never dirty cache copies (because writes are forbidden). That must be design, I agree. To keep this condition (no dirty cache for COW page), we need to flush cache before ptep_set_wrprotect. That's my point. Please look at the code path: (kernel/fork.c) do_fork - copy_process - copy_mm - dup_mm - dup_mmap - (mm/memory.c) copy_page_range - copy_p*d_range - copy_one_pte - ptep_set_wrprotect The function flush_cache_dup_mm is called from dup_mmap, that's enough for a case of a process with single thread. I think that: We need to flush cache before ptep_set_wrprotect for a process with multiple threads. Other threads may change memory after a thread invokes do_fork and before calling ptep_set_wrprotect. Specifically, a process may sleep at pte_alloc function to get a page. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
retitle 561203 threads and fork on machine with VIPT-WB cache reassign 561203 linux-2.6 thanks As I am sure that this bug lives in kernel, I do reassign and retitle. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#561203: threads and fork on machine with VIPT-WB cache
John David Anglin wrote: It is interesting that in the case of the Debian bug that a thread of the parent process causes the COW break and thereby corrupts its own memory. As far as I can tell, the fork'd child never writes to the memory that causes the fault. Thanks for writing and testing a patch. The case of #561203 is second scenario. I think that this case is relevant to VIVT-WB machine too (provided kernel does copy by kernel address). James Bottomley wrote: So this is going to be a hard sell because of the arch churn. There are, however, three ways to do it with the original signature. Currently, I think that signature change would be inevitable for ptep_set_wrprotect. 1. implement copy_user_highpage ... this allows us to copy through the child's page cache (which is coherent with the parent's before the cow) and thus pick up any cache changes without a flush Let me think about this way. Well, this would improve both cases of the first scenario of mine and the second scenario. But... I think that even if we would have copy_user_highpage which does copy by user address, we need to flush at ptep_set_wrprotect. I think that we need to keep the condition: no dirty cache for COW page. Think about third scenario of threads and fork: (1) In process A, there are multiple threads, and a thread A-1 invokes fork. We have process B, with a different space identifier color. (2) Another thread A-2 in process A runs while A-1 copies memory by dup_mmap. A-2 writes to the address x in a page. Let's call this page oldpage. (3) We have dirty cache for x by A-2 at the time of ptep_set_wrprotect of thread A-1. Suppose that we don't flush here. (4) A-1 finishes copy, and sleeps. (5) Child process B is waken up and sees old value at x in oldpage, through different cache line. B sleeps. (6) A-2 is waken up. A-2 touches the memory again, breaks COW. A-2 copies data on oldpage to newpage. OK, newpage is consistent with copy_user_highpage by user address. Note that during this copy, the cache line of x by A-2 is flushed out to oldpage. It invokes another memory fault and COW break. (I think that this memory fault is unhealthy.) Then, new value goes to x on oldpage (when it's physically tagged cache). A-2 sleeps. (7) Child process B is waken up. When it accesses at x, it sees new value suddenly. If we flush cache to oldpage at ptep_set_wrprotect, this couldn't occur. * * * I know that we should not do threads and fork. It is difficult to define clean semantics. Because another thread may touch memory while a thread which does memory copy for fork, the memory what the child process will see may be inconsistent. For the child, a page might be new, while another page might be old. For VIVT-WB cache machine, I am considering a possibility for the child process to have inconsistent memory even within a single page (when we have no flush at ptep_set_wrprotect). It will be needed for me to talk to linux-arch soon or later. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595839: verilog-mode: diff for NMU version 558-1.1
gregor herrmann wrote: tags 595839 + patch tags 595839 + pending thanks Dear maintainer, I've prepared an NMU for verilog-mode (versioned as 558-1.1) and uploaded it to DELAYED/2. Please feel free to tell me if I should delay it longer. Thanks. However, I think that verilog-mode should be deleted. That's because it has been integrated into GNU Emacs 23 already. The package is exactly for older Emacsen such as GNU Emacs 21 / GNU Emacs 22. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595839: verilog-mode: diff for NMU version 558-1.1
gregor herrmann wrote: I guess now - I should cancel the NMU and - you will file a removal request Ok? Yes, I will do file the removal request next week. -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603983: gnupg2: Signing with SHA256 by Smartcard
Package: gnupg2 Version: 2.0.14-2 Severity: normal With Smartcard, signing with SHA256 is not possible in current gpg2 in Debian. It is already fixed in trunk, please consider to include the fix for Debian. Message in list: http://lists.gnupg.org/pipermail/gnupg-devel/2010-November/025819.html Fix by Gentoo guy: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/app-crypt/gnupg/files/gnupg-2.0.16-opengpgv2-sha2.patch?revision=1.1view=markup -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg2 depends on: ii dpkg1.15.8.5 Debian package management system ii gnupg-agent 2.0.14-2 GNU privacy guard - password agent ii install-info4.13a.dfsg.1-6 Manage installed documentation in ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.2-1 Multi-protocol file transfer libra ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libgpg-error0 1.6-1library for common error values an ii libksba81.0.7-2 X.509 and CMS support library ii libreadline66.1-3GNU readline and history libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnupg2 recommends: ii libldap-2.4-2 2.4.23-6 OpenLDAP libraries Versions of packages gnupg2 suggests: pn gnupg-doc none (no description available) pn xloadimagenone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603984: gnupg2: scdaemon: once error, no success any more
Package: gnupg2
Version: 2.0.14-2
Severity: normal
When scdaemon got some error, it does not recover. Then, gpg2 doesn't
work any more. The problem is reported to upstream already. Please
consider to apply my patch.
Message in the list:
http://lists.gnupg.org/pipermail/gnupg-devel/2010-November/025828.html
Index: scd/command.c
===
--- scd/command.c (revision 5485)
+++ scd/command.c (working copy)
@@ -305,7 +305,11 @@
{
if (apdu_reset (slot))
{
+#if 0
slot_table[slot].reset_failed = 1;
+#else
+ slot_table[slot].valid = 0;
+#endif
}
application_notify_card_reset (slot);
}
@@ -394,7 +398,11 @@
/* Try to open the reader. */
if (ss-slot == -1)
-ss-slot = apdu_open_reader (opt.reader_port);
+{
+ ss-slot = apdu_open_reader (opt.reader_port);
+ if (ss-slot == -1)
+ ss-valid = 0;
+}
/* Return the slot_table index. */
return 0;
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages gnupg2 depends on:
ii dpkg1.15.8.5 Debian package management system
ii gnupg-agent 2.0.14-2 GNU privacy guard - password agent
ii install-info4.13a.dfsg.1-6 Manage installed documentation in
ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libcurl3-gnutls 7.21.2-1 Multi-protocol file transfer libra
ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr
ii libgpg-error0 1.6-1library for common error values an
ii libksba81.0.7-2 X.509 and CMS support library
ii libreadline66.1-3GNU readline and history libraries
ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages gnupg2 recommends:
ii libldap-2.4-2 2.4.23-6 OpenLDAP libraries
Versions of packages gnupg2 suggests:
pn gnupg-doc none (no description available)
pn xloadimagenone (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603985: gnupg2: scdaemon sends SIGUSR2 to foreground gpg-agent
Package: gnupg2 Version: 2.0.14-2 Severity: normal When there is no gpg-agent, gpg2 with smartcard doesn't works well. A fix is already committed to upstram trunk. Please consider to include the fix to Debian. The message in the list: http://lists.gnupg.org/pipermail/gnupg-devel/2010-November/025817.html The patch: http://lists.gnupg.org/pipermail/gnupg-devel/attachments/2010/ecd7b53d/attachment.asc The patch cannot be applied to 2.0.14 directly, but it can be easily applied manually. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg2 depends on: ii dpkg1.15.8.5 Debian package management system ii gnupg-agent 2.0.14-2 GNU privacy guard - password agent ii install-info4.13a.dfsg.1-6 Manage installed documentation in ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.2-1 Multi-protocol file transfer libra ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libgpg-error0 1.6-1library for common error values an ii libksba81.0.7-2 X.509 and CMS support library ii libreadline66.1-3GNU readline and history libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnupg2 recommends: ii libldap-2.4-2 2.4.23-6 OpenLDAP libraries Versions of packages gnupg2 suggests: pn gnupg-doc none (no description available) pn xloadimagenone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603987: gnupg2: scdaemon sends SIGUSR2 to foreground gpg-agent
Package: gnupg2 Version: 2.0.14-2 Severity: normal Using gpg2 with smartcard, we need a fix for foreground gpg-agent. It is reported to upstream and fix is already committed to trunk. Please consider to apply the fix for Debian. Message in the mailing list: http://lists.gnupg.org/pipermail/gnupg-devel/2010-November/025817.html The patch: http://lists.gnupg.org/pipermail/gnupg-devel/attachments/2010/ecd7b53d/attachment.asc The patch can not be applied to 2.0.14 (because trunk includes support of WindowsCE), but it is easily applied manually. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages gnupg2 depends on: ii dpkg1.15.8.5 Debian package management system ii gnupg-agent 2.0.14-2 GNU privacy guard - password agent ii install-info4.13a.dfsg.1-6 Manage installed documentation in ii libbz2-1.0 1.0.5-6 high-quality block-sorting file co ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.21.2-1 Multi-protocol file transfer libra ii libgcrypt11 1.4.5-2 LGPL Crypto library - runtime libr ii libgpg-error0 1.6-1library for common error values an ii libksba81.0.7-2 X.509 and CMS support library ii libreadline66.1-3GNU readline and history libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages gnupg2 recommends: ii libldap-2.4-2 2.4.23-6 OpenLDAP libraries Versions of packages gnupg2 suggests: pn gnupg-doc none (no description available) pn xloadimagenone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#578337: libgc: Fixing FTBFS (7.1)
Hello, Chris Lamb, 2010-06-07 09:55, NIIBE Yutaka wrote: Seven weeks ago, as #578337, I filed a bug report for libgc wrt fixing FTBFS. But I see no progress yet. Chris, do you get the bug report? Please check it. The upstream is about to release new version. Please work for libgc in Debian. I am sending this messaget to you, because I think that you are the maintainer of libgc package. --- Date: Wed, 12 Aug 2009 02:16:30 +0100 Source: libgc Binary: libgc1c2 libgc-dev Architecture: source amd64 Version: 1:7.1-1 Distribution: experimental Urgency: low Maintainer: Chris Lamb la...@debian.org Changed-By: Chris Lamb la...@debian.org Description: libgc-dev - conservative garbage collector for C (development) libgc1c2 - conservative garbage collector for C and C++ Closes: 329338 422440 434106 446068 535985 541015 Changes: libgc (1:7.1-1) experimental; urgency=low . * New maintainer. (Closes: #541015) [...] --- -- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
