Bug#1019973: netbase: Update /etc/rpc from glibc/inet/etc.rpc
Package: netbase Version: 6.3 Severity: wishlist X-Debbugs-Cc: none, OGAWA Hirofumi Dear Maintainer, For NFS, it can be using RPC program number 100227 for nfs acl. But current debian /etc/rpc is missing the entry for it. So "ss -a -r" can't resolve rpc service name for example. In glibc/inet/etc.rpc nfs_acl 100227 Example of "ss -a -r" tcp LISTEN 0 64 0.0.0.0:2049 0.0.0.0:* should be tcp LISTEN 0 64 0.0.0.0:rpc.nfs_acl 0.0.0.0:* Thanks. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.19.9 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) -- no debconf information -- OGAWA Hirofumi
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
bash-5.0 fixed the nanosecond timestamp compare bug. So, in the case of /bin/sh == /bin/bash, this will be fixed. -- OGAWA Hirofumi
Bug#885694: bash: Fix nanosecond timestamp test
This was fixed at version 5.0-1. -- OGAWA Hirofumi
Bug#906123: texlive-extra-utils: The patch of a2ping is incorrect
Package: texlive-extra-utils Severity: normal $ head /usr/share/texlive/texmf-dist/scripts/a2ping/a2ping.pl +#! /usr/bin/perl -w +package Htex::a2ping; # # This program is free software, licensed under the GNU GPL, >=2.0. # This software comes with absolutely NO WARRANTY. Use at your own risk! # Note, this is not a patch, is actual installed script. Like this, the patch for a2ping.pl is incorrect (adding "+" for 2 lines at top). Please removing incorrect "+" from the patch for a2ping.pl. Thanks. -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.17.14 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) -- OGAWA Hirofumi
Bug#885694: bash: Fix nanosecond timestamp test
Package: bash Version: 4.4-5 Severity: normal Dear Maintainer, Current bash of source using by this package is not supporting nanoseconds timestamp comparing (e.g. [ A -ot B ]) correctly. The bug is missing update of bash-4.4/config.h.in. Without this, bash supports only second precision, so it becomes the cause of fail of some scripts (e.g. setupcon miss understands updated cache file). (bash.git commitid is b90cb5a280ebb8ac03306a5b19aea6b997c71ee7) --- config.h.in |1 + 1 file changed, 1 insertion(+) diff -puN config.h.in~stat-time-fix config.h.in --- bash-4.4/config.h.in~stat-time-fix 2017-12-29 15:48:33.524667872 +0900 +++ bash-4.4-hirofumi/config.h.in 2017-12-29 15:48:48.893632593 +0900 @@ -449,6 +449,7 @@ #undef SYS_TIME_H_DEFINES_STRUCT_TIMESPEC #undef PTHREAD_H_DEFINES_STRUCT_TIMESPEC +#undef HAVE_STRUCT_STAT_ST_ATIM_TV_NSEC #undef TYPEOF_STRUCT_STAT_ST_ATIM_IS_STRUCT_TIMESPEC #undef HAVE_STRUCT_STAT_ST_ATIMESPEC_TV_NSEC #undef HAVE_STRUCT_STAT_ST_ATIMENSEC _ -- System Information: Debian Release: buster/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.14.8 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages bash depends on: ii base-files 10 ii dash 0.5.8-2.5 ii debianutils 4.8.3 ii libc62.25-5 ii libtinfo56.0+20171125-1 Versions of packages bash recommends: pn bash-completion Versions of packages bash suggests: ii bash-doc 4.4-5 -- no debconf information -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
Hi, I got same issue with this bug, and checked the details of bug. # stat /etc/console-setup/cached_ISO-8859-1_del.kmap.gz File: /etc/console-setup/cached_ISO-8859-1_del.kmap.gz Size: 4793 Blocks: 16 IO Block: 4096 regular file Device: 801h/2049dInode: 18350479Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2017-01-29 19:32:33.001665826 +0900 Modify: 2017-11-28 14:10:18.621974890 +0900 Change: 2017-11-28 14:10:18.621974890 +0900 Birth: - # stat /etc/default/console-setup File: /etc/default/console-setup Size: 281 Blocks: 8 IO Block: 4096 regular file Device: 801h/2049dInode: 18350186Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) Access: 2017-11-28 14:10:18.009968364 +0900 Modify: 2017-11-28 14:10:18.005968321 +0900 Change: 2017-11-28 14:10:18.005968321 +0900 Birth: - Here is timestamps of some of affected files. Like above, FS is using nanoseconds timestamp, and cached is newer than config file (/etc/default/console-setup) as expected. But the issue in bash, # if [ /etc/default/console-setup -ot /etc/console-setup/cached_ISO-8859-1_del.kmap.gz ]; then echo yes; else echo no; fi no On debian, bash is not compiled with nanoseconds support (this seems be the bug of bash). So, if same timestamp in seconds resolution, setupcon confuses like the following log. + '[' -z '' -a -f /etc/console-setup/cached_ISO-8859-1_del.kmap.gz ']' + '[' /etc/default/keyboard -ot /etc/console-setup/cached_ISO-8859-1_del.kmap.gz -a /etc/default/console-setup -ot /etc/console-setup/cached_ISO-8859-1_del.kmap .gz ']' + '[' '' ']' + tempfile ++ mktemp /tmp/tmpkbd.XX + TMPFILE=/tmp/tmpkbd.kmP7z9 + tempfiles=' /tmp/tmpkbd.kmP7z9' So, my suggestion to fix this bug, choose the cached file if same timestamp, not only older. With this patch, seems to be working as expected in my case (if console-setup and cached_* was updated within same second). Thanks. --- setupcon~ 2017-11-28 14:33:16.030927321 +0900 +++ setupcon2017-11-28 15:05:46.735112236 +0900 @@ -1121,9 +1121,12 @@ if [ "$do_kbd" = linux ]; then fi fi +# If timestamp is same, use cached if \ -[ -z "$KMAP" -a -f "$cached" ] \ -&& [ "$CONFIG" -ot "$cached" -a "$CONFIG2" -ot "$cached" ] +[ -z "$KMAP" ] \ + && [ -f "$cached" ] \ + && [ ! "$cached" -ot "$CONFIG" ] \ + && [ ! "$cached" -ot "$CONFIG2" ] then KMAP="$cached" fi -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#846014: gnuplot-doc: gnuplot-doc has invalid info-dir-entry
Package: gnuplot-doc Version: 5.0.5+dfsg1-4 Severity: normal Hi, Current info for gnuplot-doc is "gnuplot.info.gz". But info-dir-entry of "gnuplot.info.gz" has, START-INFO-DIR-ENTRY * GNUPLOT5: (gnuplot5). An Interactive Plotting Program END-INFO-DIR-ENTRY So, by mismatch of "(gnuplot5)" vs "gnuplot.info.gz", the info browser finds "gnuplot5.info.gz", instead of "gnuplot.info.gz". E.g. $ info gnuplot5 [info says "Unable to find node referenced by 'GNUPLOT5' in '(dir)Top'."] -- System Information: Debian Release: stretch/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.8.10 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#804703: gnome-keyring: The race with SessionManager initialization
Jeremy Bicha <jbi...@linux.com> writes: > Control: tags -1 moreinfo > > Please update to gnome-keyring 3.20.0-1 and report back whether this > fixes your bug. > > gnome-keyring 3.20 fixed https://bugzilla.gnome.org/738205 > (Despite the bug title, it wasn't limited to just Wayland sessions). At least for now, this bug is not reproduced. So it would be better to close the bug. If reproduced, I will re-open. Thanks. -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#818697: [Pkg-tcltk-devel] Bug#818697: libtcl8.6: Segv in Tcl_FinalizeNotifier()
Sergei Golovan <sgolo...@nes.ru> writes:
>> Tcl_FinalizeNotifier() is using following combination
>>
>> pthread_mutex_lock();
>> pthread_cond_wait(, );
>> pthread_mutex_unlock();
>>
>> From history, this is clearly conversion mistake. notifierInitMutex should be
>> notifierMutex (no Init).
>
> I'm not sure that the correct way to fix this is to replace
> notifierInitMutex by notifierMutex. The notifierInitMutex was
> introduced recently, and I think it was intentional. So, maybe to fix
> this we should go the other way: replace notifierMutex by
> notifierInitMutex in pthread_cond_wait? Could you try and comment on
> this as well? I don't have access to hardware with HLE/RTM extensions,
> so can't test myself.
I see. Then another candidate is the following.
pthread_mutex_lock();
pthread_mutex_lock();
pthread_cond_wait(, );
pthread_mutex_unlock();
pthread_mutex_unlock();
Because notifierCV is protected by notifierMutex in other places
(StartNotifierThread and NotifierThreadProc). So without notifierMutex
lock, it would be wrong way (has possibility of race).
So, I tested the following version, and it seems to be working.
---
debian/changelog|6 ++
unix/tclUnixNotfy.c |2 ++
2 files changed, 8 insertions(+)
diff -puN unix/tclUnixNotfy.c~fix-mutex-typo unix/tclUnixNotfy.c
--- tcl8.6-8.6.5+dfsg/unix/tclUnixNotfy.c~fix-mutex-typo2016-03-19
01:56:33.736475677 +0900
+++ tcl8.6-8.6.5+dfsg-hirofumi/unix/tclUnixNotfy.c 2016-03-20
20:42:03.421497517 +0900
@@ -433,9 +433,11 @@ Tcl_FinalizeNotifier(
"unable to write q to triggerPipe");
}
close(triggerPipe);
+ pthread_mutex_lock();
while(triggerPipe != -1) {
pthread_cond_wait(, );
}
+ pthread_mutex_unlock();
if (notifierThreadRunning) {
int result = pthread_join((pthread_t) notifierThread, NULL);
--
OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#818697: libtcl8.6: Segv in Tcl_FinalizeNotifier()
Package: libtcl8.6 Version: 8.6.5+dfsg-2 Severity: normal When closing wish, process die at pthread_cond_wait(, ); if cpu is supporting HLE/RTM. (xend instruction doesn't allow to use without xbegin) Tcl_FinalizeNotifier() is using following combination pthread_mutex_lock(); pthread_cond_wait(, ); pthread_mutex_unlock(); >From history, this is clearly conversion mistake. notifierInitMutex should be notifierMutex (no Init). --- unix/tclUnixNotfy.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN unix/tclUnixNotfy.c~fix-mutex-typo unix/tclUnixNotfy.c --- tcl8.6-8.6.5+dfsg/unix/tclUnixNotfy.c~fix-mutex-typo2016-03-19 01:25:29.900145502 +0900 +++ tcl8.6-8.6.5+dfsg-hirofumi/unix/tclUnixNotfy.c 2016-03-19 01:24:20.795871648 +0900 @@ -417,7 +417,7 @@ Tcl_FinalizeNotifier( #ifdef TCL_THREADS ThreadSpecificData *tsdPtr = TCL_TSD_INIT(); - pthread_mutex_lock(); + pthread_mutex_lock(); notifierCount--; /* @@ -460,7 +460,7 @@ Tcl_FinalizeNotifier( #endif /* __CYGWIN__ */ tsdPtr->waitCVinitialized = 0; - pthread_mutex_unlock(); + pthread_mutex_unlock(); #endif /* TCL_THREADS */ } } _ -- System Information: Debian Release: stretch/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.5 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages libtcl8.6 depends on: ii libc6 2.22-3 ii tzdata 2016a-1 ii zlib1g 1:1.2.8.dfsg-2+b1 libtcl8.6 recommends no packages. Versions of packages libtcl8.6 suggests: ii tcl8.6 8.6.5+dfsg-1 -- no debconf information -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#818665: libvirglrenderer-dev: Missing virglrenderer.pc for pkg-config
Package: libvirglrenderer-dev Version: 0.4.0-5 Severity: normal Hi, qemu uses pkg-config to detect libvirglrenderer package to use. Please include virglrenderer.pc to libvirglrenderer-dev. Maybe, add line to debian/rules/libvirglrenderer-dev.install? Thanks. -- System Information: Debian Release: stretch/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.4.5 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages libvirglrenderer-dev depends on: ii libvirglrenderer0 0.4.0-5 libvirglrenderer-dev recommends no packages. libvirglrenderer-dev suggests no packages. -- no debconf information -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#805768: vinagre: Remove freerdp-x11 from Recommends
Package: vinagre Version: 3.18.2-1 Severity: normal Hi, In my current install, freerdp-x11 for vinagre's recommends is the last user of obsoleted gst-0.10. So I checked why vinagre wants freerdp-x11. In old code of vinagre, it used xfreerdp binary directly. But current code already uses freerdp library, not xfreerdp binary. So, I think we drop freerdp-x11 from Recommends of vinagre. If I'm missing something, please drop freerdp-x11 from Recommends. Thanks. -- System Information: Debian Release: stretch/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.18.24 (SMP w/8 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: sysvinit (via /sbin/init) Versions of packages vinagre depends on: ii dconf-gsettings-backend [gsettings- 0.24.0-2 ii libavahi-common3 0.6.32~rc+dfsg-1 ii libavahi-gobject00.6.32~rc+dfsg-1 ii libavahi-ui-gtk3-0 0.6.32~rc+dfsg-1 ii libc62.19-22 ii libcairo21.14.4-1 ii libdbus-glib-1-2 0.102-1 ii libfreerdp-core1.1 1.1.0~git20140921.1.440916e+dfsg1-5+b1 ii libfreerdp-gdi1.11.1.0~git20140921.1.440916e+dfsg1-5+b1 ii libfreerdp-locale1.1 1.1.0~git20140921.1.440916e+dfsg1-5+b1 ii libgdk-pixbuf2.0-0 2.32.2-1 ii libglib2.0-0 2.46.2-1 ii libgtk-3-0 3.18.2-1 ii libgtk-vnc-2.0-0 0.5.3-1.3 ii libsecret-1-00.18.3-1 ii libspice-client-glib-2.0-8 0.29-1+b1 ii libspice-client-gtk-3.0-40.29-1+b1 ii libtelepathy-glib0 0.24.1-1.1 ii libvte-2.91-00.42.1-1 ii libxml2 2.9.2+zdfsg1-4 Versions of packages vinagre recommends: pn freerdp-x11 vinagre suggests no packages. -- no debconf information -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#736824: New release of POSIX manpages
0 21:09:19.586128995 +0900
@@ -1,6 +1,6 @@
Andries copies some new files to this location, so it should be
checked frequently:
- ftp://ftp.win.tue.nl/pub/home/aeb/linux-local/manpages/
+ https://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/
This is an internal reminder.
diff -urNp a/debian/rules b/debian/rules
--- a/debian/rules 2004-08-27 17:46:51.0 +0900
+++ b/debian/rules 2015-11-10 21:32:42.949169977 +0900
@@ -1,7 +1,5 @@
#! /usr/bin/make -f
-export DH_COMPAT=2
-
PKGNAME=manpages-posix
build:
@@ -11,9 +9,8 @@ build:
clean:
dh_testdir
dh_testroot
- rm -f build-stamp install-stamp
- -rm -rf *~ *.orig "#*" debian/$(PKGNAME) debian/$(PKGNAME)-dev debian/*~ debian/files*
- -find man? -name '*~' -exec rm {} \;
+ -rm -rf debian/$(PKGNAME) debian/$(PKGNAME)-dev
+ -find man?p -name '*~' -exec rm {} \;
dh_clean
binary-arch: build
diff -urNp a/debian/source/format b/debian/source/format
--- a/debian/source/format 1970-01-01 09:00:00.0 +0900
+++ b/debian/source/format 2015-11-10 22:40:07.280386219 +0900
@@ -0,0 +1 @@
+3.0 (quilt)
diff -urNp a/debian/watch b/debian/watch
--- a/debian/watch 1970-01-01 09:00:00.0 +0900
+++ b/debian/watch 2015-11-10 22:01:55.289029232 +0900
@@ -0,0 +1,2 @@
+version=3
+https://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/man-pages-posix-(\d+)-a\.tar\.xz
EOF
--
OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#736824: New release of POSIX manpages
On Tue, 10 Nov 2015 23:30:12 +0900 OGAWA Hirofumi <hirof...@mail.parknet.co.jp> wrote: > On Mon, 27 Jan 2014 09:33:55 +0100 Francesco Paolo Lovergine > <fran...@debian.org> wrote: > > Package: manpages-posix > > Version: 2.16-1 > > Severity: wishlist > > I wrote script to help package update. This makes manpages-posix-2.17 > with patched debian/ for 2.17. > > Please update this package. This update fixes bugs (#470841, #522292, #705032). And maybe (#520162)? -- OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#804703: gnome-keyring: The race with SessionManager initialization
Package: gnome-keyring
Version: 3.18.2-1
Severity: normal
Hi,
When I start gnome-session (not sure if startx is important to
reproduce) by
$ startx
Current gnome-keyring has the race with org.gnome.SessionManager
initialization of gnome-session. Because dbus doesn't seem to make the
name available to others immediately.
The sequence of the race is:
gnome-session gnome-keyring
.SessionManager init
run autostart apps
start by autostart
call .SessionManager.Setenv
call .SessionManager.ClientPrivate
.SessionManager available
This race becomes the cause of random Setenv failure for SSH_AUTH_SOCK
for example like following.
** Message: couldn't register in session:
GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name
org.gnome.SessionManager was not provided by any .service files
To fix this, the attached patch starts to watch .NameOwnerChanged before
calling .SessionManager. With this, if .SessionManager is not available
yet, callings are done via .NameOwnerChanged notification.
Then, after makes sure calling of .SessionManager was done, this
removes watch of .NameOwnerChanged.
-- System Information:
Debian Release: stretch/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.18.24 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages gnome-keyring depends on:
ii dbus-x11 1.10.2-1
ii dconf-gsettings-backend [gsettings-backend] 0.24.0-2
ii gcr 3.18.0-1
ii libc62.19-22
ii libcap-ng0 0.7.7-1
ii libcap2-bin 1:2.24-12
ii libgck-1-0 3.18.0-1
ii libgcr-base-3-1 3.18.0-1
ii libgcrypt20 1.6.4-3
ii libglib2.0-0 2.46.1-2
ii p11-kit 0.23.1-3
ii pinentry-gnome3 0.9.6-4
Versions of packages gnome-keyring recommends:
ii libpam-gnome-keyring 3.18.2-1
gnome-keyring suggests no packages.
-- no debconf information
--
OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Current gnome-keyring has the race with org.gnome.SessionManager
initialization of gnome-session. Because dbus doesn't make the name
available to others immediately.
The sequence of the race is:
gnome-session gnome-keyring
.SessionManager init
run autostart apps
start by autostart
call .SessionManager.Setenv
call .SessionManager.ClientPrivate
.SessionManager available
This race becomes the cause of random Setenv failure for SSH_AUTH_SOCK
for example like following.
** Message: couldn't register in session: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files
To fix this, this starts to watch .NameOwnerChanged before calling
.SessionManager. With this, if .SessionManager is not available yet,
callings are done via .NameOwnerChanged notification.
Then, after makes sure calling of .SessionManager was done, this
removes watch of .NameOwnerChanged.
---
daemon/dbus/gkd-dbus-environment.c |9 ++-
daemon/dbus/gkd-dbus-session.c | 89 ++--
daemon/dbus/gkd-dbus.c |1
3 files changed, 92 insertions(+), 7 deletions(-)
diff -puN daemon/dbus/gkd-dbus-environment.c~session-race-fix daemon/dbus/gkd-dbus-environment.c
--- gnome-keyring-3.18.2/daemon/dbus/gkd-dbus-environment.c~session-race-fix 2015-10-29 20:37:32.812933216 +0900
+++ gnome-keyring-3.18.2-hirofumi/daemon/dbus/gkd-dbus-environment.c 2015-10-29 20:38:12.196871701 +0900
@@ -103,6 +103,7 @@ on_watch_environment (gpointer data, gpo
void
gkd_dbus_environment_init (GDBusConnection *conn)
{
+ static gboolean watch_installed = FALSE;
const gchar **envp;
/*
@@ -114,6 +115,10 @@ gkd_dbus_environment_init (GDBusConnecti
for (; *envp; ++envp)
setenv_request (conn, *envp);
- gkd_util_watch_environment (on_watch_environment, g_object_ref (conn),
-(GDestroyNotify) g_object_unref);
+ if (!watch_installed) {
+ watch_installed = TRUE;
+ gkd_util_watch_environment (on_watch_environment,
+ g_object_ref (conn),
+ (GDestroyNotify) g_object_unref);
+ }
}
diff -puN daemon/dbus/gkd-dbus-session.c~session-race-fix daemon/dbus/gkd-dbus-session.c
--- gnome-keyring-3.18.2/daemon/dbus/gkd-dbus-session.c~session-race-fi
Bug#798094: man-db: Bug of scripting usage with "man -a"
Package: man-db
Version: 2.7.2-1
Severity: normal
Current "man -a" uses /dev/tty unconditionally. This means no way to use
for scripting usage, or such.
For example, emacs can view all manpages via (setq Man-switches "-a").
With this configuration, emacs does
man -a | post-process
But current man version asks via /dev/tty in background, and bother emacs.
Also simple example is,
$ man -a | less
Older versions can show all manpages as contiguous file. Current version
ask to user via /dev/tty in background from man command, totally useless.
The following patch restores the behavior of older version.
Thanks.
src/man.c |4
1 file changed, 4 insertions(+)
diff -puN src/man.c~script-usage-fix src/man.c
--- man-db-2.7.2/src/man.c~script-usage-fix 2015-09-05 23:16:15.120264227
+0900
+++ man-db-2.7.2-hirofumi/src/man.c 2015-09-05 23:28:19.507147470 +0900
@@ -2015,6 +2015,10 @@ static inline int do_prompt (const char
FILE *tty = NULL;
skip = 0;
+ /* If no interactive, choose "view" without asking */
+ if (!isatty (STDOUT_FILENO) || !isatty (STDIN_FILENO))
+ return 0;
+
tty = fopen ("/dev/tty", "r+");
if (!tty)
return 0;
_
-- System Information:
Debian Release: stretch/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.18.5 (SMP w/8 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
Versions of packages man-db depends on:
ii bsdmainutils 9.0.6
ii debconf [debconf-2.0] 1.5.57
ii dpkg 1.18.2
ii groff-base 1.22.3-1
ii libc6 2.19-19
ii libgdbm3 1.8.3-13.1
ii libpipeline1 1.4.1-1
ii zlib1g 1:1.2.8.dfsg-2+b1
man-db recommends no packages.
Versions of packages man-db suggests:
ii epiphany-browser [www-browser] 3.16.3-1
ii groff 1.22.3-1
ii less458-3
ii lynx-cur [www-browser] 2.8.9dev6-3
ii w3m [www-browser] 0.5.3-24
-- debconf information:
* man-db/install-setuid: false
man-db/auto-update: true
--
OGAWA Hirofumi <hirof...@mail.parknet.co.jp>
Bug#586455: eblook: --with-readline became the cause of wrong behavior
Package: eblook Version: 1:1.6.1-6 Severity: normal Hi, I recently saw the eblook's wrong behavior with -e euc-jp on LANG=ja_JP.UTF-8. For example session (note input is euc-jp), $ LANG=ja_JP.UTF-8 /home/hirofumi/bin/eblook -q -e euc-jp /usr/local/share/dict/srd-fpw eblook select 1 eblook search テスト 1. 12079:1506 exgaiji=ha263amgaiji=ha263igaiji=ha263nagaiji=ha263tion [テスト] 2. 23711:1208 ngaiji=ha332eds assgaiji=ha331ssment [テスト] 3. 27110:218 pigaiji=ha263lot [テスト] 4. 29302:178 quegaiji=ha263ry [テスト] 5. 36889:748 test1 [テスト] 6. 38349:652 trgaiji=ha346gaiji=ha263gaiji=ha33but [テスト] eblook set prompt eblook Unkown command: set prompt eblook eblook Note, I inputed select 1 search テスト set prompt eblook actually, but the behavior is 'search テスト'. With some debugging, the cause of this behavior looks like readline() returned the 'search テスト'. Because, perhaps locale is UTF-8, but input text was EUC-JP, I'm not sure though. This setup (-e euc-jp on UTF-8) is the default of lookup-el on emacs. Any idea to fix this? -- System Information: Debian Release: squeeze/sid APT prefers testing-proposed-updates APT policy: (500, 'testing-proposed-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.33 (SMP w/2 CPU cores) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages eblook depends on: ii dpkg1.15.7.2 Debian package management system ii install-info4.13a.dfsg.1-5 Manage installed documentation in ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libeb13 4.4.2-2 C library for accessing electronic ii libncurses5 5.7+20100313-2 shared libraries for terminal hand ii libreadline66.1-3GNU readline and history libraries ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime eblook recommends no packages. Versions of packages eblook suggests: pn lookup-el none (no description available) -- no debconf information -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#586455: eblook: --with-readline became the cause of wrong behavior
Tatsuya Kinoshita t...@vega.ocn.ne.jp writes: On June 20, 2010 at 2:24AM +0900, hirofumi (at mail.parknet.co.jp) wrote: Package: eblook Version: 1:1.6.1-6 Severity: normal [...] I recently saw the eblook's wrong behavior with -e euc-jp on LANG=ja_JP.UTF-8. [...] With some debugging, the cause of this behavior looks like readline() returned the 'search テスト'. Because, perhaps locale is UTF-8, but input text was EUC-JP, I'm not sure though. This setup (-e euc-jp on UTF-8) is the default of lookup-el on emacs. Any idea to fix this? Hmm, with or without readline(), eblook on UTF-8 seems buggy. BTW, what problem? I didn't have any problem with previous eblook version on debian/testing until now (sorry, I forgot actual version). Does LC_ALL=C prevent your problem? I'm thinking about updating the lookup-el package as follows. I'm not using lookup-el package actually, because I'm using emacs on bzr with custom lookup. So, I tested it with the following, $ cat ~/bin/eblook #!/bin/sh export LANGUAGE=C export LC_ALL=C export LANG=C exec /usr/bin/eblook $@ $ and with this hack, it seems to work for me (tested a few word only though). However, if eblook is really buggy on UTF-8, why don't we set C to locale in eblook? Thanks. -- OGAWA Hirofumi hirof...@mail.parknet.co.jp -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#451819: bash: clear_console segv if stdin isn't tty
Package: bash
Version: 3.1dfsg-8
Severity: normal
I've found the bug of clear_console.
It happened on shutdown process. If login was killed before bash,
the session will be gone. So ttyname() will return NULL. Then
clear_console will die with SEGV if .bash_logout runs clear_console.
The attached patch fixes it by does nothing if stdin is not tty.
--
OGAWA Hirofumi [EMAIL PROTECTED]
--- bash-3.1dfsg/debian/clear_console.c.orig 2007-11-19 03:52:34.0 +0900
+++ bash-3.1dfsg/debian/clear_console.c 2007-11-19 03:45:10.0 +0900
@@ -139,6 +139,9 @@ int is_pseudo_tty(int fd)
{
char *tty = ttyname(fd);
+ if (tty == NULL)
+return -1;
+
if (!strncmp(tty, /dev/pts/, 9))
return 1;
Bug#343648: file: file_4.15-2 doesn't work, but file-4.16 works file.
Package: file Version: 4.15-2 Severity: wishlist [file_4.15-2] $ file KNOPPIX_V4.0.2CD-2005-09-23-EN.iso KNOPPIX_V4.0.2CD-2005-09-23-EN.iso: [file-4.16] $ file KNOPPIX_V4.0.2CD-2005-09-23-EN.iso KNOPPIX_V4.0.2CD-2005-09-23-EN.iso: ISO 9660 CD-ROM filesystem data 'KNOPPIX ' (bootable) The file_4.15-2 does not work for me, but the problem seems to have fixed in file-4.16. So, could you update the deb to file-4.16? ftp://ftp.astron.com/pub/file/ -- System Information Debian Release: testing/unstable Kernel Version: Linux devron 2.6.15-rc5 #1 SMP Fri Dec 16 03:38:00 JST 2005 i686 GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333776: linux-2.6: vfat driver in 2.6.12 is not properly case-insensitive
Ingo Oeser [EMAIL PROTECTED] writes: This is known bug. For fixing this bug cleanly, we will need to much change the both of nls and filesystems. Using per locale collation sequences? :-) Do you know, how Windows handles the problem of differing collation sequences on the file system? I don't know. Why do we need to care the collation sequences here? Or is the file system always dependend on the locale of the Windows version, which created the file system? Probably, yes. I think we need to know on-disk filename's code set. -- OGAWA Hirofumi [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333776: linux-2.6: vfat driver in 2.6.12 is not properly case-insensitive
Anton Altaparmakov [EMAIL PROTECTED] writes: Probably, yes. I think we need to know on-disk filename's code set. If FAT stores the filenames in 8 bits (non-UTF) then yes, it will be in the current locale/code page of the Windows system writing them (e.g. that happens with the names of EAs in NTFS). If the names are stored in 16-bit Unicode like on NTFS then obviously they are completely locale/code page independent. (Makes my life in NTFS a _lot_ easier. Especially since the NTFS volume contains an upcase table for the full 16-bit Unicode which we load and use to do upcasing for the case insensitive comparisons...) Yes, I got to know it from fs/ntfs/*. :) Unfortunately, FAT stores 8/16bits codeset filename always. (Unicode (UCS2?) is stored in only case of longname.) Thanks. -- OGAWA Hirofumi [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333776: linux-2.6: vfat driver in 2.6.12 is not properly case-insensitive
Horms [EMAIL PROTECTED] writes:
static struct nls_table table = {
.charset= utf8,
.uni2char = uni2char,
.char2uni = char2uni,
.charset2lower = identity, /* no conversion */
.charset2upper = identity,
.owner = THIS_MODULE,
};
I guess it is charset2lower or charset2upper that vfat is calling,
which make no conversion, thus leading to the problem I outlined above.
My question is: Is this behaviour correct, or is it a bug?
This is known bug. For fixing this bug cleanly, we will need to much
change the both of nls and filesystems.
Thanks.
--
OGAWA Hirofumi [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#333776: linux-2.6: vfat driver in 2.6.12 is not properly case-insensitive
OGAWA Hirofumi [EMAIL PROTECTED] writes:
Horms [EMAIL PROTECTED] writes:
static struct nls_table table = {
.charset= utf8,
.uni2char = uni2char,
.char2uni = char2uni,
.charset2lower = identity, /* no conversion */
.charset2upper = identity,
.owner = THIS_MODULE,
};
I guess it is charset2lower or charset2upper that vfat is calling,
which make no conversion, thus leading to the problem I outlined above.
My question is: Is this behaviour correct, or is it a bug?
This is known bug. For fixing this bug cleanly, we will need to much
change the both of nls and filesystems.
And fatfs has utf8 option, probably the behavior is preferable than
iocharset=utf8. However, unfortunately utf8 has problem too.
--
OGAWA Hirofumi [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#308072: statfs returns wrong values for 250Gb FAT fs
Hi, Horms [EMAIL PROTECTED] writes: printf(f_bsize = %ld blocks\nf_blocks = %ld blocks\nf_bfree = %ld blocks\nused = %ld blocks\n, stats.f_bsize, stats.f_blocks, stats.f_bfree, used); kib = stats.f_bsize / 1024; printf(total = %ld KiB\nfree = %ld KiB\nused = %ld KiB\n, kib * stats.f_blocks, kib * stats.f_bfree, kib * used); Filesystem may have the corrupted free-cluster value. I couldn't reproduce the problem on 2.6.12-rc4. Could you try a recently dosfsck (dosfstools-2.11 or later)? Also could you send the output of above program? Thanks. -- OGAWA Hirofumi [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
