Bug#589477: Jigdo search still broken.
On Fri, Nov 12, 2010 at 12:20:36PM +0100, Simon Paillard wrote: Where can we find source and documentation about the jigdo search ? The source code used to be downloadable on the search page... I've just uploaded it here: http://atterer.org/sites/atterer/files/jigdo-search-070308.tar.gz It requires setting up a cronjob to download and pre-process the data. Cheers, Richard -- __ , | ) /| Richard Atterer | GnuPG key: 888354F7 | \/ | http://atterer.org | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589477: Jigdo search still broken.
Hello, On Thu, Nov 11, 2010 at 08:01:35PM +0100, Simon Paillard wrote: As we've just got another report about jigdo search, I wonder if there are updates about moving this service to get it operationnal. Hi, it's still on my TODO list, though unfortunately I have been rather busy with other things lately. The thing is also: It's not ideal to put it on my own webspace again, nor to use Phil's VM, since neither is an official Debian machine. So either way, it would only be a temporary solution. :-| By the way, thanks for your help with CD vendor entries, Simon - very much appreciated! :) Richard -- __ , | ) /| Richard Atterer | GnuPG key: 888354F7 | \/ | http://atterer.org | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582430: /etc/cron.d/drupal6 causes mails from cron after package is removed
Package: drupal6 Version: 6.15-1 Severity: minor Hello, /etc/cron.d/drupal6 contains this line: [ -x /usr/share/drupal6/scripts/cron.sh ] /usr/share/drupal6/scripts/cron.sh In the case that drupal6 is uninstalled but not purged, the line will cause cron to email me with command failed with exit status 1 every hour. Please change the command to the following to fix this: if test -x /usr/share/drupal6/scripts/cron.sh; then /usr/share/drupal6/scripts/cron.sh; fi Cheers, Richard -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-trunk-686 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages drupal6 depends on: ii apache2-mpm-prefork [httpd] 2.2.15-5 Apache HTTP Server - traditional n ii curl 7.20.1-2 Get a file from an HTTP, HTTPS or pn dbconfig-common none (no description available) ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy pn mysql-client | virtual-mysql- none (no description available) ii php5 5.3.2-1server-side, HTML-embedded scripti ii php5-gd 5.3.2-1GD module for php5 pn php5-mysql | php5-pgsql none (no description available) ii postfix [mail-transport-agent 2.6.5-3High-performance mail transport ag ii wwwconfig-common 0.2.1 Debian web auto configuration Versions of packages drupal6 recommends: pn mysql-server | postgresql none (no description available) drupal6 suggests no packages. Richard -- __ , | ) /| Richard Atterer | \/ | http://atterer.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571962: azureus: Fails to start with Azureus core already instantiated
Quick fix: ln -s /usr/share/java/swt-gtk-3.5.1.jar /usr/share/java/swt.jar Cheers, Richard -- __ , | ) /| Richard Atterer | \/ | http://atterer.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569134: xorg: Display will hang with a solid colour screen, only fixed by a suspend/resume cycle.
On Thu, Feb 11, 2010 at 12:35:44AM +0100, Julien Cristau wrote: Is this on 945GM? If so, it can be worked around by passing i915.powersave=0 to the kernel, and was fixed for me by http://lists.freedesktop.org/pipermail/intel-gfx/2010-February/005763.html Yes, it's 945GM. lspci says: VGA compatible controller: Intel Corporation Mobile 945GME Express Integrated Graphics Controller (rev 03) (prog-if 00 [VGA controller]) So i915.powersave=0 is better than using i915.modeset=0 ? The latter seems to work for me so far. Cheers, Richard -- __ , | ) /| Richard Atterer | \/ | http://atterer.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#569134: xorg: Display will hang with a solid colour screen, only fixed by a suspend/resume cycle.
Hello, I can confirm this on an EeePC 1008HA, running a vanilla 2.6.33-rc6 kernel and xserver-xorg-video-intel 2:2.9.1-2. It seems to be caused by KMS: http://wiki.debian.org/KernelModesetting https://bugs.freedesktop.org/show_bug.cgi?id=25681 From the moment the X server starts, the console becomes inaccessible, with corrupt output being shown when I switch there. For example, I can still see the cursor blinking, but that blinking happens for a couple of pixels spread all over parts of the screen. I use GRUB_GFXMODE=800x600 in /etc/default/grub for a VESA fb console - http://en.gentoo-wiki.com/wiki/Intel_GMA#Kernel_Modesetting says that this is a bad idea... A possible temporary fix might be to disable KMS, by passing i915.modeset=0 to the kernel. For the record, the rest is exactly the same as in the original bug report: Occasional (every 30 sec?) flickering/tearing of the screen, as if the start of the video RAM were wrong for a frame or less. Eventually (after maybe 20 minutes use on average), the screen will go all black or grey. Suspend to RAM and resume is the only way to fix it, switching to the console and back won't do. Before the last upgrade, everything worked just fine. Cheers, Richard -- __ , | ) /| Richard Atterer | \/ | http://atterer.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551938: w3c-libwww: CVE-2009-2625
tags 551938 wontfix patch severity 551938 normal thanks On Fri, Oct 23, 2009 at 06:48:21PM +0200, Moritz Muehlenhoff wrote: Well, I've already prepared new versions of the packages, although they are completely untested ATM, except that I had a look at them with debdiff/interdiff: http://atterer.net/libwww/ Please upload this for a oldstable point update. Please use distribution=oldstable and file a bug against release.debian.org (with reportbug from testing/unstable), so that the stable release managers can ack the upload. Hmm, since I haven't really tested the packages at all and you don't seem to think that the issue is important, I won't push for inclusion in a point update. Cheers, Richard -- __ , | ) /| Richard Atterer | \/ | http://atterer.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551938: w3c-libwww: CVE-2009-2625
Hello Mike, thanks for noticing that w3c-libwww ships a vulnerable local copy of expat! On Wed, Oct 21, 2009 at 06:40:08PM -0400, Michael Gilbert wrote: hello, a security issue has been disclosed for expat. see [0], [1]. w3c-libwww embeds expat, so it is also affected. this affects all supported debian releases, so please coordinate with the security team to prepare DSAs. mike [0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-2625 [1] https://bugs.gentoo.org/show_bug.cgi?id=280615 w3c-libwww is currently at 5.4.0-11 in oldstable and unstable. I want it removed from the archive because it is old and suffers from bitrot, see #440436. So I suggest the following: * Simply remove it from unstable, this should be possible with minor problems, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=440436#63 * Fix the problem in oldstable by applying the security patch to libwww's own copy of expat. Of course, eliminating the duplicate expat would be cleaner, but the effort is hardly justified at this point, or what do you think? The bugfix patch is here, it applies to libwww's expat copy: https://bugs.gentoo.org/attachment.cgi?id=201849 http://expat.cvs.sourceforge.net/viewvc/expat/expat/lib/xmltok_impl.c?r1=1.15r2=1.13 Cheers, Richard -- __ , | ) /| Richard Atterer | \/ | http://atterer.net signature.asc Description: Digital signature
Bug#552033: RM: w3c-libwww libwww-doc -- ROM; Removal scheduled long ago; security issues
Package: ftp.debian.org Severity: grave Hello, please remove w3c-libwww and libwww-doc from unstable. I have been planning to request this for a long time because it is unmaintained upstream and hardly used in Debian. It is no longer part of stable or testing. See #440436. Removal will not cause any problems, as there are no remaining build-rdeps in unstable. Removal is the easiest way to deal with a security issue which is present in the embedded copy of expat, see #551938 and CVE-2009-2625. I will prepare fixed packages for oldstable. Thanks! Richard -- __ , | ) /| Richard Atterer | \/ | http://atterer.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551938: w3c-libwww: CVE-2009-2625
On Thu, Oct 22, 2009 at 11:34:32PM +0200, Moritz Muehlenhoff wrote: But please proceed with the removal from unstable by filing a removal bug against ftp.debian.org. Amaya has been removed and the other users have been fixed. I've filed for removal: #552033 Since CVE-2009-2625 doesn't allow code injection, but only DoS and given that libwww in oldstable is only used by wmweather, I think we can ignore it, unless Nico wants to work on an update? Well, I've already prepared new versions of the packages, although they are completely untested ATM, except that I had a look at them with debdiff/interdiff: http://atterer.net/libwww/ Are you interested in using these? Cheers, Richard sha384sum: 518b5f248997eb31f3c0bc5e876b50fe2265d693c6686f2caec2c86d01f67a5b3d57459447fd73201df49048078bfd8b libwww0_5.4.0-11+etch1_amd64.deb 417eb401b507c1901941659a437b304d8bbc40da60c6bba2916842a109ab0b15c1fa95b3da5da9a3eec44135e06b96bc libwww-dev_5.4.0-11+etch1_amd64.deb 2064a45e8123d9eab51d7f20f9ec419fa692b8c87c95dd13f654c310ffa1068c6c0e03ff9910add9e32950efce10f25d libwww-ssl0_5.4.0-11+etch1_amd64.deb cf79bae0eb283237b50518b95e1c8755464036eaf3162557f7022f62cdab405ae47518623a03cbf5e918fba54c2d libwww-ssl-dev_5.4.0-11+etch1_amd64.deb ced1bb2f057754679d1447414882ef724a903745bc6d6b5d3b21de35ea30d13a70970974f44ad205c89caed41f5116b0 w3c-libwww_5.4.0-11+etch1_amd64.changes 0a720f95e35051033a469a05a20088c8c5ad109b41fea5e6e8a372c3d40881289160f90d1cbc68e1eda436b26f2cb3c1 w3c-libwww_5.4.0-11+etch1.diff.gz 06f0d46eef90ef111e8c9ba1269e62c64aa04df01c6be153b78c03f2cf7fd2407f9cef12488be98c27a7ea6132df1c0f w3c-libwww_5.4.0-11+etch1.dsc 0ea73901b7da23d403b43910f97e7ed7dff11d539811244136c5102dde67bee5aea10b2f5dd1ab16f898da8a65d65352 w3c-libwww_5.4.0.orig.tar.gz -- __ , | ) /| Richard Atterer | GnuPG key: 888354F7 | \/ | http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 signature.asc Description: Digital signature
Bug#535743: (w3c-libwww_5.4.0-11/avr32): FTBFS: Outdated config.{sub,guess}
Hello, this bug is unlikely to get fixed since libwww is to be removed from the archive anyway, see #440436. All the best, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#445529: Window title bar hidden below gnome-panel
http://bugzilla.gnome.org/show_bug.cgi?id=572573 http://svn.gnome.org/viewvc/metacity?view=revisionrevision=4191 I can confirm that this bug fixes the problem for me! As the issue was beginning to get on my nerves, I simply applied the patch to the current 2.26 Debian package and recompiled. ;) Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#445529: Window title bar hidden below gnome-panel
I hit the same problem today while upgrading my testing system: My two non-autohiding panels at the top and bottom of the screen are ignored when opening or maximizing windows, so the window title bar ends up hidden below the panel. The title bar is still partially hidden if I make the panels auto-hide. Re-installing metacity did not help. My gut feeling made me also upgrade gnome-panel to 2.26.2-1 from sid. This did not change anything in the case that the panels are not auto-hide. However, if the panels *do* have autohide enabled, the title bar is not partially hidden, everything works as advertised! This Gnome bug seems to be the one we're looking for. What version of gnome-panel did the fix go into? http://bugzilla.gnome.org/show_bug.cgi?id=572573 Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#523690: std::map::erase(map.end()) should be a no-op
Package: libstdc++6
Version: 4.3.3-3
Severity: normal
Hello,
The std::map::erase(iterator) method in libstdc++6 cannot deal with the case
that it is called with the end() iterator:
$ cat foo.cc
#include map
int main(int, char**) {
std::mapint,int m;
m[1] = 2;
m[3] = 4;
m.erase(m.find(5)); // 5 not found, so find() returns end()
}
$ g++ -O2 -Wall -o foo foo.cc
$ $ ./foo
*** glibc detected *** ./foo: free(): invalid pointer: 0xbfc25c24 ***
=== Backtrace: =
/lib/i686/cmov/libc.so.6[0xb7cd81e4]
[snip backtrace]
I do not have a copy of the standard itself, but in C++ 3rd ed, section
17.4.1.7, page 489, Stroustrup says simply Erasing end() is harmless, which
I interpret as it has no effect.
Cheers,
Richard
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.28.7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libstdc++6 depends on:
ii gcc-4.3-base 4.3.3-3The GNU Compiler Collection (base
ii libc6 2.9-4 GNU C Library: Shared libraries
ii libgcc1 1:4.3.3-3 GCC support library
libstdc++6 recommends no packages.
libstdc++6 suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#461097: ocropus -- Document analysis and OCR system
Hello, any news on ocropus packages for Debian? I tried compiling it myself the other day and ran into some issues compiling OpenFST, but that did not look too serious. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516107: jigdo-file: jigdo-lite lists wrong mirror for country de
tags 516107 +wontfix thanks On Thu, Feb 19, 2009 at 11:54:15AM +0100, Hilmar Preusse wrote: I've used the functionality to list all mirrors in a country to get a possible download list. After selecting de jigdo lists mostly german mirrors, but is lists too a University in Canada (see attached script session). I guess the filter is confused by the de in the Name of the University Universiteacute; de Sherbrooke. Yes - for two-character searches, the regexp that's used allows space, full stop and slashes after the country: case $REPLY in [a-z][a-z]) REPLY=[. ]$REPLY[/. ];; esac That's more or less intended, I prefer to return too many results rather than too few. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512919: xrandr should always fully honour --pos switch
Package: x11-xserver-utils
Version: 7.3+5
Severity: wishlist
Tags: patch
Hello,
the xrandr binary has the following feature which I propose to
remove/change:
When you use --pos to position one or more outputs within the large virtual
screen, it first sets the offset(s) as specified on the command line. However,
it then shifts all outputs up and left on the virtual screen such that the
topmost output is always at y=0 and the leftmost one at x=0.
I am not sure why this is done. :-| About the only reason I can imagine is to
avoid problems when the user repeatedly uses e.g. --right-of to keep
swapping two screens. If this is the only reason, then the code for
--right-of etc. should take care of shifting other outputs to the left to
fit the current output within the virtual screen.
The current behaviour is problematic in at least two cases:
1) It's confusing when you set up screen positions by invoking xrandr more
than once, e.g.:
$ xrandr --output VGA --pos 1280x0
$ xrandr --output LVDS --pos 0x0
If LVDS was disabled and is only enabled by the second command, this will not
work because VGA actually ends up at position 0x0 after the first command.
2) If there is only one output, it can only ever be at position 0x0. I needed
it elsewhere for a VNC-supported dual-screen setup:
I want to set my physical monitor (1280x1024) to display the right half of my
desktop, and then export the left half of the desktop (1400x1050) to a laptop
using VNC, like this:
$ xrandr --fb 2680x1050 --output VGA --pos 1400x0
$ x11vnc -display :0 -clip 1400x1050+0+0 -viewonly -cursorpos -xdamage -xdamage
(Then simply run xtightvncviewer -fullscreen HOSTNAME on the laptop.)
Without the output shifting code (see patch), this works fine! This patch is
not intended to be applied as-is; additional code for --right-of etc. would be
required to preserve the behaviour of the existing xrandr tool. Alternatively,
there could be a --forcepos switch or similar which disables the position
shifting.
Cheers,
Richard
--- xrandr.c.orig 2009-01-25 00:34:06.0 +0100
+++ xrandr.c2009-01-25 00:34:17.0 +0100
@@ -1392,31 +1392,6 @@
if (!any_set)
fatal (loop in relative position specifications\n);
}
-
-/*
- * Now normalize positions so the upper left corner of all outputs is at
0,0
- */
-min_x = 32768;
-min_y = 32768;
-for (output = outputs; output; output = output-next)
-{
- if (output-mode_info == NULL) continue;
-
- if (output-x min_x) min_x = output-x;
- if (output-y min_y) min_y = output-y;
-}
-if (min_x || min_y)
-{
- /* move all outputs */
- for (output = outputs; output; output = output-next)
- {
- if (output-mode_info == NULL) continue;
-
- /*output-x -= min_x;
- output-y -= min_y;
- output-changes |= changes_position;*/
- }
-}
}
static void
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.28
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages x11-xserver-utils depends on:
ii cpp 4:4.3.2-2 The GNU C preprocessor (cpp)
ii libc6 2.7-18 GNU C Library: Shared libraries
ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library
ii libsm62:1.0.3-2 X11 Session Management library
ii libx11-6 2:1.1.5-2 X11 client-side library
ii libxau6 1:1.0.3-3 X11 authorisation library
ii libxaw7 2:1.0.4-2 X11 Athena Widget library
ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar
ii libxi62:1.1.4-1 X11 Input extension library
ii libxmu6 2:1.0.4-1 X11 miscellaneous utility library
ii libxmuu1 2:1.0.4-1 X11 miscellaneous micro-utility li
ii libxrandr22:1.2.3-1 X11 RandR extension library
ii libxrender1 1:0.9.4-2 X Rendering Extension client libra
ii libxt61:1.0.5-3 X11 toolkit intrinsics library
ii libxtrap6 2:1.0.0-5 X11 event trapping extension libra
ii libxxf86misc1 1:1.0.1-3 X11 XFree86 miscellaneous extensio
ii libxxf86vm1 1:1.0.2-1 X11 XFree86 video mode extension l
ii x11-common1:7.3+18 X Window System (X.Org) infrastruc
x11-xserver-utils recommends no packages.
x11-xserver-utils suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511652: udev rules shouldn't be empty by default
tags 511652 wontfix thanks Hi Scott, it's great to see there's an Ubuntu package even though this is a rather specialized program - thanks! On Tue, Jan 13, 2009 at 02:35:39AM +, Scott James Remnant wrote: * Modify the package so that the udev rules aren't actually installed by default, and instruct the user to copy out of examples and then modify; otherwise they'll get conffile hell forever after. Is this a general Ubuntu policy of no empty conffiles that you're implementing here? Having spent some time thinking about this, I'm not convinced this is the best way for this particular package. First, in my view (and I'm also the upstream author) the program is feature-complete and bigger changes to the conffile are very unlikely. Furthermore, the conffile is very simple, just a few lines of text. On upgrade, a diff will tell the user what is being changed, and I guess it will be easy to keep one's own configuration or port one's own settings to the new conffile. Your solution has the disadvantage that the manually added configuration file will stay behind forever when the package is purged. The whole conffile mechanism is designed to help users migrate their settings to newer versions of a package, so why shouldn't we use it? What happens if a (theoretical) future version of the package breaks existing configuration files? With a manually-added file, there will be no indication that a problem might exist. With a conffile, there will be a warning, which can be ignored by the user if he is confident the old settings are OK... Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#511652: udev rules shouldn't be empty by default
On Thu, Jan 15, 2009 at 06:04:17PM +, Scott James Remnant wrote: No, this is the Ubuntu policy that packages are not permitted to install into /etc/udev/rules.d and instead must install into /lib/udev/rules.d This matches the upstream udev software, it's Debian that's strange in using /etc for such things. OK, thanks for the information. If Debian used /lib/udev/rules.d, I would implement your solution (or maybe use an /etc/default/ script), but I think with the current state of things, the conffile is a good solution. (If everyone else is using the /lib dir, Debian should also adopt this practice, but I won't be the one to request the change, I'm afraid.) Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#510907: aptitude upgrade returns error on udftools
severity 510907 normal thanks I'm downgrading this bug because by default, udftools does nothing unless the user changes /etc/default/udftools. Thus, only active users of packet writing can be affected by any bug like this. What's the content of /etc/default/udftools on your machine? Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#507993: A similar (?) livelock
Hi ael, thanks for this! Unfortunately, as you suspect, the backtrace is not useful without debugging information. :-/ I've just uploaded a version of jigdo-file which contains debugging symbols: http://atterer.net/jigdo-file_0.7.3-2_i386.deb Maybe retry with it and see if you can trigger the problem again. Please also add --debug=all to jigdoOpts in your ~/.jigdo-lite configuration file to get more information! What exactly is happening during the livelock? Does jigdo-file take up all CPU time, or does it just appear to hang? How long have you waited before interrupting it? The code has not changed significantly in a long time and AFAIR, you're the first to report this kind of problem. This makes me think that something must be special about your setup - anything unusual that you can think of? Are you running several jigdo downloads in parallel with the same cache file? Please also send me the contents of your ~/.jigdo-lite file. This livelock was *not* cleared by removing temporary files. Did you also remove the cache? What else was the machine doing at the time, was any other software apart from the regular desktop stuff running? What filesystem are you creating your images on? Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483853: patch and NMU
On Sat, Jul 19, 2008 at 01:04:38AM +0200, Francesco Namuri wrote: Package: libwww-doc Followup-For: Bug #483853 tags 483853 + patch thanks Hi, I've made a patch to solve this problem, without a feedback I try to do an NMU to solve the problem. Thanks - but libwww-doc should be removed from the archive, together with libwww! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#474313: Infinite loop not reproducible.
tags 474313 patch
thanks
On Sun, Jul 13, 2008 at 07:31:57PM +0200, Georges Khaznadar wrote:
Hello, I tried to reproduce the bug about a 100 µF capacitor, the way
you described it:
To reproduce, start ktechlab, create a new circuit, drag a capacitor
onto it, select the capacitor, then change its value in the top bar.
and the bug was not triggered. I am using the version 0.3-9 of ktechlab,
with an amd64 platform.
Strange that it's so different on amd64 - after looking more closely, I was
able to identify two distinct bugs in the code.
I retried with 0.3-9 inside a sid chroot on my i386 machine. First of all,
this version *crashed* when I dragged any symbol onto a new circuit. I
recompiled with debugging symbols and -fno-inline using gcc 4.3.1, and got:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5e7b700 (LWP 32442)]
0x082455fd in Map::reset (this=0x8941480) at matrix.cpp:308
308 (*m_map)[i][j] = 0;
(gdb) bt
#0 0x082455fd in Map::reset (this=0x8941480) at matrix.cpp:308
#1 0x082466ab in Map (this=0x8941480, size=2) at matrix.cpp:292
#2 0x08246776 in Matrix (this=0x893b958, n=2, m=0) at matrix.cpp:35
#3 0x0824220d in ElementSet (this=0x8941920, circuit=0x893ab88, n=2, m=0) at
elementset.cpp:32
#4 0x0823f77f in Circuit::init (this=0x893ab88) at circuit.cpp:203
...
It turned out that Map::Map() creates a new ETMap(m_size) and then calls
reset(), which assumes that *m_map is square. However, the new
ETMap(m_size) only creates a vector that contains two *empty* vectors, so
reset() would overwrite random memory. The attached patch fixes this by not
calling reset() and instead initializing the array properly.
Recommendation to upstream authors: Use valgrind!
OK, this allowed me to actually trigger the bug that I originally reported,
and which still existed. It turned out to be infinite recursion:
#135 0x0814ec5b in DoubleSpinBox::valueChanged (this=0xa34ccb0,
t0=9.9991e-05) at doublespinbox.moc:95
#136 0x0814f63a in DoubleSpinBox::checkIfChanged (this=0xbf7d4aac) at
doublespinbox.cpp:210
#137 0x0814f7c8 in DoubleSpinBox::qt_invoke (this=0xa34ccb0, _id=56,
_o=0xbf7d4bdc) at doublespinbox.moc:103
#138 0xb6582f6d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#139 0xb65839f0 in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#140 0xb68c7960 in QSpinBox::valueChanged () from /usr/lib/libqt-mt.so.3
#141 0xb669a4c6 in QSpinBox::valueChange () from /usr/lib/libqt-mt.so.3
#142 0xb668cd59 in QRangeControl::setValue () from /usr/lib/libqt-mt.so.3
#143 0xb6698b23 in QSpinBox::setValue () from /usr/lib/libqt-mt.so.3
#144 0xb669a02b in QSpinBox::interpretText () from /usr/lib/libqt-mt.so.3
#145 0xb6698385 in QSpinBox::value () from /usr/lib/libqt-mt.so.3
#146 0xb6699987 in QSpinBox::currentValueText () from /usr/lib/libqt-mt.so.3
#147 0xb6699bfa in QSpinBox::selectAll () from /usr/lib/libqt-mt.so.3
#148 0xb669a2fb in QSpinBox::updateDisplay () from /usr/lib/libqt-mt.so.3
#149 0xb669a4a8 in QSpinBox::valueChange () from /usr/lib/libqt-mt.so.3
#150 0xb668cd59 in QRangeControl::setValue () from /usr/lib/libqt-mt.so.3
#151 0xb6698b23 in QSpinBox::setValue () from /usr/lib/libqt-mt.so.3
#152 0x0814fb23 in DoubleSpinBox::setValue (this=0xa34ccb0,
value=9.9991e-05) at doublespinbox.cpp:78
#153 0x080ca642 in ItemInterface::slotSetData (this=0xa17dad0, [EMAIL
PROTECTED], value={d = 0xbf7d4fcc}) at iteminterface.cpp:570
#154 0x080cab29 in ItemInterface::tbDataChanged (this=0xa17dad0) at
iteminterface.cpp:480
#155 0x080cc668 in ItemInterface::qt_invoke (this=0xa17dad0, _id=4,
_o=0xbf7d50bc) at iteminterface.moc:107
#156 0xb6582f6d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#157 0xb658388d in QObject::activate_signal () from /usr/lib/libqt-mt.so.3
#158 0x0814ec5b in DoubleSpinBox::valueChanged (this=0xa34ccb0,
t0=9.9991e-05) at doublespinbox.moc:95
The first and last line of the above are the same: The code recurses
forever updating the widget. This is because in
DoubleSpinBox::checkIfChanged(), the check m_lastEmittedValue == newValue
never becomes true due to a rounding error.
The bug is that the comparison takes place using a double value (e.g.
100.0e-6 for 100uF), whereas the widget stores two items, an integer 100
and a multiplier (like 1.0e-6 for micro). Converting the two back and forth
never gives an exact match.
(Incidentally, I find it strange that the widget needs to emit I have
changed in response to it receiving a you have changed. It smells wrong,
but I don't understand the code well enough to say whether it's a bug.)
My fix is to perform the above comparison on the two values (integer and
multiplier) rather than the combined double. The patch is attached. I've
only tested it lightly!
Cheers,
Richard
--
__ _
|_) /| Richard Atterer
| \/¯| http://atterer.net
¯ '` ¯
--- ./src/gui/doublespinbox.cpp.orig2008-07-13 20:52
Bug#469449: *prod* new Hugin version available
Hello, *prod* ;-) I'm looking forward to having Hugin 0.7 in unstable - is there anything which prevents its being uploaded? Many thanks for your work! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#476112: udftools: Incomplete LSB init header
On Tue, Apr 22, 2008 at 10:30:45PM +0200, Petter Reinholdtsen wrote: Hi. Any hope of having a fix for this issue uploaded quickly? I can NMU to solve it. The current settings make the package misbehave when dependency based boot sequencing is enabled. If you want, feel free to NMU. Otherwise, I'll try to get it fixed next weekend. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#474313: Infinite loop when creating 100uF capacitor in circuit
Package: ktechlab Version: 0.3-8 Severity: important Any attempt to create a 100uF capacitor causes the application to freeze at 100% CPU. This only happens at exactly 100uF - something like 99uF is OK. To reproduce, start ktechlab, create a new circuit, drag a capacitor onto it, select the capacitor, then change its value in the top bar. It doesn't seem to be the simulation, the problem also happens when simulation is paused. I tried stracing the process, but this doesn't give any useful info: The process alternates between read(), write(), poll() and gettimeofday() calls. Justification for severity important: You lose your unsaved work when the bug is triggered. Cheers, Richard -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages ktechlab depends on: ii gpsim 0.22.0-4 Simulator for Microchip's PIC micr ii kdelibs4c2a4:3.5.8.dfsg.1-7 core libraries and binaries for al ii libacl12.2.45-1 Access control list shared library ii libart-2.0-2 2.3.20-1 Library of functions for 2D graphi ii libatk1.0-01.20.0-1 The ATK accessibility toolkit ii libattr1 1:2.4.41-1Extended attribute shared library ii libaudio2 1.9.1-2 Network Audio System - shared libr ii libc6 2.7-6 GNU C Library: Shared libraries ii libcairo2 1.4.14-1 The Cairo 2D vector graphics libra ii libfontconfig1 2.5.0-2 generic font configuration library ii libfreetype6 2.3.5-1+b1FreeType 2 font engine, shared lib ii libgamin0 [libfam0]0.1.9-2 Client library for the gamin file ii libgcc11:4.3.0-1 GCC support library ii libglib2.0-0 2.16.1-2 The GLib library of C routines ii libgtk2.0-02.12.9-2 The GTK+ graphical user interface ii libice62:1.0.4-1 X11 Inter-Client Exchange library ii libidn11 1.4-1 GNU libidn library, implementation ii libjpeg62 6b-14 The Independent JPEG Group's JPEG ii libpango1.0-0 1.20.0-1 Layout and rendering of internatio ii libpng12-0 1.2.15~beta5-3PNG library - runtime ii libpopt0 1.10-3lib for parsing cmdline parameters ii libqt3-mt 3:3.3.8b-5Qt GUI Library (Threaded runtime v ii libreadline5 5.2-3 GNU readline and history libraries ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstdc++6 4.3.0-1 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.3-7 X11 client-side library ii libxcursor11:1.1.9-1 X cursor management library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxfixes3 1:4.0.3-2 X11 miscellaneous 'fixes' extensio ii libxft22.1.12-2 FreeType-based font drawing librar ii libxi6 2:1.1.3-1 X11 Input extension library ii libxinerama1 2:1.0.3-1 X11 Xinerama extension library ii libxrandr2 2:1.2.2-1 X11 RandR extension library ii libxrender11:0.9.4-1 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii zlib1g 1:1.2.3.3.dfsg-11 compression library - runtime Versions of packages ktechlab recommends: ii gputils 0.13.5-1 GNU PIC utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#201589: GnuPG does not work with Privoxy
reassign 201589 gnupg 1.4.6-2
retitle 201589 GnuPG does not work with Privoxy (and maybe other HTTP proxies?)
[patch]
tags 201589 + patch
thanks
Hi,
there was a long-standing bug against Privoxy that keyserver access does
not work with GnuPG. I actually found out that GnuPG is the culprit, not
Privoxy.
The problem only occurs with the built-in curl-shim.c code, not when
libcurl is used. BTW, you should explicitly build --without-curl, otherwise
any installed curl dev package on the build machine will be picked up.
The attached patch simply disables two lines of code. I'm not sure what
their purpose is - without them, keyserver access for sending and
retrieving keys works both with and without a proxy.
HTTP_FLAG_NO_SHUTDOWN isn't actually used anywhere else in the code.
The patch also adds a Host: header when an HTTP proxy is used. I think
the host header is always required by the spec, and if it's not there, this
might cause problems with some proxies/servers. Virtual keyserver hosting
is fairly uncommon these days ;) - nevertheless, having Host: is more
correct.
Finally: Maybe consider changing to --with-curl - that curl-shim code looks
quite hacked up and does a lot of ugly string/malloc operations...
Cheers,
Richard
--
__ _
|_) /| Richard Atterer
| \/¯| http://atterer.net
¯ '` ¯
--- ./util/http.c.orig 2006-07-24 15:46:27.0 +0200
+++ ./util/http.c 2008-01-05 20:53:08.706898505 +0100
@@ -212,8 +212,10 @@
iobuf_ioctl (hd-fp_write, 1, 1, NULL); /* keep the socket open */
iobuf_close (hd-fp_write);
hd-fp_write = NULL;
+#if 0
if ( !(hd-flags HTTP_FLAG_NO_SHUTDOWN) )
shutdown( hd-sock, 1 );
+#endif
hd-in_data = 0;
hd-fp_read = iobuf_sockopen( hd-sock , r );
@@ -573,13 +575,14 @@
request=xmalloc(strlen(server)*2 + strlen(p)
+ (authstr?strlen(authstr):0)
- + (proxy_authstr?strlen(proxy_authstr):0) + 65);
+ + (proxy_authstr?strlen(proxy_authstr):0) + 256);
if( proxy *proxy )
- sprintf( request, %s http://%s:%hu%s%s HTTP/1.0\r\n%s%s,
+ sprintf( request, %s http://%s:%hu%s%s HTTP/1.0\r\nHost:
%s:%hu\r\n%s%s,
hd-req_type == HTTP_REQ_GET ? GET :
hd-req_type == HTTP_REQ_HEAD? HEAD:
hd-req_type == HTTP_REQ_POST? POST: OOPS,
server, port, *p == '/'? :/, p,
+ server, port,
authstr?authstr:,proxy_authstr?proxy_authstr: );
else
{
Bug#201589: GnuPG does not work with Privoxy
Duh, duplication of effort. This is already fixed in upstream SVN (my fix was right!;), close this bug with the gnupg 1.4.7 or 2.0.2 upload. https://bugs.g10code.com/gnupg/issue739 Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#440436: Amaya will be hurt
On Wed, Jan 02, 2008 at 03:52:17PM -, Regis Boudin wrote: On Sat, December 15, 2007 11:42, Richard Atterer wrote: Having tried to create a program using both libwww and libcurl, I can say that libcurl is _much_ better in every aspect. These days, libcurl can even do HTTP pipelining, which was only supported by libwww for a long time. OK, the good news is, upstream reacted very positively to my suggestion to switch to libcurl. That's great! TBH, I'm not too surprised, libwww _is_ difficult to get to work at times. One thing I'm not sure about yet is how to handle WebDAV with it. Not much of a problem for me at the moment anyway, considering the feature is disabled in both libwww and Amaya... WebDAV support is raised on the libcurl mailing list from time to time. Curl doesn't directly support WebDAV, but you can generate quite arbitrary HTTP-like requests with it, including overwriting the request method with e.g. MKCOL rather than GET/POST. So it should be possible to get it to work. Alternatively, WebDAV support could be added to curl. Having hacked libcurl on several occasions, I can say that its code is quite beautiful and fun to work with, in contrast to libwww... Well, or look at libneon. mapserver is actually a false positive, they switched to libcurl ages ago, bug filed. Seems to be the case with xdvik-ja too. Which only leaves : amaya liboop (reverse b-dep are lsh-utils, and ruli) wmweather+ xmlrpc-c (reverse b-dep are libapache2-mod-xmlrpc2, openser, and rtorrent) As I wrote previously, I will be happy to take over maintainership until it can be actually removed. How do you want me to handle this ? Simply make an upload setting myself as new maintainer ? Yes, feel free to take over maintainership this way! (Close this bug with the upload if you do plan to take it over permanently, and not only until Amaya has moved to libcurl.) BTW, if you keep the package in the archive, consider getting rid of the non-SSL versions. I introduced them because of possible license incompatibilities between any GPL packages and OpenSSL, but last time I checked (=a long time ago!;-), there weren't actually any such problems with the current depends in the Debian archive. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ signature.asc Description: Digital signature
Bug#440436: Amaya will be hurt
On Fri, Dec 14, 2007 at 05:38:12PM -, Regis Boudin wrote: Amaya build-depends on libwww and seriously relies on it. Removing it will put me in a quite uncomfortable situation. I would like to avoid following upstream who use a statically built and linked version of the library if I can. Hmm, OK. Using a statically linked version would have been my first suggestion. I could try to push them towards libcurl, though I'm afraid they won't react well... Having tried to create a program using both libwww and libcurl, I can say that libcurl is _much_ better in every aspect. These days, libcurl can even do HTTP pipelining, which was only supported by libwww for a long time. Would you maybe be interested in taking over maintainership of libwww? BTW, currently the following unstable packages build-dep on libwww: amaya liboop mapserver wmweather+ xdvik-ja xmlrpc-c Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#456102: FTBFS: error: 'INT_MAX' undeclared
On Wed, Dec 12, 2007 at 09:19:51PM -0700, Martin Michlmayr wrote: cdrwtool.c: In function 'cdrom_open_check': cdrwtool.c:606: error: 'INT_MAX' undeclared (first use in this function) This puzzled me at first, as line 606 reads: ret = ioctl(fd, CDROM_DRIVE_STATUS, CDSL_CURRENT); Both constants come from linux/cdrom.h. For me it contains: #define CDROM_DRIVE_STATUS 0x5326 /* Get tray position, etc. */ #define CDSL_CURRENT((int) (~0U1)) I wouldn't be surprised if the second #define had been changed to use INT_MAX in more recent kernel sources. So is this a bug in the header file - should it include limits.h itself? Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#455087: /etc/modutils/udftools seems odd location
On Sun, Dec 09, 2007 at 09:27:12AM +0900, Osamu Aoki wrote: The recent modprobe.conf(5) manpage does not seem to mention /etc/modutils/ any more (I do not know if it ever did). This looks like old location which might be supported as compatibility but may be better to use normal location if these alias need to be activated. Yes, right - /etc/modutils is old. I probably should have removed the file altogether in my previous upload. I think these days block numbers are not even allocated statically for pktcdvd anymore, so the file might be useless. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#455001: Add Suggests: konsole - is needed by Terminal tab in kate
Package: kate Version: 4:3.5.7.dfsg.1-1 Severity: minor Hello, When clicking on the Terminal tab in kate, only a grey area without content appears if konsole is not installed. Please suggest konsole in the kate package! Alternatively, it would be nice if there were some feedback about the lack of konsole, e.g. an error message in that grey area when one tries to open the terminal tab without success. I first installed kterm and didn't realize for a while that kate really wanted konsole instead of kterm. (FWIW, I'm a Gnome user, that's why only a minimal set of KDE packages is installed on my machine.) Cheers, Richard -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.22.9 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages kate depends on: ii kdelibs4c2a 4:3.5.8.dfsg.1-3 core libraries and binaries for al ii libacl1 2.2.45-1 Access control list shared library ii libart-2.0-22.3.19-3 Library of functions for 2D graphi ii libattr11:2.4.39-1 Extended attribute shared library ii libaudio2 1.9.1-1 Network Audio System - shared libr ii libc6 2.7-3GNU C Library: Shared libraries ii libfontconfig1 2.4.2-1.2generic font configuration library ii libfreetype62.3.5-1+b1 FreeType 2 font engine, shared lib ii libgamin0 [libfam0] 0.1.9-2 Client library for the gamin file ii libgcc1 1:4.2.2-4GCC support library ii libice6 2:1.0.4-1X11 Inter-Client Exchange library ii libidn111.1-1GNU libidn library, implementation ii libjpeg62 6b-14The Independent JPEG Group's JPEG ii libpng12-0 1.2.15~beta5-3 PNG library - runtime ii libqt3-mt 3:3.3.7-9Qt GUI Library (Threaded runtime v ii libsm6 2:1.0.3-1+b1 X11 Session Management library ii libstdc++6 4.2.2-4 The GNU Standard C++ Library v3 ii libx11-62:1.0.3-7X11 client-side library ii libxcursor1 1:1.1.9-1X cursor management library ii libxext61:1.0.3-2X11 miscellaneous extension librar ii libxft2 2.1.12-2 FreeType-based font drawing librar ii libxi6 2:1.1.3-1X11 Input extension library ii libxinerama11:1.0.2-1X11 Xinerama extension library ii libxrandr2 2:1.2.2-1X11 RandR extension library ii libxrender1 1:0.9.4-1X Rendering Extension client libra ii libxt6 1:1.0.5-3X11 toolkit intrinsics library ii zlib1g 1:1.2.3.3.dfsg-6 compression library - runtime Versions of packages kate recommends: pn kregexpeditor none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#454255: udftools: udf/tools should be available.
On Tue, Dec 04, 2007 at 12:05:37PM +0100, Jean-Michel wrote: Package: udftools Version: 1.0.0b3-12 Severity: normal It allows to do: ./chkudf /dev/hda What do you mean? There is no chkudf in the udftools package (or source), so this is not a bug in udftools. Also, in the udf-0.9.8.tar.gz archive downloadable from http://sourceforge.net/projects/linux-udf/ there is a tools subdirectory, but it is empty. Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#453665: udftools: configure should check for apt-get install libreadline-dev
I'm preparing an updated version of the package right now - please wait a few days before you continue your work, to avoid duplication of effort! On Fri, Nov 30, 2007 at 03:10:53PM +0100, Jean-Michel wrote: Before compiling, apt-get install libreadline-dev should be launched. configure script might check for such a component. This is already checked, because of the Build-Depends: libreadline5-dev in debian/control. Please use the dpkg-buildpackage command to build the package! Oh, and if you provide patches for existing bugs like you did for #453629, please add them to the existing bug rather than opening a new one. I guess you already noticed that. :) Thanks for your contribution! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#401302: ekiga: Ekiga cannot find webcam
Derek Wueppelmann wrote on Tue, 02 Jan 2007: I am also having the same issue with this package. If you use v4l instead of v4l2 it will detect the device correctly and work. However v4l2 does not work and it does give an error.. I'm currently facing the same problem, but with v4l and v4l2 swapped: I have a uvcvideo (i.e. v4l2-only) webcam. ekiga 2.0.3-6+b1 in testing recognizes it correctly. In the configuration druid, it only offers me a V4L2 entry for the Video Manager step. However, ekiga 2.0.11-2 in unstable only offers V4L, not V4L2. When clicking on test settings one screen later, or when restarting ekiga after the druid is finished, I always get an error message that opening /dev/video0 failed. It looks a bit as if the v4l_2_ support is gone..? BTW, I am running the unstable version in my unstable chroot. But that shouldn't be a problem... I can access the webcam fine using luvcview both under testing and unstable, as /dev is bind-mounted to the chroot's /dev. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#401302: ekiga: Ekiga cannot find webcam
On Fri, Oct 19, 2007 at 11:10:33PM +0200, Richard Atterer wrote: However, ekiga 2.0.11-2 in unstable only offers V4L, not V4L2. Ah, investigating a little more revealed that the reason was simply that I did not have libpt-1.10.10-plugins-v4l2 installed. Please consider adding a Depends, the connection from ekiga to this package is not obvious! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#440436: The maintainer plans to request removal of this package from the Debian archive
Package: w3c-libwww Severity: critical This message is mainly for the RMs, BSP bug hunters etc. who have a look at libwww. I'm filing this against my own package. I am going to request removal because: - the code is old and suffers from bitrot - there are probably more security issues lurking somewhere in there, similar to #334443 which was fixed in October 2005 - upstream is dead - libcurl is a much better replacement I still need to have a closer look at the rdeps - feel free to help with this. From a quick look, removing libwww is probably not too much of a problem. Cheers, Richard -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.21.1 (PREEMPT) Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400023: PDF causes gv to consume all available memory, machine swaps madly
On Sun, Jul 29, 2007 at 08:58:54PM +0200, Bernhard R. Link wrote: Here the file just needs a bit of time and then causes the X server to consume around 400MB more. (which is not that much considering a 1x1 pixel image of the whole page is loaded into it). What kind of machine do you see this behaviour on? Would the X server taking 400MB more be likely to cause that kind of swapping? Yes, most likely - I only have 512 MB on that machine (a Centrino notebook), and IIRC a couple of other applications were loaded at the time. So technically speaking, this may not be a bug and you could argue that I should use ulimit -d to prevent this kind of problem. But it is very unexpected that a simple PDF file, which displays fine in other programs, will cause the machine to grind to a halt when I use gv. :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#433329: Please clarify whether Lucida Bright/Lucida Sans fonts are supported
Package: texlive-fonts-recommended Version: 2007-10 Severity: minor Hello, texlive-fonts-recommended contains the following files related to Lucida Bright fonts: /usr/share/doc/texlive-fonts-recommended/latex/psnfssx/lucidabr.txt.gz /usr/share/doc/texlive-fonts-recommended/latex/psnfssx/lucfont.tex /usr/share/doc/texlive-fonts-recommended/latex/psnfssx/lucfont.dvi.gz /usr/share/texmf-texlive/tex/latex/psnfssx/lucidbrb.sty /usr/share/texmf-texlive/tex/latex/psnfssx/lucmin.sty /usr/share/texmf-texlive/tex/latex/psnfssx/lucidbry.sty /usr/share/texmf-texlive/tex/latex/psnfssx/luctime.sty /usr/share/texmf-texlive/tex/latex/psnfssx/lucbmath.sty /usr/share/texmf-texlive/tex/latex/psnfssx/lucmtime.sty /usr/share/texmf-texlive/tex/latex/psnfssx/lucidabr.sty /usr/share/doc/texlive-doc/latex/psnfssx/lucidabr.txt.gz /usr/share/doc/texlive-doc/latex/psnfssx/lucfont.tex /usr/share/doc/texlive-doc/latex/psnfssx/lucfont.dvi.gz All this suggests that it is possible to use Lucida Bright under Debian. However, I get errors trying to use the font (e.g. typesetting lucfont.tex above). After googling for hours, I am still scratching my head - could it be that the font is non-free and thus not supported? After all, there's no trace of any hls* file in any of the TeX packages. Then why are these files present?? I suggest to document that it is not possible to use the fonts under Debian, preferably both in README.Debian and in /usr/share/doc/texlive-fonts-recommended/latex/psnfssx/lucidabr.txt.gz Alternatively, the above files could be removed from the package ...unless there is an easy way to install the non-free fonts - can they be downloaded somewhere? Cheers, Richard ## List of ls-R files -rw-r--r-- 1 root root 916 2007-07-16 07:49 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 2007-07-02 11:42 /usr/share/texmf/ls-R - /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 27 2007-07-06 16:47 /usr/share/texmf-texlive/ls-R - /var/lib/texmf/ls-R-TEXLIVE lrwxrwxrwx 1 root root 27 2007-07-06 16:47 /usr/share/texmf-texlive/ls-R - /var/lib/texmf/ls-R-TEXLIVE ## Config files lrwxrwxrwx 1 root root 20 2007-07-02 11:42 /usr/share/texmf/web2c/texmf.cnf - /etc/texmf/texmf.cnf -rw-r--r-- 1 root root 4396 2007-07-06 16:54 /var/lib/texmf/web2c/fmtutil.cnf -rw-r--r-- 1 root root 6619 2007-07-06 16:54 /var/lib/texmf/web2c/updmap.cfg -rw-r--r-- 1 root root 4542 2007-07-06 16:54 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 4 -rw-r--r-- 1 root root 283 2006-08-16 17:02 mktex.cnf ## md5sums of texmf.d 25bf3a257a0bedb5c67349c3eaff74af /etc/texmf/texmf.d/05TeXMF.cnf 5f7f6652cc8b8071c9e4ea6ba9e9f0a1 /etc/texmf/texmf.d/15Plain.cnf 8a26468004b5ebc7ae9884740356c1d0 /etc/texmf/texmf.d/45TeXinputs.cnf ea33127256c6a9f37145ae5b16fdb80c /etc/texmf/texmf.d/55Fonts.cnf afccf1d3f87057411166a77c58e00bd1 /etc/texmf/texmf.d/65BibTeX.cnf 9da7c1c7b1eaf06f941af91f48a23068 /etc/texmf/texmf.d/75DviPS.cnf e36faa13563bdb46303b91ab3f6ea638 /etc/texmf/texmf.d/85Misc.cnf 7e8f87acdeba48edac16d851c77b9e75 /etc/texmf/texmf.d/90TeXDoc.cnf 30f4f13357c2761ed01a6a15f28725a5 /etc/texmf/texmf.d/95NonPath.cnf 0b5483ae6af6c33480de5d1f628ffe83 /etc/texmf/texmf.d/96JadeTeX.cnf -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.20.2 (PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages texlive-fonts-recommended depends on: ii texlive-base 2007-10TeX Live: Essential programs and f ii texlive-common2007-10TeX Live: Base component Versions of packages texlive-fonts-recommended recommends: ii tipa 2:1.3-8system for processing phonetic sym Versions of packages tex-common depends on: ii debconf 1.5.13 Debian configuration management sy ii ucf 3.001 Update Configuration File: preserv Versions of packages texlive-fonts-recommended is related to: pn tetex-basenone (no description available) pn tetex-bin none (no description available) pn tetex-extra none (no description available) ii tex-common1.9Common infrastructure for using an -- debconf information: tex-common/check_texmf_wrong: tex-common/check_texmf_missing: tex-common/singleuser: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#428880: libwww-doc: invalid link
On Fri, Jun 15, 2007 at 12:23:26AM +0300, Mohammed Sameer wrote: Go to: file:///usr/share/doc/libwww-doc/html/Library/index.html#Legal Libwww is covered by this copyright notice as well as the full W3C license Clicking on copyright or full W3C license - 404 The files are available online: http://www.w3.org/Consortium/Legal/libwww-copyright-notice-19980720.html http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 But you are right, they should probably be included in the package. The copyright notice is already there in /usr/share/doc/libwww-doc/copyright. The other software notice somehow got left out, the Debian copyright file only contains the Intellectual Property Notice. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#422777: xserver-xorg: MergedFB CRT2 Clone stopped working after reboot
Hello, I'm not the original bug submitter, but for the record: Brice Goglin wrote: You could possibly try upgrading xserver-xorg-video-ati to the one currently in experimental (1:6.6.191-1). However, in the end it might be better to wait for the next official release of the ATI driver before upgrading to xserver-xorg-core 1.3. Upgrading to 1:6.6.192-1 in experimental was the right thing for me: I was unable to get dual-head (via MergedFB) to work with the current packages in testing. ...So please upload that package to the regular archive soon! :) I now have a working dual-head configuration on my Sony Vaio PCG-Z1RSP (Radeon Mobility M6 LY): The 1400x1050 panel of the laptop is the primary screen, an external LCD is driven at 1280x1024. Previously, X11 always complained on startup that it was unable to find any working modes for the external LCD, and switched off MergedFB. Cheers, Richard xorg.conf snippet: Section Device Identifier RadeonMerged Driver radeon Option MergedFB true Option MonitorLayout LVDS, CRT Option CRT2Position LeftOf Option MetaModes 1400x1050-1280x1024 Option MergedXineramaCRT2IsScreen0 false Option MergedNonRectangular true EndSection -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#418676: jigdo-file: Bad processing existing jigdo file
retitle 418676 jigdo-lite: No error message if disk is full when unpacking .jigdo file tags 418676 wontfix thanks On Thu, Apr 12, 2007 at 04:06:49PM +0200, Wojciech Zareba wrote: I have possible explanation: the filesystem was full. But this is still a bug, becouse the program behaves unsuitably to the situation and mislead the user. OK, but as it would be difficult to fix the jigdo-lite script, I will not try to make the error handling better. This is just one more area where extending the shell script any further does not make sense. The jigdo GUI application should fix these issues, but unfortunately I'm pessimistic that I'll ever finish the GUI... :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#418676: jigdo-file: Bad processing existing jigdo file
Hello, everything seems to work fine if I start the download with jigdo-lite http://cdimage.debian.org/debian-cd/4.0_r0/amd64/jigdo-dvd/debian-40r0-amd64-DVD-2.jigdo Can you try this? Looks like your local copy of the .jigdo file is somehow corrupted. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#418694: jigdo-file md5sum should ignore --no-check-files option
Package: jigdo Version: 0.7.3-1 Severity: normal Date: Sun, 8 Apr 2007 17:37:22 -0300 From: Carlos Carvalho [EMAIL PROTECTED] To: debian-cd@lists.debian.org Subject: followup: jigdo template mdsum mismatch?? Message-ID: [EMAIL PROTECTED] Looking at this portion of jigdo-mirror, # If possible, check md5sum of template data if test $templateMD5; then set -- `$jigdoFile md5sum --report=quiet template` if test $1 = $templateMD5; then log Template checksum is correct else log Error - template checksum mismatch exitCode=1 rm -f image template return 0 fi else $jigdoFile is jigdo-file --cache=$tmpDir/jigdo-cache.db --cache-expiry=1w --report=noprogress --no-check-files, as usual (this is the default in jigdo-mirror). However when used with --no-check-files jigdo-file does NOT produce any md5sum! Taking a trace of jigdo-mirror I get this: + test OLshs7sHh08k63h8bLp8-Q -- This is the md5sum of the template, ++ jigdo-file --cache=/home/debian-cd-sync/alpha.cd/jigdo-cache.db --cache-expir y=1w --report=noprogress --no-check-files md5sum --report=quiet template + set -- + test '' = OLshs7sHh08k63h8bLp8-Q + log 'Error - template checksum mismatch' This shows that jigdo-file is returning an empty checksum. Running the command by hand does produce nothing, with an exit status of zero. Removing the --no-check-files argument yields the correct checksum. This is a bug in jigdo-file, for not ignoring the option when used with a md5sum command, since the man page says All options are silently ignored if they are not applicable to the current command. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.9 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#418727: udftools: writing to dvd-ram cause total userspace freeze
On Wed, Apr 11, 2007 at 05:43:46PM +0200, Dusan Zatkovsky wrote: Maybe it should be kernel problem. (?) Yes, it is bound to be a problem with the drivers for your device, or another part of the kernel. udftools is only the userspace portion. Try upgrading to the latest kernel - maybe use a kernel from kernel.org, Debian always lags a bit. Please close this bug, the udftools userspace tools do not (directly) cause the crash. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#418195: netinst/bc: README contains para irrelevant
On Sun, Apr 08, 2007 at 02:09:53AM +0200, Frans Pop wrote: On Sunday 08 April 2007 01:25, Steve McIntyre wrote: I think we've grown too much to claim that anything after disc#1 is just special-interest. Is there better wording for this? Yes, I agree. Maybe: It is unlikely that you will need all of the TOTALNUM disks in the set. The higher the number in the set, the less likely it is that you will use any of the packages that are included; higher-number images contain mostly special-interest programs. FWIW, the CD FAQ has been saying for a while that the first two CDs are enough: You will probably only need the first DVD (or the first two CDs) unless you have very special requirements. http://www.debian.org/CD/faq/#which-cd But maybe these days even two CDs is not enough for a full desktop install?? Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯
Bug#413574: jigdo really needs to be completed
severity 413574 normal thanks On Mon, Mar 05, 2007 at 10:01:53PM -, peter green wrote: currently there is no decent method for downloading cd images other than http/ftp. jigdo-lite is virtually unusable (no indication of progress or if its resuming or restarting etc). Bittorrent is only usable on some networks (often throttled or banned) and only for the most common images. I basically agree, but still, this is not important priority. Unfortunately, my spare time is very limited, so don't hold your breath waiting for a fully usable jigdo application. :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#410191: closed by Richard Atterer [EMAIL PROTECTED] (Re: Bug#410191: Acknowledgement (usbfs: cannot create file in a specific directory))
On Sun, Feb 11, 2007 at 07:34:02PM +0100, Jean-Michel wrote: Well, I just do not understand why you closed this bug concerning udf fs. Oops, sorry! Did you not get my previous email? I thought it was going to be forwarded to you. Here it is again: - Forwarded message from Richard Atterer [EMAIL PROTECTED] - Date: Sat, 10 Feb 2007 01:40:10 +0100 From: Richard Atterer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Bug#410191: Acknowledgement (usbfs: cannot create file in a specific directory) touch: ne peut faire un touch sur `/mnt/iomega/data/toto': Erreur d'entrée/sortie My French is almost non-existent, but I guess this means I/O error, right? This is a hint that your medium is broken, i.e. the Iomega disc is faulty. :-( NOTE: Ensure that you mount the medium using the noatime mount option! Otherwise, every read from the device will also cause a write operation because the last read timestamp is updated. I don't know how many write operations your medium supports, but with optical discs it is usually only 1000 or so, so when you frequently make changes to a directory (e.g. data in your case), the directory's timestamp gets updated many many times. After a few months or a year, the respective block on the disc can no longer be overwritten, and you get an I/O error. Unless you disagree, I'll close this bug. This is not a problem with udftools, just a hardware failure. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯ - End forwarded message -
Bug#410191: usbfs: cannot create file in a specific directory
On Sun, Feb 11, 2007 at 10:38:39PM +0100, Jean-Michel wrote: This looks rare. Disks have been bought (and used) two month ago only! I see. :-/ Have you tried whether the error also occurs under Windows? What does the kernel output the moment the write fails? For hard discs, dmesg or /var/log/syslog contain kernel messages in this case, which include exact sector numbers. If you see this kind of message in your log, the Rev drive is telling Linux that it can no longer read or write the respective sector, which would be a strong indication that the disc is broken. In fact this is a 35 Gigabytes removable hard drive, the one described on the page hereafter: http://en.wikipedia.org/wiki/Iomega_REV I cannot find any information on whether the drive uses magneto-optical technology (unlike normal hard drives, which are magnetic-only - I suspect that it _is_ magneto-optical, and this also sounds like it: 2) REV drives employ a two dimensional error correction system that requires the host to send data in 64KB aligned chunks to achieve optimal performance. The UDF format used on REV cartridges helps to force 64KB aligned transfers. RedChaos http://en.wikipedia.org/w/index.php?title=User:RedChaosaction=edit 00:10, 17 July 2006 (UTC) I am not so sure of an hardware failure. The disk has been reformated, and I continue to use it. I hope it is not an hardware issue. BTW, if you want to find out whether bad sectors still exist on the disc, you can use the badblocks program (e2fsprogs package). Might be that the IO error could be related to failures which occurs when trying to write a file greater than 1 gigabyte? As far as I know, UDF has no such size restrictions. All the best, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#410191: Acknowledgement (usbfs: cannot create file in a specific directory)
touch: ne peut faire un touch sur `/mnt/iomega/data/toto': Erreur d'entrée/sortie My French is almost non-existent, but I guess this means I/O error, right? This is a hint that your medium is broken, i.e. the Iomega disc is faulty. :-( NOTE: Ensure that you mount the medium using the noatime mount option! Otherwise, every read from the device will also cause a write operation because the last read timestamp is updated. I don't know how many write operations your medium supports, but with optical discs it is usually only 1000 or so, so when you frequently make changes to a directory (e.g. data in your case), the directory's timestamp gets updated many many times. After a few months or a year, the respective block on the disc can no longer be overwritten, and you get an I/O error. Unless you disagree, I'll close this bug. This is not a problem with udftools, just a hardware failure. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#407144: udftools: can't install in etch chroot
On Tue, Jan 16, 2007 at 02:33:05PM +0100, Bruno Muller wrote: Setting up udftools (1.0.0b3-12) ... /var/lib/dpkg/info/udftools.postinst: line 12: ./MAKEDEV: No such file or directory OK, it seems udftools needs a dependency on makedev - or maybe I should no longer attempt to use makedev at all, see #405821. I had thought that no dependency is needed because makedev is Priority: required, but actually that is only true for Priority: essential. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#406968: Specify complete upstream license possibilities in copyright file. Consider LGPL, not GPL for Debian patches
Package: lzma Version: 4.43-3 Severity: normal Hi, the copyright file only mentions LGPL licensing, whereas the upstream source allows several alternatives. While it is no legal problem that only LGPL is mentioned, the use of GPL for the Debian patches actually turns the whole code into GPL AFAIK. Maybe you could consider releasing the patches in a less strict format; maybe even one as lax as BSD, in order not to tighten up the licensing? At a minimum, could you use LGPL instead of GPL? Cheers, Richard -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages lzma depends on: ii libc62.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-21 GCC support library ii libstdc++6 4.1.1-21The GNU Standard C++ Library v3 lzma recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#407019: Please implement new view to get 1 editor views on the same .tex document
Package: kile Version: 1:1.9.3-1 Severity: wishlist Hello, In long .tex documents I find it crucial to be able to edit in one place, then in another, and then to go back to the first one. This could be supported by allowing two editor views on the same .tex document. The views must be linked so that changes in one view are immediately reflected in the other one. Kile does not allow that; there is no new view functionality, and attempts to open the same file a second time are ignored. Please implement this feature! For me, it is so important that I might actually go back to using another editor, despite the fact that I like kile! :-/ -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages kile depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-5 core libraries and binaries for al ii konsole4:3.5.5a.dfsg.1-5 X terminal emulator for KDE ii libc6 2.3.6.ds1-8 GNU C Library: Shared libraries ii libgcc11:4.1.1-21GCC support library ii libqt3-mt 3:3.3.7-2 Qt GUI Library (Threaded runtime v ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii tetex-bin 3.0-28The teTeX programs Versions of packages kile recommends: ii kdvi4:3.5.5-2dvi viewer for KDE ii kghostview 4:3.5.5-2PostScript viewer for KDE ii tetex-doc 3.0.dfsg.3-5 The documentation component of the ii tetex-extra 3.0.dfsg.3-5 Additional TeX input files of teTe -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#405067: php5-cli: Segfault after infinite recursion inside pcre - random memory corruption?
On Sat, Dec 30, 2006 at 10:23:06PM +0100, Richard Atterer wrote: One more thing: I also tried to trim down the example further by reducing the length of the subject string. This gives weird results: The following has occurred to me: The program starts crashing when the region matched by the regex (begins with the opening ?php) is about 4000 bytes long. At this point, the stack contains some 8100 stack frames, half of them on ./pcre_exec.c:1190, the other half on ./pcre_exec.c:677. Thus, it is possible that the special input causes one recursive step (i.e., one call through ./pcre_exec.c:677) for each character that is consumed. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#405067: php5-cli: Segfault after infinite recursion inside pcre - random memory corruption?
Package: php5 Version: 5.2.0-8 Severity: important Tags: security Hello, while developing my PHP application, I stumbled across PCRE usage which crashes the PHP binary. After some trial and error, I was able to reduce the problem to the attached piece of PHP code. I was able to reproduce the segfault on 3 different machines running Debian, under php 5.2.0-8 (testing, 2 machines) and 4.3.10-18 (stable). I also compiled versions of libpcre3 and php5-cli with debugging information to get a stack trace. The topmost frames of the stack backtrace follow at the end of this message. Inside libpcre3, the code recurses through pcre_exec.c lines 677 and 1190 until the stack overflows. Next, I tried to find out whether the crash is reproducible with a C program. But while AFAICT the attached C program does the same as the code in php-5.2.0/ext/pcre/php_pcre.c, no segfault happens. So maybe PHP corrupts memory between compiling and executing the regex? I don't know! :-/ Running valgrind php5 php-5.2.0-8-segfault.php doesn't output anything which looks like a PCRE-related bug. One more thing: I also tried to trim down the example further by reducing the length of the subject string. This gives weird results: When some parts of the input are removed, the crash becomes unreliable in that executing php5 php-5.2.0-8-segfault.php will crash sometimes and sometimes it will not. I've anonymized my code by replacing alphabetic characters with x, that's why it looks so weird. :) I'm tagging this security as this MAY potentially be a nasty bug which might allow more than just segfaults. If you disagree, feel free to remove the tag. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯ #8146 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9319a4, flags=value optimized out, rdepth=31) at ./pcre_exec.c:677 #8147 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9321a4, flags=value optimized out, rdepth=30) at ./pcre_exec.c:1190 #8148 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9321a4, flags=value optimized out, rdepth=29) at ./pcre_exec.c:677 #8149 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9329a4, flags=value optimized out, rdepth=28) at ./pcre_exec.c:1190 #8150 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9329a4, flags=value optimized out, rdepth=27) at ./pcre_exec.c:677 #8151 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9331a4, flags=value optimized out, rdepth=26) at ./pcre_exec.c:1190 #8152 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9331a4, flags=value optimized out, rdepth=25) at ./pcre_exec.c:677 #8153 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9339a4, ---Type return to continue, or q return to quit--- flags=value optimized out, rdepth=24) at ./pcre_exec.c:1190 #8154 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9339a4, flags=value optimized out, rdepth=23) at ./pcre_exec.c:677 #8155 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9341a4, flags=value optimized out, rdepth=22) at ./pcre_exec.c:1190 #8156 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9341a4, flags=value optimized out, rdepth=21) at ./pcre_exec.c:677 #8157 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9349a4, flags=value optimized out, rdepth=20) at ./pcre_exec.c:1190 #8158 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9349a4, flags=value optimized out, rdepth=19) at ./pcre_exec.c:677 #8159 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9351a4, flags=value optimized out, rdepth=18) at ./pcre_exec.c:1190 #8160 0xb7e29c04 in match (eptr=value optimized out, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9351a4, flags=value optimized out, rdepth=17) at ./pcre_exec.c:677 #8161 0xb7e2a5a7 in match (eptr=0xb72ce7a4 ;\n, ecode=value optimized out, offset_top=6, md=0xbf939658, ims=0, eptrb=0xbf9359a4, flags=value optimized out, rdepth=16) at ./pcre_exec.c:1190 #8162 0xb7e29c04
Bug#237965: Problem still exists
Hello, the DGA mouse problem still exists, I just got hit by it on one machine of mine, whereas everything worked fine on another. The problems occurred both with a USB and a PS/2 mouse, with and without gpm running. The fix of setting SDL_VIDEO_X11_DGAMOUSE=0 worked fine. Please don't close this bug, otherwise I'd never have found out about the solution! Maybe you could mention the fix in the README.Debian. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯
Bug#370384: pretty unacceptable
severity 370384 normal thanks I basically agree, it is a bit misleading that the jigdo GUI application is not yet capable of processing .jigdo files. However, the app is not useless; it is a normal download manager for FTP and HTTP. Furthermore, jigdo-file (i.e. the package containing jigdo-lite) and jigdo share the same source. Removing jigdo would also mean removing jigdo-lite at this point of the release AFAICT, as the release managers would not agree to changing the jigdo build not to produce a jigdo package. Thus, I'll set the severity back to normal - the bug does not fit the grave description, nor even important! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#398884: jigdo-file: hangs during package scan and consumes 100% of CPU
Hi Baurzhan, have you made any progress on this? The chance of fixing this in time for etch becomes smaller with every day! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#403209: Per-device locking - necessary to avoid long wait for multi-device card reader
Package: usbmount Version: 0.0.14-0.1 Severity: normal Tags: patch Hello, I own a bazillion-in-one USB card reader which registers 4 different devices when it is plugged in. As Murphy would have it, the slot which actually contains my xD card is always registered last (or second-to-last) by udev. Due to usbmount's global lock, this leads to a long wait: Dec 15 11:38:36 x usbmount[28589]: trying to acquire lock /var/run/usbmount/.mount.lock Dec 15 11:38:36 x usbmount[28589]: acquired lock /var/run/usbmount/.mount.lock Dec 15 11:38:36 x usbmount[28589]: testing whether /dev/sdb is readable Dec 15 11:38:36 x usbmount[28617]: trying to acquire lock /var/run/usbmount/.mount.lock Dec 15 11:38:36 x usbmount[28632]: trying to acquire lock /var/run/usbmount/.mount.lock Dec 15 11:38:36 x usbmount[28609]: trying to acquire lock /var/run/usbmount/.mount.lock Dec 15 11:38:36 x usbmount[28589]: attempt 0 to read from /dev/sdb failed Dec 15 11:38:37 x usbmount[28589]: attempt 1 to read from /dev/sdb failed Dec 15 11:38:38 x usbmount[28589]: attempt 2 to read from /dev/sdb failed Dec 15 11:38:39 x usbmount[28589]: attempt 3 to read from /dev/sdb failed Dec 15 11:38:40 x usbmount[28589]: attempt 4 to read from /dev/sdb failed Dec 15 11:38:41 x usbmount[28589]: attempt 5 to read from /dev/sdb failed Dec 15 11:38:42 x usbmount[28589]: attempt 6 to read from /dev/sdb failed Dec 15 11:38:43 x usbmount[28589]: attempt 7 to read from /dev/sdb failed Dec 15 11:38:44 x usbmount[28589]: attempt 8 to read from /dev/sdb failed Dec 15 11:38:45 x usbmount[28589]: attempt 9 to read from /dev/sdb failed Dec 15 11:38:46 x usbmount[28589]: attempt 10 to read from /dev/sdb failed Dec 15 11:38:47 x usbmount[28589]: attempt 11 to read from /dev/sdb failed Dec 15 11:38:48 x usbmount[28589]: attempt 12 to read from /dev/sdb failed Dec 15 11:38:49 x usbmount[28589]: attempt 13 to read from /dev/sdb failed Dec 15 11:38:50 x usbmount[28589]: attempt 14 to read from /dev/sdb failed Dec 15 11:38:51 x usbmount[28589]: attempt 15 to read from /dev/sdb failed Dec 15 11:38:52 x usbmount[28589]: attempt 16 to read from /dev/sdb failed Dec 15 11:38:53 x usbmount[28589]: attempt 17 to read from /dev/sdb failed Dec 15 11:38:54 x usbmount[28589]: attempt 18 to read from /dev/sdb failed Dec 15 11:38:55 x usbmount[28589]: attempt 19 to read from /dev/sdb failed Dec 15 11:38:56 x usbmount[28589]: cannot read from /dev/sdb Dec 15 11:39:06 x usbmount[28617]: acquired lock /var/run/usbmount/.mount.lock Dec 15 11:39:06 x usbmount[28617]: testing whether /dev/sdd is readable Dec 15 11:39:06 x usbmount[28617]: attempt 0 to read from /dev/sdd failed Dec 15 11:39:06 x usbmount[28632]: cannot acquire lock /var/run/usbmount/.mount.lock Dec 15 11:39:06 x usbmount[28609]: cannot acquire lock /var/run/usbmount/.mount.lock Dec 15 11:39:06 x usbmount[28748]: trying to acquire lock /var/run/usbmount/.mount.lock Dec 15 11:39:07 x usbmount[28617]: attempt 1 to read from /dev/sdd failed Dec 15 11:39:08 x usbmount[28617]: attempt 2 to read from /dev/sdd failed Dec 15 11:39:09 x usbmount[28617]: attempt 3 to read from /dev/sdd failed Dec 15 11:39:10 x usbmount[28617]: attempt 4 to read from /dev/sdd failed Dec 15 11:39:11 x usbmount[28617]: attempt 5 to read from /dev/sdd failed Dec 15 11:39:12 x usbmount[28617]: attempt 6 to read from /dev/sdd failed Dec 15 11:39:13 x usbmount[28617]: attempt 7 to read from /dev/sdd failed Dec 15 11:39:14 x usbmount[28617]: attempt 8 to read from /dev/sdd failed Dec 15 11:39:15 x usbmount[28617]: attempt 9 to read from /dev/sdd failed Dec 15 11:39:16 x usbmount[28617]: attempt 10 to read from /dev/sdd failed Dec 15 11:39:17 x usbmount[28617]: attempt 11 to read from /dev/sdd failed Dec 15 11:39:18 x usbmount[28617]: attempt 12 to read from /dev/sdd failed Dec 15 11:39:19 x usbmount[28617]: attempt 13 to read from /dev/sdd failed Dec 15 11:39:20 x usbmount[28617]: attempt 14 to read from /dev/sdd failed Dec 15 11:39:21 x usbmount[28617]: attempt 15 to read from /dev/sdd failed Dec 15 11:39:22 x usbmount[28617]: attempt 16 to read from /dev/sdd failed Dec 15 11:39:23 x usbmount[28617]: attempt 17 to read from /dev/sdd failed Dec 15 11:39:24 x usbmount[28617]: attempt 18 to read from /dev/sdd failed Dec 15 11:39:25 x usbmount[28617]: attempt 19 to read from /dev/sdd failed Dec 15 11:39:26 x usbmount[28617]: cannot read from /dev/sdd Dec 15 11:39:36 x usbmount[28748]: acquired lock /var/run/usbmount/.mount.lock Dec 15 11:39:36 x usbmount[28748]: testing whether /dev/sde1 is readable Dec 15 11:39:36 x usbmount[28748]: /dev/sde1 contains a filesystem or disklabel Dec 15 11:39:36 x usbmount[28748]: /dev/sde1 contains filesystem type vfat Dec 15 11:39:36 x usbmount[28748]: mountpoint /media/usb0 is available for /dev/sde1 Dec 15 11:39:36 x usbmount[28748]: executing command: mount -tvfat -onoexec,nodev,noatime,gid=windows,umask=002 /dev/sde1 /media/usb0 Dec 15 11:39:36 x usbmount[28748]: executing command: run-parts /etc/usbmount/mount.d
Bug#398884: jigdo-file: hangs during package scan and consumes 100% of CPU
Hi Baurzhan, On Thu, Nov 16, 2006 at 09:31:28AM +0100, Baurzhan Ismagulov wrote: Images offered by `debian-testing-i386-binary-3.jigdo': 1: 'Debian GNU/Linux testing Etch - Official Snapshot i386 Binary-3' (debian-testing-i386-binary-3.iso) Further information about `debian-testing-i386-binary-3.iso': Generated on Fri, 10 Nov 2006 11:10:04 +0100 Path to scan: /mnt/tmp Not downloading .template file - `debian-testing-i386-binary-3.template' already present 100% 38416k/38416k scanning `.../1/pool/main/v/vtk/vtk-doc_5.0.1-4_all.deb' Please let me know if I can help, e.g., through enabling debugging, etc.? The people are waiting for the RC1 ;) . For now, I skip scanning. Please add a --debug=all switch to the jigdo-file invocations inside jigdo-lite. The easiest way to do this is to add the following to jigdoOpts in your ~/.jigdo-lite: --debug=all 2~/jigdo.log This might create quite a lot of debug output. Then please compress the log file and mail it to me. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#398373: RC class bug, dataloss grade, No 398373
FWIW, I also experienced this when unmounting a USB stick using nautilus. Because I pulled out the USB stick too quickly, I ended up with a corrupted filesystem. :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯
Bug#398884: jigdo-file: hangs during package scan and consumes 100% of CPU
On Tue, Nov 28, 2006 at 02:09:09PM +0100, Baurzhan Ismagulov wrote: jigdoOpts='--cache jigdo-file-cache.db --debug=all 2~/jigdo.log' Jigdo-lite complained: Skipping object `2~/jigdo.log' (No such file or directory) Hm, strange. :-/ So I removed the redirection part and redirected the jigdo-lite output. Attached is the log file, however, I'm not sure this is what you want. Unfortunately this doesn't contain any of the debug info, so no, not useful. ;-/ Another try: Run jigdo-lite as usual until the point where it hangs. Then, find out the exact jigdo-_file_ command line of the hanging process, e.g. with: ps aux | grep jigdo-file Interrupt jigdo-lite and run that jigdo-file command directly from the command line. Add the --debug=all switch and 2~/jigdo.log as before. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#288615: Issue with language negotiation exceptions [kind-of patch]
Hi, just stopping by here on my search for a different bug... As I read the docs (exactly the bit you quoted in the bug report!), Apache is behaving as described. However, its behaviour could be improved to be a bit more useful. To the bug submitter: The only solution that I see for you ATM is to create symlinks for all language subsets that are important to you. For example, create a symlink called index.fr-fr.html which points to index.fr.html. To the maintainers: The browser requests the languages fr-fr,en-us;q=0.3, which is broken behaviour anyway as far as the HTTP standard is concerned; fr and en;q=0.3 ought to be added. When Apache sees that Accept-Language header, it cannot match it against the, say, index.en.html and index.fr.html files on disc. So the second part of the paragraph quoted in the bug report applies: The above list of language preferences is turned into fr-fr,en-us;q=0.3,fr;q=0.001,en;q=0.001 The order in this list does not matter, only the weight of each variant. So - oops: Suddenly fr and en have equal priority! :-( At this point, the two available variants are in every practical aspect equally well-suited. Now the algorithm described on http://httpd.apache.org/docs/2.2/content-negotiation.html#algorithm will try to select one variant just to create a predictable, reproducible response. In our case, en sorts earlier alphabetically than fr, so en is served. The solution to this is: Do not use a quality value of 0.001 when adding the non-subset languages, but multiply the (implicit) 1.0 of fr-fr and the 0.3 of en-us with 0.001. Disclaimer: I'm not an Apache hacker, but having looked at the source for 10 minutes, it appears the change would be inside set_language_quality() in modules/mappers/mod_negotiation.c. Instead of the line fiddle_q = 0.001f; you'd want something similar to fiddle_q = 0.001f * accs[i].quality; (completely untested) Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#400023: PDF causes gv to consume all available memory, machine swaps madly
Package: gv Version: 1:3.6.2-2 Severity: normal Hello, when opening the attached PDF in xpdf or acroread, an empty page is displayed. When opening it in gv, it seems like all memory is consumed; the machine stops responding and I can see that the HD is busy all the time. My interpretation is that it's swapping madly, but I have no proof. If I interrupt gv early enough, I can still recover, but on one occasion I just did a hard reset after waiting for 10 minutes. IIRC the file was created by inkscape's PDF export, but I'm not entirely sure. (It may also have been OpenOffice.) Cheers, Richard -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages gv depends on: ii gs-esp [gs] 8.15.3.dfsg.1-1 The Ghostscript PostScript interpr ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libsm6 1:1.0.1-3 X11 Session Management library ii libx11-6 2:1.0.3-3 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library ii libxpm4 1:3.5.5-2 X11 pixmap library ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii xaw3dg 1.5+E-14Xaw3d widget set gv recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400030: PDF causes gv to consume all available memory, machine swaps madly
Package: gv Version: 1:3.6.2-2 Severity: normal Hello, when opening the attached PDF in xpdf or acroread, an empty page is displayed. When opening it in gv, it seems like all memory is consumed; the machine stops responding and I can see that the HD is busy all the time. My interpretation is that it's swapping madly, but I have no proof. If I interrupt gv early enough, I can still recover, but on one occasion I just did a hard reset after waiting for 10 minutes. IIRC the file was created by inkscape's PDF export, but I'm not entirely sure. (It may also have been OpenOffice.) Cheers, Richard -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages gv depends on: ii gs-esp [gs] 8.15.3.dfsg.1-1 The Ghostscript PostScript interpr ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libsm6 1:1.0.1-3 X11 Session Management library ii libx11-6 2:1.0.3-3 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library ii libxpm4 1:3.5.5-2 X11 pixmap library ii libxt6 1:1.0.2-2 X11 toolkit intrinsics library ii xaw3dg 1.5+E-14Xaw3d widget set gv recommends no packages. -- no debconf information kill-gv.pdf Description: Adobe PDF document
Bug#400023: Acknowledgement (PDF causes gv to consume all available memory, machine swaps madly)
Um, how come reportbug didn't send the attachment even though I told it to?! Anyway, here is the problematic file! Cheers, Richard kill-gv.pdf Description: Adobe PDF document
Bug#398653: clock-applet crashes when trying to run evolution which is not installed
Package: gnome-panel Version: 2.14.3-2 Severity: minor Hi, if I open the mini calendar view by single-clicking on the clock applet, and then double click on a particular day, then clock-applet freezes and crashes. I've verified that this is due to the fact that evolution is not installed; if I install evolution, everything works as expected. clock-applet should not crash in this case, it should pop up an error message which tells me to install evolution. Cheers, Richard -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.9 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) Versions of packages gnome-panel depends on: ii gnome-about2.14.3-1 The GNOME about box ii gnome-control-center 1:2.14.2-3+b1 utilities to configure the GNOME d ii gnome-desktop-data 2.14.3-1 Common files for GNOME 2 desktop a ii gnome-menus2.16.0-2 an implementation of the freedeskt ii gnome-panel-data 2.14.3-2 common files for GNOME 2 panel ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.12.3-1 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-2 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-5 The Bonobo UI library ii libc6 2.3.6.ds1-7 GNU C Library: Shared libraries ii libcairo2 1.2.4-4 The Cairo 2D vector graphics libra ii libecal1.2-6 1.6.3-2 Client library for evolution calen ii libedataserver1.2-71.6.3-2 Utility library for evolution data ii libedataserverui1.2-6 1.6.3-2 GUI utility library for evolution ii libgconf2-42.16.0-2 GNOME configuration database syste ii libglade2-01:2.6.0-2 library to load .glade files at ru ii libglib2.0-0 2.12.4-1 The GLib library of C routines ii libgnome-desktop-2 2.14.3-1 Utility library for loading .deskt ii libgnome-menu2 2.16.0-2 an implementation of the freedeskt ii libgnome2-02.16.0-2 The GNOME 2 library - runtime file ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.2-2+b1 GNOME virtual file-system (runtime ii libgtk2.0-02.8.20-3 The GTK+ graphical user interface ii liborbit2 1:2.14.3-0.1 libraries for ORBit2 - a CORBA ORB ii libpanel-applet2-0 2.14.3-2 library for GNOME 2 panel applets ii libpango1.0-0 1.14.7-1 Layout and rendering of internatio ii libwnck18 2.14.3-1 Window Navigator Construction Kit ii libx11-6 2:1.0.3-2 X11 client-side library ii libxau61:1.0.1-2 X11 authorisation library ii menu-xdg 0.2.3 freedesktop.org menu compliant win Versions of packages gnome-panel recommends: ii evolution-data-server1.6.3-2 evolution database backend server ii gnome-applets2.14.3-1+b1 Various applets for GNOME 2 panel ii gnome-session2.14.3-3The GNOME 2 Session Manager -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392886: Does not show .jpeg images in file dialog, only .jpg
Package: hugin Version: 0.6.1-1 Severity: minor Hi, the subject line already describes the whole problem: If I want to add JPEG files to a panorama, e.g. via the button Add individual images..., then the resulting file dialog does not allow me to open .jpeg images - I have to rename them to use a .jpg extension before they appear in the list of files, or select All files (*). While this is only a minor issue, it'd be nice if it could be fixed! Cheers, Richard -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17.9 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) Versions of packages hugin depends on: ii hugin-bin 0.6.1-1hugin binaries ii hugin-tools 0.6.1-1some tools for hugin ii libpano12-bin 2.8.3-1panorama tools utilities hugin recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390204: tesseract-ocr
Hi, I just compiled v1.02 using GCC 4.1.2 without problems. The Aspirin code seems to be gone in this release, and the README contains a note that it is not needed. This seems like a nice enough program! In a quick test using a warped, underexposed picture from a digital camera, it didn't really produce usable results, but with a dictionary and better input it might work well! Big problem for me: It does not understand German umlauts yet. Hint: To produce a .tif which the program can understand, use something like convert -compress none -monochrome -density 150x150 inputfile.jpeg output.tif I might package this if nobody else is interested. However, I'll gladly step back if someone else wants to do it, as I have little spare time. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#386962: misc improvements
On Mon, Sep 11, 2006 at 12:54:53PM +0200, Marco d'Itri wrote: The correct way to detect udev is test -e /dev/.udev, there is no reason to provide a know to override this check. OK, thanks - I wasn't sure how to detect udev, so I added the config option to disable it in case I messed up. I think you should not ask the user if the devices should be created, most packages don't (and over 75% of Debian users already use udev anyway). Yeah - this used to be required by policy, so I added the question, even though I also thought it wasn't necessary. References to devfs should be removed since it's not supported anymore. Right. README.Debian should be updated since modern kernels support packet writing and UDF out of the box. OK. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#384042: svn list file:///repo/no-longer-existing-dir does not work
Package: subversion Version: 1.3.2-5 Severity: minor Hello, If I have a repository at /tmp/repo, then listing its complete contents at any point in time is possible via svn list -R file:///repo. However, if I only want to list the contents of /dir inside the repository with svn list file:///repo/dir, I run into trouble if /dir no longer exists ***in the most recent revision***. Specifying an earlier revision using the -r switch does not change this. Here is a complete example (Output of uninteresting commands not included): $ svnadmin create /tmp/repo $ svn co file:///tmp/repo/ /tmp/checkout $ cd /tmp/checkout $ mkdir a $ date a/x $ svn add a $ svn ci -m a Adding a Adding a/x Transmitting file data . Committed revision 1. $ svn mv a b $ svn ci -m Deleting a Adding b Committed revision 2. $ svn list -r 1 -R file:///tmp/repo/ a/ a/x $ svn list -r 1 -R file:///tmp/repo/a svn: File not found: revision 2, path '/a' IMHO the last command should work, it should output a single line saying x. The error message File not found: revision 2, path '/a' is weird, as I'm explicitly telling it to look at revision 1, not 2. For the current revision, everything works as expected: $ svn list -r 2 -R file:///tmp/repo/b x FWIW, svnlook tree -r1 /tmp/repo /a works just fine. Cheers, Richard -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.20 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages subversion depends on: ii libapr0 2.0.55-4 the Apache Portable Runtime ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libsvn0 1.3.2-5Shared libraries used by Subversio subversion recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384042: svn list file:///repo/no-longer-existing-dir does not work
On Mon, Aug 21, 2006 at 01:58:24PM -0500, Peter Samuelson wrote: I'll check with upstream to see if that's intentional. Other than that, can I close this bug? I understand that the behavior is not obvious, but it _is_ intentional. Yes, please close the bug, and many thanks for the explanation! Despite having read most of the svnbook, I hadn't heard of peg revisions. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#362962: Please document that nm-applet needs the notification area applet to appear on the panel
On Mon, Jun 19, 2006 at 06:23:14PM +0200, Michael Biebl wrote: First of all, the notification area applet is added to the gnome panel by default. So this shouldn't be a problem at all. For people that remove the notification area applet from the gnome-panel, I assume they know what they are doing. I have been upgrading from older Gnome versions for many years, always taking my old panel with me. This way, I somehow seem to have missed the notification area so far. Second, the description of network-manager-gnome says, that it is a notification area applet. Hm, it says notification applet, which to my uneducated mind ;) sounded just like an applet which notifies you of events - and when I hear applet in conjunction with Gnome, I think of regular Gnome panel applets. Maybe you could change it into applet for the notification area of your desktop environment? That would have given me enough of a clue. Fifth, there are many other programs, that use a systray icon. Should they all contain documentation about how to enable the systray dock of their desktop environment of choice. I don't think so. No, they shouldn't, you're right. But maybe it should be made clearer that this applet package with a *-gnome name is not a panel applet. I'm intended to close this bug, but first want to hear your comment. Fair enough, it's your choice. Thanks for your work! Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#362962: Please document that nm-applet needs the notification area applet to appear on the panel
reopen 362962
retitle 362962 Please document that nm-applet needs the notification area
applet to appear on the panel [was: Networkmanager is not present in the
gnome-panel applets listing]
thanks
Hello,
it took 15 minutes of head-scratching, running nm-applet manually, reading
manpages etc. before I figured out that you have to add the notification
area applet to the panel to see the NetworkManager icon.
Please make this clearer in the documentation! It'd be great if you could
add it in several places:
- Put it in the package description. For example:
Note: The Notification Area applet must be running for
the NetworkManager icon to appear on your panel.
- Put it in the nm-applet manpage more clearly - state that you have to
add the notification area applet to the panel. The manpage talks about
a notify-area, but I had no idea so far what that area is, and whether
it was already existent on my desktop.
- Put it in the README.Debian for both network-manager{-gnome,}
The manpage points the user to
/usr/share/doc/network-manager/README.Debian for the information on how
to add nm-applet in your gnome notify-area, but that file doesn't
discuss installing the applet at all.
Thanks for the great work!
Cheers,
Richard
--
__ _
|_) /| Richard Atterer
| \/¯| http://atterer.net
¯ '` ¯
Bug#372093: udftools: cdrwtool [manual] Mention default settings and clarify options -l
Thanks for the suggestions! On Thu, Jun 08, 2006 at 11:54:13AM +0300, Jari Aalto wrote: The description of option -l needs clarification. I'm unable to grasp (as non-english speaking), which values are attached to which types of sessions. Something like this would be more clear: -l type Set multi-session field to 0, 1 or 3. Value 0 corresponds to ... Value 1 corresponds to ... Don't forget to mention the (default) values to each option. Can you give this information to me? I'll gladly include it in the manpage if you do. Unfortunately, I don't know the details either. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#351865: Allow any user to unmount automounted devices
Hi, it turns out that newer versions of umount no longer allow the symlink trick which my patch used to avoid having to make modifications to /etc/fstab. I'll see if I can come up with a new patch, it will probably modify /etc/fstab unless I can find another way... :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#368372: gnome-display-properties fails to alter desktop/display resolution
Package: gnome-control-center Version: 1:2.12.3-2 Severity: normal Hello, I have 3 display resolutions set in my X configuration. I can switch between these using keypad +/-, but if I do that, the virtual desktop size does not change, i.e. if I choose a low-res mode, the viewport scrolls. I can successfully switch between my modes using the xrandr command from xbase-clients 6.9.0.dfsg.1-6 (using xrandr -s 0 to xrandr -s 2) - in this case, the screen resolution changes *and* the Gnome desktop adjusts accordingly. However, if I run gnome-display-properties, choosing a new mode does not have any effect. The moment I click on Apply to switch to another resolution, the following is output on the terminal I started it from, and gnome-display-properties exits. $ gnome-display-properties The program 'gnome-display-properties' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 3061 error_code 2 request_code 156 minor_code 2) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Maybe the X API for xrandr has changed?? All the best, Richard -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16.11 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) Versions of packages gnome-control-center depends on: ii capplets-data 1:2.12.3-2 configuration applets for GNOME 2 ii desktop-file-utils0.10-1 Utilities for .desktop files ii gnome-desktop-data2.14.1.1-1 Common files for GNOME 2 desktop a ii gnome-icon-theme 2.14.2-1 GNOME Desktop icon theme ii gnome-menus 2.14.0-1 an implementation of the freedeskt ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-0 1.11.4-2 The ATK accessibility toolkit ii libaudiofile0 0.2.6-6Open-source version of SGI's audio ii libavahi-client3 0.6.9-8Avahi client library ii libavahi-common3 0.6.9-8Avahi common library ii libavahi-compat-howl0 0.6.9-8Avahi Howl compatibility library ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libbonoboui2-02.14.0-2 The Bonobo UI library ii libc6 2.3.6-7GNU C Library: Shared libraries ii libcairo2 1.0.4-2The Cairo 2D vector graphics libra ii libdbus-1-2 0.61-5 simple interprocess messaging syst ii libebook1.2-5 1.4.2.1-2 Client library for evolution addre ii libesd0 0.2.36-3 Enlightened Sound Daemon - Shared ii libfontconfig12.3.2-5.1 generic font configuration library ii libfreetype6 2.1.10-3 FreeType 2 font engine, shared lib ii libgamin0 [libfam0] 0.1.7-3Client library for the gamin file ii libgconf2-4 2.14.0-1 GNOME configuration database syste ii libgcrypt11 1.2.2-1LGPL Crypto library - runtime libr ii libglade2-0 1:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.10.2-1 The GLib library of C routines ii libgnome-desktop-22.14.1.1-1 Utility library for loading .deskt ii libgnome-keyring0 0.4.9-1GNOME keyring services library ii libgnome-menu22.14.0-1 an implementation of the freedeskt ii libgnome2-0 2.14.1-1 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeui-0 2.14.1-1 The GNOME 2 libraries (User Interf ii libgnomevfs2-02.14.0-2 GNOME virtual file-system (runtime ii libgnutls11 1.0.16-14+b1 GNU TLS library - runtime library ii libgpg-error0 1.2-1 library for common error values an ii libgstreamer-plugins0.8-0 0.8.12-1 Various GStreamer libraries and li ii libgstreamer0.8-0 0.8.12-1 Core GStreamer libraries, plugins, ii libgtk2.0-0 2.8.16-1 The GTK+ graphical user interface ii libice6 6.9.0.dfsg.1-6 Inter-Client Exchange library ii libjpeg62 6b-12 The Independent JPEG Group's JPEG ii libmetacity0 1:2.14.1-2 library of lightweight GTK2 based ii libnautilus-extension12.12.2-2 libraries for nautilus components ii liborbit2
Bug#342973: Package explicitely build-depends on g++-3.4
On Sat, May 13, 2006 at 12:16:57AM +0200, Martin Michlmayr wrote: This bug explicitly build-depends on g++ 3.4 on arm, hppa and m68k because of a bug that has been fixed a long time ago. This bug asking you to move to gcc 4.x has been open for about 150 now days without any answer from you. Do you think you will make an upload soon, moving to 4.x on all platforms (i.e. dropping the explicit build-depends on 3.4) or can we do an NMU? Oh, sorry - somehow, I forgot about this bug. :-| I'll make an upload in the next few days, please don't NMU yet. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#364309: www.debian.org: Languages names have inconsistent capitalization
On Sat, Apr 22, 2006 at 01:17:27PM -0300, Damián Viano wrote: It would be nice if this gets consistent. As I understand it, the capitalization is the correct one when writing the language name in that particular language. In some languages, language names are always spelled with a capital initial letter, in others lowercase. So IMHO it makes sense and shouldn't change. Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯
Bug#360527: udftools: serious lack of documentation
Hello Mau, I don't use udftools myself. I'm always open for suggestions on how to improve its documentation, but I need other people's help for this. The following recipe is from the German c't magazine (8/2006,p.122) and is advertised as the right way to do it for DVD-RAM. If this works for you (possibly adjusted for DVD-RW), I can include it in the package's README.Debian. Format the DVD with: mkudffs --udfrev=0x0150 --spartable=2 --media-type=dvdram /dev/pktcdvd/0 The above is for UDF 1.50, use --udfrev=0x0201 for UDF 2.01. The version decision has mostly to do with compatibility: - Windows 98/ME can read up to v1.02 - Win2k, Mac OS 9, Linux 2.4 can read up to v1.50 - Win XP/2003 up to v2.01 - Linux 2.6 up to v2.60 For normal data, UDF 1.50 is OK. UDF 2.00 and 2.01 introduce additional functionality for streaming audio/video media. To mount the disk, something like this is needed in /etc/fstab: /dev/pktcdvd/0 /media/dvd-ram udfnoatime,rw,sync,user,noauto 0 0 Hope this helps - please give me feedback if you try it out! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#359698: pgp-clean: Allow export of subkeys
Package: signing-party Version: 0.4.5-1 Severity: wishlist Hello, at present, keys exported with pgp-clean cannot be used for encryption because the tool does not export the subkeys associated with a key. It would be nice if pgp-clean supported an option to leave the subkeys in the exported data. Cheers, Richard -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15.3 Locale: LANG=en_US.UTF-8, LC_CTYPE=de_DE (charmap=ISO-8859-1) Versions of packages signing-party depends on: ii gnupg1.4.2.2-1 GNU privacy guard - a free PGP rep ii libgnupg-interfa 0.33-5 Perl interface to GnuPG ii libmailtools-per 1.74-0.1Manipulate email in perl programs ii libmime-perl 5.419-1 Perl5 modules for MIME-compliant m ii libtext-template 1.44-1.1Text::Template perl module ii mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent Versions of packages signing-party recommends: ii dialog1.0-20060221-1 Displays user-friendly dialog boxe ii libintl-perl 1.16-1 Uniforum message translations syst ii libpaper-utils1.1.14-5 Library for handling paper charact ii libtext-iconv-perl1.4-2 converts between character sets in ii postfix [mail-transport-a 2.2.9-1A high-performance mail transport ii recode3.6-12 Character set conversion utility ii whiptail 0.51.6-31 Displays user-friendly dialog boxe -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#357274: www.debian.org: please publish Mirror.masterlist
On Thu, Mar 16, 2006 at 03:32:41PM +0100, Filippo Giunchedi wrote: I'm in the process of adapting netselect to the archive split, thus having Mirrors.masterlist available on the web without and html would be of great help FWIW, it is available under the following URL: http://cvs.debian.org/*checkout*/webwml/english/mirror/Mirrors.masterlist?root=webwml Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯
Bug#306210: acknowledged by developer (libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries))
On Sat, Feb 25, 2006 at 01:04:32AM +1030, Ron wrote: Would you like to hear the most amusing irony about this that I've seen to date? While poking about to fix some different problems, I just happened to notice that upstream DID apply your patch to the current release. Whoa, interesting! I tested your mingw32 3.4.5.20060117.1-1 package without success - was this built using the current release you refer to?? If yes, I will have to check once more where the problem is. I guess you should update the other reports to concur that it in fact does not work for you either... ;-) My patch works with mingw32 3.4.2.20040916.1-2 - does the timestamp in the version number refer to the GCC release? A lot can happen in 1.5 years. :-| Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#306210: acknowledged by developer (libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries))
reopen 306210 thanks On Fri, Feb 03, 2006 at 07:48:53AM -0800, Debian Bug Tracking System wrote: I'm going to tentatively close this bug in the belief that it is fixed in the current unstable packages. I'm sorry, I've just tested it and it still doesn't work. :-/ I compiled my example program using mingw 3.4.5.20060117.1-1, mingw32-binutils 2.16.91-20060119.1-1 and mingw32-runtime 3.9-3, then ran it on an NTFS partition on a Windows XP system. The program wrote 4294963200 bytes of data (that's 0xF000), then exited with: -1 strerror: no space left on device Did you actually apply my patch? Unfortunately, upstream seems to ignore my bug report (no followups on http://sourceforge.net/tracker/index.php?func=detailaid=1235337group_id=2435atid=102435), maybe you could prod them about it? BTW, this bug should probably be reassigned to mingw and not libstdc++, because according to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22388#c3 the respective bug is in mingw-specific modifications to the standard libstdc++. The test case you posted, when run under wine, writes out a file of 4294971402 bytes -- and though the output there is still not correct I don't think wine is a good test platform for this kind of thing. :-/ Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: 0x888354F7 | \/¯| http://atterer.net | 08A9 7B7D 3D13 3EF2 3D25 D157 79E6 F6DC 8883 54F7 ¯ '` ¯
Bug#351859: vfat + sync option seriously hurts write performance of USB sticks - please document
Package: usbmount Version: 0.0.14 Severity: wishlist This bug is related to #337483. However, there is no immediate solution to that bug's problem. Meanwhile, please document the fact that using the sync option makes writing to flash devices much slower with vfat! For quite a while, I actually thought that my USB stick was broken... in my case (USB 2.0 stick), I get 30kB/sec with the sync option, and 7MB/sec without it! Consider adding notes both to /usr/share/doc/usbmount/README and /etc/usbmount/usbmount.conf Many thanks! Richard -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) Versions of packages usbmount depends on: ii lockfile-progs0.1.10 Programs for locking and unlocking ii udev 0.081-1/dev/ and hotplug management daemo usbmount recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#351865: Allow any user to unmount automounted devices [patch]
Package: usbmount
Version: 0.0.14
Severity: wishlist
Tags: patch
Hello,
here is a patch for /usr/share/usbmount/usbmount which allows _any_
user to unmount a device which was mounted automatically by usbmount.
This is great for USB sticks which are formatted as vfat and which you
do not want to mount with the sync option due to the resulting
horrible write performance.
You can safely use such USB sticks without sync if you always
remember to unmount the device. With this patch, unmounting becomes
very easy - for example, it can be done in a convenient way using
Nautilus on the Gnome desktop.
The idea is: Add to /etc/fstab entries of this form:
/var/run/usbmount/dev-media-usb0 /media/usb0 auto users,noauto 0 0
/var/run/usbmount/dev-media-usb1 /media/usb1 auto users,noauto 0 0
Note how each device is the string /var/run/usbmount/dev, followed
by the mount point name (with / replaced by -).
Next, have usbmount create symbolic links to the actual devices. For
example, when mounting /dev/hdb4 on /media/usb0, first create a symlink
/var/run/usbmount/dev-media-usb0 - /dev/hdb4
and then mount /var/run/usbmount/dev-media-usb0 on /media/usb0.
The symlink trick has the advantage that /etc/fstab does not need to be
changed dynamically whenever a device is plugged in. Due to the users
option in the fstab line, any user is allowed to unmount the device.
The filesystem type (auto in the two lines above) is ignored by
umount AFAICT, so it need not be correct.
Another nice thing: The mount command actually notices that the mount
device is a symlink _and follows it_, so mtab will still show
/dev/hdb4 as the device instead of /var/run/usbmount/dev-media-usb0!
Cool!
IMHO this is a very useful feature - hopefully it'll make its way into
your package!
Cheers,
Richard
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15)
Versions of packages usbmount depends on:
ii lockfile-progs0.1.10 Programs for locking and unlocking
ii udev 0.081-1/dev/ and hotplug management daemo
usbmount recommends no packages.
-- no debconf information
--- usbmount2006-02-08 01:02:42.0 +0100
+++ /usr/share/usbmount/usbmount2006-02-08 01:22:40.0 +0100
@@ -117,9 +117,14 @@
options=$MOUNTOPTIONS${options:+,$options}
fi
+ # Create a symlink to the device and use that for mounting.
+ # This is necessary to allow any user to unmount the device.
+ devlink=/var/run/usbmount/dev`echo $mountpoint | sed s%/%-%g`
+ ln -sf $DEVNAME $devlink
+
# Mount the filesystem.
- log info executing command: mount -t$fstype
${options:+-o$options} $DEVNAME $mountpoint
- mount -t$fstype ${options:+-o$options} $DEVNAME
$mountpoint
+ log info executing command: mount -t$fstype
${options:+-o$options} $devlink $mountpoint
+ mount -t$fstype ${options:+-o$options} $devlink
$mountpoint
# Determine vendor and model.
vendor=
@@ -147,6 +152,7 @@
# Run hook scripts; ignore errors.
export UM_DEVICE=$DEVNAME
+ export UM_DEVLINK=$devlink
export UM_MOUNTPOINT=$mountpoint
export UM_FILESYSTEM=$fstype
export UM_MOUNTOPTIONS=$options
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#342973: Package explicitely build-depends on g++-3.4
On Mon, Dec 12, 2005 at 12:54:36AM +0100, Matthias Klose wrote: This package build-depends for some reason on g++-3.4 (most likely, because it could not be built with a newer g++ version. Actually, I added the build-dep because at the time, GCC 3.3 was still the default gcc for some arches, but jigdo needed 3.4. It should build fine using the latest gcc, so I'll use that for the next upload. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#340913: Please blacklist Google Analytics
Package: privoxy Version: 3.0.3-4 Severity: wishlist Hello, Google Analytics looks like a pretty scary approach to cross-site user tracking - see http://www.google.com/analytics/. Please blacklist the following address in the default privoxy installation: http://www.google-analytics.com/urchin.js Cheers, Richard -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
On Tue, Oct 11, 2005 at 01:13:53AM +0930, Ron wrote: Could you confirm if this is still a problem with the current release or not? Yes - unfortunately it is! The program I posted earlier in this bug writes just a little less than 4GB of data into the file (on NTFS), then fails with No space left on device. I cross-compiled this program today in a freshly updated sid chroot. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#332130: udftools depends on debconf without | debconf-2.0 alternate; blocks cdebconf transition
On Tue, Oct 04, 2005 at 11:47:13PM +, Joey Hess wrote: This package depends/pre-depends on debconf without allowing the dependency to be satisfied with an alternate of debconf-2.0. That is to say, its dependency should read: debconf | debconf-2.0 I uploaded a fixed package (1.0.0b3-11) the day before yesterday, which AFAICT correctly declares the dependency. Please close this bug if you agree. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#325643: libcurl and moc
FWIW, I've started work on implementing the solution outlined in http://curl.haxx.se/legal/distro-dilemma.html. However, my spare time is very limited, so I can't promise anything about when (or even whether) I can finish this. Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Bug#325643: libcurl and moc
On Fri, Sep 02, 2005 at 04:04:27AM -0700, Steve Langasek wrote: But no one has yet answered my question: *why* are there ABI differences between the gnutls and openssl builds? To the best of my knowledge (I could be wrong), ATM the only ABI difference is that when OpenSSL is used, curl_easy_setopt(handle, CURLOPT_SSL_CTX_FUNCTION, param) is supported. That CURLOPT_SSL_CTX_FUNCTION code cannot be supported if GnuTLS is used because GnuTLS does not offer comparable functionality. param above is a pointer to an OpenSSL SSL_CTX struct. According to the curl_easy_setopt manpage: This function gets called by libcurl just before the initialization of an SSL connection after having processed all other SSL related options to give a last chance to an application to modify the behaviour of openssl's ssl initialization. IMHO this incompatibility is quite minor - very few programs will actually register that callback. However, Daniel (curl upstream) believes it possible that future versions of the library will provide other SSL-related hooks of this sort. On Sat, Sep 03, 2005 at 12:47:06AM +1000, Paul TBBle Hampson wrote: If I've understood correctly, it is because curl expects the client program or library to -lgnutls or -lopenssl and therefore provide the SSL symbols to match the symbols which that build of the .so file is expecting. This is the point I move from suggesting things to spectating, 'cause I can't wrap my head above the reason for the above. No, you're mixing things up. I believe you're talking about what is described towards the end of http://curl.haxx.se/legal/distro-dilemma.html. Whenever libcurl switches to the described mechanism, then _at_that_moment_ it might be necessary to increase the .so version. That's because programs are then required to link explicitly against one of the SSL-enabling backend libs, called lib2 on the page above. You don't suddenly want your old libcurl3-using programs to fail with run-time link errors... HTH, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Bug#320163: jigdo: Short description too vague.
On Wed, Jul 27, 2005 at 02:05:40PM +0200, Sebastian Seifert wrote: I installed this in search for a general download manager. jigdo's short descriptions seems to imply generality, while it is only meant for the download of very specific things. Please change it to Download manager for jigdo CD images or likewise. Actually, the jigdo GUI *can* also download normal files via HTTP or FTP. I'm going to close this bug unless there's a problem with that functionality. Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#306210: LFS problems with mingw32 - solved! [patch]
Hi Ron, here is a patch which enables LFS support when cross-compiling libstdc++ for mingw32. The patch is fully tested and I have confirmed that it works! (Great, *finally* I no longer have to compile natively!!) IMHO this is a bug in libstdc++ - I've already reported it as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22388. Before GCC 3.4, LFS was not supported for mingw32. Starting with 3.4, it was, but the configuration that is used for cross-compiling libstdc++ (libstdc++-v3/crossconfig.m4) does _not_ enable LFS. The patch below enables it and re-runs autoconf. I guess the problem does not occur with upstream's package because they build everything natively under Windows, and in that case, libstdc++ runs some configure tests to determine whether LFS is present. It'd be great if you could apply this patch soon! Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯ diff --minimal --unified -urN debian.orig/control debian/control --- debian.orig/control 2005-07-09 17:47:49.0 +0200 +++ debian/control 2005-07-09 20:03:00.0 +0200 @@ -1,7 +1,7 @@ Source: mingw32 Section: devel Priority: optional -Build-Depends: mingw32-binutils, mingw32-runtime, debhelper (= 4.0), gettext, perl +Build-Depends: mingw32-binutils, mingw32-runtime, debhelper (= 4.0), gettext, perl, autoconf Maintainer: Ron Lee [EMAIL PROTECTED] Standards-Version: 3.6.1.1 diff --minimal --unified -urN debian.orig/patches/large-file-support.patch debian/patches/large-file-support.patch --- debian.orig/patches/large-file-support.patch1970-01-01 01:00:00.0 +0100 +++ debian/patches/large-file-support.patch 2005-07-09 19:59:35.0 +0200 @@ -0,0 +1,10 @@ +--- gcc-3.4.2-20040916-1/libstdc++-v3/crossconfig.m4.orig 2004-08-15 10:41:14.0 +0200 gcc-3.4.2-20040916-1/libstdc++-v3/crossconfig.m4 2005-07-09 19:53:15.0 +0200 +@@ -234,6 +234,7 @@ + GLIBCXX_CHECK_LINKER_FEATURES + GLIBCXX_CHECK_COMPLEX_MATH_SUPPORT + GLIBCXX_CHECK_WCHAR_T_SUPPORT ++AC_DEFINE(_GLIBCXX_USE_LFS) + ;; + *-netbsd*) + AC_CHECK_HEADERS([nan.h ieeefp.h endian.h sys/isa_defs.h \ diff --minimal --unified -urN debian.orig/rules debian/rules --- debian.orig/rules 2005-07-09 20:54:14.0 +0200 +++ debian/rules2005-07-09 20:54:06.0 +0200 @@ -105,6 +105,9 @@ patch -p0 $$p; \ done; + # Extra fixes + cd $(build_src)/gcc-3.4.2-20040916-1/libstdc++-v3 autoconf + touch $@
Bug#312906: BUG in 3.1r0a CD iso
On Sun, Jun 12, 2005 at 01:20:52PM +0100, [EMAIL PROTECTED] wrote: The problem has been found in all ISO CD images of i386 Debian 3.1 (and 3.1 r0a), provided by ftp.nl.debian.org and ftp2.fr.debian.org. (others haven't been tested). The problem is known, a note has been present on the release information page http://www.debian.org/CD/releases/ for a few days. I have just added an entry in the CD FAQ at http://www.debian.org/CD/faq/#debian31r0: toc-add-entry name=debian31r0I have downloaded/bought the 3.1 rev0 (or rev0a) images, but the disc's README says that this is an unofficial CD of the current development version!/toc-add-entry pThe README is wrong, in fact the images emare/em the official 3.1 rev0a images. Due to a mistake, the README information for an unofficial rather than an official image was used - sorry about the confusion! As this is considered to be a minor issue, it will only be fixed for the rev1 images, there will not be a 3.1 rev0b release./p Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯
Bug#310881: /usr/bin/jigdo-lite: jigdo-lite doesn't know copy:// urls
On Thu, May 26, 2005 at 07:40:05PM +0200, Goswin Brederlow wrote: deb copy:///mnt/mirror/ivanova/debian-amd64 testing main contrib Interesting - I hadn't heard of that! jigdo-file does understand file:// URLs, so I guess just replacing copy: with file: would work, right? Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://atterer.net ¯ '` ¯
Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
On Mon, Apr 25, 2005 at 11:30:05AM +0930, Ron wrote: Do we need to enable LFS explicitly somehow? To my knowledge, no. This was supposed to be fixed for all architectures with GCC 3.4 (there were other problems for GCC 3.0 to 3.3). I guess the relevant code in libstdc++ just #defines _FILE_OFFSET_BITS=64, things might go wrong if your glibc-cross headers somehow don't react to this. I don't see anything obvious in the information provided. Do you know what was 'fixed' in the msys release? No, sorry. :-| The problem was still there in their very first GCC 3.4 release candidate, but they fixed it after I contacted them. I'm currently waiting on a new binutils release to fix some known issues, if you can track down the cause of this, I can update likewise, but I don't have time to chase this myself in the immediate near future. OK. Are you going to ask upstream about this? Cheers, Richard -- __ _ |_) /| Richard Atterer | \/¯| http://geht.net.gibts.bei.atterer.net ¯ '` ¯
Bug#306210: libstdc++: Big file support not working with Debian mingw32 package (OK with upstream native binaries)
Package: mingw32
Version: 3.4.2.20040916.1-2
Severity: normal
Hi,
there is a problem with the binaries created by the cross-compiler; if
they use the standard C++ library to access big files, seeking beyond
4GB does not appear to work.
For a loong time, this was an upstream problem, but it was fixed with
mingw.org's 3.4.0 release. Unfortunately, it still happens with
binaries that I cross-compile from Debian. :-(
The small program below prints the correct value 63 when compiled
under Windows XP using mingw.org's binaries, but prints -1
strerror: no error (i.e. EOF) when cross-compiled.
Working configurations on Windows were all the post-3.4.0 ones that I
tried. Today, I specifically re-checked that the following results in
working binaries:
gcc-core-3.4.1-20040711-1.tar.gz
gcc-g++-3.4.1-20040711-1.tar.gz
w32api-2.5.tar.gz
mingw-runtime-3.3.tar.gz
gcc-core-3.4.2-20040916-1.tar.gz
gcc-g++-3.4.2-20040916-1.tar.gz
w32api-2.5.tar.gz (sorry, forgot upgrading that)
mingw-runtime-3.7.tar.gz
g++ -v prints this:
Reading specs from C:/msys/1.0/mingw/bin/../lib/gcc/mingw32/3.4.2/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry
--disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt
--without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
A fix for this would be very much appreciated!! - Compiling on Windows
with MSYS is such a PITA! :-/
--
#include fstream
#include iostream
#include string.h
using namespace std;
int main() {
fstream f(testfile, ios::binary|ios::in|ios::out|ios::trunc);
#ifdef __MINGW32__
unsigned long long left = 0x11000ULL;
char buf[4096];
memset(buf, 0, 4096);
f.write(buf, 4096);
f.write([EMAIL PROTECTED], 10); // 64 aka '@' at 0x1004
f.write(buf, 4096 - 10);
left -= 8192;
while (left 0) {
f.write(buf, 4096);
left -= 4096;
}
#else
f.seekp(0x11000ULL);
#endif
f.write(YADA?YADA!, 10);
f.seekg(0x11004ULL);
cout f.get() endl; // Should print 63 for the '?' at 0x11004
cout strerror: strerror(errno) endl;
}
--
-- System Information:
Debian Release: 3.1
APT prefers testing
APT policy: (990, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27
Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15)
Versions of packages mingw32 depends on:
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii mingw32-binutils2.15.94-20050118.1-1 Minimalist GNU win32 (cross) binut
ii mingw32-runtime 3.7-1Minimalist GNU win32 (cross) runti
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#303124: g++-2.95 spews out lots of warnings with glib header files
Package: libglib2.0-dev Version: 2.6.3-1 Severity: minor Hello, compiling glib applications with g++-2.95 is possible, but the compiler outputs a lot of warnings like this: /usr/include/glib-2.0/gobject/gtype.h:431: warning: `visibility' attribute directive ignored /usr/include/glib-2.0/gobject/gtype.h:432: warning: `visibility' attribute directive ignored /usr/include/glib-2.0/gobject/gtype.h:433: warning: `visibility' attribute directive ignored Apparently, this is caused by the G_GNUC_INTERNAL e.g. in gtype.h:431: voidg_value_c_init (void) G_GNUC_INTERNAL; /* sync with gvalue.c */ I used the following compiler switches: -Wall -W -Wpointer-arith -Wconversion -Woverloaded-virtual -O2 The headers should suppress these warnings if the detected compiler is gcc 2.95. Cheers, Richard -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (990, 'testing') Architecture: i386 (i686) Kernel: Linux 2.4.27 Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-15) Versions of packages libglib2.0-dev depends on: ii libc6-dev [libc-dev]2.3.2.ds1-20 GNU C Library: Development Librari ii libglib2.0-02.6.3-1 The GLib library of C routines ii pkg-config 0.15.0-4 Manage compile and link flags for -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
