Bug#875890: Please consider shipping /etc/apparmor.d/usr.sbin.mysqld from upstream
Hi there, If you look at message #30 attached to bug #875890 you'll see I have already documented exactly what the problem is, plus suggested a couple of solutions. Cheers, John Winters On 09/05/2021 01:02, Otto Kekäläinen wrote: Hello! Apparmor for MariaDB has not seen much progress lately. I would be happy to get contributions on this topic. If you want to help improve MariaDB in Debian in the open source way, you could for example: - submit your suggestion for a fix as a Merge Request at https://salsa.debian.org/mariadb-team/mariadb-10.5 - help with documentation/testing to improve our understanding on what exactly the bug is about - triage the other bugs filed against MariaDB in Debian so there is time freed up to work on this bug Thanks! -- Xronos Scheduler - https://xronos.uk/ All your school's schedule information in one place. Timetable, activities, homework, public events - the lot Live demo at https://schedulerdemo.xronos.uk/
Bug#875890: Further information
> Trying to reload apparmor policies did not help, it appears that > apparmor_parser ignores policies that are empty? A further data point on this - I have been struggling with much the same problem upgrading from Stretch + MySql to Buster + MariaDB. Despite having the supplied empty AppArmor profile file in place, MySql was unable to initialise its database files nor to run. Querying AppArmor with "sudo aa-status" indicated that the restrictions were still in place, although not apparently defined anywhere. It appears that AppArmor *caches* a binary version of each profile configuration file, and if its binary cache is newer than the text file then it assumes that it doesn't need to recompile, so you end up with an out-of-date configuration and MySql can't run. Two suggestions: 1) As part of the installation process, touch the supplied /etc/apparmor.d/usr.sbin.mysqld file so that it gets re-compiled. 2) Explicitly invoke apparmor_parser as part of the installation of the file, forcing it to be compiled. Cheers, John Winters -- Xronos Scheduler - https://xronos.uk/ All your school's schedule information in one place. Timetable, activities, homework, public events - the lot Live demo at https://schedulerdemo.xronos.uk/
Bug#869774: The fix in Jessie does not actually seem to fix the problem.
Running Debian Jessie with all the latest updates in place and Thunderbird still says it can't talk to Enigmail. Unable to access the Enigmail logs because the Enigmail menu item in Thunderbird does nothing. John
Bug#820026: icedove crashes suddenly
At the risk of adding little more than a me too... I too find that Icedove 4.5 just closes inexplicably several times an hour. I've struggled to find any particular way I can trigger it to happen, but without success. Generally one click on an e-mail to read it, and Icedove just shuts down. After re-starting, the same e-mail can be read without difficulty. Perhaps however these reports should be switched to a separate ticket, since they more than likely relate to a completely different problem. John signature.asc Description: OpenPGP digital signature
Bug#745206: Happens on most (but not all) CDs
I've been hitting this problem too - exactly the same symptoms. It doesn't happen on all CDs, but it seems to be predictable about which ones it will fail on. If a CD fails, it will fail every time you try to rip it, whilst if one succeeds, it succeeds a second time. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745206: Appears to be fixed in 3.12.0-1
I've just done some further testing. The same CDs which trigger the problem on a Wheezy system rip fine on a Jessie system running sound-juicer 3.12.0-1. Unfortunately, dependencies mean that this version of the package will not install cleanly on a Wheezy system. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748190: Gnome desktop lacks dependency on systemd-shim
A less drastic solution is to install systemd-shim. This should be a dependency somewhere in the Gnome packages, since without it Gnome lacks basic functionality - you can't shut your computer down. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746698: ruby-passenger-doc does not actually contain the documentation
Package: ruby-passenger-doc Version: 3.0.13debian-1+deb7u2 Severity: minor Dear Maintainer, The package ruby-passenger-doc currently in Wheezy does not actually contain the documentation which it purports to contain. There seems to have been a problem when building it, and each of the documentation files simply contains: Mizuho required to build docs The corresponding package for Wheezy does seem to contain the documentation. -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ruby-passenger-doc depends on no packages. ruby-passenger-doc recommends no packages. Versions of packages ruby-passenger-doc suggests: ii epiphany-browser [www-browser] 3.4.2-2.1 ii google-chrome-stable [www-browser] 34.0.1847.132-1 ii iceweasel [www-browser] 29.0-1~bpo70+1 ii links2 [www-browser]2.7-1+deb7u1 ii w3m [www-browser] 0.5.3-8 -- 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#746698: Slight correction
s/Wheezy/Jessie in the last line of the report. Documentation files missing content in the Wheezy version, but there in the Jessie version. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690856: Debian #690856 pgf: Trying to draw an arc causes latex to loop, using all CPU time of one core.
On Fri, 14 Mar 2014 11:44:10 +0100, Hilmar Preusse hill...@web.de wrote: Unreproducible w/ pgf in unstable. Can we close this bug? As I said when I submitted it, the bug was fixed in the Wheezy release so as Wheezy is now Stable it is probably time to close it. Cheers, John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741456: xen-utils-common: Starting domUs with xm fails - unable to find xenbr0. Works with xl.
Package: xen-utils-common Version: 4.3.0-3 Severity: normal Dear Maintainer, I've just set up a fresh Jessie system using the installer dated 2014-03-05, then installed and enabled Xen 4.3. I've done this quite a few times before using Wheezy and 4.1. I set up xenbr0, then created a test domU using xen-create-image, which completed without issue. However I was unable to start the new domU, getting the error message: Could not find bridge device bridge name xenbr0 xenbr0 is definitely there and working and responds to all the usual diagnostic tools. I notice that the xen installation still defaults to using xm, although the documentation says that it's deprecated. I therefore changed /etc/default/xen to specify a TOOLSTACK of xl and re-booted. The domU then started up without difficulty, confirming that xenbr0 is in fact there and working. Perhaps it's time to make xl the default? Is xm suffering from bit rot? John -- System Information: Debian Release: jessie/sid APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages xen-utils-common depends on: ii gawk1:4.0.1+dfsg-2.1 ii lsb-base4.1+Debian12 ii python 2.7.5-5 ii ucf 3.0027+nmu1 ii udev204-7 ii xenstore-utils 4.3.0-3+b1 xen-utils-common recommends no packages. xen-utils-common suggests no packages. -- Configuration Files: /etc/default/xendomains changed: XENDOMAINS_SAVE= XENDOMAINS_RESTORE=false XENDOMAINS_AUTO=/etc/xen/auto XENDOMAINS_STOP_MAXWAIT=300 /etc/xen/xend-config.sxp changed: (network-script 'network-bridge bridge=xenbr0') (vif-script vif-bridge) (dom0-min-mem 512) (enable-dom0-ballooning no) (total_available_memory 0) (dom0-cpus 0) (vncpasswd '') -- 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#714470: Problem still exists in 7.3.0 installer
I've just tried to re-install Debian on a NUC and encountered the same problem. IIRC, when I first installed it I used an image on CD and had no issues - the installation went smoothly and everything worked. I recently decided to upgrade the NUC to a 480G SSD, and went for a fresh installation using a thumb drive and initially the 7.1.0 installation image. The noticeable difference is that the installation process insists on creating an EFI boot partition, and you don't get the Install Grub to MBR? query. Instead a message flashes by mentioning something about dummy grub or null grub and then the installer says that installation is complete. The trouble is that it then doesn't boot. I tried downloading the latest installer image 7.3.0 but the problem was exactly the same. I then downloaded the latest netboot.tar.gz image and set up a network boot environment to do the installation. This worked fine. The installer did not insist on an EFI boot partition - indeed I let it choose everything and it went for a traditional layout. The Install Grub to MBR? prompt was back, and after the installation was complete the NUC booted without difficulty. It looks like the implementation of EFI booting isn't quite complete and/or correct, so the thumb drive installer probably shouldn't default to it. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652739: A (possibly) useful tip
Although old, this bug seems to be still extant in current versions (Wheezy) and in other distributions. Various workarounds are documented on the web, but not all work in all installations. For instance, if you're using Xen then you can't change the NIC type unless you have hardware virtualisation. After a bit of research, I found one workaround which should work anywhere, and is probably worth documenting in the same place as the bug is documented. On your client machine, set up a firewall rules as follows: iptables -A POSTROUTING -t mangle -p udp --dport 67 -j CHECKSUM --checksum-fill and on your server machine, do similarly with the following: iptables -A POSTROUTING -t mangle -p udp --sport 67 -j CHECKSUM --checksum-fill this will cause the firewall elves to fix the checksum which isc-dhcp-server/client has failed to put on the packets. Slightly incredible that it's the same piece of software failing at both ends. isc-dhcp fails to put a checksum on the packet, then refuses to process the packet because the checksum isn't there. Anyway, a bit of pragmatic help I hope. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670097: Extra data point
I still see this particular phenomenon, using gnome-shell 3.4.2-7. My X display still seems to be working fine, the mouse pointer moves around and if left alone the display blanks after the usual timeout, then comes back after I move the mouse. However no key presses or mouse clicks seem to register within the desktop. The one thing I can do is Ctrl-Alt-F1, to switch to a text terminal, log in again and do killall -HUP gnome-shell which causes gnome-shell to exit and re-start and all is going again. My extra data point is that this is often associated with a flurry (say up to a dozen) of notifications from nonsense users popping up at the bottom of the screen. People with names like squeezybuttocks...@hotmail.com wanting permission to know when I'm on line. These appear in a flurry immediately after I've re-started gnome-shell. Could there be some sort of cause and effect? I confess, I don't understand the mechanism by which they arise at all (I'm not a user of any social media sites). John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690856: pgf: Trying to draw an arc causes latex to loop, using all CPU time of one core.
Package: pgf
Version: 2.00-1
Severity: important
Trying to draw an arc in tikz seems to cause Latex to lock up every
single time. It consumes all of one CPU core and only stops when you
hit Ctrl-C.
The following complete source will demonstrate the problem:
\documentclass{article}
\usepackage{tikz}
\begin{document}
\begin{tikzpicture}
\draw (6, 3) arc [radius=3, start angle=-90, end angle=90];
\end{tikzpicture}
\end{document}
The various parameters to the \draw don't seem to matter much. I've
tried a few and haven't managed to find one which doesn't demonstrate
the problem.
I've tested this on both 32-bit and 64-bit Squeeze installations.
Both had the same problem.
I've also tried the same source on a Wheezy installation (and on Mac OS)
and didn't see the problem.
Since it seems to have been fixed in the Wheezy version, this report is
probably of no more than documentary interest, but I'm submitting it for
the record. Had it been here when I hit the problem I could have saved
myself quite a bit of time.
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages pgf depends on:
ii latex-xcolor2.11-1 Easy driver-independent TeX class
ii texlive-latex-recommend 2009-11+squeeze1 TeX Live: LaTeX recommended packag
pgf recommends no packages.
pgf 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#690367: hunspell: Latest version keeps gravitating to Finnish as a language.
Package: libhunspell-1.3-0 Version: 1.3.2-4 Severity: normal File: hunspell Dear Maintainer, Since the latest version of hunspell etc. arrived in Wheezy, all spell checking seems to default to Finnish as a language. This affects both Iceweasel and Icedove. I can set it back to English, but the next time I open a new page I'm on Finnish again. My default language is English English, rather than American English in case that makes any difference. Cheers, John -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.5.0-1-midnight (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libhunspell-1.3-0:amd64 depends on: ii libc6 2.13-35 ii libgcc11:4.7.1-7 ii libstdc++6 4.7.1-7 ii multiarch-support 2.13-35 Versions of packages libhunspell-1.3-0:amd64 recommends: ii hunspell-en-us [hunspell-dictionary] 20070829-6 ii hunspell-sv-se [hunspell-dictionary] 1.51-1 ii myspell-bg [myspell-dictionary] 4.1-3 ii myspell-ca [myspell-dictionary] 0.20111230b-4 ii myspell-cs [myspell-dictionary] 20040229-5.1 ii myspell-da [myspell-dictionary] 1.6.25-1.1 ii myspell-de-de [myspell-dictionary]20120607-1 ii myspell-en-gb [myspell-dictionary]1:3.3.0-4 ii myspell-eo [myspell-dictionary] 2.1.2000.02.25-45 ii myspell-es [myspell-dictionary] 1.11-4 ii myspell-et [myspell-dictionary] 1:20030606-20 ii myspell-fr [myspell-dictionary] 1.4-26 ii myspell-he [myspell-dictionary] 1.1-2 ii myspell-hu [myspell-dictionary] 1.2+repack-2 ii myspell-it [myspell-dictionary] 1:3.3.0-4 ii myspell-ku [myspell-dictionary] 0.20.0-2 ii myspell-lt [myspell-dictionary] 1.2.1-3 ii myspell-lv [myspell-dictionary] 0.9.4-5 ii myspell-nb [myspell-dictionary] 2.0.10-5.1 ii myspell-nl [myspell-dictionary] 1:2.10-1 ii myspell-nn [myspell-dictionary] 2.0.10-5.1 ii myspell-pl [myspell-dictionary] 20120520-1 ii myspell-pt-br [myspell-dictionary]20110527-2 ii myspell-pt-pt [myspell-dictionary]20091013-4 ii myspell-ru [myspell-dictionary] 0.99g5-18 ii myspell-sk [myspell-dictionary] 0.5.5a-2.3 ii myspell-sl [myspell-dictionary] 1.0-5 ii myspell-uk [myspell-dictionary] 1.6.5-2 libhunspell-1.3-0:amd64 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#690367: hunspell: Latest version keeps gravitating to Finnish as a language.
On 13/10/12 12:13, Rene Engelhard wrote: reassign 690367 iceweasel,icedove tag 690367 + moreinfo thanks On Sat, Oct 13, 2012 at 11:34:33AM +0100, John Winters wrote: Since the latest version of hunspell etc. arrived in Wheezy, all spell latest version of hunspell? Huh? [2011-10-18] hunspell 1.3.2-4 MIGRATED to testing (Britney) That is the latest version. Sorry, really. I don't believe that this bug was there 1 year and noone noticed. Did someone get out of bed on the wrong side this morning or are you always this scratchy? Could you actually take some minimal care when you report a bug? Yes, I always do. However with this sort of thing it's very difficult to decide which of a whole lot of packages is the relevant one. When the same update affects two different applications the chances are it's the common component. checking seems to default to Finnish as a language. This affects both Iceweasel and Icedove. Those probably got updates. Not hunspell. Unfortunately, it's very difficult to see after an update what got updated. Certainly both Iceweasel and Icedove *and lots of the components of the spell checker* got updated in the last week or so. Until one has worked out the exact cause of the bug, it makes sense to at least start off the bug report with the most generic component. Reassigning to them. You may well be correct in your re-assignment, but your people skills need work. That reminds me - I got flamed the last time I reported a bug in the spell checker. I eventually tracked it down and fixed it myself, and submitted the fix. Flaming users who don't have your intimate familiarity with the interworking of a lot of closely-working components is not however the best way to encourage this kind of assistance. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#686064: Missing file in Debian mirrors prevents debmirror working
Package: debmirror Version: 1:2.12~bpo60+1 Severity: important This probably isn't a bug in debmirror, but it prevents debmirror from working and I've hunted but can't find anywhere else to report it. Please re-direct appropriately if there is anywhere better for it. Currently the file: debian/dists/squeeze-updates/main/binary-armel/Packages.diff/Index contains a reference to a file: 2012-08-19-1411.58.gz but that file is missing from the directory. I've checked on both ftp.uk.debian.org and ftp.debian.org and neither has it. This causes debmirror to fail every time. (Actually, I'm not certain that it is the presence of the file in Index which causes it - but debmirror definitely tries to download it and fails because it isn't there.) All the similar files in the same directory fail their sha1sum checks when tested by debmirror and are ignored, but it's the missing one that stops debmirror working at all. Command used to invoke debmirror: /usr/bin/debmirror /mirror/debian \ --host=ftp.uk.debian.org \ --method=http \ --root=debian \ --dist=squeeze,squeeze-updates,wheezy \ --arch=i386,amd64,armel \ --i18n \ --nosource \ --verbose \ --ignore-release-gpg -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-5-kirkwood Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages debmirror depends on: ii bzip2 1.0.5-6+squeeze1 high-quality block-sorting file co pn libdigest-md5-perl none(no description available) ii liblockfile-simple-per 0.207-1 Simple advisory file locking ii libnet-inet6glue-perl 0.4-2 glue module to make perl modules I ii libwww-perl5.836-1 Perl HTTP/WWW client/server librar ii perl [libdigest-sha-pe 5.10.1-17squeeze3 Larry Wall's Practical Extraction ii perl-modules [libnet-p 5.10.1-17squeeze3 Core Perl modules ii rsync 3.0.7-2 fast remote file copy program (lik Versions of packages debmirror recommends: ii ed1.4-3 The classic UNIX line editor ii gpgv 1.4.10-4 GNU privacy guard - signature veri ii patch 2.6-2 Apply a diff file to an original Versions of packages debmirror suggests: ii gnupg 1.4.10-4 GNU privacy guard - a free PGP rep -- 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#619295: Also happens on the upgrade to 6.0.3
This problem hasn't manifested itself on any routine updates since the 6.0.2 upgrade, but now 6.0.3 has been released it's happening again. 100% occurrence so far. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#635689: virtualbox-ose: Virtualbox guest utils should be installed to match host version, not guest version.
Package: virtualbox-ose Version: 3.2.10-dfsg-1 Severity: wishlist If you use VirtualBox OSE on Debian, with different versions of Debian on the host and guest systems, then the wrong version of the VirtualBox guest modules gets installed. This happened before with Lenny on the host and Squeeze as the guest, and it's happening now with Squeeze as the host and Wheezy as the guest. The version of the guest utils installed on the Wheezy guest don't work with the version of VirtualBox OSE running on the host. At the very least, could alternative versions be made available in the Debian repository, so that one can manually install the right version on the quest with a simple apt-get install virtualbox-ose-guest-utils.version Ideally the wheezy repository should include suitable guest modules to allow a wheezy guest to run on a squeeze host, and so on. Even better would be if the right version were chosen at installation of the guest, but that's probably more complicated. Better still would be to provide reverse compatibility so newer guests will still work with older hosts, but that's probably an upstream issue. -- System Information: Debian Release: 6.0.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages virtualbox-ose depends on: ii adduser3.112+nmu2add and remove users and groups ii libc6 2.11.2-10 Embedded GNU C Library: Shared lib ii libcurl3 7.21.0-2 Multi-protocol file transfer libra ii libgcc11:4.4.5-8 GCC support library ii libpng12-0 1.2.44-1 PNG library - runtime ii libpython2.6 2.6.6-8+b1Shared Python runtime library (ver ii libsdl1.2debian1.2.14-6.1Simple DirectMedia Layer ii libssl0.9.80.9.8o-4squeeze1 SSL shared libraries ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libvncserver0 0.9.7-2+b1API to write one's own vnc server ii libx11-6 2:1.3.3-4 X11 client-side library ii libxcursor11:1.1.10-2X cursor management library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxml22.7.8.dfsg-2+squeeze1 GNOME XML library ii libxmu62:1.0.5-2 X11 miscellaneous utility library ii libxt6 1:1.0.7-1 X11 toolkit intrinsics library ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii python-central 0.6.16+nmu1 register and build utility for Pyt ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages virtualbox-ose recommends: ii libgl1-mesa-glx [libg 7.7.1-4A free implementation of the OpenG ii libqt4-opengl 4:4.6.3-4+squeeze1 Qt 4 OpenGL module ii libqtcore44:4.6.3-4+squeeze1 Qt 4 core module ii libqtgui4 4:4.6.3-4+squeeze1 Qt 4 GUI module ii virtualbox-ose-dkms 3.2.10-dfsg-1 x86 virtualization solution - kern ii virtualbox-ose-qt 3.2.10-dfsg-1 x86 virtualization solution - Qt b Versions of packages virtualbox-ose suggests: ii libasound2 1.0.23-2.1shared library for ALSA applicatio ii libpulse0 0.9.21-3+squeeze1 PulseAudio client libraries pn vde2 none(no description available) ii virtualbox-guest-addit 3.2.10-1 guest additions iso image for Virt -- 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#619295: Happens reliably on upgrade to 6.0.2
I've had this happen on both the systems which I've tried to upgrade to 6.0.2 using the Gnome update manager application. Both were up to date with security patches and both displayed the above symptoms as soon as update-manager-gnome attempted to do the 6.0.2 upgrade. Most of my systems are headless and upgraded fine with a simple apt-get upgrade. The two on which I had the problem also upgraded fine with this method once I'd killed the runaway process. In case it's relevant, both are amd64 systems. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619295: Happens on x86 too
I just remembered I had one other system with a GUI which hadn't been upgraded to 6.0.2. This one is x86. I started up the gnome update interface and sure enough, the update-manager took one core to full load and kept it there. I let it run for 5 minutes of CPU time before I killed it. There were 117 packages waiting to be updated, and an apt-get upgrade worked fine. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601830: -n1 workaround does seem effective.
After 4 days without lockups, it appears that the -n1 workaround is effective. Cheers, John -- Abingdon School: A company limited by guarantee Registered in England and Wales Company No. 3625063. Registered Office: Stratton House Bath Street Abingdon OX14 3LA Registered Charity No. 1071298. All information in this message and attachments is confidential and may be legally privileged. Only intended recipients are authorised to use it. E-mail transmissions are not guaranteed to be secure or error free and the sender does not accept liability for such errors or omissions. The company will not accept any liability in respect of such communication that violates our e-mail policy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601830: Bind9 freezing up
I'm getting the same problem with a completely default bind9 installation. It's acting purely as a recursive resolver for local processes on a lightly loaded machine. The machine is a dual CPU PowerPC G5 and it locks up about once a day. Stopping it by normal methods doesn't work and a kill -9 is needed. John -- Abingdon School: A company limited by guarantee Registered in England and Wales Company No. 3625063. Registered Office: Stratton House Bath Street Abingdon OX14 3LA Registered Charity No. 1071298. All information in this message and attachments is confidential and may be legally privileged. Only intended recipients are authorised to use it. E-mail transmissions are not guaranteed to be secure or error free and the sender does not accept liability for such errors or omissions. The company will not accept any liability in respect of such communication that violates our e-mail policy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598720: Happens on both amd64 and i386 platforms
I've tried this on a number of machines, both amd64 and i386, and it happens every time on all of them. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595999: It does seem to be a problem with ftp.uk.debian.org
I have experienced exactly this problem getting this file from ftp.uk.debian.org. Switching to using ftp.debian.org cures it, so it does indeed seem to be a corrupt file on the ftp.uk.debian.org mirror. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591298: [pkg-cli-apps-team] Bug#593616: f-spot: F-Spot crashes if I try to import pictures
On 29/08/10 12:58, Iain Lane wrote: I've built a little backport of f-spot from experimental to squeeze/amd64 which I believe you are running. If you trust my deb, you can get it from: http://people.ubuntu.com/~laney/f-spot_0.7.2-1_amd64.deb md5sum 3f64e304de2c406f97b341616db9ab66 f-spot_0.7.2-1_amd64.deb sha1sum 895d2a8dfbd428d7f35b68c494ee77c9a142faad f-spot_0.7.2-1_amd64.deb It'd be nice if you could try this. Thank you - that one seems to work beautifully. [snip] Looking at your trace, I wonder if there's a particular image in your import directory that is causing this problem. Maybe you could also try with 0.6.x on a new user account? Tried that - it didn't seem to make any difference. I do have a large collection of photos (2.6G) but I've tried pointing the old f-spot at smaller and smaller subsets of it without success - it always crashed on the first photo it attempted. Thank you for your assistance - I'll now try to learn how to use the program. Cheers, John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593616: [pkg-cli-apps-team] Bug#593616: f-spot: F-Spot crashes if I try to import pictures
On 24/08/10 10:54, Iain Lane wrote: Hiya, On Thu, Aug 19, 2010 at 05:52:43PM +0100, John Winters wrote: Package: f-spot Version: 0.6.2-2 Severity: important F-Spot disappears as soon as I select a directory to import. Running it in a terminal produces the following trace: [Info 17:45:58.313] Initializing Mono.Addins [Info 17:45:58.709] Hack for gnome-settings-daemon engaged Thanks for your report. I suspect that this problem has been fixed in f-spot in experimental*. Could you try and upgrade to this version and see if you can reproduce it there? Thanks for the suggestion. I tried to upgrade to this version, but rapidly found myself in dependency hell, and would have had to upgrade major chunks of my system to get it installed. Note that the 0.7 series will upgrade your database in a backwards-incompatible way, so you may wish to back your ~/.config/f-spot/ directory up before launching the new version, in case you wish to revert back to 0.6.x. As F-spot has never worked for me, I tried deleting the whole of the ~/.config/f-spot directory and starting again, but it still crashes immediately you point it an import directory (which is the first thing it asks you to do when you start it for the first time). How does anyone ever get past this point? Cheers, John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#593616: f-spot: F-Spot crashes if I try to import pictures
Package: f-spot Version: 0.6.2-2 Severity: important F-Spot disappears as soon as I select a directory to import. Running it in a terminal produces the following trace: [Info 17:45:58.313] Initializing Mono.Addins [Info 17:45:58.709] Hack for gnome-settings-daemon engaged (f-spot:7863): GdkPixbuf-WARNING **: GdkPixbufLoader finalized without calling gdk_pixbuf_loader_close() - this is not allowed. You must explicitly end the data stream to the loader before dropping the last reference. error checking orientation item ImportCommand+SourceItem System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Date () [0x0] error checking orientation System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Date () [0x0] System.NullReferenceException: Object reference not set to an instance of an object at FSpot.JpegFile.get_Description () [0x0] error checking orientation *** glibc detected *** f-spot: malloc(): smallbin double linked list corrupted: 0x024e2f20 *** === Backtrace: = /lib/libc.so.6(+0x71b16)[0x7ff982880b16] /lib/libc.so.6(+0x7542d)[0x7ff98288442d] /lib/libc.so.6(__libc_malloc+0x70)[0x7ff982885970] /usr/lib/libsqlite3.so.0(+0x41e7f)[0x7ff96fdeae7f] /usr/lib/libsqlite3.so.0(+0xa109)[0x7ff96fdb3109] /usr/lib/libsqlite3.so.0(+0xa1e8)[0x7ff96fdb31e8] /usr/lib/libsqlite3.so.0(+0x14145)[0x7ff96fdbd145] /usr/lib/libsqlite3.so.0(+0x458a6)[0x7ff96fdee8a6] /usr/lib/libsqlite3.so.0(+0x72646)[0x7ff96fe1b646] /usr/lib/libsqlite3.so.0(sqlite3_step+0x1b0)[0x7ff96fe091f0] [0x41b01786] === Memory map: 0040-00666000 r-xp fe:05 49247 /usr/bin/mono 00866000-00869000 rw-p 00266000 fe:05 49247 /usr/bin/mono 00869000-008a2000 rw-p 00:00 0 01f06000-02ceb000 rw-p 00:00 0 [heap] 40054000-40064000 rwxp 00:00 0 40082000-40092000 rwxp 00:00 0 40147000-40157000 rwxp 00:00 0 40225000-40235000 rwxp 00:00 0 407a7000-407b7000 rwxp 00:00 0 40882000-40892000 rwxp 00:00 0 409dc000-409ec000 rwxp 00:00 0 40ac6000-40ad6000 rwxp 00:00 0 40b55000-40b65000 rwxp 00:00 0 40caf000-40cbf000 rwxp 00:00 0 40ccd000-40cdd000 rwxp 00:00 0 40d5c000-40d6c000 rwxp 00:00 0 40f45000-40f55000 rwxp 00:00 0 40f57000-40f67000 rwxp 00:00 0 411a8000-411b8000 rwxp 00:00 0 412fd000-4130d000 rwxp 00:00 0 41451000-41461000 rwxp 00:00 0 41726000-41736000 rwxp 00:00 0 418be000-418ce000 rwxp 00:00 0 41af3000-41b03000 rwxp 00:00 0 41d37000-41d47000 rwxp 00:00 0 41fa6000-41fb6000 rwxp 00:00 0 7ff9642bd000-7ff9643b3000 r-xp fe:05 151537 /usr/lib/libstdc++.so.6.0.13 7ff9643b3000-7ff9645b3000 ---p 000f6000 fe:05 151537 /usr/lib/libstdc++.so.6.0.13 7ff9645b3000-7ff9645ba000 r--p 000f6000 fe:05 151537 /usr/lib/libstdc++.so.6.0.13 7ff9645ba000-7ff9645bc000 rw-p 000fd000 fe:05 151537 /usr/lib/libstdc++.so.6.0.13 7ff9645bc000-7ff9645d1000 rw-p 00:00 0 7ff9645d1000-7ff9645d5000 r-xp 08:02 1140544 /lib/libattr.so.1.1.0 7ff9645d5000-7ff9647d4000 ---p 4000 08:02 1140544 /lib/libattr.so.1.1.0 7ff9647d4000-7ff9647d5000 rw-p 3000 08:02 1140544 /lib/libattr.so.1.1.0 7ff9647d5000-7ff9647dd000 r-xp fe:05 147527 /usr/lib/libfam.so.0.0.0 7ff9647dd000-7ff9649dc000 ---p 8000 fe:05 147527 /usr/lib/libfam.so.0.0.0 7ff9649dc000-7ff9649dd000 rw-p 7000 fe:05 147527 /usr/lib/libfam.so.0.0.0 7ff9649dd000-7ff9649de000 ---p 00:00 0 7ff9649de000-7ff9651de000 rw-p 00:00 0 7ff9651de000-7ff9651df000 ---p 00:00 0 7ff9651df000-7ff9659df000 rw-p 00:00 0 7ff9659df000-7ff9659e ---p 00:00 0 7ff9659e-7ff9661e rw-p 00:00 0 7ff9661e-7ff9661e1000 ---p 00:00 0 7ff9661e1000-7ff9669e1000 rw-p 00:00 0 7ff966b9d000-7ff966ba4000 r-xp 08:02 1140534 /lib/libacl.so.1.1.0 7ff966ba4000-7ff966da3000 ---p 7000 08:02 1140534 /lib/libacl.so.1.1.0 7ff966da3000-7ff966da4000 rw-p 6000 08:02 1140534 /lib/libacl.so.1.1.0 7ff966da4000-7ff966db2000 r-xp fe:05 377072 /usr/lib/gnome-vfs-2.0/modules/libfile.so 7ff966db2000-7ff966fb2000 ---p e000 fe:05 377072 /usr/lib/gnome-vfs-2.0/modules/libfile.so 7ff966fb2000-7ff966fb3000 rw-p e000 fe:05 377072 /usr/lib/gnome-vfs-2.0/modules/libfile.so 7ff966fb3000-7ff966fc7000 r-xp fe:05 155803
Bug#546351: Update
Since when is documentation which doestn't exist at all considered as a bug? Hmmm, not sure. Certainly for at least the last 30 years. Probably much longer but that's as long as I've been involved in professional software development. Wikipedia says in the `Software Bug' as first sentence: A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces, an incorrect or unexpected result, or causes it to behave in unintended ways That seems to cover it nicely. flaw and failure both apply appropriately in this case. If you're having trouble comprehending how lack of documentation can be considered a bug, try turning the problem around and looking at it from a different direction. As it stands, if you install the package it does not work. Ah yes, that's because extra steps are needed to get it to work. Fine. What are the extra steps? Nobody knows. Actually, that Nobody knows isn't quite fair. Clearly some people know, but apparently none of the company presently assembled, and as that includes the maintainers of the package that's a pretty big deficiency. Clearly, adding some documentation is not the only way of fixing this bug, but the alternative - completing the installation process so that the package works after it's been installed - would be much, much harder to achieve. I will continue my researches, and if I manage to discover how to get the package working I will contribute a README in the hope of closing this bug. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546351: Warning
There is a danger here of rendering a system un-bootable.
Since just installing grub-efi doesn't give you a working
boot mechanism, removing the alternative would seem to be
both unnecessary and dangerous.
See #543376
You can see from the filelist that grub-efi-{ia32,amd64} and
grub-pc all have files included which the other ones have too.
So it isn't that easy to just remove the Conflicts in
debian/control for them.
Just uninstalling grub-pc doestn't make your system unbootable.
It doestn't touch /boot/grub
A warning for anyone following down the same route of trying to get this
package working. Installing the Lenny version of grub-efi (and thus
removing grub-pc) doesn't render your system un-bootable by the old
method, but installing the Sid version (as advised elsewhere in this
thread) does. You thus get just one guess at the magic incantations
needed to get grub-efi up and running before you need to resort to some
sort of recovery disc.
The error given when you try to boot using BIOS grub is Unknown command
initrd.
John
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546351: grub-efi: Grub-efi lacks any documentation
Package: grub-efi
Version: 1.96+20080724-16
Severity: important
The grub-efi package seems to be intended to allow Debian to be
booted on Intel-based Macs - e.g. a Mac mini. However it lacks
any documentation about how you can do this. There are references
to a general page on the EFI component of Grub2, but the package as
built does not match this page and the user is left scrabbling in
the dark.
Just a one page basic HOWTO would greatly improve the usefulness
of this package. I'd offer to write it but I'm still struggling
to discover how the package can be used.
This package could potentially be extremely useful, given the
well known problems trying to boot Mac minis headless using
the legacy BIOS boot facility.
-- Package-specific info:
*** WARNING grub-setup left core.img in filesystem
*** BEGIN /proc/mounts
/dev/disk/by-uuid/9bfe8835-09d4-4640-a012-3b48575f3ab7 / ext3
rw,errors=remount-ro,data=ordered 0 0
/dev/mapper/lvmdata-home /home ext3 rw,errors=continue,data=ordered 0 0
/dev/mapper/lvmdata-usr /usr ext3 rw,errors=continue,data=ordered 0 0
*** END /proc/mounts
*** BEGIN /boot/grub/device.map
(hd0) /dev/sda
*** END /boot/grub/device.map
*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/update-grub using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
set default=0
set timeout=5
terminal console
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/05_debian_theme ###
set menu_color_normal=cyan/blue
set menu_color_highlight=white/blue
### END /etc/grub.d/05_debian_theme ###
### BEGIN /etc/grub.d/10_hurd ###
### END /etc/grub.d/10_hurd ###
### BEGIN /etc/grub.d/10_linux ###
menuentry Debian GNU/Linux, linux 2.6.26-2-amd64 {
set root=(hd0,3)
search --fs-uuid --set 9bfe8835-09d4-4640-a012-3b48575f3ab7
linux /boot/vmlinuz-2.6.26-2-amd64
root=UUID=9bfe8835-09d4-4640-a012-3b48575f3ab7 ro
initrd /boot/initrd.img-2.6.26-2-amd64
}
menuentry Debian GNU/Linux, linux 2.6.26-2-amd64 (single-user mode) {
set root=(hd0,3)
search --fs-uuid --set 9bfe8835-09d4-4640-a012-3b48575f3ab7
linux /boot/vmlinuz-2.6.26-2-amd64
root=UUID=9bfe8835-09d4-4640-a012-3b48575f3ab7 ro single
initrd /boot/initrd.img-2.6.26-2-amd64
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file is an example on how to add custom entries
### END /etc/grub.d/40_custom ###
*** END /boot/grub/grub.cfg
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages grub-efi depends on:
ii grub-common 1.96+20080724-16 GRand Unified Bootloader, version
ii libc6 2.7-18 GNU C Library: Shared libraries
grub-efi recommends no packages.
Versions of packages grub-efi suggests:
pn os-prober none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546351: grub-efi: Grub-efi lacks any documentation
Felix Zielcke wrote: [snip] With `general page' above you mean these 2 Wiki sites? http://grub.enbug.org/TestingOnEFI http://grub.enbug.org/TestingOnMacbook Yes. The problem is, that neither Robert nor me has any EFI system so we have to rely on upstream (or other people) for the documentation about that. You can just install the sid version under lenny. There's no need for a backport. I'd recommend it anyway, we fixed many many things since the lenny version. It's not the installing that's a problem. The thing is, just installing it doesn't really do anything. It certainly doesn't render the system efi-bootable. Once you have installed the grub-efi package you have to do something to make it actually work. The package includes no clue as to what this something is. Compare with the traditional grub and lilo packages, which once you've installed them will boot the system. I'd also query why installing grub-efi causes grub-pc to be uninstalled. There is a danger here of rendering a system un-bootable. Since just installing grub-efi doesn't give you a working boot mechanism, removing the alternative would seem to be both unnecessary and dangerous. Thanks for your feedback. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546351: Status change
Incidentally, I notice you've changed the status of this bug from Important to Wishlist. I'm not going to start ping-ponging it, but the Debian bug specifications define Important as: a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. Now the lack of documentation for grub-efi renders it unusable to anyone who doesn't have the specialist knowledge to cope without it. The subset of the population which *does* have that specialist knowledge is apparently so small that it doesn't even include the maintainers of the package. By any definition, that's a problem which has a major effect on the usability of a package, certainly not a mere Wishlist item. John -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545206: Upgrade to gthumb-data_3:2.10.8-1+lenny2 fails with file clash
David Paleino wrote: On Sat, 05 Sep 2009 18:59:52 +0100, John Winters wrote: I've just tried to upgrade my Lenny system with the latest security fixes and the upgrade failed on the gthumb-data package, with the following error. [..] trying to overwrite `/usr/share/locale/nb', which is also in package policycoreutils It seems like policycoreutils installed /usr/share/locale/nb as a file, rather than a directory. Could you please confirm this? Yes, indeed it was. I deleted the file and then the upgrade proceeded normally. Thank you for your assistance. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545206: Upgrade to gthumb-data_3:2.10.8-1+lenny2 fails with file clash
Package: gthumb-data Version: 3:2.10.8-1+lenny1 Severity: important I've just tried to upgrade my Lenny system with the latest security fixes and the upgrade failed on the gthumb-data package, with the following error. Preparing to replace gthumb-data 3:2.10.8-1+lenny1 (using .../gthumb-data_3%3a2.10.8-1+lenny2_all.deb) ... Unpacking replacement gthumb-data ... dpkg: error processing /var/cache/apt/archives/gthumb-data_3%3a2.10.8-1+lenny2_all.deb (--unpack): trying to overwrite `/usr/share/locale/nb', which is also in package policycoreutils dpkg-deb: subprocess paste killed by signal (Broken pipe) Errors were encountered while processing: /var/cache/apt/archives/gthumb-data_3%3a2.10.8-1+lenny2_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- System Information: Debian Release: 5.0.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.26-2-486 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#500058: Seems to be fixed in 2.6.30 (as packaged for Squeeze)
A workaround for this bug with the 2.6.26 kernels was to blacklist: jmb38x_ms memstick in /etc/modprobe.d/blacklist.conf. This is still required for the 2.6.26 kernels in Lenny. I've just upgraded to Squeeze and the 2.6.30 kernel there seems to have fixed the problem. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522312: Not a fault in the Debian installer
Please close this one. The fault lay with the mirror which hadn't been updated since Lenny's release. The stable link still pointed to etch. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#522312: debian-installer: Lenny install image for AMD64 puts etch in /etc/apt/sources.list
Package: debian-installer Severity: important I just downloaded the installer image for Lenny, called: debian-500-amd64-netinst.iso and used it to do a clean install on an AMD system. It all seemed to run fine but at the end I found I had a hybrid Lenny/Etch system. The kernel was 2.6.26 (indicating Lenny) but the version of OpenOffice.org was 2.0 (indicating Etch). Investigating /etc/apt/sources.list I found that the embedded release name was etch where it should have been lenny, meaning that I seemed to have got a Lenny base system with Etch used for everything else. Editing /etc/apt/sources.list to change the system to lenny and then doing an apt-get dist-upgrade seems to have cured it. The only slightly odd thing which I did during the installation was to use a local Debian mirror (which carries Etch, Lenny and Squeeze) instead of a public one. -- System Information: Debian Release: 5.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-liberty15 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506571: sa-exim overrides local spamc configuration by default
Package: sa-exim Version: 4.2.1-4 Severity: wishlist By default the sa-exim configuration file overrides any local configuration of spamc to tell it to connect to spamd on localhost. If spamc has been configured to connect to a spamd somewhere else then sa-exim fails until its configuration is updated. Since spamc's default target is localhost anyway, it would be preferable to leave things alone rather then explicitly overriding spamc's configuration. The use could then edit sa-exim.conf if he wants to get sa-exim's invocation of spamc to connect to a different instance of spamd (which seems an unlikely requirement). -- 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.18-6-xen-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages sa-exim depends on: ii debconf [debconf-2.0] 1.5.11etch2 Debian configuration management sy ii exim4-daemon-heavy 4.63-17 exim MTA (v4) daemon with extended ii libc6 2.3.6.ds1-13etch7 GNU C Library: Shared libraries ii spamc 3.1.7-2 Client for SpamAssassin spam filte Versions of packages sa-exim recommends: ii perl5.8.8-7etch3 Larry Wall's Practical Extraction -- debconf information: sa-exim/purge_spool: false -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#500058: linux-image-2.6.26-1-686: Acer Aspire One won't boot with SDHC card inserted
Package: linux-image-2.6.26-1-686 Version: 2.6.26-5 Severity: normal The current kernel for Lenny (2.6.26-1) boots fine on an Acer Aspire One, except if there is an SDHC card in one of the card reader slots. Then the boot process gets as far as: Waiting for /dev to be fully populated and hangs. After a minute the following message appears: BUG: soft lockup - CPU#1 stuck for 61s! [kmemstick:1503] and the message is repeated every minute after that. The same configuration boots successfully with kernel 2.6.22 and the memory card can be accessed once the boot is complete (although 2.6.22 doesn't support other aspects of the hardware). -- Package-specific info: ** Version: Linux version 2.6.26-1-686 (Debian 2.6.26-5) ([EMAIL PROTECTED]) (gcc version 4.1.3 20080623 (prerelease) (Debian 4.1.2-23)) #1 SMP Wed Sep 10 16:46:13 UTC 2008 ** Command line: root=/dev/sda1 ro elevator=noop quiet ** Tainted: P (1) ** Kernel log: [4.411602] ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx [4.455799] Driver 'sd' needs updating - please use bus_type methods [4.455966] sd 1:0:0:0: [sda] 15761088 512-byte hardware sectors (8070 MB) [4.456009] sd 1:0:0:0: [sda] Write Protect is off [4.456015] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [4.456087] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [4.456222] sd 1:0:0:0: [sda] 15761088 512-byte hardware sectors (8070 MB) [4.456262] sd 1:0:0:0: [sda] Write Protect is off [4.456268] sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00 [4.456341] sd 1:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [4.456351] sda: sda1 sda2 [4.461826] sd 1:0:0:0: [sda] Attached SCSI disk [4.567128] PM: Starting manual resume from disk [4.949434] usb 5-5: new high speed USB device using ehci_hcd and address 3 [5.302032] usb 5-5: configuration #1 chosen from 1 choice [5.348648] usb 5-5: New USB device found, idVendor=064e, idProduct=d101 [5.348648] usb 5-5: New USB device strings: Mfr=3, Product=1, SerialNumber=4 [5.348648] usb 5-5: Product: Acer Crystal Eye webcam [5.348648] usb 5-5: Manufacturer: SuYin [5.348648] usb 5-5: SerialNumber: CN0316-M608-OV01-VA-R02.00.00 [5.407072] udevd version 125 started [5.587926] usb 1-1: new low speed USB device using uhci_hcd and address 4 [5.756507] usb 1-1: configuration #1 chosen from 1 choice [5.760819] usb 1-1: New USB device found, idVendor=1267, idProduct=0210 [5.760819] usb 1-1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [5.760819] usb 1-1: Product: PS/2+USB Mouse [5.782903] Linux video capture interface: v2.00 [5.799282] uvcvideo: Found UVC 1.00 device Acer Crystal Eye webcam (064e:d101) [5.803246] input: Acer Crystal Eye webcam as /class/input/input1 [5.803331] usbcore: registered new interface driver uvcvideo [5.803341] USB Video Class driver (v0.1.0) [6.176665] ACPI: WMI: Mapper loaded [6.196669] acer-wmi: Acer Laptop ACPI-WMI Extras version 0.1 [7.506790] Linux agpgart interface v0.103 [7.526372] agpgart: Detected an Intel 945GME Chipset. [7.526605] agpgart: Detected 7932K stolen memory. [7.542793] agpgart: AGP aperture is 256M @ 0x2000 [7.844087] ACPI: PCI Interrupt :00:1b.0[A] - GSI 16 (level, low) - IRQ 16 [7.844133] PCI: Setting latency timer of device :00:1b.0 to 64 [7.876856] hda_codec: Unknown model for ALC268, trying auto-probe from BIOS... [8.168975] ath_hal: module license 'Proprietary' taints kernel. [8.181538] AR5210, AR5211, AR5212, AR5416, RF5111, RF5112, RF2413, RF5413, RF2133, RF2425, RF2417) [8.545621] ACPI: PCI Interrupt :03:00.0[A] - GSI 18 (level, low) - IRQ 18 [8.545646] PCI: Setting latency timer of device :03:00.0 to 64 [9.035636] MadWifi: ath_attach: Switching rfkill capability off. [9.091067] input: Power Button (FF) as /class/input/input2 [9.091344] ACPI: AC Adapter [ACAD] (off-line) [9.135933] ACPI: Power Button (FF) [PWRF] [9.136795] input: Power Button (CM) as /class/input/input3 [9.180203] ACPI: Power Button (CM) [PWRB] [9.180382] input: Lid Switch as /class/input/input4 [9.239222] ACPI: Lid Switch [LID0] [9.239424] input: Sleep Button (CM) as /class/input/input5 [9.267172] ACPI: Sleep Button (CM) [SLPB] [ 10.090084] ACPI: Battery Slot [BAT1] (battery present) [ 10.215969] input: Video Bus as /class/input/input6 [ 10.266579] ACPI: Video Device [OVGA] (multi-head: yes rom: yes post: no) [ 10.390518] iTCO_wdt: Intel TCO WatchDog Timer Driver v1.03 (30-Apr-2008) [ 10.390684] iTCO_wdt: Found a ICH7-M TCO device (Version=2, TCOBASE=0x0460) [ 10.390742] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [ 10.967495] intel_rng: FWH not detected [ 11.180260] input: PC Speaker as /class/input/input7 [ 11.393304] usbcore: registered new interface driver
Bug#498507: oolite segfaults at startup on amd64 platform
Package: oolite
Version: 1.65-6+b1
Severity: important
On attempting to run oolite on an AMD64 Lenny system I get the
following:
[EMAIL PROTECTED]:~$ oolite
2008-09-10 17:37:39.660 oolite[9567] initialising SDL
2008-09-10 17:37:39.765 oolite[9567] init: numSticks=0
2008-09-10 17:37:39.766 oolite[9567] CREATING MODE LIST
2008-09-10 17:37:39.766 oolite[9567] Added res 1024 x 768
2008-09-10 17:37:39.766 oolite[9567] Added res 800 x 600
2008-09-10 17:37:39.766 oolite[9567] Added res 720 x 450
2008-09-10 17:37:39.766 oolite[9567] Added res 640 x 512
2008-09-10 17:37:39.766 oolite[9567] Added res 512 x 384
2008-09-10 17:37:39.766 oolite[9567] Added res 400 x 300
2008-09-10 17:37:39.766 oolite[9567] Added res 320 x 240
Segmentation fault
[EMAIL PROTECTED]:~$
Running with strace, and quoting the 25 lines leading up to the SEGV
I get:
read(4, 0xb7e5b4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
open(/dev/zero, O_RDWR) = 11
mmap(NULL, 544768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_32BIT, 11, 0) =
0x408e
close(11) = 0
brk(0xc69000) = 0xc69000
brk(0xcb8000) = 0xcb8000
select(5, [4], [4], NULL, NULL) = 1 (out [4])
writev(4, [{[EMAIL
PROTECTED]'\0\0\0\0\0\0\0\0\0\0\0\1\1\1\0\221\31\3\0\0\0\0\0\1..., 36}], 1) =
36
select(5, [4], [], NULL, NULL) = 1 (in [4])
read(4,
\1m\31\0\1\0\0\0\4\0\0\0\0\0\0\\5)\2\0\0\0\0\0\0\0\0\0\0\0\0\0..., 4096)
= 36
read(4, 0xb7e5b4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
getpid()= 9245
getpid()= 9245
shmdt(0x7f3de8aee000) = 0
select(5, [4], [4], NULL, NULL) = 1 (out [4])
writev(4, [{[EMAIL PROTECTED]..., 12}], 1) = 12
select(5, [4], [], NULL, NULL) = 1 (in [4])
read(4, \1\2\33\0\0\0\0\0
\0\300\3\0\0\0\0\34C\0\0\0\0\0\0P\2477\373\377\177\0\0..., 4096) = 32
read(4, 0xb7e5b4, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
select(4, [3], [3], NULL, NULL) = 2 (in [3], out [3])
read(3, \26\0f\0\16\0 \4\16\0 \4\r\0 \4\0\0\0\0 \3X\2\0\0\0\0\0\0\0\0...,
4096) = 32
writev(3, [{+\30\1\0..., 4}], 1) = 4
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3, \1\2g\0\0\0\0\0
\0\300\3\0\0\0\0\34C\0\0\0\0\0\0P\2477\373\377\177\0\0..., 4096) = 32
read(3, 0xb83864, 4096) = -1 EAGAIN (Resource temporarily
unavailable)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGSEGV, {SIG_DFL}, {0x7f3df0fd7740, [], SA_RESTORER,
0x7f3df0dc0a90}, 8) = 0
futex(0x4198b9e0, FUTEX_WAIT, 9246, NULL) = 0
ioctl(6, 0x4122, 0) = 0
poll([{fd=5, events=POLLIN|POLLERR|POLLNVAL}], 1, -1) = 1 ([{fd=5,
revents=POLLIN}])
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-liberty8 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages oolite depends on:
ii gnustep-base-runtime 1.16.1-2lenny1 GNUstep Base library
ii libc6 2.7-13 GNU C Library: Shared libraries
ii libgcc1 1:4.3.1-9 GCC support library
ii libgl1-mesa-glx [libgl1] 7.0.3-5A free implementation of the OpenG
ii libglu1-mesa [libglu1]7.0.3-5The OpenGL utility library (GLU)
ii libgnustep-base1.16 1.16.1-2lenny1 GNUstep Base library
ii libobjc2 4.3.1-9Runtime library for GNU Objective-
ii libsdl-image1.2 1.2.6-3image loading library for Simple D
ii libsdl-mixer1.2 1.2.8-4mixer library for Simple DirectMed
ii libsdl1.2debian 1.2.13-2 Simple DirectMedia Layer
ii oolite-data 1.65-2 Data files for the space-sim game
oolite recommends no packages.
oolite suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388814: Further information
The last note on this bug requests an strace of what ifup is doing. Since no-one else has done it I thought I would. Two possible facts to record here first: 1) The problem does not manifest itself on a Sarge diskless system. There you can run ifup -a as much as you like without losing the connection. 2) The problem only manifests itself if the relevant link is configured to use dhcp. If you give it a static address in /etc/network/interfaces then you get an error message (File exists) but the link isn't lost and the system continues to run. However the fact that the link is up still isn't recorded in /etc/network/run/ifstate. Anyway - the step which causes the problem doesn't seem to be within ifup itself at all. The last thing which it does before the link goes down is to invoke dhclient. Presumably the actual killing of the link is happening there. It's notable that the default dhcp changed to version 3 in Etch so this may be where the change happened. I'm not sure whether the test for the link already being up should be added to ifup or dhclient - perhaps this bug record needs redirecting again? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#449040: Also provides no means to know what is going to be removed, even if you look
Further to this issue, when update-manager offers you the option to switch to Smart upgrade mode it says, Be sure to check the proposed removals for software you would like to keep installed. but nowhere does it tell you what the proposed removals are, so you can't check them whether you want to or not. You have to exit update-manager and run a different upgrade tool if you want to know details of what the problem is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487874: Problem appeared with hunspell 1.2.4
I've been doing some regression testing and the problem appeared in hunspell 1.2.4. The previous release of hunspell used in Lenny (1.2.2) does not have the same problem. diffing the two versions of affentry.cxx shows changes in precisely the area where the bug lies, but I can't find any release notes which detail what the code changes were trying to achieve - the NEWS file just says Bug fixes. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487874: Problem is in hunspell and not myspell-en-gb
I've now diagnosed this problem and (unless there are some stringent rules on the contents of .aff files which I've been unable to find) the problem lies in hunspell and not in myspell-en-gb. It's just that the extra complexity of myspell-en-gb tickles the bug in hunspell. An example of a rule which hunspell fails to process correctly is: SFX D 0 ed [aeio][aeiou][bcdfgkmnprstvz] And a suitable word for demonstrating the problem is entertained. The actual processing happens in the SfxEntry::test_condition method in the affentry.cxx compilation unit. It tries to work backwards through the proposed stem (entertain) and at the same time backwards through the above comparison rule. When it finds the 'n' (the last letter of entertain) in the third group it sets a flag (called ingroup) and decrements its pointer into the target word so that pointer is now pointing at the 'i' of entertain. However it then carries on working its way through the characters of the third group. Fortunately there is no 'i' there to find so the bug does no harm. The code then moves on to the second group of characters, and works backwards through it until it finds the 'i', which matches the letter currently being pointed at in the target word. It sets the flag again and again decrements the pointer into the target word so now it points at the 'a' in entertain. This time the bug bites. Because the code goes on processing the remaining characters in the second group it then finds the 'a' there, which causes the pointer into the target word to be decremented again - now it points to the latter 't' in entertain and so when the code comes to process the first group of characters it can't get a match (it wants to find 'a', but that's been and gone). As a quick demonstration that this explanation is correct, you can edit the en_GB.aff file and reverse the middle group of the rule so that it reads: SFX D 0 ed [aeio][uoiea][bcdfgkmnprstvz] Hunspell then successfully recognises entertained as being a word. Can this bug be reassigned to the hunspell source package? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487874: Problem of duff words in myspell-en-gb is more widespred
There seem to be a lot more words either spelled wrongly or just plain missing in this version (1:2.4.0-2) of myspell-en-gb. Opening any existing English language document will throw up quite a few red-underlined words which are correctly spelled. Examples are: existing entertained (offers entertainned, which is wrong) consisting persisted All of these words are listed correctly in the version of myspell-en-gb in Etch (2.0.4~rc1-3) I would suggest that the severity of this error needs increasing markedly, because the dictionary is useless with this many errors in it. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#487874: Problem of duff words in myspell-en-gb is more widespread
Rene Engelhard wrote: Hi, John Winters wrote: All of these words are listed correctly in the version of myspell-en-gb in Etch (2.0.4~rc1-3) I would suggest that the severity of this error needs increasing markedly, because the dictionary is useless with this many errors in it. And what would you suggest? Remove the package? Revert to an ancient version? I thought it was perfectly clear what I was suggesting - escalating the severity because the package is seriously broken. If you want to go further, and if it can't be determined how it was broken, then perhaps reverting to the last known good version would be the best bet. It's not after all that ancient. And are you sure this is a dictionary bug after all (i.e. are the words really missing there - didn't check myself yet) or whether OOo or iceweasel or whatever you use myspell-en-gb with just doesn't handle it correctly in some manner? No, I'm not sure, but the problem seems to manifest itself in both OOo and iceweasel, so it suggests that the problem is in the dictionary. Now, if you want to be constructive instead of getting silly then you can perhaps suggest how one could test where the problem is. It seems to be a systemic thing (all the duff words are derivatives) so it could be an algorithmic error. The addition of lots of broken versions of the words also suggests this. If you think the bug is filed against the wrong package, then make a suggestion of what it should be filed against, but don't post such inflammatory silliness. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#422100: Total bytes figure reported by debmirror is hopelessly wrong.
Package: debmirror Version: 20060907.1 Severity: minor I was puzzled by the apparently appalling throughput being achieved by debmirror until I realised it was using a nonsensical total for the number of bytes transferred. For example: Downloaded 60 MiB in 7123s at 8.58 kiB/s Nearly two hours for 60 MiB looks dreadful, but then I checked how much it had actually downloaded. The following downloads occurred during the run of debmirror: total size is 49346242 speedup is 1.00 total size is 147718710 speedup is 1.00 total size is 112573184 speedup is 1.00 total size is 179826378 speedup is 1.00 total size is 314808900 speedup is 1.00 total size is 352018324 speedup is 1.00 total size is 121487820 speedup is 1.00 total size is 90141452 speedup is 1.00 total size is 36065234 speedup is 1.00 total size is 448769566 speedup is 1.00 total size is 205355332 speedup is 1.00 total size is 24047366 speedup is 1.00 total size is 42010528 speedup is 1.00 total size is 19569308 speedup is 1.00 total size is 59404878 speedup is 1.00 total size is 82376048 speedup is 1.00 total size is 282801820 speedup is 1.00 total size is 834051558 speedup is 1.00 total size is 99735260 speedup is 1.00 total size is 57858900 speedup is 1.00 total size is 273668514 speedup is 1.00 total size is 208600568 speedup is 1.00 total size is 136772168 speedup is 1.00 total size is 394115268 speedup is 1.00 total size is 80825220 speedup is 1.00 total size is 430140616 speedup is 1.00 (I've lined up the numbers to ease addition.) As you can see, this adds up to more like 5 GiB rather than 60 MiB which is much more believable on an 8 megabit link. This happens every time I invoke it with a passable number of files to be fetched. -- 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.20.4-blandings2 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Versions of packages debmirror depends on: ii bzip2 1.0.3-6high-quality block-sorting file co ii libcompress-zlib-perl 1.42-2 Perl module for creation and manip ii libdigest-sha1-perl 2.11-1 NIST SHA-1 message digest algorith ii liblockfile-simple-perl 0.2.5-7Simple advisory file locking ii libwww-perl 5.805-1WWW client/server library for Perl ii perl [libdigest-md5-perl] 5.8.8-7Larry Wall's Practical Extraction ii perl-modules [libnet-perl]5.8.8-7Core Perl modules ii rsync 2.6.9-2fast remote file copy program (lik Versions of packages debmirror recommends: ii gnupg 1.4.6-2GNU privacy guard - a free PGP rep ii patch 2.5.9-4Apply a diff file to an original -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413520: installation-reports: Installation on Mini-ITX (EPIA 800) system completes but fails to boot
Package: installation-reports Severity: important I've been trying a number of times to install Etch on a Mini-ITX based, EPIA 800 system. This box has been running for some time as a diskless workstation running Sarge. I've now put a HDD in it and am trying to install Etch using the network boot method. The installation appears to run flawlessly, right up to the point where the system tries to boot the new installation. Then it gets as far as the second line of the boot (Uncompressing kernel) and re-boots. I got slightly further when I used the rc1 installer. Then it would get to Waiting for /dev to be populated before re-booting. Unfortunately, because it fails so early in the boot process it is difficult if not impossible to gain any more diagnostic information. If I switch the box back to network booting and tell it to boot Sarge rather than the Etch installer then it still works perfectly happily and is 100% stable. -- Package-specific info: Boot method: network Image version: Daily build 20070215 Date: Date and time of the install Machine: Mini-ITX EPIA 800 Partitions: df -Tl will do; the raw partition table is preferred Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [ ] Detect network card:[ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[E] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. I worried that the problem might be the 486 kernel which the installer installs by default, so I built a replacement kernel with all the same settings but changed to a C3 processor. This made no difference. I have deleted all the auto-gathered system information which was added below because it relates to the system on which I am typing this, rather than the one I am installing. As I can't boot that system I can't use it to submit this report. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299622: xserver-xfree86: dpkg-reconfigure does not create /etc/X11/XF86Config-4
Brice Goglin wrote: Hi, About 2 years ago, you reported (or replied to) a bug in the Debian BTS regarding dpkg-reconfigure not creating XF86Config-4. Did you reproduce this bug recently? If not, I will close this bug in the next weeks. No, I haven't seen this recently, but I now use Xorg rather than XFree86. dpkg-reconfigure xserver-xorg behaves in a more logical way in that it renames the existing file and writes the new one as requested. I have no way of knowing whether the fix suggested has been applied in xserver-xfree86. Regards, John Winters -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#336214: Correction to workaround
The workaround suggested for this bug of putting the umask setting in /etc/gdm/Init/Default doesn't work. Hardly surprising really as that script ends with an exit 0 line, so whatever instance of the shell was executing it dies, and the modified umask dies with it. The workaround which actually works is to put the umask specification in /etc/gdm/Xsession, as suggested in bug #314791. I put it just after the Beginning session setup... message so that it would affect as much as possible, and it doesn't seem to get messed up again by gdm. This is a horrible bug. I've spent half today re-discovering it. Once you've worked out that it's gdm doing the dirty deed it's easy to find previous records, but until that particular piece of information falls into place it's a stinker. I hate to think how many other people have wasted that much time on it. -- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381855: Amendment to problem report
After further investigation, it appears that this problem is not fundamentally one with CUPS - at worst it's a problem of interaction between CUPS and libgnomeprint2.2. I've now done some further tests and found that the symptoms described earlier apply only to Gnome applications. KDE applications consistently get the paper size right - for both local and remote CUPS printers. Unfortunately I can't find a way to interrogate CUPS directly and ask it, What paper size do you think that remote CUPS printer uses?. However as KDE gets it right, presumably the right information is there somewhere. I will raise a bug report against libgnomeprint2.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#382141: libgnomeprint2.2-0: Gets paper size wrong for remote CUPS printers
Package: libgnomeprint2.2-0 Version: 2.12.1-6 Severity: important I previously reported this as a problem in CUPS, but it seems to affect only Gnome applications - hence reported here. The current version of libgnomeprint in Etch doesn't seem to pick up the paper size from CUPS printers on other CUPS servers. Although the CUPS server has them configured with A4 paper, remote workstations running Etch always try to use them as if they had letter-sized paper. I thought at first that this was a problem between different versions of CUPS, as the main print server on our network is running Sarge and CUPS version 1.1.23-10sarge. Sarge workstations get the paper size right but Etch workstations get it wrong. However, I've now done some further tests and it seems to be a fundamental problem with libgnomeprint accessing CUPS printers which are not local to that machine. If the CUPS printer is configured in CUPS on the local machine then libgnomeprint gets the paper size right, but if the printer is configured on a different CUPS server and the local CUPS instance has learned about it automatically through the CUPS mechanisms then the paper size gets lost and libgnomeprint defaults to US-Letter instead of the configured paper size. KDE applications on the other hand get the paper size right for both local and remote CUPS printers, so it seems as the information is there - just that libgnomeprint isn't picking it up. I took two Etch workstations, each of which was getting the paper size wrong for printers accessed on the main print server. I attached a printer to each of these workstations and configured them (through CUPS) as local printers with A4 sized paper. Attempting to print to either printer on the workstation to which it is attached correctly brings up A4 as the paper size. However, I then changed the CUPS settings on each of the workstations to make the new printers available to other machines on the network. Each workstation quickly added the other's printer to its list of available printers, but attempting to print to them from a Gnome application (e.g. Evince) always brings up Letter as the preferred paper size, despite them both being set to A4. This happens with all applications which use the Gnome print mechanism. It's also noticeable that if you run gnome-cups-manager, it can display attributes (like paper size) for local CUPS printers but just gives a blank list for remote CUPS printers. Presumably part of the same problem. -- 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-amtrak1 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Versions of packages libgnomeprint2.2-0 depends on: ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libcupsys2 1.2.2-1 Common UNIX Printing System(tm) - ii libfontconfig1 2.3.2-7 generic font configuration library ii libfreetype6 2.2.1-2 FreeType 2 font engine, shared lib ii libglib2.0-0 2.10.3-3 The GLib library of C routines ii libgnomecups1.0-1 0.2.2-5 GNOME library for CUPS interaction ii libgnomeprint2.2-data 2.12.1-6 The GNOME 2.2 print architecture - ii libgnutls131.4.1-1 the GNU TLS library - runtime libr ii libpango1.0-0 1.12.3-1+b1 Layout and rendering of internatio ii libpopt0 1.10-2lib for parsing cmdline parameters ii libxml22.6.26.dfsg-3 GNOME XML library ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages libgnomeprint2.2-0 recommends: ii cupsys1.2.2-1Common UNIX Printing System(tm) - -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#381855: cupsys: CUPS uses wrong paper size for remote CUPS printers
Package: cupsys Version: 1.2.2-1 Severity: important The current version of CUPS in Etch doesn't seem to pick up the paper size from printers on other CUPS servers. Although the CUPS server has them configured with A4 paper, remote workstations running Etch always try to use them as if they had letter-sized paper. I thought at first that this was a problem between different versions of CUPS, as the main print server on our network is running Sarge and CUPS version 1.1.23-10sarge. Sarge workstations get the paper size right but Etch workstations get it wrong. However, I've now done some further tests and it seems to be a fundamental problem with CUPS 1.2.2-1 accessing remote printers on another CUPS server. I took two Etch workstations, each of which was getting the paper size wrong for printers accessed on the main print server. I attached a printer to each of these workstations and configured them (through CUPS) as local printers with A4 sized paper. Attempting to print to either printer on the workstation to which it is attached correctly brings up A4 as the paper size. However, I then changed the CUPS settings on each of the workstations to make the new printers available to other machines on the network. Each workstation quickly added the other's printer to its list of available printers, but attempting to print to them always brings up Letter as the preferred paper size, despite them both being set to A4. Each instance of CUPS seems to be respecting the paper size configuration when accessing a local printer, but ignoring it and using Letter instead when accessing a remote CUPS printer. -- 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-amtrak1 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Versions of packages cupsys depends on: ii adduser 3.95Add and remove users and groups ii cupsys-common1.2.2-1 Common UNIX Printing System(tm) - ii debconf [debconf-2.0]1.5.2 Debian configuration management sy ii gs-esp 8.15.1.dfsg.1-2 The Ghostscript PostScript interpr ii libacl1 2.2.41-1Access control list shared library ii libc62.3.6-15GNU C Library: Shared libraries ii libcupsimage21.2.2-1 Common UNIX Printing System(tm) - ii libcupsys2 1.2.2-1 Common UNIX Printing System(tm) - ii libdbus-1-2 0.62-4 simple interprocess messaging syst ii libgnutls13 1.4.1-1 the GNU TLS library - runtime libr ii libldap2 2.1.30-13+b1OpenLDAP libraries ii libpam0g 0.79-3.1Pluggable Authentication Modules l ii libpaper11.1.19 Library for handling paper charact ii libslp1 1.2.1-5 OpenSLP libraries ii lsb-base 3.1-10 Linux Standard Base 3.1 init scrip ii patch2.5.9-4 Apply a diff file to an original ii perl-modules 5.8.8-4 Core Perl modules ii poppler-utils [xpdf-util 0.4.5-4.1 PDF utilitites (based on libpopple ii procps 1:3.2.7-2 /proc file system utilities ii zlib1g 1:1.2.3-13 compression library - runtime Versions of packages cupsys recommends: ii cupsys-client 1.2.2-1 Common UNIX Printing System(tm) - ii foomatic-filters3.0.2-20060712-1 linuxprinting.org printer support pn smbclient none (no description available) -- debconf information: cupsys/raw-print: true cupsys/backend: ipp, lpd, parallel, socket, usb -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366715: installation-report: Installer gets stuck if it can't access security.debian.org
On Thu, 2006-05-11 at 06:57 +0200, Christian Perrier wrote: [snip] I wonder whether we could have a kind of compromise here: -keep the current behaviour when a regular mirror has been chosen -at least ask for a proxy for security.d.o when the mirror settings have been entered manually Excellent suggestion - this would maintain the desired simplicity whilst allowing the installer to cope in a situation which is all too common. John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366715: installation-report: Installer gets stuck if it can't access security.debian.org
Package: installation-report Severity: important I'm trying to use the Debian Installer etch beta 2 to install systems within a fairly tightly firewalled network. Although the installer prompts to ask what repository it should use for the main packages it then tries to use a hard-coded source (presumably security.debian.org) to check for security updates, without first seeking permission to do this or guidance on how to do it. In our network, this fails (slowly) because all direct outgoing http requests are dropped at the firewall. After a significant delay a message appears explaining what has happened and offering the option to continue (it advises that the problem should be investigated and corrected later). If one then selects the Continue button, nothing further happens. The installation process does not move on and there's no way to get back to the menu. Apart from fixing this getting stuck problem, can I suggest the following enhancements to the installer: 1) Ask before attempting to get security updates. (Obviously default to yes). 2) Ask where to get them from. I have a local copy of them but there seems to be no way to tell the installer to use this local copy. 3) Ask for proxy information. This can (and in our case does) differ from the proxy information needed to access the main package repository. Obviously again - default to the same proxy information as previously entered. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.16.2-bluebox3 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#366715: installation-report: Installer gets stuck if it can't access security.debian.org
On Wed, 2006-05-10 at 16:38 -0400, Joey Hess wrote: John Winters wrote: I'm trying to use the Debian Installer etch beta 2 to install systems within a fairly tightly firewalled network. Although the installer prompts to ask what repository it should use for the main packages it then tries to use a hard-coded source (presumably security.debian.org) to check for security updates, without first seeking permission to do this or guidance on how to do it. In our network, this fails (slowly) because all direct outgoing http requests are dropped at the firewall. After a significant delay a message appears explaining what has happened and offering the option to continue (it advises that the problem should be investigated and corrected later). If one then selects the Continue button, nothing further happens. The installation process does not move on and there's no way to get back to the menu. You need to wait for it to time out a second time. This problem has already been fixed in apt-setup 0.10 unstable, which will only have the first timeout and not the second. Glad to hear it. 1) Ask before attempting to get security updates. (Obviously default to yes). There's no good reason to ask. Well, no - clearly there is a good reason to ask. If the machine is network connected it should make every possible effort to use security updates, True, and by failing to ask it is not making every possible effort to use them. doing anything else is asking to be insecure. Because it doesn't ask the current behaviour is *less* secure than it could potentially be. The updates are there and available to be installed, but by being inflexible the installer *prevents* me using them. If you really want to disable it, you can preseed apt-setup/security_host to an empty string, as documented in the installation manual. Where? I've read all the apparently relevant chunks of the installation manual but can find nothing like that documented in it. I've even had a fresh look now that you've told me it's there, and I still can't find it. The problem with a very large manual like that (with no index) is that it's only really useful to the person who wrote it, and thus who knows what's there. 2) Ask where to get them from. I have a local copy of them but there seems to be no way to tell the installer to use this local copy. apt-setup/security_host can be used to override this. However, the security team doesn't like mirrors of security.debian.org, and asking that kind of question in any regular install is counter to our UI guidelines. We try to avoid asking questions when there's a default that will work for 99.99% of users. 3) Ask for proxy information. This can (and in our case does) differ from the proxy information needed to access the main package repository. Obviously again - default to the same proxy information as previously entered. While it seems that apt might support per-host proxy settings, I think you'd be better off fixing your network. I doubt that anyone else will ever have such a setup, Clearly you have little experience of real-world networks. This is just the sort of problem which a non-admin on a Windows network has to deal with on a daily basis. If you have administrator access it's easy, but if not it's hard to impossible. Yes, the particular network on which I was trying to do it is badly set up, but the problem is equally the fault of bad defaults in the Debian installer. Just saying, It's the other components fault - fix that is the worst form of buck-passing. Sorry to be short, but it's been a long and hard day and you need to realise that a response like yours does the Debian project (which I greatly admire) absolutely no favours. John -- John Winters, Wallingford, Oxon, England i = (free (NULL); i++); -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#359849: ifupdown: ifdown disables wake-on-lan
Package: ifupdown Version: 0.6.7 Severity: normal It appears that ifdown, when run during the shutdown of a Debian system, disables any Wake-on-LAN settings which may have been set with ethtool whilst the system was running. This then prevents the system from being started up again remotely. A (very unsatisfactory) workaround is to comment out the line invoking ifdown in /etc/init.d/networking. A better fix would surely be for ifdown to leave the NIC's WOL settings alone. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.14.5-athlon3 Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Versions of packages ifupdown depends on: ii debconf [debconf-2.0] 1.4.30.13Debian configuration management sy ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii net-tools 1.60-10 The NET-3 networking toolkit -- debconf information: ifupdown/convert-interfaces: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#356657: Latest tar (1.14-2.1) no longer works with remote devices
Package: tar
Version: 1.14-2.1
Severity: important
Since installing the latest security-fixed version of tar (1.14-2.1) it
does not seem to be possible to access remote tape devices. The
following strace shows the problem. Note that tar does not seem to
have made any attempt to access the device - it shuts down almost
as soon as it starts up.
As a piece of background, rsh is configured to point to ssh and
the invoking user can ssh to the remote machine without needing
a password. However as can be seen from the strace, tar doesn't
get as far as trying to invoke anything - it errors out before
getting that far.
execve(/bin/tar, [tar, cvf, [EMAIL PROTECTED]:/dev/dat, bin], [/* 13
vars */]) = 0
uname({sys=Linux, node=emperor, ...}) = 0
brk(0) = 0x8072000
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7f0f000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.preload, O_RDONLY)= -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=56394, ...}) = 0
old_mmap(NULL, 56394, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f01000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/tls/librt.so.1, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\220\32...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=22940, ...}) = 0
old_mmap(NULL, 21588, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xb7efb000
old_mmap(0xb7f0, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x5000) = 0xb7f0
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/tls/libc.so.6, O_RDONLY)= 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0`Z\1\000...,
512) = 512fstat64(3, {st_mode=S_IFREG|0755, st_size=1254468, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7efa000
old_mmap(NULL, 1264780, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xb7dc5000
old_mmap(0xb7eef000, 36864, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0x129000) = 0xb7eef000
old_mmap(0xb7ef8000, 7308, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7ef8000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/tls/libpthread.so.0, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0pF\0\000...,
512) = 512fstat64(3, {st_mode=S_IFREG|0755, st_size=78233, ...}) = 0
old_mmap(NULL, 60772, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) =
0xb7db6000
old_mmap(0xb7dc2000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED,
3, 0xc000) = 0xb7dc2000
old_mmap(0xb7dc3000, 7524, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7dc3000
close(3)= 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS,
-1, 0) = 0xb7db5000
set_thread_area({entry_number:-1 - 6, base_addr:0xb7db5080,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1}) = 0
munmap(0xb7f01000, 56394) = 0
set_tid_address(0xb7db50c8) = 5974
rt_sigaction(SIGRTMIN, {0xb7dba5d0, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) =
0
clock_gettime(CLOCK_REALTIME, {1142173985, 513367000}) = 0
brk(0) = 0x8072000
brk(0x8093000) = 0x8093000
brk(0) = 0x8093000
rt_sigaction(SIGCHLD, {SIG_DFL}, {SIG_DFL}, 8) = 0
write(2, tar: , 5tar: )= 5
write(2, [EMAIL PROTECTED]:/dev/dat: Cannot ope..., [EMAIL
PROTECTED]:/dev/dat:
Cannot open) = 33
write(2, : Input/output error, 20: Input/output error)= 20
write(2, \n, 1
) = 1
write(2, tar: , 5tar: )= 5
write(2, Error is not recoverable: exitin..., 37Error is not
recoverable: exiting now) = 37
write(2, \n, 1
) = 1
exit_group(2) = ?
-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.6.14.5-athlon3
Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to
en_GB)
Versions of packages tar depends on:
ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248433: Also FUBARs Mini-ITX system
I've had a lot of grief over the last week caused by just this same problem. I have a headless server with a Mini-ITX m/board which has been running very happily for a year or so. Up until a week ago, it hadn't been re-booted for 3-4 months. I then had occasion to re-boot it (because I'd replaced a failing fan) and after the re-boot - no ethernet connectivity. I spent a long time thinking it was a hardware problem until eventually I booted the box with an up-to-date Sarge installation CD. As part of the startup process it asked, Which of your ethernet cards do you want to use?, which surprised me as I only had one. It did however give me the clue as to what was wrong. Somewhere in the process of tracking Sarge updates (and some time in the last 3-4 months) the priorities have changed. Where before the system used the ethernet hardware for eth0 it now chooses to use the Firewire port instead. This is without any configuration changes on the box - just software updates. This bug most definitely should not have a wontfix attribute. Imagine a headless server in a dark data-centre. All it needs is routine updates and a re-boot and the thing is totally FUBARed. This is *not* the sort of behaviour one expects of a Debian installation. What's described here is a serious bug and it needs attention. I would be delighted to look at it if you could provide me with some guidance about how hotplug decides what order to assign to network devices. John Winters -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248433: Also FUBARs Mini-ITX system
On Sun, 2005-06-05 at 20:54 +0200, Marco d'Itri wrote: On Jun 05, John Winters [EMAIL PROTECTED] wrote: This bug most definitely should not have a wontfix attribute. Imagine Try sending a patch then... As I said before, I'd be delighted to, but some cooperation is needed. described here is a serious bug and it needs attention. I would be delighted to look at it if you could provide me with some guidance about how hotplug decides what order to assign to network devices. It does not. The kernel does. Since you're determined not to be helpful, it makes it very difficult for anyone else to fix the problem either. Provide some information, or even just some pointers and you could at least achieve the state of being neutral, rather than being an active impediment to a fix. Regards, John Winters -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#248433: Further information
Incidentally, and further to my last e-mail... In the time period I referred to the kernel on the affected box had *not* changed, just the hotplug package. It isn't just a kernel problem and it is a very real and serious problem. Just saying it's someone else's problem is no help at all and will not fix it. Regards, John -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#307070: tar invokes non-existent rmt to access remote tape drive
Package: tar Version: 1.14-2 Severity: normal If you invoke tar with a remote device name it tries to invoke /usr/libexec/rmt on the remote box, but this file (and indeed the whole directory) does not exist on a Debian Sarge system. Examining the executable of tar with strings, the name of the executable appears to be hard-coded into the tar program. A workaround is to create the libexec directory on the remote system, then a symlink for rmt pointing to /etc/alternatives/rmt. The tar package doesn't seem to have changed recently - has the Debian policy perhaps changed and left tar behind? -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-1-686-smp Locale: LANG=en_GB, LC_CTYPE=en_GB (charmap=ISO-8859-1) (ignored: LC_ALL set to en_GB) Versions of packages tar depends on: ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299622: Update with suggested solutions
I've now spent some time tracing exactly what the code is doing and know what is causing the problems. 1) The code which purports to check the md5sum doesn't actually do exactly that. Instead it checks that the whole line in the .md5sum file matches with what it expects. You can thus have the odd situation where the md5sum matches but the rest of the line doesn't and so the check fails. This could be fixed either by comparing just the first field of each (the md5sum itself) or by updating the documentation to make it clear that the full path must be used when re-generating the .md5sum file. I would suggest that the former approach is the better fix, because there are lots of valid ways of referencing any file, even if you insist on an absolute reference. 2) The code does actually attempt to issue a message explaining why it hasn't written the file, but the message is by default suppressed. I would suggest that a message which is trying to say, I'm not going to do what you asked me to do because... warrants a status (on the Information, Warning, Error, Severe error scale) of at least Warning. By using warn instead of observe the message would at least appear and much bafflement could be avoided. I hope this is useful input. Regards, John Winters -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#299622: Suggested fix doesn't help
I have precisely the same problem with dpkg-reconfigure xserver-xfree86 not writing /etc/X11/XF86Config-4. I have tried the fix suggested by Martin Braure de Calignon but it makes no difference at all. There are actually two separate bugs here: 1) That the code silently fails to write the file if the md5sum doesn't match. It should at the very least give a message saying that the file hasn't been written and why. Better still would be a prompt (like one gets during an apt-get upgrade) asking for permission to overwrite the file. 2) There is some other circumstance - as yet unknown - in which it fails to write the file. I can provide an strace -f of the process if that would help. John Winters -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#295245: kernel-source-2.6.10: VIA Rhine driver leaves i/f in state which prevents re-boot
Package: kernel-source-2.6.10 Severity: normal I use a number of Mini-ITX systems as diskless workstations. These boot over Ethernet using PXELINUX. They work fine with kernel 2.6.8 but as soon as I upgraded one to 2.6.10 I found I couldn't reboot it without turning the power right off. You actually have to disconnect the power lead - it's not enough for the board just to go to its power-off state. What happens when you switch on is the BIOS doesn't seem to be able to make head or tail of the state of the ethernet interface and exits without attempting to boot. This happens 100% of the time if the previous boot used a 2.6.10 kernel. It doesn't happen if the previous kernel used was 2.6.8 or earlier. I note that the VIA-Rhine driver has had a Massive clean-up between kernels 2.6.8 and 2.6.10. Possibly too massive? -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-stb4 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
