Bug#1062579: /usr/bin/wasm-opt has no manpage
Package: binaryen Version: 108-1 Severity: normal Per Debian Policy 12.1, each program, utility, and function should have an associated manpage. Currently /usr/bin/wasm-opt is lacking one. T -- Real men don't take backups. They put their source on a public FTP-server and let the world mirror it. -- Linus Torvalds
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
On Fri, Feb 10, 2023 at 08:58:41AM +0100, Tormod Volden wrote: > On Fri, Feb 10, 2023 at 1:18 AM H. S. Teoh wrote: > > > xscreensaver-settings: 16:11:29: xscreensaver-gl-visual did not report a GL > > visual! > > Segmentation fault > > --snip--- > > > > Apparently there *is* a segfault, even though it doesn't appear that way > > when I run the official binaries. This looks to be the same bug as > > #1030659 after all. > > Teoh, can you please apply the patch I posted in #1030659 to get rid > of the segfault? Hi Tormod, Sorry for taking so long to get back to you. Here's the output after I recompiled with the patch: --snip--- xscreensaver-settings: 11:15:48: DISPLAY=:0.0 xscreensaver-settings: 11:15:48: added "/usr/libexec/xscreensaver" to $PATH xscreensaver-settings: 11:15:48: pref changed: GtkSpinButton xscreensaver-settings: 11:15:48: pref changed: GtkSpinButton xscreensaver-settings: 11:15:48: pref changed: GtkSpinButton xscreensaver-settings: 11:15:48: pref changed: GtkSpinButton xscreensaver-settings: 11:15:48: pref changed: GtkSpinButton xscreensaver-settings: 11:15:48: pref changed: GtkSpinButton xscreensaver-settings: 11:15:48: pref changed: GtkSpinButton xscreensaver-settings: 11:15:48: pref changed: GtkCheckButton xscreensaver-settings: 11:15:48: pref changed: GtkCheckButton xscreensaver-settings: 11:15:48: pref changed: GtkCheckButton xscreensaver-settings: 11:15:48: pref changed: GtkRadioButton xscreensaver-settings: 11:15:48: pref changed: GtkRadioButton xscreensaver-settings: 11:15:48: list selection changed xscreensaver-settings: 11:15:48: scheduling preview "moebiusgears --root" xscreensaver-settings: 11:15:48: /usr/local/share/xscreensaver/config/moebiusgears.xml does not exist. xscreensaver-settings: 11:15:48: scheduling preview "moebiusgears --root" xscreensaver-settings: 11:15:48: /usr/local/share/xscreensaver/config/moebiusgears.xml does not exist. xscreensaver-settings: 11:15:48: scheduling preview "moebiusgears --root" xscreensaver-settings: 11:15:48: select list elt 145 xscreensaver-settings: 11:15:48: scheduling preview "moebiusgears --root" xscreensaver-settings: 11:15:48: /usr/local/share/xscreensaver/config/moebiusgears.xml does not exist. xscreensaver-settings: 11:15:48: scheduling preview "moebiusgears --root" xscreensaver-settings: 11:15:48: xscreensaver-gl-visual did not report a GL visual! xscreensaver-settings: 11:15:48: couldn't convert X Visual 0x0 to a GdkVisual; winging it. xscreensaver-settings: 11:15:48: using default visual 0x0 xscreensaver-settings: 11:15:48: saved screenshot 0x1a00010 1920x1080 for window 0x1af 425x238+437+116 xscreensaver-settings: 11:15:48: X error: xscreensaver-settings: Failed request: BadMatch (invalid parameter attributes) xscreensaver-settings: Major opcode: 42 (X_SetInputFocus) xscreensaver-settings: Resource id:0x1a7 xscreensaver-settings: Serial number: 451 / 452 --snip--- > In your first post (with the Debian binaries) > xscreensaver-gl-visual reported 0x21, and there was no segfault. I > wonder why xscreensaver-gl-visual is giving different results. Debian > is not patching anything in this regard, although build flags can be > different in your local build. Can you please attach your config.h? > Did you install all standard build dependencies for xscreensaver? [...] I did an `apt-get builddep xscreensaver`. That ought to have been enough, right? Here's my config.h: --snip--- /* config.h. Generated from config.h.in by configure. */ /* config.h.in. Generated from configure.ac by autoheader. */ /* xscreensaver, Copyright © 1991-2022 Jamie Zawinski. * Generate this file by running 'configure' rather than editing it by hand. */ /* Define this to allow root to unlock, when not using PAM. */ /* #undef ALLOW_ROOT_PASSWD */ /* Define to 1 if translation of program messages to the user's native language is requested. */ #define ENABLE_NLS 1 /* This is the name of the gettext package to use. */ #define GETTEXT_PACKAGE "xscreensaver" /* Define this if gettimeofday takes two arguments. */ #define GETTIMEOFDAY_TWO_ARGS 1 /* Define this for Solaris getpwanam. */ /* #undef HAVE_ADJUNCT_PASSWD */ /* Define to 1 if you have the Mac OS X function CFLocaleCopyPreferredLanguages in the CoreFoundation framework. */ /* #undef HAVE_CFLOCALECOPYPREFERREDLANGUAGES */ /* Define to 1 if you have the Mac OS X function CFPreferencesCopyAppValue in the CoreFoundation framework. */ /* #undef HAVE_CFPREFERENCESCOPYAPPVALUE */ /* Define to 1 if you have the header file. */ #define HAVE_CRYPT_H 1 /* Define if the G
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
On Thu, Feb 09, 2023 at 11:16:15AM +0100, Tormod Volden wrote: > On Thu, Feb 9, 2023 at 10:20 AM Tormod Volden wrote: > > Would it be possible for you to build the upstream sources, without > > optimization, and try it out? You shouldn't need to install any of > > it, just run driver/xscreensaver-settings --debug from the build > > tree. And also rename your ~/.xscreensaver so that it runs with > > default settings. > > Now it gets a bit complicated if we don't want to install it, but at > the same time let the built xscreensaver-settings find the > screensavers from the already installed Debian packages, we need to > set the exec-prefix. In this case do not run make install afterwards! > >From unpacked upstream sources: > > ./configure CFLAGS="-g -O0" --exec-prefix=/usr > make -j4 > driver/xscreensaver-settings --debug [...] Here is the output: --snip--- $ driver/xscreensaver-settings --debug xscreensaver-settings: 16:11:29: DISPLAY=:0.0 xscreensaver-settings: 16:11:29: added "/usr/libexec/xscreensaver" to $PATH xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton xscreensaver-settings: 16:11:29: pref changed: GtkSpinButton xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton xscreensaver-settings: 16:11:29: pref changed: GtkCheckButton xscreensaver-settings: 16:11:29: pref changed: GtkRadioButton xscreensaver-settings: 16:11:29: pref changed: GtkRadioButton xscreensaver-settings: 16:11:29: list selection changed xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell" xscreensaver-settings: 16:11:29: /usr/local/share/xscreensaver/config/polytopes.xml does not exist. xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell" xscreensaver-settings: 16:11:29: /usr/local/share/xscreensaver/config/polytopes.xml does not exist. xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell" xscreensaver-settings: 16:11:29: select list elt 168 xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell" xscreensaver-settings: 16:11:29: /usr/local/share/xscreensaver/config/polytopes.xml does not exist. xscreensaver-settings: 16:11:29: scheduling preview "polytopes -root -polytope 120-cell" xscreensaver-settings: 16:11:29: xscreensaver-gl-visual did not report a GL visual! Segmentation fault --snip--- Apparently there *is* a segfault, even though it doesn't appear that way when I run the official binaries. This looks to be the same bug as #1030659 after all. T -- If it tastes good, it's probably bad for you.
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
On Thu, Feb 09, 2023 at 08:57:22PM +0100, Tormod Volden wrote: > > Since upgrading to 6.06+dfsg1-2, I have been unable to run > > xscreensaver-settings or xscreensaver-demo. The main xscreensaver > > >From which version did you upgrade? 5.45+dfsg1-2 T -- Written on the window of a clothing store: No shirt, no shoes, no service.
Bug#1030909: Unable to run xscreensaver-demo or xscreensaver-settings
Package: xscreensaver Version: 6.06+dfsg1-2 Severity: important Since upgrading to 6.06+dfsg1-2, I have been unable to run xscreensaver-settings or xscreensaver-demo. The main xscreensaver binary still runs and works correctly; however, I can no longer configure which screensavers show up except by editing .xscreensaver by hand. So marking this as important. Here's the typical output from xscreensaver-settings: xscreensaver-settings: 15:24:45: X error: xscreensaver-settings: Failed request: BadMatch (invalid parameter attributes) xscreensaver-settings: Major opcode: 42 (X_SetInputFocus) xscreensaver-settings: Resource id:0x187 xscreensaver-settings: Serial number: 440 / 441 Here's the output from xscreensaver-settings --debug: xscreensaver-settings: 15:25:11: DISPLAY=:0 xscreensaver-settings: 15:25:11: added "/usr/libexec/xscreensaver" to $PATH xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton xscreensaver-settings: 15:25:11: pref changed: GtkSpinButton xscreensaver-settings: 15:25:11: pref changed: GtkCheckButton xscreensaver-settings: 15:25:11: pref changed: GtkCheckButton xscreensaver-settings: 15:25:11: pref changed: GtkCheckButton xscreensaver-settings: 15:25:11: pref changed: GtkRadioButton xscreensaver-settings: 15:25:11: pref changed: GtkRadioButton xscreensaver-settings: 15:25:11: list selection changed xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root" xscreensaver-settings: 15:25:11: reading /usr/share/xscreensaver/config/hextrail.xml... xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root" xscreensaver-settings: 15:25:11: reading /usr/share/xscreensaver/config/hextrail.xml... xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root" xscreensaver-settings: 15:25:11: select list elt 114 xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root" xscreensaver-settings: 15:25:11: reading /usr/share/xscreensaver/config/hextrail.xml... xscreensaver-settings: 15:25:11: scheduling preview "hextrail --root" xscreensaver-settings: 15:25:12: xscreensaver-gl-visual says the GL visual is 0x21. xscreensaver-settings: 15:25:12: using non-default visual 0x21 xscreensaver-settings: 15:25:12: saved screenshot 0x1800010 1920x1080 for window 0x18f 425x238+437+116 xscreensaver-settings: 15:25:12: X error: xscreensaver-settings: Failed request: BadMatch (invalid parameter attributes) xscreensaver-settings: Major opcode: 42 (X_SetInputFocus) xscreensaver-settings: Resource id:0x187 xscreensaver-settings: Serial number: 440 / 441 I found bug #1030659, which seems to be related to this issue (it also has the X_SetInputFocus error), but in my case there is no segfault so I decided to file a separate bug. Some other information that may be pertinent: - CPU: AMD Ryzen 7 5700G with Radeon Graphics - GPU: Cezanne [Radeon Vega Series / Radeon Vega Mobile Series] (rev c8) - glxinfo output: please see attached. - Desktop environment: none, using minimal XDM + ratpoison as WM. Possibly relevant packages: hi ratpoison 1.4.8-2+b1amd64keyboard-only window manager ii xdm1:1.1.11-3+b2 amd64X display manager ii xserver-common 2:21.1.6-1all common files used by various X servers ii xserver-xorg-core 2:21.1.6-1amd64Xorg X server - core server ii xserver-xorg-input-evdev 1:2.10.6-2+b1 amd64X.Org X server -- evdev input driver ii xserver-xorg-input-kbd 1:1.9.0-1+b3 amd64X.Org X server -- keyboard input driver ii xserver-xorg-input-libinput1.2.1-1+b1amd64X.Org X server -- libinput input driver ii xserver-xorg-input-mouse 1:1.9.3-1+b1 amd64X.Org X server -- mouse input driver ii xserver-xorg-video-amdgpu 22.0.0-3 amd64X.Org X server -- AMDGPU display driver T -- Recently, our IT department hired a bug-fix engineer. He used to work for Volkswagen.
Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle
On Wed, Jan 05, 2022 at 08:35:55PM +0100, Marc Haber wrote: [...] > The changes we made that might cause this are mainly setting use_pty > in /etc/sudoers and some changes in pam configuration. Can you try > using sudo 1.9.8 with the sudoers file and and /etc/pam.d snapshot > from sudo 1.9.5? [...] Some further digging turned up this: https://github.com/sshuttle/sshuttle/pull/668 Looks like sshuttle is incompatible with use_pty. Upstream has a patch that issues a more helpful error message in this case, but that version hasn't made it into Debian yet. Perhaps this bug should be reassigned to sshuttle? T -- Why waste time reinventing the wheel, when you could be reinventing the engine? -- Damian Conway
Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle
On Wed, Jan 05, 2022 at 08:35:55PM +0100, Marc Haber wrote: [...] > The changes we made that might cause this are mainly setting use_pty > in /etc/sudoers and some changes in pam configuration. Can you try > using sudo 1.9.8 with the sudoers file and and /etc/pam.d snapshot > from sudo 1.9.5? [...] I did some digging, and discovered that setting use_pty is indeed what makes the difference. Installing sudo 1.9.8 and manually commenting out use_pty fixes the problem. I've no idea why, though. Maybe sshuttle needs to pass some extra options to sudo in order to work around this? T -- In theory, there is no difference between theory and practice.
Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle
On Wed, Jan 05, 2022 at 02:25:27PM +0100, Marc Haber wrote: [...] > On Tue, Jan 04, 2022 at 06:36:52PM -0800, H. S. Teoh wrote: > > PermissionError: [Errno 1] Operation not permitted > > c : fatal: ['/usr/bin/sudo', '-p', '[local sudo] Password: ', > > '/usr/bin/env', 'PYTHONPATH=/usr/lib/python3/dist-packages', > > '/usr/bin/python3', '/usr/bin/sshuttle', '-v', '--method', 'nft', > > '--firewall'] returned 1 > > Can you please verify whether this command also fails on the command > line, and then reduce the command line so that we can find out whatever > the current sudo doesn't like? [...] The failure appears to be coming from sshuttle itself, with that specific combination of arguments. It's not sudo that's rejecting the command per se, but something about the environment it sets up isn't working well with sshuttle. The failure is coming from the os.setsid() call inside sshuttle (the lines before the ones you quoted above). The previous version of sudo was obviously setting up *something* differently, such that this call worked. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
Bug#1003154: sudo 1.9.8p2-1 breaks sshuttle
Package: sudo
Version: 1.9.8p2-1
Severity: important
The latest version of sudo (1.9.8p2-1) breaks the sshuttle package.
After upgrading sudo, sshuttle fails with this error:
--snip--
Starting sshuttle proxy (version 1.0.5).
Traceback (most recent call last):
File "/usr/bin/sshuttle", line 33, in
sys.exit(load_entry_point('sshuttle==1.0.5', 'console_scripts',
'sshuttle')())
File "/usr/lib/python3/dist-packages/sshuttle/cmdline.py", line 46, in main
return firewall.main(opt.method, opt.syslog)
File "/usr/lib/python3/dist-packages/sshuttle/firewall.py", line 102, in main
stdin, stdout = setup_daemon()
File "/usr/lib/python3/dist-packages/sshuttle/firewall.py", line 73, in
setup_daemon
os.setsid()
PermissionError: [Errno 1] Operation not permitted
c : fatal: ['/usr/bin/sudo', '-p', '[local sudo] Password: ', '/usr/bin/env',
'PYTHONPATH=/usr/lib/python3/dist-packages', '/usr/bin/python3',
'/usr/bin/sshuttle', '-v', '--method', 'nft', '--firewall'] returned 1
--snip--
Downgrading to 1.9.5p2-3 fixes the problem.
T
--
A programming language should be a toolbox for the programmer to draw
upon, not a minefield of dangerous explosives that you have to very
carefully avoid touching in the wrong way.
Bug#985797: Hyperrogue creates hyperrogue.{ini,log} in current directory instead of .hyperrogue.{ini,log} in home directory
Package: hyperrogue Version: 11.3o-1 Severity: normal Contrary to what's claimed on the manpage, hyperrogue reads and creates hyperrogue.ini and hyperrogue.log in the current working directory, instead of ~/.hyperrogue.ini and ~/.hyperrogue.log. Either the manpage is wrong, or hyperrogue was misconfigured in the build. I'd prefer the latter, since it doesn't make sense for per-game configuration/logs to be stored in the current working directory. T -- I've been around long enough to have seen an endless parade of magic new techniques du jour, most of which purport to remove the necessity of thought about your programming problem. In the end they wind up contributing one or two pieces to the collective wisdom, and fade away in the rearview mirror. -- Walter Bright
Bug#984941: RM: cons -- RoQA; Unusable due to obsolete dependency
On Wed, Mar 10, 2021 at 11:47:24AM -0600, Gunnar Wolf wrote: [...] > After quickly analyzing the situation, I am requesting the removal of > cons from the archive. My reasoning is: > > 1. cons' last upload was in 2016, and the prior one was in 2006 > 2. cons has no reverse dependencies in the archive > 3. It was not part of buster, and most probably won't make it to >bullseye > 4. RC bug #904627 dates back to 2018, and has had no interaction > 5. The package's popcon is very low (12). It had a peak nearing 100 >back in 2008, but has a steady downward tendence since ~2013. [...] I agree. Cons has essentially been supplanted by SCons (albeit Conscripts are not directly compatible with SCons, some work is required to migrate). I no longer use Cons as I've migrated all my Cons-based project to SCons, and furthermore Cons has unresolved bugs that probably will never be fixed. Upstream has essentially abandoned it many years ago. I have no plans to make any further uploads of Cons. It may be safely removed from the archive. T -- It is impossible to make anything foolproof because fools are so ingenious. -- Sammy signature.asc Description: PGP signature
Bug#737185: axe: Build-depends on deprecated Tcl 8.4
On Fri, Jan 31, 2014 at 10:39:34AM +0400, Sergei Golovan wrote: Package: axe Version: 6.1.2-16 Severity: serious Tags: patch Dear Maintainer, We are about to drop Tcl/Tk 8.4 from Debian, and your axe package build depends on tcl8.4-dev. The attached patch replaces tcl8.4-dev by tcl-dev in build dependencies, which makes it build successfully for unstable where tcl-dev pulls tcl8.5-dev, but not in experimental where tcl-dev depends on tcl8.6-dev, so I had to define USE_INTERP_RESULT macro also. If you don't mind, I could do NMU with these changes. [...] Hi, Thanks for taking the time to make this patch! Please go ahead and NMU, as I actually have not been using this package for years now. If you like, you could take over as maintainer too. T -- Two wrongs don't make a right; but three rights do make a left... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674097: Buggy output with -layers OptimizeFrame
Package: imagemagick Version: 8:6.7.4.0-5 Severity: normal Somewhere between 6.6.* and 6.7.*, something went wrong with convert's -layers OptimizeFrame. When assembling an animated .gif from a series of images (all of exactly the same dimensions), when -layers OptimizeFrame is specified, an extraneous border is added to the right and bottom edges of the resulting .gif. When -layers OptimizeFrame is omitted, the resulting .gif has the same dimensions as the input frames, as expected. This extraneous border is sometimes white, sometimes black. Example buggy output: convert -delay 150 /usr/share/icons/gnome/48x48/mimetypes/libreoffice-* -layers OptimizeFrame /tmp/test.gif identify /tmp/test.gif All input files are 48x48, but the resulting .gif has dimensions 60x66. This is wrong, since optimizing frames should never increase the size of the original input frames. If -layers OptimizeFrame is omitted, then the output is normal (48x48). If the input files have transparency, the border is black -- very noticeably buggy output. T -- It's bad luck to be superstitious. -- YHL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#667459: Bug confirmed
I just encountered the same bug yesterday. I was running a custom kernel that did not have KMS enabled, and the radeon driver (6.14.4-1) crashes with a segfault upon startup (regardless of the KMS setting in modprobe, so it's not the setting but the KMS itself that made the difference). Downgrading to 6.14.3-2 resolves the problem. Today, I rebuilt the kernel with KMS enabled, and now 6.14.4-1 works without any problem. T -- I'm not childish; I'm just in touch with the child within! - RL -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#478213: [PATCH] Powermanga segfault due to array overrun
Hi All,
I've been experiencing sporadic segfaults as well over the years, and
finally today I caught it while running powermanga (with full debugging
symbols) under gdb. I can confirm that what Kalle Olavi Niemitalo said
is correct: img_old_angle is assigned the value of img_angle before
img_angle is clipped by the array bounds, so there is a possibility of
it being out of bounds.
Here's a patch to fix this bug:
--- tmp/powermanga-0.90.orig/src/shots.c2007-08-24 00:55:17.0
-0700
+++ powermanga-0.90-dfsg/src/shots.c2011-12-26 21:10:28.0 -0800
@@ -447,8 +447,6 @@
{
bullet-img_angle = (Sint16) (bullet-angle / PI_SUR_16);
}
-/* save current angle for the calculation of the next angle */
-bullet-img_old_angle = bullet-img_angle;
/* avoid negative indexes */
bullet-img_angle = (Sint16) abs (bullet-img_angle);
/* avoid a shot angle higher than the number of images */
@@ -456,6 +454,8 @@
{
bullet-img_angle = (Sint16) (bullet-spr.numof_images - 1);
}
+/* save current angle for the calculation of the next angle */
+bullet-img_old_angle = bullet-img_angle;
/* draw the shot sprite */
draw_sprite (bullet-spr.
img[bullet-img_angle],
Please apply the patch and upload. Thanks!! :)
T
--
Change is inevitable, except from a vending machine.
--- tmp/powermanga-0.90.orig/src/shots.c 2007-08-24 00:55:17.0 -0700
+++ powermanga-0.90-dfsg/src/shots.c 2011-12-26 21:10:28.0 -0800
@@ -447,8 +447,6 @@
{
bullet-img_angle = (Sint16) (bullet-angle / PI_SUR_16);
}
-/* save current angle for the calculation of the next angle */
-bullet-img_old_angle = bullet-img_angle;
/* avoid negative indexes */
bullet-img_angle = (Sint16) abs (bullet-img_angle);
/* avoid a shot angle higher than the number of images */
@@ -456,6 +454,8 @@
{
bullet-img_angle = (Sint16) (bullet-spr.numof_images - 1);
}
+/* save current angle for the calculation of the next angle */
+bullet-img_old_angle = bullet-img_angle;
/* draw the shot sprite */
draw_sprite (bullet-spr.
img[bullet-img_angle],
signature.asc
Description: Digital signature
Bug#653078: Missing dependency on libphobos2
Package: gdc-4.6 Version: 0.29.1-4.6.2-3 Severity: normal Hi, Thanks sooo much for finally packaging gdc for D version 2!! There's a missing dependency on libphobos2-4.6-dev, however. This causes standard library references like std.compiler to fail to compile. Manually installing libphobos2-4.6-dev fixes the problem. This should be a Recommends: so that apt-get knows to install it by default. Thanks! T -- If it's green, it's biology, If it stinks, it's chemistry, If it has numbers it's math, If it doesn't work, it's technology. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650416: Please upload latest upstream
Package: libcdd0 Version: 094b.dfsg-4.2 Severity: wishlist The latest upstream is 094f, which has been available since 2008. It would be nice if we could update the libcdd packages to this version, which can be obtained from here: ftp://ftp.ifor.math.ethz.ch/pub/fukuda/cdd/ This latest version includes some bug fixes for the LP algorithms provided by the library. It's distributed under GPL2. Thanks very much! --T -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#631135: Support D version 2
Package: gdc Version: 4.4.5-10 Severity: wishlist Currently, gdc as shipped in Debian only supports D version 1, which is no longer recommended for new projects by the D development team. Support for D version 2 is already in upstream gdc; it would be much appreciated if Debian could provide a gdc build that supports D version 2. :) Thanks! T -- Why waste time learning, when ignorance is instantaneous? -- Hobbes, from Calvin Hobbes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630094: gdc looks for cc1d in wrong path
Package: gdc-4.4
Version: 1.063-4.4.6-2
Severity: serious
$ gdc hash.d
gdc: error trying to exec 'cc1d': execvp: No such file or directory
$ strace gdc hash.d
execve(/usr/bin/gdc, [gdc, hash.d], [/* 21 vars */]) = 0
[... snipped ...]
stat(/mnt/1/usr/bin/../lib/gcc/x86_64-linux-gnu/4.4.6/cc1d, 0x7fff976f3240) =
-1 ENOENT (No such file or directory)
stat(/mnt/1/usr/bin/../lib/gcc/cc1d, 0x7fff976f3240) = -1 ENOENT (No such
file or directory)
stat(/usr/libexec/gcc/x86_64-linux-gnu/4.4.6/cc1d, 0x7fff976f3240) = -1
ENOENT (No such file or directory)
stat(/usr/libexec/gcc/x86_64-linux-gnu/cc1d, 0x7fff976f3240) = -1 ENOENT (No
such file or directory)
stat(/usr/lib/gcc/x86_64-linux-gnu/4.4.6/cc1d, 0x7fff976f3240) = -1 ENOENT
(No such file or directory)
stat(/usr/lib/gcc/x86_64-linux-gnu/cc1d, 0x7fff976f3240) = -1 ENOENT (No such
file or directory)
stat(/mnt/1/usr/bin/../lib/gcc/x86_64-linux-gnu/4.4.6/../../../../x86_64-linux-gnu/bin/x86_64-linux-gnu/4.4.6/cc1d,
0x7fff976f3240) = -1 ENOENT (No such file or directory)
stat(/mnt/1/usr/bin/../lib/gcc/x86_64-linux-gnu/4.4.6/../../../../x86_64-linux-gnu/bin/cc1d,
0x7fff976f3240) = -1 ENOENT (No such file or directory)
vfork(gdc: error trying to exec 'cc1d': execvp: No such file or directory
) = 27254
--- SIGCHLD (Child exited) @ 0 (0) ---
wait4(27254, [{WIFEXITED(s) WEXITSTATUS(s) == 255}], 0, NULL) = 27254
stat(/tmp/ccjeVKQM.s, {st_mode=S_IFREG|0600, st_size=0, ...}) = 0
unlink(/tmp/ccjeVKQM.s) = 0
exit_group(1) = ?
From the strace, it seems that gdc is looking for cc1d under the '4.4.6'
subdirectory in gcc/x86_64-linux-gnu, but the gdc-4.4 package ships cc1d
in a different directory:
$ dpkg -L gdc-4.4
[... snipped ...]
/usr/lib/gcc/x86_64-linux-gnu
/usr/lib/gcc/x86_64-linux-gnu/4.4
/usr/lib/gcc/x86_64-linux-gnu/4.4/cc1d
[... snipped ...]
Manually adding a symlink 4.4.6 - 4.4 in /usr/lib/gcc/x86_64-linux-gnu
fixes the problem.
--T
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630094: gdc looks for cc1d in wrong path
On Sat, Jun 11, 2011 at 03:29:12AM +0200, Matthias Klose wrote: wait until -3 is built OK, thanks for the quick response! BTW, I notice that gdc ships with D version 1 support by default. Is there any plan to release a build with D version 2 support anytime soon? Thanks! --T -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622893: /etc/init.d/udev should not rely on /run unless it's actually writable
Package: udev Version: 167-2 Severity: important The latest udev upgrades completely broke my system, because somebody shipped /run (was it base-files?), but /etc/init.d/udev was run when the root FS is still mounted read-only. As a result, it sees /run and tries to create stuff under it and fails, aborts, and the rest of the boot process was screwed because /dev was not populated. (I don't know why it didn't mount tmpfs over /run, which *would* have avoided the problem.) `\rm -rf /run` fixed the problem. Regardless of whose fault it is that /run is broken, IMNSHO /etc/init.d/udev should not be using it unless it's actually writable --- not just permissions writable, but it shouldn't be used at all if the filesystem it's on is mounted read-only, or if it can't be written to for whatever other reason. At the very least, /etc/init.d/udev should catch failures and fallback to /dev/.udev if /run fails for any reason (if anything, /dev/ is at least guaranteed to be writable, since if not, we're screwed anyway and there's no point in continuing). I'll leave it up to the maintainer to decide what severity this bug should be at. (I was going to file it as critical but since removing /run fixed the problem, I'll settle with 'important'). T -- PNP = Plug 'N' Pray -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#617839: FTBFS with gcc 4.5
On Fri, Mar 11, 2011 at 07:40:57PM +0100, Artur Rona wrote: Package: atom4 Version: 4.1-5 I have noticed that revision 4.1-5 has introduced FTBFS with gcc 4.5. Here is a piece of log: g++ -pedantic -Werror -DDATADIR=\/usr/share/games/atom4\ -O2 -Iinclude -Iproglib/include -c engine/ai.cc -o engine/ai.o cc1plus: warnings being treated as errors engine/ai.cc: In member function 'void atom4ai::pick_best_move(int)': engine/ai.cc:227:31: error: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result engine/ai.cc:228:31: error: ignoring return value of 'ssize_t write(int, const void*, size_t)', declared with attribute warn_unused_result [...] Hi Artur, Thanks for the report! I don't have very much time to work on this package currently; so please feel free to NMU as you see fit. Thanks! T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603611: RFA: axe -- An editor for X
Package: wnpp Severity: normal I have not been using this editor for many years now. The codebase is old and buggy: some features are no longer working, and difficult to fix due to the fact that parts of it was copy-n-pasted from very old X11R5 and X11R4 code and then hacked. There's currently a bug against the .info files it ships with---unfortunately upstream did not ship the .texi source for it so it's annoying to fix. This package is non-free, and upstream has repeatedly declined to change its license, which makes it not worthwhile to invest the time and effort to fix it. Upstream has also abandoned it years ago. In short, this package is non-free, buggy, and nearing the end of its life. A few people (very few, but non-zero) still use it, so it should probably still stick around for a little longer. I no longer have the time or interest to maintain it, so I'll be very happy if someone else can take the job. Thanks! T -- Ruby is essentially Perl minus Wall. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600139: RE : Bug#600139: mogrify does not respect +set date:create and +set date:modify
merge 594693 600139 thanks On Sun, Oct 17, 2010 at 11:09:58AM +0200, Bastien ROUCARIES wrote: We have some previous bug report about this. Search convert and size on the pts. I have not a full internet connection but this bug is tagged fixed upstream. Feel free to merge the two bug report Bastien Le 13 oct. 2010 23:45, H. S. Teoh hst...@quickfur.ath.cx a écrit : Package: imagemagick Version: 8:6.6.0.4-2.2 Severity: normal Since about version 5 or so, imagemagick has started to always add metadata fields to output files that support it. The date:create and date:modify fields are always added to PNG files. This is problematic when script-generated images are managed by SVN, because SVN always finds a difference in the image files even though their content and other non-volatile metadata are identical. This behaviour can be suppressed in `convert` by specifying `+set date:create +set date:modify`; the properties are not written to the target file. However, `mogrify`, which modifies the file in-place, does not appear to respect this. It will ALWAYS set date:create and date:modify in the file regardless of whether the +set options are specified. This is a bug. T -- He who does not appreciate the beauty of language is not worthy to bemoan its flaws. -- It's amazing how careful choice of punctuation can leave you hanging: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600139: mogrify does not respect +set date:create and +set date:modify
Package: imagemagick Version: 8:6.6.0.4-2.2 Severity: normal Since about version 5 or so, imagemagick has started to always add metadata fields to output files that support it. The date:create and date:modify fields are always added to PNG files. This is problematic when script-generated images are managed by SVN, because SVN always finds a difference in the image files even though their content and other non-volatile metadata are identical. This behaviour can be suppressed in `convert` by specifying `+set date:create +set date:modify`; the properties are not written to the target file. However, `mogrify`, which modifies the file in-place, does not appear to respect this. It will ALWAYS set date:create and date:modify in the file regardless of whether the +set options are specified. This is a bug. T -- He who does not appreciate the beauty of language is not worthy to bemoan its flaws. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598401: Command for deliberately discarding undo history
Package: vim Version: 2:7.3.000+hg~ee53a39 Severity: wishlist Since 7.3, vim comes with the Persistent Undo feature. While it is nice to preserve undo history across opening/closing buffers, there doesn't seem to be a way to *deliberately* discard undo history. It would be nice if there was a command to do this. T -- The fact that anyone still uses AOL shows that even the presence of options doesn't stop some people from picking the pessimal one. - Mike Ellis -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#549483: axe: diff for NMU version 6.1.2-15.1
On Wed, Apr 28, 2010 at 06:36:59AM -0700, tony mancill wrote: [...] Dear maintainer, I've prepared an NMU for axe (versioned as 6.1.2-15.1) and uploaded it to DELAYED/3. Please feel free to tell me if I should delay it longer. [...] Hi, Thanks for the NMU! I'm sorry I have been very busy lately and haven't had the time to look after this package. Thanks for your help. T -- Time flies like an arrow. Fruit flies like a banana. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518557: Wrong path in hal-synce-rndis
Package: synce-hal
Version: 0.13.1-1
Severity: serious
Justification: makes rndis devices unusable
Hi, there is an error in /usr/lib/hal/hal-synce-rndis: the path to /var
is prefixed with /usr, with the result that dhclient is unable to create
the pidfile and the lease file, so that HAL doesn't think the device is
connected.
% grep /var /usr/lib/hal/hal-synce-rndis
pidfile = /usr/var/run/dhclient-synce-+iface+.pid
leasefile = /usr/var/run/dhclient-synce-+iface+.lease
pidfile = /usr/var/run/dhclient-synce-+iface+.pid
leasefile = /usr/var/run/dhclient-synce-+iface+.lease
%
From a cursory look at the source, this appears to be caused by running
configure with --prefix=/usr, since line 950 in the configure script
reads:
localstatedir='${prefix}/var'
So when $prefix is set to /usr in debian/rules, localstatedir gets set
to /usr/var/, which is non-existent.
The configure script probably has to be coaxed to do the right thing by
explicitly specifying localstatedir=/var, or something along those
lines.
T
--
The easy way is the wrong way, and the hard way is the stupid way. Pick one.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501591: Reading from stdin with +I- is broken
On Sun, Feb 01, 2009 at 11:51:04PM +0100, Torsten Werner wrote: Hi, On Wed, Oct 8, 2008 at 6:35 PM, H. S. Teoh hst...@quickfur.ath.cx wrote: According to the manpage, running 'povray +I-' will read the input file from stdin. According to the povray output, it has set the input file to stdin; however, it seems to be reading garbage characters instead of the real standard input. The answer from the upstream authors is: The man page is outdated. This is a documentation bug. There is no stdin reading supported and has not been for a long time as the ability to seek within the file must be available for POV-Ray to work properly with all scene files. [...] OK, then the manpage needs to be fixed. :-) Thanks for the followup. T -- It is of the new things that men tire --- of fashions and proposals and improvements and change. It is the old things that startle and intoxicate. It is the old things that are young. -- G.K. Chesterton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#501591: Reading from stdin with +I- is broken
Package: povray
Version: 1:3.6.1-12
Severity: normal
According to the manpage, running 'povray +I-' will read the input file from
stdin. According to the povray output, it has set the input file to stdin;
however, it seems to be reading garbage characters instead of the real standard
input. Example:
---snip---
% echo 'sphere { 0,0,0, 1 }' | povray +I-
povray: cannot open the user configuration file
/home/hsteoh/.povray/3.6/povray.conf: No such file or directory
Persistence of Vision(tm) Ray Tracer Version 3.6.1 (Debian (i486-linux-gnu-g++
4.3.1 @ i486-pc-linux-gnu))
This is an unofficial version compiled by:
Clément Stenac zorglub at debian dot org for Debian www.debian.org
The POV-Ray Team(tm) is not responsible for supporting this version.
POV-Ray is based on DKBTrace 2.12 by David K. Buck Aaron A. Collins
Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2004 Persistence of Vision Raytracer Pty. Ltd.
Primary POV-Ray 3.5/3.6 Developers: (Alphabetically)
Chris Cason Thorsten Froehlich Nathan Kopp Ron Parker
Contributing Authors: (Alphabetically)
Steve Anger Eric Barish Dieter BayerSteve A. Bennett
David K. Buck Nicolas Calimet Aaron A. CollinsChris Dailey
Steve DemlowAndreas Dilger Alexander Enzmann Dan Farmer
Mark Gordon Christoph Hormann Mike Hough Chris Huff
Kari Kivisalo Lutz KretzschmarJochen Lippert Pascal Massimino
Jim McElhiney Douglas MuirJuha Nieminen Bill Pulver
Eduard Schwan Wlodzimierz Skiba Robert Skinner Yvo Smellenbergh
Zsolt Szalavari Scott TaylorMassimo Valentini Timothy Wegner
Drew Wells Chris Young
Other contributors are listed in the documentation.
Support libraries used by POV-Ray:
ZLib 1.2.3.3, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
LibPNG 1.2.27, Copyright 1998-2002 Glenn Randers-Pehrson
LibJPEG 6b, Copyright 1998 Thomas G. Lane
LibTIFF 3.8.2, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Redirecting Options
All Streams to console..On
Debug Stream to console.On
Fatal Stream to console.On
Render Stream to consoleOn
Statistics Stream to consoleOn
Warning Stream to console...On
Parsing Options
Input file: stdin (compatible to version 3.61)
Remove boundsOn
Split unions.Off
Library paths:
/usr/share/povray
/usr/share/povray/ini
/usr/share/povray/include
Output Options
Image resolution 320 by 240 (rows 1 to 240, columns 1 to 320).
Output file: /tmp/stdin.png, 24 bpp PNG
Graphic display..On (gamma: 2.2)
Mosaic preview...Off
CPU usage histogram..Off
Continued trace..Off
Tracing Options
Quality: 9
Bounding boxes...On Bounding threshold: 3
Light Buffer.On
Vista Buffer.On Draw Vista BufferOff
Antialiasing.Off
Clock value:0.000 (Animation off)
0:00:00 Parsing
Parse Error: Illegal character in input file, value is fff8.
Total Scene Processing Times
Parse Time:0 hours 0 minutes 0 seconds (0 seconds)
Photon Time: 0 hours 0 minutes 0 seconds (0 seconds)
Render Time: 0 hours 0 minutes 0 seconds (0 seconds)
Total Time:0 hours 0 minutes 0 seconds (0 seconds)
%
---snip---
T
--
VI = Visual Irritation
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#501592: Paragraph truncated in manpage
Package: povray Version: 1:3.6.1-12 Severity: normal Quote from the manpage: snip Parsing options: Iinput_file_name or Input_File_Name=file Specifies the input file to use. If the input file name is ’-’, the scene description will be read from the standard input. The HIheader_include_file_name or Include_Header=file Specifies a file as the first include file of a scene file. This can be used to always include a specific set of default include files used by all your scenes. snip The paragraph after Iinput_file_name... seems to be truncated. T -- Claiming that your operating system is the best in the world because more people use it is like saying McDonalds makes the best food in the world. -- Carl B. Constantine -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#495130: Dangling symlink: /usr/share/doc/libcdd-dev/NEWS
Package: libcdd-dev Version: 094b.dfsg-2 Severity: normal Hi, the symlink /usr/share/doc/libcdd-dev/NEWS points to /usr/share/doc/libcdd-dev/HISTORY, but the latter file doesn't exist in this package. Perhaps an oversight in the packaging? Thanks, T -- People walk. Computers run. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489921: odccm should be replaceable with synce-hal
Package: synce-sync-engine Version: 0.11.1-1 Severity: important Hi, currently synce-sync-engine depends on odccm, but for some devices, synce-hal should be used instead, and odccm should NOT be used (odccm and synce-hal conflict with each other). So the Depends: line should have 'odccm | synce-hal' instead of just 'odccm'. Thanks! T -- If the comments and the code disagree, it's likely that *both* are wrong. -- Christopher -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#489922: odccm conflicts with synce-hal
Package: odccm Version: 0.11.1-1 Severity: important Hi, odccm conflicts with synce-hal, and should have synce-hal on its Conflicts: line. Although they can both be installed, they do not work when both are running: odccm will attempt to grab the connection before synce-hal is able to fully synchronize with the PocketPC, which may cause connection failure (and other problems) with the device. Thanks! T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474882: xscavenger: FTBFS: scav.c:561: internal compiler error: in build2_stat, at tree.c:3116
severity 474882 important thanks Hi, this appears to be a bug in gcc 4.3 (I don't think internal compiler error is the fault of the code; even if the code is wrong, the compiler should not encounter an internal error). I'll downgrade this to important while I investigate why it's failing in this way. --T On Mon, Apr 07, 2008 at 10:53:34PM +0200, Lucas Nussbaum wrote: Package: xscavenger Version: 1.4.4-5 Severity: serious User: [EMAIL PROTECTED] Usertags: qa-ftbfs-20080407 qa-ftbfs Justification: FTBFS on i386 Hi, During a rebuild of all packages in sid, your package failed to build on i386. This rebuild was done with gcc 4.3 instead of gcc 4.2, because gcc 4.3 is now the default on most architectures (even if it's not the case on i386 yet). Feel free to downgrade this bug to 'important' if your package is only built on i386, and this bug is specific to gcc 4.3 (i.e the package builds fine with gcc 4.2). Relevant part: make[1]: Entering directory `/build/user/xscavenger-1.4.4/src' gcc -m32 -g -O2 -fno-strict-aliasing -O2 -g -pipe -Wall -Wno-pointer-sign -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DFUNCPROTO=15 -DNARROWPROTO -DLIBNAME=\/usr/lib/games/xscavenger\ -c -o anim.o anim.c anim.c: In function 'animprocess': anim.c:613: warning: 'by' may be used uninitialized in this function anim.c:613: warning: 'bx' may be used uninitialized in this function gcc -m32 -g -O2 -fno-strict-aliasing -O2 -g -pipe -Wall -Wno-pointer-sign -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DFUNCPROTO=15 -DNARROWPROTO -DLIBNAME=\/usr/lib/games/xscavenger\ -c -o edit.o edit.c gcc -m32 -g -O2 -fno-strict-aliasing -O2 -g -pipe -Wall -Wno-pointer-sign -Dlinux -D__i386__ -D_POSIX_C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DFUNCPROTO=15 -DNARROWPROTO -DLIBNAME=\/usr/lib/games/xscavenger\ -c -o scav.o scav.c scav.c: In function 'paintlevel': scav.c:561: internal compiler error: in build2_stat, at tree.c:3116 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. make[1]: *** [scav.o] Error 1 The full build log is available from: http://people.debian.org/~lucas/logs/2008/04/07 A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on about 50 AMD64 nodes of the Grid'5000 platform, using a clean chroot containing a sid i386 environment. Internet was not accessible from the build systems. -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- Never wrestle a pig. You both get covered in mud, and the pig likes it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#472796: Bug confirmed
severity 472796 serious thanks Justification: makes package useless. This morning I upgraded, and got the same error: debtags: symbol lookup error: debtags: undefined symbol: _ZN6wibble9exception10AddContext9s_contextE dpkg: error processing debtags (--configure): subprocess post-installation script returned error exit status 127 T -- What's a hot crossed bun? An angry rabbit. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464742: Please depend on libgif4 instead of libungif4g
Package: fontforge Version: 0.0.20071110-1 Severity: normal Hi, now that libgif4 has replaced libungif4g, fontforge should no longer depend on libungif4g, but on libgif4 instead. Thanks! --T -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#211305: Output of ssh -vvv
On Fri, Feb 01, 2008 at 09:43:30PM +, Colin Watson wrote: On Mon, Jan 14, 2008 at 09:10:04PM -0800, H. S. Teoh wrote: A little more investigation has revealed a non-random way of reproducing this bug. I have discovered that the random disconnects were due to exim4 on the remote host trying to deliver large emails to a forwarded port. Attempting to deliver any one of these large emails triggers either the Bad packet length error or the fatal buffer_append_space error. This is https://bugzilla.mindrot.org/show_bug.cgi?id=1360. I'm going to backport the patch now. However, it's not the same as whatever #211305 originally was; the upstream bug trail indicates that it's due to a patch in 4.7. [...] Ah, I see. Thanks for the info. I thought they were the same problem, but apparently not. Sorry for the confusion. --T -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#460768: patch
On Tue, Jan 29, 2008 at 10:40:58PM +0800, Ying-Chun Liu (PaulLiu) wrote: tags 460768 + patch thanks Dear all, I made a patch for transition to gnome2. It seems not hard. :) The rest is to adjust the Build-Depends field in debian/control. For example, depends on libgnomeui-dev instead of libgnome-dev. [...] Thanks for the help! I've uploaded the fixed package to the queue. --T signature.asc Description: Digital signature
Bug#460768: Upload pending
tags 460768 + pending thanks T -- Guns don't kill people. Bullets do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#211305: Bad packet length errors also seen here
Hi, Recently I'm starting to see this issue as well, on ssh (1:4.7p1-2). Here's my setup: my home PC has a script that connects via ssh to a remote server, bringing it back up whenever it does down. It runs ssh with a few forwarded ports, so that connecting to localhost:1234 on the remote server gets forwarded over the tunnel back to port 22 on the home PC. This way, when I'm not at home, I can connect to the remote server, then run 'ssh -Cp1234 localhost' to get a shell on my home PC. If the connection dies for whatever reason, the script brings it back up. This arrangement has been working quite well for several months now, but recently, I started seeing random disconnects when I connect to my home PC over the forwarded port. This only happens randomly, so at first I attributed it to an unreliable link at home (either due to ISP failure or cable modem reboots, etc.). But eventually, I noticed messages of this sort in the remote server's auth.log: Jan 14 15:38:26 eusebeia sshd[32486]: fatal: buffer_append_space: len 1892239 not supported Jan 14 15:41:56 eusebeia sshd[17967]: Received disconnect from 70.79.82.195: 2: Bad packet length 325212. Jan 14 15:44:26 eusebeia sshd[29914]: fatal: buffer_append_space: len 1897286 not supported Jan 14 15:49:05 eusebeia sshd[3128]: fatal: buffer_append_space: len 1880259 not supported Clearly, given the frequency of this error, something is wrong, but I'm not sure what. If you'd like me to test anything in my setup, please let me know, as I'm seeing this problem every day. T -- Two wrongs don't make a right; but three rights do make a left... signature.asc Description: Digital signature
Bug#211305: Output of ssh -vvv
Hi, A little more investigation has revealed a non-random way of reproducing this bug. I have discovered that the random disconnects were due to exim4 on the remote host trying to deliver large emails to a forwarded port. Attempting to deliver any one of these large emails triggers either the Bad packet length error or the fatal buffer_append_space error. Downgrading to openssh-client 1:4.6p1-5 fixes the problem. I can readily reproduce the bug by upgrading to openssh-client 1:4.7p1-2. The server is running on 1:4.7p1-2 in both cases. (I didn't explicitly test downgrading both server and client, but presumably that works since that was what I have been running on before upgrading to 1:4.7p1-*.) Anyway, I've attached the output of 'ssh -vvv' of a session that aborted due to this bug (see badlength.LOCAL), as well as the corresponding snippet from the server's auth.log (in badlength.REMOTE). Hope this helps to locate the bug. If you need more info, please let me know, as I can now reliably reproduce this problem. Thanks! --T debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win 2097152 max 32768 debug1: client_request_forwarded_tcpip: listen localhost port 2501, originator 127.0.0.1 port 56903 debug2: fd 9 setting O_NONBLOCK debug2: fd 9 setting TCP_NODELAY debug3: fd 9 is O_NONBLOCK debug3: fd 9 is O_NONBLOCK debug1: channel 3: new [127.0.0.1] debug1: confirm forwarded-tcpip debug3: channel 3: waiting for connection debug1: channel 3: connected Disconnecting: Bad packet length 434908. debug3: channel 0: close_fds r 4 w 4 e -1 c -1 debug3: channel 1: close_fds r 5 w 5 e -1 c -1 debug3: channel 2: close_fds r 6 w 7 e 8 c -1 debug3: channel 3: close_fds r 9 w 9 e -1 c -1 debug1: compress outgoing: raw data 764, compressed 589, factor 0.77 debug1: compress incoming: raw data 49924, compressed 36743, factor 0.74 Jan 14 20:37:11 eusebeia sshd[12112]: debug1: Connection to port 2501 forwarding to localhost port 0 requested. Jan 14 20:37:11 eusebeia sshd[12112]: debug2: fd 11 setting TCP_NODELAY Jan 14 20:37:11 eusebeia sshd[12112]: debug2: fd 11 setting O_NONBLOCK Jan 14 20:37:11 eusebeia sshd[12112]: debug3: fd 11 is O_NONBLOCK Jan 14 20:37:11 eusebeia sshd[12112]: debug1: channel 2: new [forwarded-tcpip] Jan 14 20:37:11 eusebeia sshd[12112]: debug2: channel 2: open confirm rwindow 2097152 rmax 2097152 Jan 14 20:37:12 eusebeia sshd[12112]: Received disconnect from 70.79.82.195: 2: Bad packet length 434908. Jan 14 20:37:12 eusebeia sshd[12112]: debug1: do_cleanup Jan 14 20:37:12 eusebeia sshd[12112]: debug1: PAM: cleanup Jan 14 20:37:12 eusebeia sshd[12112]: pam_env(ssh:setcred): Unable to open env file: /etc/environment: No such file or directory Jan 14 20:37:12 eusebeia sshd[12112]: pam_unix(ssh:session): session closed for user hsteoh Jan 14 20:37:12 eusebeia sshd[12112]: debug3: PAM: sshpam_thread_cleanup entering Jan 14 20:37:12 eusebeia sshd[12102]: debug1: do_cleanup Jan 14 20:37:12 eusebeia sshd[12102]: debug1: PAM: cleanup Jan 14 20:37:12 eusebeia sshd[12102]: debug3: PAM: sshpam_thread_cleanup entering Jan 14 20:37:12 eusebeia sshd[12102]: debug1: session_pty_cleanup: session 0 release /dev/pts/1 signature.asc Description: Digital signature
Bug#456031: XBomb interacts badly with ratpoison
Package: xbomb Version: 2.1a-7 Severity: normal Due to the way xbomb reacts to X11 resize events, if the window manager is ratpoison, it will get stuck in an infinite loop of trying to resize itself, only to have ratpoison resize it to something else, ad infinitum. Something must be wrong with the way xbomb resizes itself, because non-maximal windows are possible under ratpoison (e.g. transients in games like freedroid-rpg, xscavenger, etc., which manage to get a non-maximal size without being in an infinite loop fighting with the WM). Related packages: ii ratpoison1.4.2-1 keyboard-only window manager T -- Your inconsistency is the only consistent thing about you! -- KD -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454638: libc6 unusable on kernel 2.6.9 due to opendir/O_CLOEXEC problems
Package: libc6 Version: 2.7-3 Severity: grave Justification: renders system (mostly) unusable Hi, I upgraded libc6 to 2.7-3 using apt-get on a system running kernel 2.6.9 with SMP (unfortunately I don't have the option of changing this kernel, it's provided by my colo provider), and dpkg crashed with Unknown error 530. Subsequently, everything that scanned directories crashed with the same error (ls, dpkg, etc.). Eventually, I found out that the filesystem was still intact; I could cd into directories, and ls works on the current directory. My current shell (presumably still linked to the old shared lib) can still scan directories (`echo /path/name/*` works). Pathnames that referenced individual files also worked; but any new process besides my current shell that used opendir() crashed with the same error. Then I found this: http://www.nabble.com/-Bug-libc-5227--New:-opendir-and-O_CLOEXEC-problems-with-Linux-2.6.9-5.ELsmp-kernel-t4705183.html It seems that glibc 2.7 has problems with opendir() and O_CLOEXEC on kernel 2.6.9 with SMP enabled. Downgrading to glibc2.6 fixed all my problems. I presume libc6 2.7 works on the most recent kernels, but it's very not-nice for people running 2.6.9 with smp to upgrade libc6 and find their system almost completely unusable. T -- How are you doing? Doing what? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452718: ttf-opensymbol non-installable
Package: ttf-opensymbol Version: 1:2.3.0.dfsg-3 Severity: serious Hi, upgrading to ttf-opensymbol with apt-get gives me: Setting up ttf-opensymbol (1:2.3.0.dfsg-3) ... Updating fontconfig cache... /var/lib/dpkg/info/ttf-opensymbol.postinst: line 98: 4969 Segmentation fault fc-cache -fs dpkg: error processing ttf-opensymbol (--configure): subprocess post-installation script returned error exit status 139 Errors were encountered while processing: ttf-opensymbol This is with fontconfig 2.5.0-2. Looks like a fontconfig bug, but filing against ttf-opensymbol since it seems to be the only font causing problems. Feel free to reassign if necessary, thanks. T -- People tell me I'm stubborn, but I refuse to accept it! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419936: glotski: minimums are not minimal
On Wed, Apr 18, 2007 at 04:56:34PM -0400, Alan Curry wrote: Package: glotski Version: 0.2-4 Severity: normal In 3 of the levels that come with glotski, the displayed minimum number of moves is wrong. See http://www.clss.net/~pacman/glotsol/ for my improved solutions and the brute-force search program I used to find them (giving me confidence that they are truly minimal.) I reported this upstream a while ago and got nothing but a promise to look into it. [...] Hi, Sorry for taking so long to respond. I've just verified that your solutions are correct. Will update it in the next upload. AFAIK, upstream hasn't been active since January 2000. I'll send the patch upstream, but no guarantee they will do anything about it. T -- There are four kinds of lies: lies, damn lies, and statistics. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#438329: xscavenger: not handling nostrip build option (policy 10.1)
On Thu, Aug 16, 2007 at 11:34:16AM +0200, Julien Danjou wrote: Package: xscavenger Version: 1.4.4-4 Severity: wishlist User: [EMAIL PROTECTED] Usertags: nostrip Hello, There was a problem while autobuilding your package with DEB_BUILD_OPTIONS=nostrip. Final binaries are still stripped. If you call dh_strip correctly in debian/rules, this may mean that upstream is stripping anyway. You should look for call to strip, ld -s or install -s which may strip binaries. [...] Hi, thanks for bringing this to my attention. I will fix this in my next upload. Thanks! T -- Life would be easier if I had the source code. -- YHL signature.asc Description: Digital signature
Bug#423141: more questions about #423141
Hi, sorry for taking so long to reply. Things just kept coming up. On Wed, Jul 11, 2007 at 11:06:16AM +0200, Bernhard R. Link wrote: [...] That may need some days before I can tell more. (Or have ideas for new testcases...) * H. S. Teoh [EMAIL PROTECTED] [070701 15:40]: Yep, it crashes. Although, the way the program is written is rather tricky to test, since it exits on keystrokes, so I have to hit C-t w before starting it. :-) Attached is a new version of the test program, that should be less sesnsitive to key events. Could you test if it also shows the behaviour of aborting when showing the window list after program started? (and not while the program is running). Ratpoison crashes both when I start the program then hit C-t w, and when I hit C-t w then run the program while the window list is still visible. There is a loop to 1000 near the end of the program. Does it also happen if that loop is removed? Yes, still happens. Does it also happen without the font or the winfmt set? (try starting ratpoison with -f /dev/null to make it omit your .ratpoisonrc). Both the test program and opera would be intresting. Actually, I think I found the real bug!! My .ratpoisonrc looks like: set winfmt %n%s%80t set wingravity center set font -misc-fixed-medium-r-normal-*-18-*-*-*-*-*-iso10646-1 After commenting out the winfmt line, ratpoison doesn't crash anymore with the test program, or with Opera. I see that the special symbols don't show up in the window list (e.g., on the Intel page, the registered trademark symbol is omitted from the window title). Looks like a pointer bug in format_string() (src/format.c) perhaps? What locale is your ratpoison running with? en_US.UTF-8 I'll try to run through the rest of your suggestions later, but I think we've found the culprit. I'll take a peek at format_string() to see if there's anything obviously wrong with it. T -- Error: Keyboard not attached. Press F1 to continue. -- Yoon Ha Lee, CONLANG -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423141: more questions about #423141
Hi, Now that I know where the bug is, I've managed to reproduce it with a debug build of ratpoison. Using gdb backtrace, I've located the problematic code: the xvsprintf() function in main.c. Towards the end of this function, there is this bit of code: - nchars = vsnprintf (buffer, size, fmt, ap_copy); #if defined(va_copy) || defined(__va_copy) va_end (ap_copy); #endif if (nchars -1 nchars size) return buffer; else if (nchars -1) size = nchars + 1; else size *= 2; - The last else clause is blatantly wrong: if vsnprintf() returns a negative value (according to the manpage, this occurs if there is an output error), then this code will double the size and try to format it again. Since the problem is not caused by the buffer size, but by an output error (which I suppose is caused by the presence of characters in the output which for some reason is in the wrong encoding), doubling the buffer size solves nothing at all. So it just loops until size is larger than the amount of available RAM, and then the allocator calls abort() and dies. I'd like to confirm my analysis with an actual code fix, but I'm not sure exactly what to do if vsnprintf() returns a negative value. The only clean way I know of is to use wide-character formatting functions, but it's non-trivial to do this with this code, and I'm not even sure if ratpoison is setting the locale properly in the first place. Maybe when I get more time I'll take another look at this. In the meantime, I hope this info may help you find a fix. T -- Why are you blatanly misspelling blatant? -- Branden Robinson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423141: P.S.
On Sun, Jul 01, 2007 at 11:59:59AM +0200, Bernhard R. Link wrote: * H. S. Teoh [EMAIL PROTECTED] [070630 20:06]: Could you try the attached program, if it also causes the crash? (Needs libx11-dev installed and compile with gcc xfakewindow.c -o xfakewindow -lX11) [...] Did you forget the attachment? Second attempt... [...] Yep, it crashes. Although, the way the program is written is rather tricky to test, since it exits on keystrokes, so I have to hit C-t w before starting it. :-) I guess this also has a side benefit of testing an alternate code path in ratpoison that leads to the same crash (updating of window list rather than just displaying it). T -- Never ascribe to malice that which is adequately explained by incompetence. -- Napoleon Bonaparte -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423141: P.S.
On Sat, Jun 30, 2007 at 11:11:25AM +0200, Bernhard R. Link wrote: * H. S. Teoh [EMAIL PROTECTED] [070630 06:45]: Also, I might add, this only happens with Opera window titles. I tried to set my rxvt title to a string containing the reg; character, but it displayed correctly. I'm not sure if this could be a bug in Opera (maybe it's not encoding the window title properly---I'm not sure how to check since ratpoison crashes outright trying to display it). But in any case, ratpoison shouldn't crash. Could you send me the output of xprop on that window when it displays that character? That would make it easier to try to reproduce it. Ah, so *that's* how I can get info out of the window without a WM. :-) The output is attached. Especially as ratpoison is not doing much with the content, it might also be a problem within xlibs. Could you mail me the versions of ratpoison and its dependencies? [...] ii libc6 2.5-9+b1 GNU C Library: Shared libraries ii libreadline5 5.2-3 GNU readline and history libraries, run-time ii libx11-6 2:1.0.3-7 X11 client-side library ii libxext6 1:1.0.3-2 X11 miscellaneous extension library ii libxinerama1 1:1.0.2-1 X11 Xinerama extension library ii libxtst6 1:1.0.1-5 X11 Testing -- Resource extension library ii ratpoison 1.4.1-4keyboard-only window manager Hope this helps to track down the problem. T -- Life is all a great joke, but only the brave ever get the point. -- Kenneth Rexroth _NET_WM_USER_TIME(CARDINAL) = 2095353897 WM_STATE(WM_STATE): window state: Normal icon window: 0x0 _NET_WM_NAME(UTF8_STRING) = 0x49, 0x6e, 0x74, 0x65, 0x6c, 0xc2, 0xae, 0x20, 0x4d, 0x6f, 0x74, 0x68, 0x65, 0x72, 0x62, 0x6f, 0x61, 0x72, 0x64, 0x73, 0x20, 0x2d, 0x20, 0x4f, 0x70, 0x65, 0x72, 0x61 XdndAware(ATOM) = ATOM _MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0xb7, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0xa6, 0xb7, 0x10, 0x0, 0x0, 0x0 OPERA_PREFERENCE(STRING) = /home/hsteoh/.opera OPERA_USER(STRING) = 1000 OPERA_VERSION(STRING) = Opera 9.21 WM_CLIENT_LEADER(WINDOW): window id # 0x82 WM_WINDOW_ROLE(STRING) = opera-mainwindow#1 _NET_WM_PID(CARDINAL) = 24299 _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL WM_PROTOCOLS(ATOM): protocols WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, WM_SAVE_YOURSELF WM_NAME(STRING) = Intel\302\256 Motherboards - Opera WM_LOCALE_NAME(STRING) = en_US.UTF-8 WM_CLASS(STRING) = opera, Opera WM_HINTS(WM_HINTS): Client accepts input or input focus: True Initial state is Normal State. bitmap id # to use for icon: 0x8b bitmap id # of mask for icon: 0x8d window id # of group leader: 0x83 WM_NORMAL_HINTS(WM_SIZE_HINTS): user specified location: 0, 0 program specified location: 0, 0 user specified size: 1022 by 766 program specified size: 1022 by 766 program specified minimum size: 1 by 154 window gravity: NorthWest WM_CLIENT_MACHINE(STRING) = crystal
Bug#423141: P.S.
On Sat, Jun 30, 2007 at 06:57:01PM +0200, Bernhard R. Link wrote: * H. S. Teoh [EMAIL PROTECTED] [070630 16:00]: Hope this helps to track down the problem. Could you try the attached program, if it also causes the crash? (Needs libx11-dev installed and compile with gcc xfakewindow.c -o xfakewindow -lX11) [...] Did you forget the attachment? T -- Computers are like a jungle: they have monitor lizards, rams, mice, c-moss, binary trees... and bugs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423141: Bug reproduced, found cause of problem
reopen 423141 thanks Hi, the bug recurred again today, and I finally discovered the cause. It is because I have Opera currently viewing a page that contains a reg; entity in its title attribute. When I switch to this tab, Opera uses it as its window title, and then C-t w causes ratpoison to exit with status 134. I managed to capture the error message as well: Virtual memory exhausted. If I switch to another tab whose title doesn't contain this character, C-t w works fine. Perhaps this is a UTF-8 issue that hasn't been fully resolved? I'm not sure what other characters may cause this problem, but I can consistently crash ratpoison this way. Anyway, if you want to reproduce this bug, you can create a simple HTML file and open it in Opera, then hit C-t w. Something like this: htmlheadtitleCrash pagereg;/title/headbody/body/html I'm running in a UTF-8 locale, if that makes a difference. Also, my .ratpoisonrc looks like: set winfmt %n%s%80t set wingravity center set font -misc-fixed-medium-r-normal-*-18-*-*-*-*-*-iso10646-1 I suspect it may be a combination of UTF-8 locale, font, and special character in window title, that triggers this bug in ratpoison. The font referenced in above is from the xfonts-efont-unicode (or xfonts-efont-unicode-ib) package. I also attached valgrind to ratpoison, and here is the output: ==24073== Memcheck, a memory error detector. ==24073== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==24073== Using LibVEX rev 1732, a library for dynamic binary translation. ==24073== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==24073== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation framework. ==24073== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==24073== For more details, rerun with: -v ==24073== ==24073== Source and destination overlap in mempcpy(0x42EC678, 0x42EC678, 25) ==24073==at 0x4023B24: mempcpy (mc_replace_strmem.c:116) ==24073==by 0x41A06F4: _IO_default_xsputn (in /lib/libc-2.5.so) ==24073==by 0x417C202: vfprintf (in /lib/libc-2.5.so) ==24073==by 0x4195C1B: vsprintf (in /lib/libc-2.5.so) ==24073==by 0x4181F2D: sprintf (in /lib/libc-2.5.so) ==24073==by 0x40BF9A0: (within /usr/lib/libX11.so.6.2.0) ==24073==by 0x40BFAC5: (within /usr/lib/libX11.so.6.2.0) ==24073==by 0x40C0424: (within /usr/lib/libX11.so.6.2.0) ==24073==by 0x40722B6: XCreateOC (in /usr/lib/libX11.so.6.2.0) ==24073==by 0x40667B6: XCreateFontSet (in /usr/lib/libX11.so.6.2.0) ==24073==by 0x805BFCD: (within /usr/bin/ratpoison) ==24073==by 0x805CEDB: (within /usr/bin/ratpoison) ==24073== ==24073== Invalid read of size 4 ==24073==at 0x4016530: (within /lib/ld-2.5.so) ==24073==by 0x4006009: (within /lib/ld-2.5.so) ==24073==by 0x40084F5: (within /lib/ld-2.5.so) ==24073==by 0x40121D4: (within /lib/ld-2.5.so) ==24073==by 0x400E255: (within /lib/ld-2.5.so) ==24073==by 0x4011C5D: (within /lib/ld-2.5.so) ==24073==by 0x4288C2C: (within /lib/libdl-2.5.so) ==24073==by 0x400E255: (within /lib/ld-2.5.so) ==24073==by 0x428929B: (within /lib/libdl-2.5.so) ==24073==by 0x4288B60: dlopen (in /lib/libdl-2.5.so) ==24073==by 0x4061448: (within /usr/lib/libX11.so.6.2.0) ==24073==by 0x406190F: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0) ==24073== Address 0x42EDAD8 is 24 bytes inside a block of size 25 alloc'd ==24073==at 0x40224B0: malloc (vg_replace_malloc.c:149) ==24073==by 0x4008AF3: (within /lib/ld-2.5.so) ==24073==by 0x40121D4: (within /lib/ld-2.5.so) ==24073==by 0x400E255: (within /lib/ld-2.5.so) ==24073==by 0x4011C5D: (within /lib/ld-2.5.so) ==24073==by 0x4288C2C: (within /lib/libdl-2.5.so) ==24073==by 0x400E255: (within /lib/ld-2.5.so) ==24073==by 0x428929B: (within /lib/libdl-2.5.so) ==24073==by 0x4288B60: dlopen (in /lib/libdl-2.5.so) ==24073==by 0x4061448: (within /usr/lib/libX11.so.6.2.0) ==24073==by 0x406190F: XCreateGlyphCursor (in /usr/lib/libX11.so.6.2.0) ==24073==by 0x4061CAC: XCreateFontCursor (in /usr/lib/libX11.so.6.2.0) ==24073== ==24073== Invalid read of size 4 ==24073==at 0x4016530: (within /lib/ld-2.5.so) ==24073==by 0x4006009: (within /lib/ld-2.5.so) ==24073==by 0x40084F5: (within /lib/ld-2.5.so) ==24073==by 0x400C616: (within /lib/ld-2.5.so) ==24073==by 0x400E255: (within /lib/ld-2.5.so) ==24073==by 0x400CBDA: (within /lib/ld-2.5.so) ==24073==by 0x4012234: (within /lib/ld-2.5.so) ==24073==by 0x400E255: (within /lib/ld-2.5.so) ==24073==by 0x4011C5D: (within /lib/ld-2.5.so) ==24073==by 0x4288C2C: (within /lib/libdl-2.5.so) ==24073==by 0x400E255: (within /lib/ld-2.5.so) ==24073==by 0x428929B: (within /lib/libdl-2.5.so) ==24073== Address 0x42EDE10 is 24 bytes inside a block of size 25 alloc'd ==24073==at 0x40224B0: malloc (vg_replace_malloc.c:149) ==24073==by 0x4008AF3: (within /lib/ld-2.5.so) ==24073==by 0x400C616: (within /lib/ld-2.5.so)
Bug#423141: P.S.
Also, I might add, this only happens with Opera window titles. I tried to set my rxvt title to a string containing the reg; character, but it displayed correctly. I'm not sure if this could be a bug in Opera (maybe it's not encoding the window title properly---I'm not sure how to check since ratpoison crashes outright trying to display it). But in any case, ratpoison shouldn't crash. T -- Let's eat some disquits while we format the biskettes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428427: dpkg -l \* \* segfaults
Package: dpkg Version: 1.14.4 Severity: normal Looks like there's some missing input sanitising in dpkg's command-line processing: % dpkg -l \* \* Segmentation fault I haven't looked in detail at what causes this. On one of my systems, something like `dpkg -l cupsys \*` also segfaults, although it didn't on this system. Running dpkg with two literal *'s causes segfaults on both systems. This probably should be fixed, in case there's an obscure security hole somewhere in there. Note that this happens when running both as non-root or as root. T -- Real Programmers use cat a.out. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423141: Bug recurred
reopen 423141 thanks Hi, today the bug recurred. I had put in an xmessage command after ratpoison in my .Xsession file in order to catch ratpoison crashing, so I was able to poke around the environment a little after the crash to determine what was going on. It appears that ratpoison is running out of virtual memory when I hit C-t w, for some reason. I wasn't running any memory hog except perhaps Opera, but then I never had things crashing because of lack of memory---at least, not unless I run something that uses a LOT of memory, and I can't imagine ratpoison opening a little window needing *that* much memory. Just this morning I was running a memory-hogging process that took up tens of MBs, and ratpoison didn't have any trouble opening the window list then. The message I'm getting is: ratpoison: Virtual memory exhausted [2]Abort ratpoison Strangely enough, after restarting ratpoison several times (while keeping the xmessage open so the session won't logout), the problem went away. All I did during that time was to save an email I was in the middle of typing (only ~200 lines, in mutt, which is text-based, so again I can't imagine how that could make a difference). Memory usage while the crash was happening: MemTotal: 255164 kB MemFree: 28648 kB Buffers: 15784 kB Cached: 100048 kB SwapCached: 21264 kB Active: 152716 kB Inactive:62508 kB SwapTotal: 120476 kB SwapFree:51108 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 91168 kB Mapped: 22316 kB Slab: 7724 kB SReclaimable: 3048 kB SUnreclaim: 4676 kB PageTables: 1136 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:248056 kB Committed_AS: 682740 kB VmallocTotal: 777940 kB VmallocUsed: 9328 kB VmallocChunk: 768524 kB Memory usage after things started working again: MemTotal: 255164 kB MemFree: 29304 kB Buffers: 17892 kB Cached: 101952 kB SwapCached: 21524 kB Active: 150060 kB Inactive:64584 kB SwapTotal: 120476 kB SwapFree:52460 kB Dirty: 24 kB Writeback: 0 kB AnonPages: 86412 kB Mapped: 19588 kB Slab: 7744 kB SReclaimable: 3048 kB SUnreclaim: 4696 kB PageTables: 1124 kB NFS_Unstable:0 kB Bounce: 0 kB CommitLimit:248056 kB Committed_AS: 674644 kB VmallocTotal: 777940 kB VmallocUsed: 9328 kB VmallocChunk: 768524 kB I don't see that much of a difference in memory usage, so I'm not convinced that it's simply because I have too little RAM. I suspect there may be some other factor that perhaps triggers a bug in ratpoison causing it to try to allocate an unusually large amount of memory. --T -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423141: Ratpoison bad build?
Package: ratpoison Version: 1.4.1-3 Severity: normal In the current binary package of ratpoison, it is possible to trigger an abort() by opening many tabs in Opera (www.opera.com), and hitting C-leftarrow, C-rightarrow (switch tabs), and C-t w repeatedly in quick succession. The gdb backtrace shows abort() being triggered somewhere inside xrealloc(), indicating some kind of memory corruption. However, I built a local copy of ratpoison with debugging symbols included, and could not trigger the bug. I rebuilt with dpkg-buildpackage and could not trigger the bug either. Perhaps the binary in the uploaded package wasn't correctly built somehow? --T -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#423141: Ratpoison bad build?
On Thu, May 10, 2007 at 09:46:14AM +0200, Bernhard R. Link wrote: * H. S. Teoh [EMAIL PROTECTED] [070510 08:26]: In the current binary package of ratpoison, it is possible to trigger an abort() by opening many tabs in Opera (www.opera.com), and hitting C-leftarrow, C-rightarrow (switch tabs), and C-t w repeatedly in quick succession. The gdb backtrace shows abort() being triggered somewhere inside xrealloc(), indicating some kind of memory corruption. However, I built a local copy of ratpoison with debugging symbols included, and could not trigger the bug. I rebuilt with dpkg-buildpackage and could not trigger the bug either. Perhaps the binary in the uploaded package wasn't correctly built somehow? What architecture are you using? i686 (Athlon Barton). Does the backtrace stop with xrealloc or does it show where this is called? The backtrace stops with xrealloc, and gdb says something along the lines of no stack frame being available to trace the higher calls. Could you try to run it in valgrind or put a xtrace between ratpoison and the server so I can see what opera is doing when switching tabs? [...] Hmm, the problem seems to have gone away after I upgraded to the latest unstable. I can't reproduce the problem anymore. It may have been a dynamic library issue with the X libraries (I know I've seen similar hard-to-reproduce problems in the past due to sync problems with X dynamic libraries). Close this bug if you wish, I'll reopen it if the problems comes back. --T -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418109: Python upgrade bug
Package: python2.4-minimal
Version: 2.4.4-3
Severity: serious
Justification: breaks upgrade
Hi, the latest python upgrade fails:
Setting up python2.4-minimal (2.4.4-3) ...
Linking and byte-compiling packages for runtime python2.4...
Traceback (most recent call last):
File /usr/bin/pycentral, line 1373, in ?
main()
File /usr/bin/pycentral, line 1363, in main
if action.check_args(global_options):
File /usr/bin/pycentral, line 971, in check_args
for rt in get_installed_runtimes():
File /usr/bin/pycentral, line 196, in get_installed_runtimes
supported = pyversions.supported_versions()
File /usr/share/pycentral-data/pyversions.py, line 98, in supported_versions
value = read_default('supported-versions')
File /usr/share/pycentral-data/pyversions.py, line 22, in read_default
value = config.get('DEFAULT', name)
UnboundLocalError: local variable 'config' referenced before assignment
dpkg: error processing python2.4-minimal (--configure):
subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
python2.4-minimal
Installed packages:
ii python-minimal 2.4.4-2A minimal subset of the Python
language (default version)
iU python2.42.4.4-3An interactive high-level
object-oriented language (version 2.4)
iF python2.4-minimal2.4.4-3A minimal subset of the Python
language (version 2.4)
ii python 2.4.4-2An interactive high-level
object-oriented language (default version)
ii python-central 0.5.13 register and build utility for
Python packages
T
--
There is no gravity. The earth sucks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#406234: Memory allocation problem upon exit
Package: powermanga Version: 0.80-dfsg-1 Severity: normal After winning the game, exiting the game will give this error: *** glibc detected *** free(): invalid pointer: 0x080a9060 *** This may or may not be related to the highscore permission problem: /var/games/powermanga/powermanga.hi: Permission denied The memory allocation bug only shows up when you win the game, though. The permission problem shows up every time the game tries to write to the highscore file. T -- The best compiler is between your ears. -- Michael Abrash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405852: Easy difficulty is broken
Package: blobwars Version: 1.05-4 Severity: normal The Easy difficulty setting is broken in many ways: - The level descriptions contain information only relevant to Normal or Hard difficulties (such as references to needing to collect dynamite or destroying security points). The worst of this is referring to bits of the story, e.g. battling Galdov, the ancient crystals, etc., that really should be hidden from the player except when playing Normal or Hard (at least, according to the Easy ending, the player shouldn't know all of this except when playing Normal or Hard). - Some levels can end in a stuck place: e.g. in Forgotten Caves, it is possible to rescue the last required MIA (in the first time through) in the cave with the green card. Upon restarting, the breakable walls that block the entrance into the cave reappear, but the player only has a pistol and has no way to get through the walls again. The only recourse is to wait for an enemy to show up and drop a grenade launcher---but since this is the Easy level, this can be a VERY long wait since enemies don't show up frequently (on the order of 20 minutes in real time, or much longer if the enemies fail to drop a grenade launcher). T -- Outlook not so good. That magic 8-ball knows everything! I'll ask about Exchange Server next. -- (Stolen from the net) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405854: Can climb up ice walls in Ice Caves #2
Package: blobwars Version: 1.05-4 Severity: minor In Ice Caves #2, it is possible to climb up the left wall of the second area with the Ice Blobs without a Jetpack. It appears to be a bug involving the earthquake in that area, where if you hold down the right and up keys while standing at the bottom of the wall, you will eventually jump all the way up into the Ice Blobs area. Unfortunately, the same trick doesn't work on right-facing walls, so if you drop down into the area inside, you'll never be able to get out (unless you have the Jetpack, in which case this bug is irrelevant). T -- Spaghetti code may be tangly, but lasagna code is just cheesy. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396631: Same problem with latest version of apache2/libapr1
On Tue, Dec 19, 2006 at 09:55:39AM +0100, Andreas Barth wrote: [...] I uploaded packages for this architecture now on http://people.debian.org/~aba/apr/ - the changes-file is signed by me so that you know it was really me. [...] I just tested it. It works flawlessly! I'm not sure why building on the server itself doesn't work... I'd like to track that down, although I don't think it's related to this bug. My locally-built package seems to be unable to correctly process apache's Include directives, so maybe this is related to filesystem access. T -- Life is unfair. Ask too much from it, and it may decide you don't deserve what you have now either. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#403792: Missing sound files
Package: fillets-ng-data
Version: 0.7.1-4
Severity: important
Hi, the sound files for the fishes' winning shouts are missing from the
package:
ResSoundPack.cpp:35: WARNING cannot load sound;
path='/usr/share/games/fillets-ng/sound/share/border/cs/sp-shout_small_01.ogg';
MixError='Mix_LoadWAV_RW with NULL src'
ResSoundPack.cpp:35: WARNING cannot load sound;
path='/usr/share/games/fillets-ng/sound/share/border/cs/sp-shout_big_00.ogg';
MixError='Mix_LoadWAV_RW with NULL src'
(These are not the only ones; all the sp-shout_{small,big}_??.ogg files
are missing.)
T
--
Indifference will certainly be the downfall of mankind, but who cares?
-- Miquel van Smoorenburg
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396631: Same problem with latest version of apache2/libapr1
On Fri, Dec 15, 2006 at 05:53:38PM -0600, Peter Samuelson wrote: [H. S. Teoh] Hi, the old patch (currently in unstable) already works---my test was invalid because I upgraded apache2 but forgot to upgrade libapr1. Do you still want me to test the new patch? Ahh - great to hear! Yes, If it's convenient for you, please do test my new patch. It's a little bit cleaner than the old one, and it does fix one bug, unless I'm completely misreading it. [... Hi, I just tried to build libapr1 with the new patch, but I'm unable to test it because I'm getting unrelated errors (apache2 doesn't load its configuration correctly and doesn't start... I don't think this is related to the patch, probably a build environment problem). T -- If a person can't communicate, the very least he could do is to shut up. -- Tom Lehrer, on people who bemoan their communication woes with their loved ones. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396631: Same problem with latest version of apache2/libapr1
On Tue, Dec 19, 2006 at 12:46:52AM +0100, Andreas Barth wrote: * H. S. Teoh ([EMAIL PROTECTED]) [061218 19:39]: On Fri, Dec 15, 2006 at 05:53:38PM -0600, Peter Samuelson wrote: [H. S. Teoh] Hi, the old patch (currently in unstable) already works---my test was invalid because I upgraded apache2 but forgot to upgrade libapr1. Do you still want me to test the new patch? Ahh - great to hear! Yes, If it's convenient for you, please do test my new patch. It's a little bit cleaner than the old one, and it does fix one bug, unless I'm completely misreading it. [... Hi, I just tried to build libapr1 with the new patch, but I'm unable to test it because I'm getting unrelated errors (apache2 doesn't load its configuration correctly and doesn't start... I don't think this is related to the patch, probably a build environment problem). Which architecture do you use? [...] i686. But it runs on a modified kernel that my colo provider uses for running virtual servers. I'm not sure if this makes a difference in the build. All I did was `apt-get source libapr1`, copy the new patch into debian/patches, and run `dpkg-buildpackage -r fakeroot`. T -- IBM = I Blame Microsoft -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396631: Same problem with latest version of apache2/libapr1
On Thu, Dec 14, 2006 at 10:42:21PM -0600, Peter Samuelson wrote: [H. S. Teoh] Hi, the fix for #396631 to libapr1 does not work. Apache2 still serves 0 bytes when running on a 2.4 kernel (on my virtual colo host). Please look into this problem. Thanks! My old patch is slightly buggy - can you try rebuilding apr 1.2.7-8.1 with this updated version of debian/patches/015_sendfile_lfs.dpatch? [...] Hi, the old patch (currently in unstable) already works---my test was invalid because I upgraded apache2 but forgot to upgrade libapr1. Do you still want me to test the new patch? T -- Klein bottle for rent ... inquire within. -- Stephen Mulraney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396631: Same problem with latest version of apache2/libapr1
reopen 396631 thanks Hi, the fix for #396631 to libapr1 does not work. Apache2 still serves 0 bytes when running on a 2.4 kernel (on my virtual colo host). Please look into this problem. Thanks! T -- Not all rumours are as misleading as this one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#402625: Broken upgrade path
Package: asymptote-doc Version: 1.18-2 Severity: serious Justification: Breaks upgrade path, should be fixed before release I notice that asymptote has been split into two packages, asymptote and asymptote-doc. Unfortunately, something went wrong with the split, causing following problem when upgrading from asymptote (1.14-1): Unpacking asymptote-doc (from .../asymptote-doc_1.18-2_all.deb) ... dpkg: error processing /var/cache/apt/archives/asymptote-doc_1.18-2_all.deb (--unpack): trying to overwrite `/usr/share/doc-base/asymptote', which is also in package asymptote Preparing to replace asymptote 1.14-1 (using .../asymptote_1.18-2_i386.deb) ... Unpacking replacement asymptote ... Errors were encountered while processing: /var/cache/apt/archives/asymptote-doc_1.18-2_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) T -- Windows: the ultimate triumph of marketing over technology. -- Adrian von Bidder -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#288680: Still not fixed
Hi all, I've just played this level, and the bug is still there (1.05-3). Like people have said, once you fall into this pit there is no way out, not even with the jetpack. It seems that the game is supposed to put you back where you fell from (like it does in other pits), but for whatever reason drops you to the bottom of the pit instead. The only way out is to RESTART the entire level and finish it without falling into this pit. Please forward this bug to upstream. T -- People tell me that I'm paranoid, but they're just out to get me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#401017: Bug is not HTTP-dependent
Hi, I'm also seeing this bug on my virtual colocated server. It doesn't seem to be specific to HTTP; I use FTP-only apt sources and I'm still seeing the bug: Hit ftp://ftp.us.debian.org unstable Release.gpg Hit ftp://ftp.us.debian.org unstable Release Hit ftp://ftp.us.debian.org unstable/main Packages/DiffIndex Hit ftp://ftp.us.debian.org unstable/contrib Packages/DiffIndex Hit ftp://ftp.us.debian.org unstable/main Sources/DiffIndex Hit ftp://ftp.us.debian.org unstable/contrib Sources/DiffIndex 99% [Sources bzip2 0] (...hangs forever...) Hope this helps to track down the problem. T -- The easy way is the wrong way, and the hard way is the stupid way. Pick one. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#399718: Bug confirmed
Hi, I am also seeing this bug: # apt-get update Hit ftp://ftp.us.debian.org unstable Release.gpg Hit ftp://ftp.us.debian.org unstable Release Hit ftp://ftp.us.debian.org unstable/main Packages/DiffIndex Hit ftp://ftp.us.debian.org unstable/non-free Packages/DiffIndex Hit ftp://ftp.us.debian.org unstable/contrib Packages/DiffIndex Hit ftp://ftp.us.debian.org unstable/main Sources/DiffIndex Hit ftp://ftp.us.debian.org unstable/non-free Sources/DiffIndex Hit ftp://ftp.us.debian.org unstable/contrib Sources/DiffIndex Reading package lists... Done W: There are no public key available for the following key IDs: A70DAF536070D3A1 W: You may want to run apt-get update to correct these problems Running apt-get update again repeats exactly the same message. Any known workarounds? T -- The peace of mind---from knowing that viruses which exploit Microsoft system vulnerabilities cannot touch Linux---is priceless. -- Frustrated system administrator. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392827: closed by Jesus Climent [EMAIL PROTECTED] (Disabling net scoreset does not warn about rules with dependencies on meta rules.)
reopen 392827 thanks Date: Thu, 2 Nov 2006 10:14:48 +0100 From: Jesus Climent [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Disabling net scoreset does not warn about rules with dependencies on meta rules. Disabling net scoreset does not warn about rules with dependencies on meta rules. The default configuration generates a warning about missing dependencies. This is a bug. Closed in the latest upload. The latest package still has this problem. T -- I'm running Windows '98. Yes. My computer isn't working now. Yes, you already said that. -- User-Friendly -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396631: Files served have 0 bytes in spite of claims in headers log
Package: apache2 Version: 2.2.3-3 Severity: important I'm running Apache on a 2.4 kernel (not by choice, my colo virtual server requires 2.4), and the latest Apache upgrade has some nasty problems. The first problem is epoll() compatibility causing child processes to segfault (already addressed by bug#392049), which I've fixed by using a libapr1 built on a 2.4 kernel. The second issue is a lot stranger and harder to track: after installing the 2.4-friendly libapr1, apache2.2 now manages to run without segfaulting, but all requests served have 0 bytes in the body. However, access.log claims that the resource was sent in its entirety (gives the correct byte count for every file I've tested), and the HTTP headers claim that Content-Length is (correctly) the size of the file. But Apache disconnects without actually sending the contents of the file. I've tested this with multiple browsers, wget, and telnet, and all of them are disconnected before actually receiving any actual content. There are no error messages in the error logs, and, from the appearance of the logs, the server is actually fully functional. An example access log line is: 130.253.190.245 - - [01/Nov/2006:12:09:35 -0800] GET /favicon.ico HTTP/1.1 200 326 - Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; InfoPath.1) which looks perfectly normal. Here's what it looks like with wget: 24.83.198.173 - - [01/Nov/2006:12:26:32 -0800] GET /favicon.ico HTTP/1.0 200 326 - Wget/1.10.2 Again, perfectly, normal, except that what really happens on the client end is that wget receives 0 bytes, and keeps retrying: 13:29:26 (0.00 B/s) - Connection closed at byte 0. Retrying. The HTTP headers look like this: HTTP/1.1 200 OK Date: Wed, 01 Nov 2006 20:30:21 GMT Server: Apache/2.2 Last-Modified: Fri, 13 Jan 2006 03:17:00 GMT ETag: 2e9809b-57e-e5fd4300 Accept-Ranges: bytes Content-Length: 1406 Connection: close Content-Type: image/x-icon And then the connection is immediately closed without actually sending the contents of the file. The files themselves are fine: I've checked both their contents and their permissions, as well as directory permissions. Besides, if I try to access a non-existent resource, Apache does successfully send an error message (with the HTML body intact). None of these problems show up on my laptop running kernel 2.6, so I suspect 2.4 incompatibility may be the culprit here. Any suggestions as to how to obtain more information would be greatly appreciated. I've run out of ideas as to where to look, since apache isn't crashing and the logs look perfectly normal. Setting LogLevel to 'debug' shows no useful information. Here are relevant packages: ii apache2 2.2.3-3Next generation, scalable, extendable web server ii apache2-mpm-prefork 2.2.3-3Traditional model for Apache HTTPD 2.1 ii apache2-utils 2.2.3-3utility programs for webservers ii apache2.2-common2.2.3-3Next generation, scalable, extendable web server ii libapr1 1.2.7-6The Apache Portable Runtime Library (libapr1 was rebuilt on 2.4 with dpkg-buildpackage to work around #392049. No changes were made to the Debian sources.) T -- Two wrongs don't make a right; but three rights do make a left... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396500: Logs filling up with prefork warning messages
Package: spamassassin Version: 3.1.4-1 Severity: normal After the last SA upgrade, spamd is now generating reams and reams of log messages like the following: Oct 31 20:33:05 eusebeia sa-exim[26929]: Removed 0 of 0 greylist tuplets in 1 seconds Oct 31 20:33:05 eusebeia sa-exim[26929]: Removed 0 of 0 greylist directories in 0 seconds Oct 31 20:33:05 eusebeia spamd[7626]: prefork: select returned -1! recovering: Bad file descriptor Oct 31 20:33:36 eusebeia last message repeated 31 times Oct 31 20:34:37 eusebeia last message repeated 59 times Oct 31 20:35:38 eusebeia last message repeated 59 times Oct 31 20:36:39 eusebeia last message repeated 60 times Oct 31 20:37:40 eusebeia last message repeated 60 times Oct 31 20:38:41 eusebeia last message repeated 60 times Oct 31 20:39:42 eusebeia last message repeated 60 times Oct 31 20:40:43 eusebeia last message repeated 60 times Oct 31 20:41:44 eusebeia last message repeated 59 times Oct 31 20:42:45 eusebeia last message repeated 59 times Oct 31 20:43:46 eusebeia last message repeated 60 times I traced the source of these messages to the code around line 244 in: /usr/share/perl5/Mail/SpamAssassin/SpamdForkScaling.pm From the comments, it looks like somebody has tried to fix this problem before, but for some reason it's still not quite working. T -- A mathematician is a device for turning coffee into theorems. -- P. Erdos -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#393300: preinst script bug
Package: console-common Version: 0.7.65 Severity: normal Here's the output from dpkg during the latest upgrade to 0.7.65: Preconfiguring packages ... (Reading database ... 27513 files and directories currently installed.) Preparing to replace console-common 0.7.64 (using .../console-common_0.7.65_all.deb) ... /var/lib/dpkg/tmp.ci/preinst: line 63: [: : integer expression expected /var/lib/dpkg/tmp.ci/preinst: line 63: [: : integer expression expected Unpacking replacement console-common ... Looks like unsafe/buggy shell code in preinst. T -- Those who have not appreciated the beauty of language are not qualified to bemoan its flaws. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382120: This bug turns out to be related to running multiple local servers
# This bug also occurs in unstable tags 382120 -experimental # This bug appears to be the same as the multi-head bug severity 382120 important merge 382120 390359 thanks Hi, after upgrading to the latest xorg release in unstable and playing around with my configuration, I discovered that this bug appears to be related to #390359. I don't have a dual head config, but I do have multiple X servers running locally off XDM (on different VT's). As I've filed more information in #390359, I'm merging this bug. T -- Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392911: Polytonic Greek keyboard map breaks ctrl-alt-F* vt switch sequence
Package: xkb-data
Version: 0.9-1
Severity: normal
Hi, after the latest upgrade, I found that I couldn't switch VT's using
the ctrl-alt-F* sequence anymore. After a bit of digging, I discovered
that it was because I was using the 'gr(polytonic)' layout using XKB.
Removing that mapping from my XKB config fixed the problem. This problem
does not occur with monotonic Greek layout ('gr' without the 'polytonic'
variant).
T
--
There's light at the end of the tunnel. It's the oncoming train.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392989: Manpage missing in latest bash
Package: bash Version: 3.1dfsg-6 Severity: important Hi, the latest bash fails to ship with a manpage (bash.1 missing), and installs a dangling symlink /usr/share/man/man1/sh.1 - bash.1 (non-existent). Filing as 'important' because according to policy 12.1 manpages should be included for each program in the same package. T -- To provoke is to call someone stupid; to argue is to call each other stupid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392911: Polytonic Greek keyboard map breaks ctrl-alt-F* vt switch sequence
On Sat, Oct 14, 2006 at 10:54:32AM +0200, Denis Barbier wrote:
[...]
I cannot reproduce this bug, please send your XKB settings and the
server-0.xkb file generated by running
$ xkbcomp :0
[...]
Oops, sorry, I misunderstood. Attached is the server-0.xkb file
generated by xkbcomp.
T
--
The best way to destroy a cause is to defend it poorly.
xkb_keymap {
xkb_keycodes xfree86+aliases(qwerty) {
minimum = 8;
maximum = 255;
ESC = 9;
AE01 = 10;
AE02 = 11;
AE03 = 12;
AE04 = 13;
AE05 = 14;
AE06 = 15;
AE07 = 16;
AE08 = 17;
AE09 = 18;
AE10 = 19;
AE11 = 20;
AE12 = 21;
BKSP = 22;
TAB = 23;
AD01 = 24;
AD02 = 25;
AD03 = 26;
AD04 = 27;
AD05 = 28;
AD06 = 29;
AD07 = 30;
AD08 = 31;
AD09 = 32;
AD10 = 33;
AD11 = 34;
AD12 = 35;
RTRN = 36;
LCTL = 37;
AC01 = 38;
AC02 = 39;
AC03 = 40;
AC04 = 41;
AC05 = 42;
AC06 = 43;
AC07 = 44;
AC08 = 45;
AC09 = 46;
AC10 = 47;
AC11 = 48;
TLDE = 49;
LFSH = 50;
BKSL = 51;
AB01 = 52;
AB02 = 53;
AB03 = 54;
AB04 = 55;
AB05 = 56;
AB06 = 57;
AB07 = 58;
AB08 = 59;
AB09 = 60;
AB10 = 61;
RTSH = 62;
KPMU = 63;
LALT = 64;
SPCE = 65;
CAPS = 66;
FK01 = 67;
FK02 = 68;
FK03 = 69;
FK04 = 70;
FK05 = 71;
FK06 = 72;
FK07 = 73;
FK08 = 74;
FK09 = 75;
FK10 = 76;
NMLK = 77;
SCLK = 78;
KP7 = 79;
KP8 = 80;
KP9 = 81;
KPSU = 82;
KP4 = 83;
KP5 = 84;
KP6 = 85;
KPAD = 86;
KP1 = 87;
KP2 = 88;
KP3 = 89;
KP0 = 90;
KPDL = 91;
SYRQ = 92;
MDSW = 93;
LSGT = 94;
FK11 = 95;
FK12 = 96;
HOME = 97;
UP = 98;
PGUP = 99;
LEFT = 100;
II65 = 101;
RGHT = 102;
END = 103;
DOWN = 104;
PGDN = 105;
INS = 106;
DELE = 107;
KPEN = 108;
RCTL = 109;
PAUS = 110;
PRSC = 111;
KPDV = 112;
RALT = 113;
BRK = 114;
LWIN = 115;
RWIN = 116;
MENU = 117;
FK13 = 118;
FK14 = 119;
FK15 = 120;
FK16 = 121;
FK17 = 122;
KPDC = 123;
LVL3 = 124;
ALT = 125;
KPEQ = 126;
SUPR = 127;
HYPR = 128;
XFER = 129;
I02 = 130;
NFER = 131;
I04 = 132;
AE13 = 133;
I06 = 134;
I07 = 135;
I08 = 136;
I09 = 137;
I0A = 138;
I0B = 139;
I0C = 140;
I0D = 141;
I0E = 142;
I0F = 143;
I10 = 144;
I11 = 145;
I12 = 146;
I13 = 147;
I14 = 148;
I15 = 149;
I16 = 150;
I17 = 151;
I18 = 152;
I19 = 153;
I1A = 154;
I1B = 155;
META = 156;
K59 = 157;
I1E = 158;
I1F = 159;
I20 = 160;
I21 = 161;
I22 = 162;
I23 = 163;
I24 = 164;
I25 = 165;
I26 = 166;
I27 = 167;
I28 = 168;
I29 = 169;
K5A = 170;
I2B = 171;
I2C = 172;
I2D = 173;
I2E = 174;
I2F = 175;
I30 = 176;
I31 = 177;
I32 = 178;
I33 = 179;
I34 = 180;
K5B = 181;
K5D = 182;
K5E = 183;
K5F = 184;
I39 = 185;
I3A = 186;
I3B = 187;
I3C = 188;
K62 = 189;
K63 = 190;
K64 = 191;
K65 = 192;
K66 = 193;
I42 = 194;
I43 = 195;
I44 = 196;
I45 = 197;
K67 = 198;
K68 = 199;
K69 = 200;
K6A = 201;
I4A = 202;
K6B = 203;
K6C = 204;
K6D = 205;
K6E = 206;
K6F = 207;
HKTG = 208;
K71 = 209;
K72 = 210;
AB11 = 211;
I54 = 212;
I55 = 213;
I56 = 214;
I57 = 215;
I58 = 216;
I59 = 217;
I5A = 218;
K74 = 219;
K75 = 220;
K76 = 221;
I5E = 222;
I5F = 223;
I60 = 224;
I61 = 225;
I62 = 226;
I63 = 227;
I64 = 228;
I65 = 229;
I66 = 230;
I67 = 231;
I68 = 232;
I69 = 233;
I6A = 234;
I6B = 235;
I6C = 236;
I6D = 237;
I6E = 238;
I6F = 239;
I70 = 240;
I71 = 241;
I72 = 242;
I73 = 243;
I74 = 244;
I75 = 245;
I76 = 246;
I77 = 247;
I78 = 248;
I79 = 249;
I7A = 250;
I7B = 251;
I7C = 252;
I7D = 253;
I7E = 254;
I7F = 255;
indicator 1 = Caps Lock;
indicator 2 = Num Lock;
indicator 3 = Scroll Lock;
virtual indicator 4 = Shift Lock;
virtual indicator 5 = Group 2;
virtual indicator 6 = Mouse Keys;
alias HZTG = TLDE;
alias HNGL = FK16;
alias HJCV = FK17;
alias I01 = XFER;
alias I03 = NFER;
alias I05 = AE13;
alias K5C = KPEQ;
alias K70 = HKTG;
alias K73 = AB11;
alias LMTA = LWIN;
alias RMTA = RWIN;
alias COMP = MENU;
alias POWR = I0C;
alias MUTE = I0D;
alias VOL- = I0E;
alias VOL+ = I0F;
alias HELP = I10;
alias STOP = I11;
alias AGAI = I12;
alias PROP = I13;
alias UNDO = I14;
alias FRNT =
Bug#392911: Polytonic Greek keyboard map breaks ctrl-alt-F* vt switch sequence
On Sat, Oct 14, 2006 at 10:54:32AM +0200, Denis Barbier wrote:
On Fri, Oct 13, 2006 at 11:37:38PM -0700, H. S. Teoh wrote:
Package: xkb-data
Version: 0.9-1
Severity: normal
Hi, after the latest upgrade, I found that I couldn't switch VT's
using the ctrl-alt-F* sequence anymore. After a bit of digging, I
discovered that it was because I was using the 'gr(polytonic)'
layout using XKB. Removing that mapping from my XKB config fixed
the problem. This problem does not occur with monotonic Greek layout
('gr' without the 'polytonic' variant).
Hi,
I cannot reproduce this bug, please send your XKB settings and the
server-0.xkb file generated by running
$ xkbcomp :0
[...]
Hmm, `xkbcomp :0` gives no output.
I'm currently using setxkbmap to alternate between different keyboard
layouts. The working configuration is:
setxkbmap us,ru -variant ,phonetic \
-option grp:lwin_toggle,grp_led:scroll
(This is done from .Xsession, but can also be used from any X terminal
like xterm or rxvt.)
The non-working configuration is:
setxkbmap us,ru,gr -variant ,phonetic,polytonic \
-option grp:lwin_toggle,grp_led:scroll
I've tried it with non-polytonic Greek, and it also works:
setxkbmap us,ru,gr -variant ,phonetic, \
-option grp:lwin_toggle,grp_led:scroll
Basically, I use the left 'windows' key to toggle between us, ru, and
gr. The ctrl-alt sequence doesn't work when I specify gr(polytonic) to
setxkbmap, regardless of whether the current layout (selected by lwin)
is actually gr(polytonic) or not. I do get the right characters in
gr(polytonic); the only obvious problem is that the vt-switch sequence
doesn't work (it inserts carets and other symbols instead).
Anyway, I tried to capture the keyboard events using xev, hopefully this
will help you track down the problem. The following is from the
non-working configuration (run xev, type ctrl-alt-F1, which does
nothing, and quit xev):
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196328814, (1021,765), root:(1022,766),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196328814, (1021,765), root:(1022,766),
state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196329991, (1021,765), root:(1022,766),
state 0xc, keycode 67 (keysym 0xffbe, F1), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyRelease event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196330220, (1021,765), root:(1022,766),
state 0xc, keycode 67 (keysym 0xffbe, F1), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196330351, (1021,765), root:(1022,766),
state 0xc, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
KeyRelease event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196330384, (1021,765), root:(1022,766),
state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196331253, (1021,765), root:(1022,766),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
The following is from the working configuration (run xev, type
ctrl-alt-F1, which switches to vt01, then alt-F7 to switch back to X,
then exit xev):
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196543663, (1021,765), root:(1022,766),
state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
KeyPress event, serial 24, synthetic NO, window 0xc1,
root 0x4c, subw 0x0, time 1196543663, (1021,765), root:(1022,766),
state 0x4, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False
VisibilityNotify event, serial 24, synthetic NO, window 0xc1,
state VisibilityFullyObscured
VisibilityNotify
Bug#390359: Bug confirmed (i810 driver malfunctioning on multi-head setup)
Hi, I just wanted to say that I'm seeing the same problem here, albeit with a slightly different configuration, which hopefully will give some insight into where the bug is. I'm running XDM with two local X servers, :0 and :1, running on vt07 and vt08. This is not a true dual-headed setup; I just have the servers share the same screen but on different VT's. This setup was working fine with the previous version of the i810 driver. After the latest upgrade (to xserver-xorg-video-i810 1.6.5-3), I can login just fine to either one of the servers, but as soon as I log out, the X server crashes. This causes XDM to attempt several times to restart it, which doesn't work. Eventually this leaves the video card in a bad state where neither X server can ever start again until I reboot the machine. Judging from the server logs (attached), the server is getting a bad V_BIOS checksum and an unknown exception (related?), as well as some permission problems. Commenting out the second X server in the xdm config (run only a single X server) causes the problem to go away. My chipset is Intel 82852/855GM, if that helps locate the source of the problem. T -- Why waste time learning, when ignorance is instantaneous? -- Calvin Hobbes Xorg.0.log.old Description: application/trash
Bug#392827: DIGEST_MULTIPLE rule depends on DCC_CHECK which is not always defined
Package: spamassassin Version: 3.1.4-1 Severity: normal Under certain configurations (I believe it's disabling DNS checks), the DCC_CHECK rule is not defined, but DIGEST_MULTIPLE depends on it and is still defined. This causes this message in the log: Oct 13 11:47:40 localhost spamd[7703]: rules: meta test DIGEST_MULTIPLE has undefined dependency 'DCC_CHECK' Looks likes an upstream bug. T -- Skill without imagination is craftsmanship and gives us many useful objects such as wickerwork picnic baskets. Imagination without skill gives us modern art. -- Tom Stoppard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392189: Apache2 cannot spawn child processes: segfault
Package: apache2-common Version: 2.2.3-2 Severity: grave Justification: renders package unusable I just upgraded to 2.2.3-2, and apache2 no longer starts due to various configuration issues. As I have a rather complicated apache2 setup, I decided to back up /etc/apache2 and re-install a clean new configuration so that I can start with something that works. Unfortunately, the default installation (without any customization) has a broken configuration: apache2: Syntax error on line 185 of /etc/apache2/apache2.conf: Syntax error on line 1 of /etc/apache2/mods-enabled/php5.load: API module structure `php5_module' in file /usr/lib/apache2/modules/libphp5.so is garbled - perhaps this is not an Apache module DSO? To fix this, I temporarily disabled php5 with `a2dismod php5`. After this apache2 starts, but then all child processes segfault. Snippet of /var/log/apache2/error.log: [Tue Oct 10 09:34:34 2006] [notice] child pid 20918 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20917 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20916 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20914 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20913 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20912 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20911 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20909 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20908 exit signal Segmentation fault (11) [Tue Oct 10 09:34:34 2006] [notice] child pid 20907 exit signal Segmentation fault (11) Typical process list: 29242 ?Rs 0:23 /usr/sbin/apache2 -k start 2426 ?Z 0:00 [apache2] defunct 2496 ?Z 0:00 [apache2] defunct 2497 ?Z 0:00 [apache2] defunct 2498 ?Z 0:00 [apache2] defunct 2499 ?Z 0:00 [apache2] defunct 2500 ?Z 0:00 [apache2] defunct 2501 ?Z 0:00 [apache2] defunct 2502 ?Z 0:00 [apache2] defunct 2503 ?Z 0:00 [apache2] defunct 2504 ?Z 0:00 [apache2] defunct 2505 ?Z 0:00 [apache2] defunct 2506 ?Z 0:00 [apache2] defunct 2507 ?Z 0:00 [apache2] defunct 2508 ?Z 0:00 [apache2] defunct 2509 ?Z 0:00 [apache2] defunct 2510 ?Z 0:00 [apache2] defunct 2511 ?Z 0:00 [apache2] defunct 2512 ?Z 0:00 [apache2] defunct 2513 ?Z 0:00 [apache2] defunct 2514 ?Z 0:00 [apache2] defunct 2515 ?Z 0:00 [apache2] defunct 2516 ?Z 0:00 [apache2] defunct 2518 ttyp0S+ 0:00 grep apache2 2519 ?Z 0:00 [apache2] defunct 2520 ?Z 0:00 [apache2] defunct 2521 ?Z 0:00 [apache2] defunct 2523 ?R 0:00 /usr/sbin/apache2 -k start Relevant packages: pi apache2-mpm-prefork 2.2.3-2Traditional model for Apache HTTPD 2.1 ii apache2-utils 2.2.3-2utility programs for webservers ii apache2.2-common2.2.3-2Next generation, scalable, extendable web se ii libapache2-mod-php5 5.1.6-3server-side, HTML-embedded scripting language (apache 2.0 module) T -- To provoke is to call someone stupid; to argue is to call each other stupid. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392228: Whatis parse fails for garlic(1)
Package: garlic Version: 1.5-2 Severity: normal When mandb tries to update the manpage database, it generates this message: warning: /usr/share/man/man1/garlic.1.gz: whatis parse for garlic(1) failed This seems to indicate that garlic's manpage does not conform to the proper manpage formatting conventions. T -- Don't drink and derive. Alcohol and algebra don't mix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385499: Random segfaults in NNTP mode
Package: mutt-ng Version: 0.0+20060429-2 Severity: normal Hi, I recently switched to mutt-ng in order to get NNTP support in my mailer. It's been working great, except that I get random segfaults from time to time when browsing newsgroups. I've not been able to find a precise sequence of events that reproduces this, but it seems to be related to syncing the news box and downloading new headers from the server. Often, when I hit $ to sync deleted messages, mutt-ng would segfault. Also, once in a while, when I return from the pager to the index, mutt-ng tries to sync with the server and either segfaults or just hangs. None of these problems occur outside NNTP mode. T -- Don't drink and derive. Alcohol and algebra don't mix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384362: TADS 3.0.9 ?
Package: tads3 Version: 3.0.8-1 Severity: wishlist Is it possible to package TADS 3.0.9? That would be very, very nice. I know this is an almost-released beta, but 3.0.9 has been out since last August, and the sample game used in the TADS 3 Tour Guide (http://users.ox.ac.uk/~manc0049/TADSGuide/index.html) no longer works with 3.0.8 (not even by compiling manually). T -- Don't drink and derive. Alcohol and algebra don't mix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382299: Max width support in format string should be documented
On Fri, Aug 18, 2006 at 10:21:49AM +0200, Bernhard R. Link wrote: * H. S. Teoh [EMAIL PROTECTED] [060810 08:13]: The format strings used in ratpoison (e.g., in the 'winfmt' setting) actually support max width specifications (e.g., %n%s%40t to limit the width of the windows list). This should be documented in the manpage info pages. Currently, they only list the possible substitution characters. I prapared a patch and sent it upstream. Now waiting for comments or inclusion in CVS before adding it to the Debian package. [...] Cool. Thanks a lot! T -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382299: Max width support in format string should be documented
Package: ratpoison Version: 1.4.0.dfsg-5 Severity: minor The format strings used in ratpoison (e.g., in the 'winfmt' setting) actually support max width specifications (e.g., %n%s%40t to limit the width of the windows list). This should be documented in the manpage info pages. Currently, they only list the possible substitution characters. T -- There's light at the end of the tunnel. It's the oncoming train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382120: xserver-xorg-video-i810 (experimental) leaves video in bad state
On Wed, Aug 09, 2006 at 03:00:39PM +1000, Drew Parsons wrote: Just thought I should let the X team know, that although the i810 driver in experimental fixes the ValidatePci() bug (see #345914, etc.), now it has problems terminating To get full support for the new i810 versions you really need the full suite of upgrades, including xserver 1.1 and mesa (libgl) 6.5. I'm already using mesa 6.5 (the version in unstable doesn't work properly on my system for some reason), and apt-get refuses to install the i810 driver from experimental unless I install xserver-xorg-core (1.1.1-1) as well. Of course, maybe it's conflicting with the other xserver-xorg-* components. I'll try again with a more complete upgrade later this week. (I already have a patched X server for 1.0.2-9 to deal with the ValidatePCI() bug, so I'm not in a hurry to upgrade.) Have you included these upgrades as well as the i810 driver? Yep. Also, try again with the new i810 1.6.3, released this week. [...] OK, I'll try that. And this time I'll try to capture crash logs as well, if that helps to track down the problem. T -- People tell me that I'm skeptical, but I don't believe it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#245574: LKM Trojan false positive
Hi, I just saw this bug when browsing through old bugs, and I thought I should give a little info hopefully to help resolve it. I have a colocated system where Debian runs from a chroot. For various reasons, there are a few daemons (kernel logging daemons, specifically) that still run from outside the chroot. I installed chkrootkit in the chroot, and it periodically reports a possible LKM trojan, because it sees the process in /proc but cannot access it since it's outside the chroot. I'm not sure if it's possible to fix this, unless there's a way to tell chkrootkit to ignore certain processes. (But this may be open to exploits.) Hope this helps. T -- Don't drink and derive. Alcohol and algebra don't mix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382120: xserver-xorg-video-i810 (experimental) leaves video in bad state
Package: xserver-xorg-video-i810 Version: 2:1.6.1-2 Severity: normal Tags: experimental Hi, Just thought I should let the X team know, that although the i810 driver in experimental fixes the ValidatePci() bug (see #345914, etc.), now it has problems terminating (e.g., logout, or ctrl-alt-Backspace). Sometimes it leaves the virtual terminal in a bad state, so that it cannot be restarted: subsequent attempts to start the X server gives: (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted Other times, it leaves the video card in a bad state so that no X further servers can start at all, on any VT, until a reboot. The logfiles show that xf86() caught signal 4. (SIGILL??) Unfortunately I don't have the original error message; when I tried to reproduce it, X crashed horribly and locked up the entire system (not ctrl-alt-SysRq, not even the power button which triggers shutdown via acpid, responded). I use xdm to spawn the servers; I'm not sure if this has anything to do with it. Downgrading to unstable (1.5.1.0-2) fixes all of these problems. ii xdm1.0.5-1X display manager T -- Life is too short to run proprietary software. -- Bdale Garbee -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345914: The freedesktop.org patch for i8xx works perfectly
On Sun, Aug 06, 2006 at 06:04:36PM +, David Nusinow wrote: [...] I'm in the process of updating the i810 driver to 1.6.1, which should contain this fix. It'll be in experimental tomorrow. Please test it and let me know if it works for you. [...] Yes it does! apt-get -t experimental install xserver-xorg-video-i810, and then restart X. Everything works normally. We can probably tag these bugs as pending now. Thanks for making this work. :-) T -- They pretend to pay us, and we pretend to work. -- Russian saying -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345914: The freedesktop.org patch for i8xx works perfectly
Hi, I've just applied the patch from: https://bugs.freedesktop.org/show_bug.cgi?id=6750 against the latest Debian source (xserver-xorg-core) and it works perfectly on my i850 chipset. I strongly urge the X maintainers to add this patch to the official Debian package before the next release---it's a showstopper for people with these Intel chipsets. This particular patch is non-intrusive; it detects exactly those chipsets that need to be fixed, and nothing else. For those who wish to test the fix (or need a fixed package to use with their Intel chipsets), I've built an (unofficial!) package for i386 here: http://eusebeia.dyndns.org/~hsteoh/debian/xserver-xorg-core_1.0.2-9_i386.deb Hope this helps. T -- Why ask rhetorical questions? -- JC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381571: Typo/grammar in manpage
Package: enigma Version: 0.92.3-2 Severity: minor Hi, there are small minor typos in enigma's manpage. A patch is attached. Thanks! T -- Why waste time learning, when ignorance is instantaneous? -- Calvin Hobbes --- enigma.6.orig 2006-08-05 07:58:10.0 -0700 +++ enigma.62006-08-05 07:56:31.0 -0700 @@ -10,13 +10,13 @@ .SH DESCRIPTION . Enigma is a puzzle game similar to Oxyd on the Atari ST or Rock'n'Roll -on the Amiga and good old Marble Madness. +on the Amiga and the good old Marble Madness. .PP In Enigma, your objective is to locate and uncover matching pairs of Oxyd stones. Simple as it sounds, this task is made more difficult by the fact that Oxyd stones tend to be hidden, inaccessible, or protected by unexpected traps. Overcoming these obstacles often requires a lot -of dexterity and wit (and can be quite addictive. +of dexterity and wit (and can be quite addictive). .PP .B For more information, please refer to the HTML manual! . @@ -29,7 +29,7 @@ .IP \-\-nograb Do not use exclusive mouse/keyboard access. .IP \-\-window -Run Enigma in a window; do not switch do fullscreen mode. +Run Enigma in a window; do not switch to fullscreen mode. .IP \-\-data=dir, \-d dir Prepend a directory to Enigma's search path. .IP \-\-lang=lang, \-l lang
Bug#381602: Manpage cleanup
Package: ri-li Version: 1.2.0-1 Severity: normal Tags: patch Hi, I've cleaned up the manpage, which has several glaring errors (e.g., referring to vdrift when the game is called ri-li). The patch is attached. Hope that helps. P.S. Tell the upstream author that Ri-li is a really awesome game! The concept is simple but very well implemented. I love it! T -- To provoke is to call someone stupid; to argue is to call each other stupid. --- ri-li.6.orig2006-08-05 12:14:42.0 -0700 +++ ri-li.6 2006-08-05 12:35:55.0 -0700 @@ -1,30 +1,25 @@ .TH RI-LI 6 .SH NAME -vdrift \(em a toy simulator game +ri-li \(em a toy simulator game .SH SYNOPSIS .PP -\fBvdrift\fR +\fBri-li\fR .SH DESCRIPTION .PP This manual page documents briefly the -\fBvdrift\fR command. +\fBri-li\fR command. .PP -Ri-Li is a video game. You drive a toy wood engine in many levels and you -must collect all the coaches to win. This package provide data files for -the game. - +Ri-Li is a OpenGL video game. You drive a toy wood engine in many levels and +you must collect all the coaches to win. .PP This manual page was written for the \fBDebian\fP distribution because the original program does not have a manual page. -Instead, it has documentation in the GNU \fBInfo\fP format; see below. -.PP -\fBvdrift\fR is a OpenGL video game. .SH OPTIONS .PP -These program doesn't accept optional parameter. +This program does not have any command-line options. .SH SEE ALSO .PP -You can visit \fIri-li homepage (link to URL http://www.ri-li.org/) \fR. +Ri-li homepage: \fBhttp://www.ri-li.org/\fR .SH AUTHOR .PP This manual page was written by Goneri Le Bouder [EMAIL PROTECTED] for @@ -32,9 +27,7 @@ granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 any later version published by the Free Software Foundation. - .PP On Debian systems, the complete text of the GNU General Public License can be found in /usr/share/common-licenses/GPL. - .\ created by instant / docbook-to-man, Sat 22 Jul 2006, 15:39
Bug#376067: Add support for utf-8 in ratpoison menus
Package: ratpoison Version: 1.4.0.dfsg-4 Severity: wishlist Hi, It'd be very nice if ratpoison could support UTF-8-encoded strings in its windows. For example, in the list of windows (C-t w), when one of the windows has a UTF-8-encoded title. Currently, it interprets the string as Latin-1 instead. T -- Don't drink and derive. Alcohol and algebra don't mix. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#347774: Bug is still there
Hi, This is just a quick followup note, that this bug still exists. Apparently, it's not as simple as I had first thought: it only happens once in a while (race condition?). My window manager is ratpoison, which automatically maximizes all windows, and I've configured 'C-t c' to spawn xterm. Usually, there are no problems, but occasionally, it seems that the SIGWINCH is not sent to the shell, and it continues to think that it's at 80x24 (the default xterm geometry). This is still happening on xterm (210-3). T -- There's light at the end of the tunnel. It's the oncoming train. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#345914: Oops, patch attached for real this time
Oops, I forgot to actually attach the patch in the last mail. T -- There's light at the end of the tunnel. It's the oncoming train. --- hw/xfree86/common/xf86Bus.c.orig2006-05-01 10:39:34.0 -0700 +++ hw/xfree86/common/xf86Bus.c 2006-04-30 16:48:06.0 -0700 @@ -2488,7 +2488,9 @@ * No need to validate on Alpha Linux or OpenBSD/sparc64, * trust the kernel. */ +/* H. S. Teoh: attempt to fix i810 bug ValidatePci(); + */ #endif xf86MsgVerb(X_INFO, 3, resource ranges after probing:\n);
Bug#345914: Problem source has been identified upstream [PATCH]
tags 345914 +patch thanks Hi, I've been hit by the same problem in all xorg servers above 6.8.2, and after searching around online, I've found the upstream bug report, which contains the solution: https://bugs.freedesktop.org/show_bug.cgi?id=5443 Basically, it's a call to ValidatePCI() that needs to be commented out. I've tested this fix myself: apt-get source xorg-xserver-core and all the build dependencies, then edit xf86Bus.c and comment out the ValidatePCI() call, then dpkg-buildpackage and install the patched package. It finally works on my Intel 855GM. I've attached the patch, for people who use the i810 driver and is running into the same problem (it was very annoying for me). Also, I've uploaded the (UNOFFICIAL!) fixed package here (i386 only, sorry), for those who badly need to get their Intel chips working: http://eusebeia.dyndns.org/~hsteoh/debian/xserver-xorg-core_1.0.2-7_i386.deb CAVEAT: this patch is probably too general; it really should be applied only if the i810 module is being used (and maybe in a few other cases---see the bug report for details). So, you should only install the above package if you are using the i810 module. I have no guarantees what it will do if you are using another chipset! USE AT YOUR OWN RISK. T -- Latin's a dead language, as dead as can be; it killed off all the Romans, and now it's killing me! -- Schoolboy -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
