Bug#776627: fonts-misaki: GD (ruby-gd) fails to render Misaki font package in Debian, but works with latest upstream.
Package: fonts-misaki
Version: 11-20080603-15
Severity: normal
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
I tried to render text with GD graphics library (ruby-gd, which
uses libgd3 internally), and noticed rendering of Misaki font fails.
* What exactly did you do (or not do) that was effective (or
ineffective)?
Following code works (= renders) with all installed TTFs, but Misaki.
[font-test-with-gd.rb]
--- cut here --- cut here --- cut here ---
#!/usr/bin/ruby
# Quick test to see if GD can draw string with given TTF file.
require 'GD'
image = GD::Image.new(640, 480)
white = image.colorAllocate(0xff, 0xff, 0xff)
black = image.colorAllocate(0x00, 0x00, 0x00)
ARGV.each do |ttf|
ret = image.stringFT(black, ttf, 12, 0, 100, 100, ABC);
puts #{ret[0]}: #{ttf} unless ret[0].nil?
end
--- cut here --- cut here --- cut here ---
I was able to workaround the issue by downloading latest TTF from
upstream website:
- http://www.geocities.jp/littlimi/misaki.htm
- http://www.geocities.jp/littlimi/arc/misaki/misaki_ttf_2012-06-03.zip
With latest TTF, above code worked without an error.
* What was the outcome of this action?
$ echo /usr/share/fonts/truetype/*/*.ttf | wc -w
218
$ ./font-test-with-gd.rb /usr/share/fonts/truetype/*/*.ttf
Could not set character size: /usr/share/fonts/truetype/misaki/misaki.ttf
Could not set character size: /usr/share/fonts/truetype/misaki/misakimn.ttf
* What outcome did you expect instead?
I expected Misaki font to render successfully, without an error.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (600, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, mipsel
Kernel: Linux 3.13-1-amd64 (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/dash
Init: unable to detect
Versions of packages fonts-misaki depends on:
ii dpkg 1.17.23
fonts-misaki recommends no packages.
fonts-misaki 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#776627: fonts-misaki: GD (ruby-gd) fails to render Misaki font package in Debian, but works with latest upstream.
I think I should withdraw this report. This was not a issue with fonts-misaki package - but just happens to occur only with this package. Upstream Misaki TTF is provided in two forms: 1. outline-based TTF 2. embedded bitmap-based TTF GD seems to work only with #1 type TTF, and fails with #2. I got an error with fonts-misaki only, because all other installed fonts were #1 type. Since #2 type should give better result for certain usecase of Misaki, I guess keeping fonts-misaki in #2 form is better. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666047: netbase: Won't halt properly with NFSroot+aufs configuration
Package: netbase Version: 4.40 Severity: minor On certain configuration described below, system fails to halt during interface shutdown process and stalls in unusable state. === Description === When a system is running on NFSroot (or any other network-based storage/filesystem), netbase usually detects it, and skips doing ifdown(8) so it can properly halt. This is done by check_network_file_systems() in /etc/init.d/networking script. However, when a root filesystem is unionized by aufs, current detection method won't work, as /etc/init.d/umountnfs.sh can unmount NFS, even when it is a rootfs. After umount, its entry in /proc/mounts is gone, but NFS(-through-aufs) is still valid and in use. Due to this detection error, networking script goes on to do ifdown(8), and stalls shutdown process. It may be possible to use modprobe -r nfs to see if NFS is really in use or not, but that is too kludgy and NFS-specific (I'm certain this will happen with all network filesystem). It may be better to mark this as WONTFIX and just keep it as a record. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (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/dash Versions of packages netbase depends on: ii initscripts 2.87dsf-8 scripts for initializing and shutt ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip Versions of packages netbase recommends: ii ifupdown 0.6.9 high level tools to configure netw netbase 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#663055: cgroup-bin: Default configuration is too strict and causes LXC to fail
Package: cgroup-bin Version: 0.37.1-1 Severity: grave Tags: patch Justification: renders package unusable Hi. About a year ago, I reported - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588494 and mentioned that LXC fails to work due to cgroup-bin's default policy being too strict (CREATE_DEFAULT=yes causes LXC to fail). Since this was just a configuration issue and user can workaround it by reconfiguration, I didn't insist on fixing. But somebody else recently made a similar report to lxc package, and lxc package now marks cgroup-bin as a conflicting package: - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647769 Since both packages have no files in common that actually conflicts, I believe resolution would be to: 1. Update cgroup-bin package, so it uses less-strict configuration by default (i.e. CREATE_DEFAULT=no in /etc/default/cgconfig). 2. Update lxc package, so it drops Conflict: cgroup-bin entry which has too much impact on usage. I will be filing similar report to LXC package, so both maintainers can work together to fix the issue. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (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 Versions of packages cgroup-bin depends on: ii libc6 2.13-27Embedded GNU C Library: Shared lib ii libcgroup10.36.2-3 A library to control and monitor c cgroup-bin recommends no packages. cgroup-bin 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#663062: lxc and cgroup-bin are now in conflict and uninstallable
Package: lxc Version: 0.7.5-1 Severity: important As a resolution to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=647769 , lxc package recently added Conflict: cgroup-bin entry. Since both packages do not have any files in conflict, and because it is valuable to have both features side-by-side, I decided to open bug reports both to lxc and cgroup-bin. Following is a report I filed for cgroup-bin: cgroup-bin: Default configuration is too strict and causes LXC to fail - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663055 As this is only a matter of (default) configuration, I would like to ask for removal of Conflict: entry and just let user do reconfiguration. Also as FYI, I believe git commit d08ba6e (Support nested cgroups) made recently to lxc repository should resolve this issue ultimately. With above commit, lxc should run regardless of how cgroup-bin is configured, as long as it has enough privilege to run. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (600, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-1-amd64 (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 Versions of packages lxc depends on: ii libc6 2.13-27Embedded GNU C Library: Shared lib ii libcap2 1:2.22-1 support for getting/setting POSIX. Versions of packages lxc recommends: ii debootstrap 1.0.35 Bootstrap a basic Debian system ii libcap2-bin 1:2.17-2 basic utility programs for using c lxc 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#663055: cgroup-bin: Default configuration is too strict and causes LXC to fail
Just FYI, I have just filed following report to lxc package: lxc and cgroup-bin are now in conflict and uninstallable - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663062 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#643730: libswarmcache-java has no dependency info, while it does depend on some
Package: libswarmcache-java
Version: 1.0RC2+cvs20071027-5
Severity: normal
While libswarmcache depends on following libraries, it's missing
Depends: line in package description:
- libcommons-logging-java
- libcommons-collections-java
- libjgroups-java
This forces user to handle dependency manually, so should be
automated. Looking into control file, I think it's missing
Depends: ${java:Depends}
entry. So the fix is probably to update as follows:
current - Depends: ${shlibs:Depends}, ${misc:Depends}
shoule be - Depends: ${java:Depends}, ${shlibs:Depends}, ${misc:Depends}
Best Regards,
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (600, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
-- 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#638838: ITP: cocot -- Wraps and converts charset encoding of program input/output.
Package: wnpp Severity: wishlist Owner: Taisuke Yamada t...@rakugaki.org * Package name: cocot Version : 20100903 Upstream Author : IWAMURO Motonori v...@nifty.com * URL : http://vmi.jp/software/cygwin/cocot.html * License : BSD Programming Lang: C Description : Wraps and converts charset encoding of program input/output. Cocot stands for COde COnverter on Tty. This tool wraps specified program and converts charset encoding of its input/output. By this conversion, cocot allows you to run any program that may not support tty charset encoding. For example, running non-UTF-8 editor on UTF-8 terminal. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637517: gpasm/gplink not working for pic16f88 since 0.13.5
Hi Luca, As an extra check I tried to reproduce the problem in order to confirm the behaviour of the 3 versions of gputils I reported and I could not reproduce the problem on squeeze. Thanks for the reportback. Glad to hear you were able to run it fine on latest Debian. I'm going to close this report, but if you see any other issue, please submit it anytime. It's better to have false report rather than people having problems with my package due to something I have missed. Best Regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637517: gpasm/gplink not working for pic16f88 since 0.13.5
Hi. Thanks for reporting. I also checked out your report on gputils site. So you're saying - gputils-0.13.4 works - gputils-0.13.5 generates totally different hex, and won't work - gputils-0.13.7 generates similar hex to 0.13.4, but still won't work right? Could you provide me the problematic C source code so I can verify the issue? Package: gputils Version: 0.13.7-1 Hi, I am facing problems compiling c code for pic16f88 since years. In the beginning I was using an old debian 4.0 32bit system and with sdcc I was able to get good .hex files. When I moved to debian 5.0 64bit the .hex generated (still with sdcc) were broken and my programmer refused to burn them to the pic. The same happens now with debian 6.0 64bit. First I thought that the problem was in sdcc, but from hints by sdcc guy and the last tests I did, I verified the same intermediate .asm files on both systems (the working one and the non-workgin one) mentioned above (except some commented lines). Trying to track the problem I think I found something: on my new debian 6.0 64bit system I can get the correct .hex if I use gputils-0.13.4 compiled from source. If I use gputils-0.13.5 compiled from source I get .hex files messed up a lot. If I use gputils-0.13.7 compiled from source I get .hex files quite similar to the ones generated by gputils-0.13.4, but with few lines different, and they do not work. I also wrote to gputils bug tracking system almost one month ago, but I suspect that nobody is taking care of that bugs submissions. If you need further informations just ask. Ciao, Luca .-. -=(§ Luca morpheus AT ferrara.linux.it §)=- °-° -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584780: dropbear script for initramfs-tools breaks DNS (and any fixed-address) server.
Ah, and I noticed initial subject was misleading: I should have written Subject: dropbear script for initramfs-tools breaks DNS (and any fixed-address) server. Excuse me for that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584780: dropbear script for initramfs-tools breaks DHCP server.
Hi. Okay...let me rephrase my previous report to make the point clear. My concern is that you shouldn't be calling configure_networking in background. Because of this, any server configured with fixed IP address could get its IP address accidentally updated to dynamic IP __after__ it has entered to (single|multi)-user mode (after exiting initramfs stage). Now, I worte could because this totally depends on timing - if fixed address assignment happens after dynamic assignment, nothing occurs. In my case, I'm running both DNS and DHCP service on a same server, and above background task killed my network by rewriting IP address of DNS server. It is certainly OK to obtain dynamic IP address while in initramfs stage, but leaving background job that could rewrite IP address after the stage is IMHO a misfeature. ip=none may be a workaround, but that means default (no ip= arg) is now unsafe for running a server once dropbear is installed. Is ending nessesary? It's been a year since I reported this, so things might have changed. I'll also try to reproduce the issue again, once I get my test environment up. Best Regards, When installed to DHCP server (running dnsmasq), initramfs-tools script that comes with dropbear breaks DHCP server by overwriting own IP address with DHCP-assigned (= self-assigned) address. if it's configured that way - yes (which is also the default, and we had the discussion already, this is probably the way to go. please feel free to discuss if you think it's the wrong way). to disable the dhcp client, add ip=none (no ip in initrd) or a static ip=... configuration to the kernel parameters. Following code in /usr/share/initramfs-tools/scripts/init-premount/dropbear is causing delayed DHCP assignment by ipconfig command invoked from configure_networking shell function. (just btw, iirc configure_networking is a 'library function' used by other initrd and networking related packages) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588324: busybox: Please include cttyhack and setsid to enable ^C in initramfs shell
Hi (and excuse me for lng delay in response). See also http://bugs.debian.org/528234 ;) Is it really needed? Maybe setsid is enough? No, it is not enough. While D-I may not be using it, cttyhack is essential to enable job control (i.e. ^C). This is really needed for initramfs hacking/debugging, which requires serious interactive shell session. And setsid only won't do. Try doing (initramfs) setsid sh ... (initramfs) sleep 5 ^C - this won't work and compare it with (initramfs) setsid cttyhack sh ... (initramfs) sleep 5 ^C (initramfs) - returns immediately Best Regards, Because current debian build of busybox (and busybox-static) does not include 'cttyhack' and 'setsid', it is impossible to use ^C and other job control feature in initramfs shell. - http://lists.busybox.net/pipermail/busybox/2008-January/029936.html As you can see in above URL, enabling CONFIG_SETSID and CONFIG_CTTYHACK would be a big plus, as then you can interrupt command in case it doesn't return (like ipconfig -c dhcp or ping). Being forced to reboot just because of one inappropriate command is not a very happy option. See also http://bugs.debian.org/528234 ;) Is it really needed? Maybe setsid is enough? /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628099: manpages-dev: Missing description in xdr(3) fails XDR codec API in some cases
Package: manpages-dev Version: 3.27-1 Severity: important Tags: patch XDR (eXternal Data Representation) is a codec format well known for its use by Sun/ONC-RPC (see rpcgen(1)). XDR API (xdr_*) which is described in this manpage can be used for generic data encoding/decoding purpose without using RPC. In that case, s/he needs to call either of - xdr_create(3) - xdrstdio_create(3) - xdrrec_create(3) to instantiate XDR* stream required by the API. However, xdrrec_create(3) manpage lacks information to make it work. When reading from xdrrec_create(3)-ed XDR* stream, xdrrec_skiprecord(3) API must be called first to find record boundary: // example of correct API call sequence xdrrec_create(xdrs, 0, 0, handle, myread, NULL); xdrs.x_op = XDR_DECODE; xdrrec_skiprecord(xdrs); However, this is not documented. It only warns as follows: Warning: this XDR stream implements an intermediate record stream. Therefore there are additional bytes in the stream to provide record boundary information. This is too vague, and should be fixed. Also due to this record boundary, it is not possible to read xdrstdio_create(3)-ed XDR* stream with xdrrec_* API and vise versa. I will post a diff in next email. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=ja_JP.UTF-8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages manpages-dev depends on: ii manpages 3.25-1 Manual pages about using a GNU/Lin manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii man-db [man-browser] 2.5.6-5on-line manual pager -- 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#628099: Acknowledgement (manpages-dev: Missing description in xdr(3) fails XDR codec API in some cases)
Here's the patch. From 812006b9018c7dad6e5a8f1187d6c1d972b3a5aa Mon Sep 17 00:00:00 2001 From: Taisuke Yamada t...@rakugaki.org Date: Fri, 27 May 2011 17:31:47 +0900 Subject: [PATCH] Clarified incompatibility and correct usage of XDR API. --- man3/xdr.3 |8 +--- 1 files changed, 5 insertions(+), 3 deletions(-) diff --git a/man3/xdr.3 b/man3/xdr.3 index eb75acf..cc8eaa4 100644 --- a/man3/xdr.3 +++ b/man3/xdr.3 @@ -287,9 +287,11 @@ Note: the XDR stream's .I op field must be set by the caller. .IP -Warning: this XDR stream implements an intermediate record stream. -Therefore there are additional bytes in the stream -to provide record boundary information. +Warning: To read from XDR stream created by this API, you'll need to +call xdrrec_skiprecord(3) first before calling any other XDR APIs. +This is because this inserts additional bytes in the stream to provide +record boundary information. Also, XDR streams created with different +xdr*_create APIs are not compatible for the same reason. .LP .nf .BI bool_t xdrrec_endofrecord(XDR * xdrs , int sendnow ); -- 1.7.4.1
Bug#591682: please include serial port configuration by default
Adding serial 0 9600 made it usable, but I also had to remove color/layout configuration (stdmenu.cfg) to show complete menu. As vesamenu.c32 switches display mode to graphical mode, it'd be better to use menu.c32 (which only uses text mode). However, you will loose all goodies like splash screen. I think it'd be better to have alternative theme for serial console (and other less-featured device). How about adding debian-simple theme? As a starter, I have attached debian-simple theme patch in this email. Anyone who don't like fancy stuff can - Change /usr/share/syslinux/themes/debian symlink - Edit EXTLINUX_THEME entry in /etc/default/extlinux to use it. Best Regards, 0001-Added-debian-simple-theme.patch Description: Binary data 0002-Added-debian-control-files-for-debian-simple-theme.patch Description: Binary data
Bug#581505: trousers init script should not use --chuid (tcsd does that by itself)
Hi. I think I'm also hitting the same problem, but with different symptom - I cannot start tcsd (0.3.5-2+b1 on sid) at all. I believe it's the init script at fault. In /etc/init.d/trousers, it invokes tcsd daemon with start-stop-daemon --start --quiet --background \ --make-pid --pidfile /var/run/tcsd.pid \ --user tss --chuid tss \ --exec /usr/sbin/tcsd -- -f However, tcsd fails to start with this configuration (without any error message). By removing --chuid tss, start-stop-daemon --start --quiet --background \ --make-pid --pidfile /var/run/tcsd.pid \ --user tss \ - HERE --exec /usr/sbin/tcsd -- -f this starts without any problem. # ps auxww | grep tcsd tss 27852 0.0 0.0 22772 1628 ? S 19:17 0:00 /usr/sbin/tcsd -f Running uid is also set collectly, as it's done by tcsd itself. === src/tcsd/svrside.c === 271 #ifndef SOLARIS 272 pwd = getpwnam(TSS_USER_NAME); ... 282 setuid(pwd-pw_uid); 283 #endif So I guess removing --chuid tss from init script solves the issue. Also, trying to set running uid outside the program is probably useless, as TSS_USER_NAME is hardcoded to be tss in the source. Best Regards, -- Taisuke Yamada (@tyamadajp) Old fingerprint = 5229 959A C85D 3C21 923A 41BD 5D60 D687 701E 5AA9 New fingerprint = 9912 2F0A F0A2 4CDC 592A 2731 A03D C4C2 EECA D0AE signature.asc Description: OpenPGP digital signature
Bug#575193: tmux dont refresh console
Thanks! Great to hear you tracked it down already!
On Nov 29, 2010, at 1:05 AM, Taisuke Yamada wrote:
I'm also hit by exactly the same issue.
Tmux fails to refresh screen (both input and output does not
show up) until I switch to another window and back.
It seems calling choose-client seems to fix the issue.
For further detail, I'll run tmux with -vvv and will report
more detail.
Sorry, I forgot to update this bug. The tmux author and I eventually
isolated the problem. It seems to be limited to aggressive-resize windows
being improperly set as hidden. Here is a patch which simply removes the
hidden flag; it should be in the next upstream version.
Index: resize.c
===
RCS file: /cvs/src/usr.bin/tmux/resize.c,v
retrieving revision 1.5
diff -u -p -r1.5 resize.c
--- resize.c 21 Jun 2010 01:27:46 - 1.5
+++ resize.c 14 Nov 2010 11:12:00 -
@@ -113,11 +113,8 @@ recalculate_sizes(void)
ssy = s-sy;
}
}
- if (ssx == UINT_MAX || ssy == UINT_MAX) {
- w-flags |= WINDOW_HIDDEN;
+ if (ssx == UINT_MAX || ssy == UINT_MAX)
continue;
- }
- w-flags = ~WINDOW_HIDDEN;
limit = options_get_number(w-options, force-width);
if (limit != 0 ssx limit)
Index: tmux.h
===
RCS file: /cvs/src/usr.bin/tmux/tmux.h,v
retrieving revision 1.246
diff -u -p -r1.246 tmux.h
--- tmux.h11 Nov 2010 20:51:30 - 1.246
+++ tmux.h14 Nov 2010 11:12:01 -
@@ -843,9 +843,8 @@ struct window {
int flags;
#define WINDOW_BELL 0x1
-#define WINDOW_HIDDEN 0x2
-#define WINDOW_ACTIVITY 0x4
-#define WINDOW_REDRAW 0x8
+#define WINDOW_ACTIVITY 0x2
+#define WINDOW_REDRAW 0x4
struct options options;
Index: tty.c
===
RCS file: /cvs/src/usr.bin/tmux/tty.c,v
retrieving revision 1.92
diff -u -p -r1.92 tty.c
--- tty.c 16 Oct 2010 08:31:55 - 1.92
+++ tty.c 14 Nov 2010 11:12:02 -
@@ -547,7 +547,7 @@ tty_write(void (*cmdfn)(
if (wp-window-flags WINDOW_REDRAW || wp-flags PANE_REDRAW)
return;
- if (wp-window-flags WINDOW_HIDDEN || !window_pane_visible(wp))
+ if (!window_pane_visible(wp))
return;
for (i = 0; i ARRAY_LENGTH(clients); i++) {
signature.asc
Description: OpenPGP digital signature
Bug#575193: tmux dont refresh console
I'm also hit by exactly the same issue. Tmux fails to refresh screen (both input and output does not show up) until I switch to another window and back. It seems calling choose-client seems to fix the issue. For further detail, I'll run tmux with -vvv and will report more detail. signature.asc Description: OpenPGP digital signature
Bug#590053: global.cgi fails to work with id-utils extension.
Hi Ron, Shigio and I are currently discussing changes to the CGI mechanism which may alter several things about how this is currently arranged. I'm planning to push a new package out once we get that resolved and know for sure which direction we'll push things in from here. [snip] For now though, the most pressing issue is to sort out how the system CGI handling should work for the next release. If you have ideas on that, maybe we should pull you in to that discussion ... [RFC] Changing the mechanism of the safe CGI script - http://lists.gnu.org/archive/html/bug-global/2010-06/msg8.html Assuming it is about above URL, I made several enhancements to global.cgi so it can support wider use-cases. I'll post it to bug-global@ list so we can discuss detail there. Best Regards, Taisuke Yamada -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#590053: global.cgi fails to work with id-utils extension.
Package: global Version: 5.7.1-1 Severity: normal Web-based source browsing fails when global.cgi is called with idutils extension enabled: # example when searching for main with id-utils extension http://.../path/to/global.cgi?type=idutilspattern=main This is because global.cgi expects newer global version that supports mixing of -I and --result=ctags-xid option. I tested latest 5.9.1 myself, and verified global.cgi then works correctly. # But, you need to rebuild index files as file format has changed. Since current debian package is based on 5.7.1, it seems it's time to upgrade. As upgrade request to 5.8.1 is still left open, I can take over as package maintainer if you don't mind. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=ja_JP.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages global depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib global recommends no packages. Versions of packages global suggests: ii apache2-mpm-prefork [httpd] 2.2.14-5 Apache HTTP Server - traditional n ii doxygen 1.6.2-1 Documentation system for C, C++, J ii elinks [www-browser]0.12~pre5-2 advanced text-mode WWW browser ii iceweasel [www-browser] 3.5.6-1 lightweight web browser based on M ii id-utils4.2-1Fast, high-capacity, identifier da ii lighttpd [httpd]1.4.26-1.1 A fast webserver with minimal memo ii links [www-browser] 2.2-1+b1 Web browser running in text mode ii lynx2.8.8dev.2-1 Text-mode WWW Browser (transitiona ii lynx-cur [www-browser] 2.8.8dev.2-1 Text-mode WWW Browser with NLS sup ii w3m [www-browser] 0.5.2-2.1WWW browsable pager with excellent -- 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#588494: cgroup-bin: Wrong filenames used in /etc/init.d/cg* scripts.
Thanks for the reply. Regarding this fix, I have another suggestion so it can co-exist with LXC (LinuX Container)and other cgroups usage. If you're going to include /etc/default/cgconfig, please consider adding CREATE_DEFAULT=no to suppress default creation of /sysdefault subgroup. This is because assigning all processes to subgroup seems to cause many problems which I will describe below. One issue with subgrouping is that LXC (LinuX Container) fails to run when invoking shell is already bound to subgroup. LXC (wrongly) expects its pid-based subgroup to appear directly under cgroups mountpoint (/), so it will not run when invoking process is already cgclassify-ed under /sysdefault subgroup. # In another word, LXC fails to find pid-based subgroup (created # by ns subsystem) appearing under /mnt/cgroups/sysdefault/pid. Also, assigning processes under /sysdefault has a side-effect of making /etc/init.d/cgconfig stop to fail when namespace (ns) subsystem is in use. # grep cgroup /proc/mounts # /etc/init.d/cgconfig start Starting cgconfig service: . # cat /proc/$$/cgroup 2:devices,ns:/sysdefault # /etc/init.d/cgconfig stop Stopping cgconfig service: cgclear failed with Operation not permitted Although you can umount cgroups manually, internal allocation of subgroup (num_cgroups) is kept, and ends up with EBUSY error when re-enabling cgroups with different configuration. # umount /mnt/cgroups # cat /proc/cgroups #subsys_namehierarchy num_cgroups enabled cpuset 0 1 1 debug 0 1 1 ns 1 2 1 ^^^- count is 2, due to / and /sysdefault cpu 0 1 1 cpuacct 0 1 1 memory 0 1 1 devices 1 2 1 ^^^- same as above freezer 0 1 1 # mount -t cgroup -o all none /mnt/cgroups mount: none already mounted or /mnt/cgroups busy # mount -t cgroup -o ns,devices,cpu none /mnt/cgroups mount: none already mounted or /mnt/cgroups busy # mount -t cgroup -o ns,devices none /mnt/cgroups # Because I cannot get out of this /sysdefault jail, it is now impossible to reconfigure except by reboot. Other commands like cgclear, cgdelete, or rmdir has no effect (all denied to execute). To summarize, cgclassify-ing all processes to subgroup by default seem to have too much impact on LXC and other use-cases. Although this is not a cgroups bug, I suggest to have less-strict default configuration until each use-case/implementation matures. Excuse me for lengthly explanation, but I wanted to be informative to other people who might be trying LXC (and failing). It took me some time to figure these out... Best Regards, Taisuke Yamada * Taisuke Yamada t...@rakugaki.org wrote: Package: cgroup-bin Version: 0.36.2-1 Severity: minor In /etc/init.d/cgconfig and /etc/init.d/cgred, external configuration files are referenced in wrong filenames (RedHat-ism?). currently used filename should be changed to --- /etc/default/cgred.conf /etc/default/cgred /etc/sysconfig/cgconfig /etc/default/cgconfig Ah, good catch. You're absolutely right. I'll have a fix uploaded for this shortly. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588493: initscript references to /etc/sysconfig/kerneloops instead of /etc/default/kerneloops.
Package: kerneloops Version: 0.12+git20090217-1 Severity: minor In /etc/init.d/kerneloops, following line seems like a RedHat-ism: [ -e /etc/sysconfig/$prog ] . /etc/sysconfig/$prog Since there're many upstream scripts using /etc/sysconfig/, maybe simply requiring ln -s sysconfig default in a policy might be an easier resolution. There's not much point in having different folder name, when both folders are used in similar way. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages kerneloops depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcurl3-gnutls 7.20.1-1 Multi-protocol file transfer libra ii libdbus-1-3 1.2.16-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.84-1 simple interprocess messaging syst ii libglib2.0-0 2.24.1-1 The GLib library of C routines ii libgtk2.0-0 2.18.6-1 The GTK+ graphical user interface ii libnotify1 [libnotify1-gtk2.1 0.4.5-1sends desktop notifications to a n kerneloops recommends no packages. kerneloops suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588494: cgroup-bin: Wrong filenames used in /etc/init.d/cg* scripts.
Package: cgroup-bin Version: 0.36.2-1 Severity: minor In /etc/init.d/cgconfig and /etc/init.d/cgred, external configuration files are referenced in wrong filenames (RedHat-ism?). currently used filename should be changed to --- /etc/default/cgred.conf /etc/default/cgred /etc/sysconfig/cgconfig /etc/default/cgconfig Yes, I can simply do ln -s default sysconfig, but at least /etc/default/cgred.conf should be changed as $ dpkg -L cgroup-bin | grep /etc/default/ /etc/default/cgred is what actually included in the package. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash Versions of packages cgroup-bin depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii libcgroup10.36.2-1 A library to control and monitor c cgroup-bin recommends no packages. cgroup-bin suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588324: busybox: Please include cttyhack and setsid to enable ^C in initramfs shell
Package: busybox Version: 1:1.15.3-1 Severity: wishlist Because current debian build of busybox (and busybox-static) does not include 'cttyhack' and 'setsid', it is impossible to use ^C and other job control feature in initramfs shell. - http://lists.busybox.net/pipermail/busybox/2008-January/029936.html As you can see in above URL, enabling CONFIG_SETSID and CONFIG_CTTYHACK would be a big plus, as then you can interrupt command in case it doesn't return (like ipconfig -c dhcp or ping). Being forced to reboot just because of one inappropriate command is not a very happy option. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages busybox depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib busybox recommends no packages. busybox suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584583: initramfs-tools: configure_networking function: repeatedly makes DHCP requests
I'm seeing similar (probably the same) issue with klibc ipconfig failing to obtain DHCP address. Due to this, I cannot boot NFS-root system using newly-generated initrd image. I have recompiled ipconfig with -DDEBUG=1, and it seems ipconfig is failing to use DHCP OFFER response from the server. I tried both source from 'git' and 'apt-get source (of klibc_1.5.18-1)'. I have attached debug output of ipconfig and tshark dump taken at DHCP server. Hope this helps to resove the problem. Best Regards, Taisuke Yamada (initramfs) ipconfig.git -t 3 -c dhcp -d eth0 IP-Config: parse_device: eth0 IP-Config: eth0 hardware address 00:16:3e:16:ac:c5 mtu 1500 DHCP eth0: state = 2 timeout - dhcp discover xid 5e901c7e secs 0 vendor_class_identifier Linux ipconfig udp src 68 dst 67 ip src 0.0.0.0 dst 255.255.255.255 bytes 299 - bytes 342 ip src 10.253.0.9 dst 10.253.0.235 udp src 67 dst 68 dhcp xid 5e901c7e dhcp offer - dhcp request xid 5e901c7e secs 0 vendor_class_identifier Linux ipconfig udp src 68 dst 67 ip src 0.0.0.0 dst 255.255.255.255 bytes 311 eth0: state = 3 - bytes 342 ip src 10.253.0.9 dst 10.253.0.235 udp src 1 dst 68 freed eth0: state = 5 Delta: 2 ms Delta: 0 ms eth0: state = 5 IP-Config: no response after 3 secs - giving up (initramfs) # tshark -V port 67 or port 68 Running as user root and group root. This could be dangerous. Capturing on eth0 Frame 1 (313 bytes on wire, 313 bytes captured) Arrival Time: Jul 7, 2010 12:37:31.534192000 [Time delta from previous captured frame: 0.0 seconds] [Time delta from previous displayed frame: 0.0 seconds] [Time since reference or first frame: 0.0 seconds] Frame Number: 1 Frame Length: 313 bytes Capture Length: 313 bytes [Frame is marked: False] [Protocols in frame: eth:ip:udp:bootp] Ethernet II, Src: Xensourc_16:ac:c5 (00:16:3e:16:ac:c5), Dst: Broadcast (ff:ff:ff:ff:ff:ff) Destination: Broadcast (ff:ff:ff:ff:ff:ff) Address: Broadcast (ff:ff:ff:ff:ff:ff) ...1 = IG bit: Group address (multicast/broadcast) ..1. = LG bit: Locally administered address (this is NOT the factory default) Source: Xensourc_16:ac:c5 (00:16:3e:16:ac:c5) Address: Xensourc_16:ac:c5 (00:16:3e:16:ac:c5) ...0 = IG bit: Individual address (unicast) ..0. = LG bit: Globally unique address (factory default) Type: IP (0x0800) Internet Protocol, Src: 0.0.0.0 (0.0.0.0), Dst: 255.255.255.255 (255.255.255.255) Version: 4 Header length: 20 bytes Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00) 00.. = Differentiated Services Codepoint: Default (0x00) ..0. = ECN-Capable Transport (ECT): 0 ...0 = ECN-CE: 0 Total Length: 299 Identification: 0x (0) Flags: 0x02 (Don't Fragment) 0.. = Reserved bit: Not Set .1. = Don't fragment: Set ..0 = More fragments: Not Set Fragment offset: 0 Time to live: 64 Protocol: UDP (0x11) Header checksum: 0x39c3 [correct] [Good: True] [Bad : False] Source: 0.0.0.0 (0.0.0.0) Destination: 255.255.255.255 (255.255.255.255) User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67) Source port: bootpc (68) Destination port: bootps (67) Length: 279 Checksum: 0x (none) Good Checksum: False Bad Checksum: False Bootstrap Protocol Message type: Boot Request (1) Hardware type: Ethernet Hardware address length: 6 Hops: 0 Transaction ID: 0x7e1c905e Seconds elapsed: 0 Bootp flags: 0x (Unicast) 0... = Broadcast flag: Unicast .000 = Reserved flags: 0x Client IP address: 0.0.0.0 (0.0.0.0) Your (client) IP address: 0.0.0.0 (0.0.0.0) Next server IP address: 0.0.0.0 (0.0.0.0) Relay agent IP address: 0.0.0.0 (0.0.0.0) Client MAC address: Xensourc_16:ac:c5 (00:16:3e:16:ac:c5) Client hardware address padding: Server host name not given Boot file name not given Magic cookie: (OK) Option: (t=53,l=1) DHCP Message Type = DHCP Discover Option: (53) DHCP Message Type Length: 1 Value: 01 Option: (t=55,l=9) Parameter Request List Option: (55) Parameter Request List Length: 9 Value: 0103060C0F111A1C28 1 = Subnet Mask 3 = Router 6 = Domain Name Server 12 = Host Name 15 = Domain Name 17 = Root Path 26 = Interface MTU 28 = Broadcast Address 40 = Network Information Service Domain Option: (t=60,l=14) Vendor class identifier = Linux ipconfig Option: (60) Vendor class identifier Length: 14 Value: 4C696E7578206970636F6E666967 End Option Frame 2 (313 bytes on wire, 313 bytes
Bug#584780: dropbear script for initramfs-tools breaks DHCP server.
Package: dropbear Version: 0.52-4 Severity: important When installed to DHCP server (running dnsmasq), initramfs-tools script that comes with dropbear breaks DHCP server by overwriting own IP address with DHCP-assigned (= self-assigned) address. Following code in /usr/share/initramfs-tools/scripts/init-premount/dropbear is causing delayed DHCP assignment by ipconfig command invoked from configure_networking shell function. configure_networking mkdir -p /var/run /sbin/dropbear This is a problem because if you install dropbear to DHCP server, this background task will wait for oneself to come up, and then rewrites own IP address. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_US.utf8 (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C) Shell: /bin/sh linked to /bin/bash Versions of packages dropbear depends on: ii libc6 2.10.2-6 Embedded GNU C Library: Shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime dropbear recommends no packages. Versions of packages dropbear suggests: ii openssh-client1:5.3p1-1 secure shell (SSH) client, for sec ii runit 2.1.1-3system-wide service supervision ii udev 150-2 /dev/ and hotplug management daemo ii xauth 1:1.0.4-1 X authentication utility -- 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#433270: bringing it into team maintenance?
Hi Pablo, Excuse me for the delay in response. I'd be happy to join in. So what should I do now? Should I simply submit joining request form on project page? Since I recently started as Debian package maintainer, I'm not an DD/DM (yet). So I needed someone to do me a sponsored upload. I guess changing header to Maintainer: Debian Java maintainers make things easier, so joining Debian-Java project sounds great for all of us. Best Regards, Taisuke Yamada Hi Taisuke, Would you consider bringing it into the Debian-Java project (http://java.debian.net/)? It is as easy as joining the Alioth project. I need this for packaging Processing, which you are of course also invited to help packaging. P. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564961: libmysql-java: Prepared Queries broken
Package: libmysql-java Version: 5.1.10+dfsg-2 Tags: unreproducible Severity: normal I have picked up this bug during Debian BSP, but was unable to reduce the problem. Since original report did not contain code or data to reproduce the issue, I will tag the issue as unreproducible, and lower its severity to normal (as important and upper-level severities requires the package to be in completely unusable state for majority of people). Best Regards, SqlTest.java Description: Binary data SqlTest.sh Description: Bourne shell script SqlTest.log Description: Binary data
Bug#489701: librxtx-java is not fixed for long time
Hi. I'm looking into this issue for Debian BSP, and got latest 2.2-pre2 packaged. I'm still making it lintian clean, though. If no one is coming up, I'd be happy to maintain this as I'll probably be using both serial/parallel port for more years. Best Regards, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526616: syslog-ng: option owner and group options for Lenny
Hi. I've picked this bug up for deian...@tokyo, and have several comments on how to fix. So the requests are: 1. Allow syslog-ng to run on different user/group. 2. Allow syslog-ng to create log file/dir with different user/group, preferrably same as #1. 3. Change log file location so logrotate configuration would be simpler. For above requests, I propose following fix/nonfix-es: - For 1 and 2, introduce EXTRAOPT= parameter in /etc/defaults/syslog-ng and let /etc/init.d/syslog-ng pick it up. This will also allow other future tweaks as well. - But, since running syslog in non-root and/or chroot-ed mode is nonstandard, making it possible should be enough. Introducing too much auto-configuration and other complexity should be avoided. - I'm against moving log files to /var/log/syslog-ng/*.log. Making it specific to syslog-ng will break compatibility with other syslog implementations, and probably many user-scripts expecting /var/log/syslog to be exact that location. I'll be submitting patch, but I got a suggestion this bug isn't grave from the first. So 1. I'll first re-rate severity of this bug to wishlist (so this won't be a blocker RC-bug). 2. Then submit a patch. Best Regards,
Bug#412610: O: gdb-m68hc1x -- GNU Debugger for the Motorola 68HC11/12 processors
Hi Aurelien, I noticed gdb-m68hc1x Debian package is an orphan, and also noticed you were the former maintainer of the package. I'm going to propose for an adpotion, and I thought if you could sponsor me just like gputils package. Could you be my sponsor for this package also? I still have many HCS12s around and I actually have more updated code for this since I recently merged target code for TBDML pod. I'm planning to submit a patch to upstream, but I'd also like to have updated binary included in Debian. Best Regards, Taisuke Yamada signature.asc Description: OpenPGP digital signature
Bug#412610: O: gdb-m68hc1x -- GNU Debugger for the Motorola 68HC11/12 processors
Hi, I'm planning to make an ITA on gdb-m68hc1x Debian package, and Aurelien Jarno suggested to contact you as you're maintaining other *-m68hc1x packages (I asked Aurelien if he could sponsor me as he happens to sponser me and he was the maintainer of the package). It seems you once submitted ITA for this package, but it's now orphaned for about a year while other m68hc1x packages are under your maintenance. Is there any reason for this? Would it be OK if I submit an ITA? Best Regards, Taisuke Yamada On Wed, Mar 18, 2009 at 08:48:06PM +0900, Taisuke Yamada wrote: Hi Aurelien, Hi, I noticed gdb-m68hc1x Debian package is an orphan, and also noticed you were the former maintainer of the package. True. I'm going to propose for an adpotion, and I thought if you could sponsor me just like gputils package. Could you be my sponsor for this package also? Yes, I am fine with that. You may also want to contact Arthur Loiret, as he has adopted the other *m68hc1x packages. I still have many HCS12s around and I actually have more updated code for this since I recently merged target code for TBDML pod. I'm planning to submit a patch to upstream, but I'd also like to have updated binary included in Debian. If you have the corresponding hardware, it's even better. Best regards, Aurelien signature.asc Description: OpenPGP digital signature
Bug#520066: autopkgtest: adt-virt-chroot fails due to invalid args for chroot call
Package: autopkgtest Version: 1.2.0 Severity: normal Tags: patch *** Please type your report below this line *** dt-virt-chroot fails to work in chroot mode due to how it passes arguments to chroot(8). I was trying to verify package by following command: # piuparts -v -d sid --adt-virt adt-virt-chroot -d /d/lib/ve/sid64-pb-1 mypackage.deb However, because of following code in adt-virt-chroot and VirtSubproc.py, it fails with following errors: === CODE #1: adt-virt-chroot === 53 chroot_arg = args[0] 54 if not chroot_arg: pe(chroot specification may not be empty) 55 if chroot_arg == '=': down = ['dchroot','-q'] 56 elif chroot_arg == '=': down = ['dchroot','-q'] 57 elif chroot_arg[0] == '=': down = ['dchroot','-q','-c',chroot_arg[1:]] 58 elif chroot_arg[0] == '/': down = ['chroot',chroot_arg,'--'] 59 else: pe(chroot spec must be =[DCHROOT] or /PATH/TO/CHROOT) === ERR #1: chroot errors with invalid -- arg === VirtSubproc: debug: executing open VirtSubproc: debug: ++ chroot /d/lib/ve/sid64-pb-1 -- true chroot: cannot run command `--': No such file or directory VirtSubproc: debug: cleanup... As error message shows, chroot(8) does not handle -- as end-of-option string. The fix is simply remove -- from line #58. === CODE #2: VirtSubproc.py === 105 def execute(cmd_string, cmd_list=[], downp=False, outp=False, timeout=0): 106 cmdl = cmd_string.split() ... 114 cmd = cmdl + cmd_list 115 if len(perhaps_down): cmd = perhaps_down + [' '.join(cmd)] 116 117 (status, out) = execute_raw(cmdl[0], None, timeout, 118 cmd, stdout=stdout) === ERR #2: Error trying to run file named mktempSPC-tSPC-d === VirtSubproc: debug: executing open VirtSubproc: debug: ++ chroot /d/lib/ve/sid64-pb-1 true VirtSubproc: debug: ++ chroot /d/lib/ve/sid64-pb-1 mktemp -t -d chroot: cannot run command `mktemp -t -d': No such file or directory VirtSubproc: debug: cleanup... Because mktemp -t -d is joined as single filename instead of as an array of cmd+args, chroot fails to find such file. The fix is to cut joining in line #115. Note this BUG #2 happens only after ERR #1 is fixed. By fixing above two, adt-virt-chroot should now be able to work with piuparts for chroot-based autopkgtest-ing. However, due to different issue in piuparts, this fix is not self-complete - additional fix is needed for piuparts to change how piuparts (wrongly?) expects adt-run to behave. # For example, piuparts hardcodes path /ADT-VIRT as chroot tree, # and it also refuses to accept --keep-source-list option because # it believes it is NOT using chroot when --adt-virt mode is selected. Best Regards, Taisuke Yamada (http://labs.aobac.net/debian/) -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-openvz-amd64 (SMP w/4 CPU cores) Locale: LANG=ja_JP.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages autopkgtest depends on: ii python2.4 2.4.6-1An interactive high-level object-o Versions of packages autopkgtest recommends: ii apt-utils 0.7.19 APT utility programs Versions of packages autopkgtest suggests: pn autopkgtest-xenlvmnone (no description available) ii curl 7.18.2-5 Get a file from an HTTP, HTTPS or -- no debconf information --- adt-virt-chroot.org 2009-03-17 13:24:23.0 +0900 +++ adt-virt-chroot 2009-03-17 15:22:58.0 +0900 @@ -55,7 +55,7 @@ if chroot_arg == '=': down = ['dchroot','-q'] elif chroot_arg == '=': down = ['dchroot','-q'] elif chroot_arg[0] == '=': down = ['dchroot','-q','-c',chroot_arg[1:]] - elif chroot_arg[0] == '/': down = ['chroot',chroot_arg,'--'] + elif chroot_arg[0] == '/': down = ['chroot',chroot_arg] else: pe(chroot spec must be =[DCHROOT] or /PATH/TO/CHROOT) if opts.gain_root != None: --- VirtSubproc.py.org 2009-03-17 13:38:17.0 +0900 +++ VirtSubproc.py 2009-03-17 15:22:27.0 +0900 @@ -112,7 +112,7 @@ else: stdout = None cmd = cmdl + cmd_list - if len(perhaps_down): cmd = perhaps_down + [' '.join(cmd)] + if len(perhaps_down): cmd = perhaps_down + cmd (status, out) = execute_raw(cmdl[0], None, timeout, cmd, stdout=stdout) signature.asc Description: OpenPGP digital signature
Bug#504473: IFA: gputils -- GNU PIC utilities
Hi Aurelien, New version of gputils was released last weekend, and I have uploaded new gputils-0.13.7 package to debian.mentors.net. It is available from - http://mentors.debian.net/debian/pool/main/g/gputils/ Please check and proceed to a sponsor upload if the package seems OK. Major changes in this package are: - New upstream version (obviously). This version is needed and works with upcoming sdcc release. - Removed PS/PDF files from gputils package, as they are included in gputils-doc package. - General updates in debian/* to make it more lintian clean. I have tested both build and installation to go cleanly on sid-amd64 and sid-i386, using pbuilder+aufs. Also, since mentors only allow source package upload, I have uploaded generated binary packages on - http://labs.aobac.net/debian/pool/local/g/ I'm not yet fully familiar with how official Debian packages are uploaded, but please use these if that's convenient. Best Regards, Taisuke Yamada signature.asc Description: OpenPGP digital signature
Bug#504473: Bug #504473,RFA: gputils -- GNU PIC utilities
retitle 504473 ITA: gputils -- GNU PIC utilities signature.asc Description: OpenPGP digital signature
Bug#512634: [PATCH] Re: ia32-libs-tools: subprocess post-installation script returned error , exit status 134
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I was recently hit by ia32-apt-get bug (Bug #512634) caused by zero-size *_Packages file, and it seems no official response was made since January. This can be fixed by simply ignoring such *_Packages file, so I'm sending in this one-line patch. Please include it in next release. Best Regards, Taisuke Yamada -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkm0hYQACgkQXWDWh3AeWqmUDACgsC7b5EfvBnljduV/t2KfPdnf /qAAoKIs/QCJR6zV8dHAFbLuoTPuz5Gb =IAl+ -END PGP SIGNATURE- --- apt-get.orig2009-03-09 11:39:25.0 +0900 +++ apt-get 2009-03-09 11:39:11.0 +0900 @@ -66,6 +66,7 @@ # Mangle foreign files for F in $LISTDIR/foreign/lists/*_*; do +test -s $F || continue DIR=$(dirname $F) case $F in *_Packages) ia32-apt-get.diff.sig Description: Binary data
Bug#504473: Bug #504473,RFA: gputils -- GNU PIC utilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks for accepting my adoption offer! Since current package is already latest (0.13.6), I'll do the packaging from next release. I'd also like to thank you for being my sponsor. I have also subscribed to the Debian Electronics Team list as you have recommended. I'll send you a note once I'm done with the initial packaging. Best Regards, Taisuke Yamada I'm interested in adopting as I'm also a long-time user of PIC microcontroller (and gputils package) for my hobby electronics project. However, as I'm not an official DD, I'll need someone to sponsor me and upload created packages. Nice, that I finally found an adopter, this package is yours. This package is not really difficult to maintain, given that upstream is doing a really good job. I am ready to sponsor your uploads for this package. Alternatively you can also join the Debian Electronics Team [1], and find uploaders there. Best regards, Aurelien [1] pkg-electronics-de...@lists.alioth.debian.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmFSmkACgkQXWDWh3AeWqnN/ACg+UEAvEYyWAq9b1GpA4tTJaDi ITQAoJlHFq+OJV5c01esPdDDzxNVjCuJ =3OeR -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#504473: Bug #504473,RFA: gputils -- GNU PIC utilities
Hello, I read your RFA on gputils Debian package, and I would like to apply as an adoptor of your package. I'm a ~10-year user of Debian as a developer/system admin, and has some experience in packaging debs (though it was for closed in-house applications). I'm interested in adopting as I'm also a long-time user of PIC microcontroller (and gputils package) for my hobby electronics project. However, as I'm not an official DD, I'll need someone to sponsor me and upload created packages. Best Regards, -- Taisuke Yamada -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#508773: linux-image-2.6.26-1-openvz-amd64: Oops in simfs module when accessing device over aufs
[ 152.964024] CR2: 0028 [ 153.342780] ---[ end trace d79ece63cdce3674 ]--- Message from sysl...@newpc at Dec 15 17:20:33 ... kernel:[ 152.964024] Oops: [1] SMP Message from sysl...@newpc at Dec 15 17:20:33 ... kernel:[ 152.964024] Code: ff c8 48 d3 e8 89 c0 48 0f af d0 48 89 55 60 48 8b 46 18 48 89 45 58 eb 12 48 89 ea 4c 89 ef ff d0 85 c0 89 c3 0f 85 b3 01 00 00 49 8b 45 28 31 db 48 81 78 38 20 8d 2f a0 0f 85 9f 01 00 00 8b Message from sysl...@newpc at Dec 15 17:20:33 ... kernel:[ 152.964024] CR2: 0028 Killed # This is a blocker for me as I couldn't wrap chroot/debootstrap environment with aufs to clone chroot tree quickly. Regards, Taisuke Yamada -- Package-specific info: ** Version: Linux version 2.6.26-1-openvz-amd64 (Debian 2.6.26-11) (wa...@debian.org) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Wed Nov 26 19:23:13 UTC 2008 ** Command line: root=/dev/md1 ro console=tty0 console=ttyS0,115200 ** Not tainted ** Kernel log: [4.860104] scsi5 : ahci [4.862839] ata1: SATA max UDMA/133 abar m2...@0xdc321000 port 0xdc321100 irq 1275 [4.869971] ata2: SATA max UDMA/133 abar m2...@0xdc321000 port 0xdc321180 irq 1275 [4.877765] ata3: SATA max UDMA/133 abar m2...@0xdc321000 port 0xdc321200 irq 1275 [4.885449] ata4: SATA max UDMA/133 abar m2...@0xdc321000 port 0xdc321280 irq 1275 [4.893130] ata5: SATA max UDMA/133 abar m2...@0xdc321000 port 0xdc321300 irq 1275 [4.900806] ata6: SATA max UDMA/133 abar m2...@0xdc321000 port 0xdc321380 irq 1275 [5.392036] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [5.418324] ata1.00: ATA-8: ST31000333AS, SD15, max UDMA/133 [5.432609] ata1.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32) [5.467482] ata1.00: configured for UDMA/133 [5.968036] ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [6.004023] ata2.00: ATA-8: ST31000333AS, SD15, max UDMA/133 [6.009795] ata2.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32) [6.047421] ata2.00: configured for UDMA/133 [6.380036] ata3: SATA link down (SStatus 0 SControl 300) [6.704036] ata4: SATA link down (SStatus 0 SControl 300) [7.028035] ata5: SATA link down (SStatus 0 SControl 300) [7.352036] ata6: SATA link down (SStatus 0 SControl 300) [7.357653] scsi 0:0:0:0: Direct-Access ATA ST31000333AS SD15 PQ: 0 ANSI: 5 [7.367558] scsi 1:0:0:0: Direct-Access ATA ST31000333AS SD15 PQ: 0 ANSI: 5 [7.380006] JMB: IDE controller (0x197b:0x2368 rev 0x00) at PCI slot :0d:00.0 [7.387727] ACPI: PCI Interrupt :0d:00.0[A] - GSI 16 (level, low) - IRQ 16 [7.395307] JMB: 100% native mode on irq 16 [7.399575] ide0: BM-DMA at 0x2000-0x2007 [7.404009] ide1: BM-DMA at 0x2008-0x200f [7.408448] Probing IDE interface ide0... [7.972085] Probing IDE interface ide1... [8.540091] ide0 at 0x2020-0x2027,0x2016 on irq 16 [8.545078] ide1 at 0x2018-0x201f,0x2012 on irq 16 [8.577547] Driver 'sd' needs updating - please use bus_type methods [8.588005] sd 0:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB) [8.600207] sd 0:0:0:0: [sda] Write Protect is off [8.605090] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [8.605145] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [8.616096] sd 0:0:0:0: [sda] 1953525168 512-byte hardware sectors (1000205 MB) [8.624459] sd 0:0:0:0: [sda] Write Protect is off [8.628747] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [8.628803] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [8.637986] sda: sda1 sda2 [8.646291] sd 0:0:0:0: [sda] Attached SCSI disk [8.651082] sd 1:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB) [8.658552] sd 1:0:0:0: [sdb] Write Protect is off [8.663425] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [8.663458] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [8.676005] sd 1:0:0:0: [sdb] 1953525168 512-byte hardware sectors (1000205 MB) [8.684201] sd 1:0:0:0: [sdb] Write Protect is off [8.688416] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [8.688473] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [8.697649] sdb: sdb1 sdb2 [8.705472] sd 1:0:0:0: [sdb] Attached SCSI disk [8.891070] md: raid1 personality registered for level 1 [8.907045] md: md0 stopped. [8.940094] md: bindsdb1 [8.943181] md: bindsda1 [8.956006] raid1: raid set md0 active with 2 out of 3 mirrors [8.967547] md: md1 stopped. [9.014449] md: bindsdb2 [9.019027] md: bindsda2 [9.032006] raid1: raid set md1 active with 2 out of 3 mirrors [9.126784] SGI XFS with ACLs, security attributes, realtime, large block/inode numbers, no debug enabled [9.137818] SGI XFS Quota Management subsystem
