Bug#832128: freespace2: Bad symlinks /usr/games/fs2_open{,_DEBUG}
Package: freespace2 Version: 3.7.2+repack-1+b1 Severity: normal Dear Maintainer, The current package contains symlinks such as /usr/games/fs2_open -> fs2_open_3.7.2+repack-1+b1 where the target doesn't exist. /usr/games/fs2_open_3.7.2 does exist so it seems likely that the build/maintainer scripts are using the Debian package version where they should be using the upstream version. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.6.0-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 Init: systemd (via /run/systemd/system) Versions of packages freespace2 depends on: ii libc6 2.23-1 ii libgcc1 1:6.1.1-9 ii libgl1-mesa-glx [libgl1] 11.2.2-1 ii libglu1-mesa [libglu1]9.0.0-2.1 ii libjansson4 2.7-5 ii libjpeg62-turbo 1:1.5.0-1 ii liblua5.1-0 5.1.5-8 ii libogg0 1.3.2-1 ii libopenal11:1.17.2-1 ii libpng16-16 1.6.23-1 ii libsdl1.2debian 1.2.15+dfsg1-4 ii libstdc++66.1.1-9 ii libtheora01.1.1+dfsg.1-14 ii libvorbis0a 1.3.5-3 ii libvorbisfile31.3.5-3 Versions of packages freespace2 recommends: ii freespace2-launcher-wxlauncher [freespace2-launcher] 0.11.0+dfsg-1 Versions of packages freespace2 suggests: ii dpkg-dev 1.18.9 ii joystick 1:1.5.1-2 pn vrms -- no debconf information
Bug#825075: deb-systemd-invoke: incomplete handling of policy-rc.d status codes
Package: init-system-helpers Version: 1.33 Severity: normal Dear Maintainer, In particular, where policy-rc.d returns 0 deb-systemd-invoke prints a spurious warning. The original spec for policy-rc.d mentioned only 0 as the return code for "action allowed" and 104 was added later. invoke-rc.d treats 0 the same as 104 and so should deb-systemd-invoke. Thanks, -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-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 Init: systemd (via /run/systemd/system) Versions of packages init-system-helpers depends on: ii perl-base 5.22.2-1 init-system-helpers recommends no packages. init-system-helpers suggests no packages. -- no debconf information
Bug#801860: /bin/journalctl: journalctl --list-boots is too slow and memory hungry
On Sun, 1 Nov 2015, Martin Pitt wrote: Did you move the old directory back (which should not touch the files and inodes of the old journal files at all) or did that actually involved file copying (in which case the files/disk location/fragmentation could have been subtly changed)? I actually copied them back, although if journalctl is concerned with the on-disk layout I'd be mightily surprised! Note that the symptom was an ever-growing heap without any IO syscalls. Just to confirm, did systemd get updated in between the time you could still reproduce it and now? It hasn't been updated since, although checking dpkg.log I see that systemd was upgraded (226-4 -> 227-2) earlier on the day that I first noticed the bug. -- Edward Allcutt
Bug#801860: /bin/journalctl: journalctl --list-boots is too slow and memory hungry
On Thu, 15 Oct 2015, Michael Biebl wrote: Can you move /var/log/journal away for testing purposes (don't delete the journal files!) and create a fresh /var/log/journal directory. Then do a couple of reboots. Is the speed reasonable then? Maybe there is something specific about those journal files which break journalctl. In that case, would you be willing to share those journal files? Hmph, this now seems unreproducible. I did: - Confirm journalctl --list-boots still hangs - mv journal oldjournal - install -d -g systemd-journal /var/log/journal - reboot (twice) - journalctl --list-boots (now works, shows 2 boots) - restore oldjournal - journalctl --list-boots (now works, shows 8 boots) bleh I think you may as well close this as unreproducible and it if comes up again I'll try to attack it with a debugger without rebooting. -- Edward Allcutt
Bug#801860: /bin/journalctl: journalctl --list-boots is too slow and memory hungry
Hi Michael, :-) On Thu, 15 Oct 2015, Michael Biebl wrote: When I run "journalctl --list-boots" (as root) I expected to get the output instantly or within seconds. Instead there was no output and it appeared hung. Checking with ps/top/strace I could see it was busy rather than sleeping and appeared to be calling brk() repeatedly to expand its heap size. I left it doing that until it had consumed 7+GiB of RSS and had started to cause memory pressure and swap usage whereupon I killed it. Is this normal? Might this be a problem with my persistent journal files? I enabled persistent journal using the instructions in /usr/share/doc/systemd/README.Debian.gz back in March. How big is your /var/log/journal/ ? Is that on HDD or SSD? What does "journalctl --verify" say? It's a laptop spinning (at 7200 rpm) rust type storage device. I don't think speed of retrieval from the disk is a factor though. # journalctl --disk-usage Archived and active journals take up 144.0M on disk. # du -xsh /var/log/journal/ 145M/var/log/journal/ # journalctl --verify PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/system@917974e30b5f49e789deec21ee0c033f-0001-0005203f0834a00a.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/user-1000@67b5841f8e0f4759b94f2b26b3f4cbf4-320a-000520930344d3a4.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/user-1001@33610609e8514da0aa13a2ea18bb1cb9-3114-000520916b47e09b.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/system@917974e30b5f49e789deec21ee0c033f-78bd-000527516f814654.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/system.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/user-1000@67b5841f8e0f4759b94f2b26b3f4cbf4-78c2-000527516f814a73.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/user-1000.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/user-1001@33610609e8514da0aa13a2ea18bb1cb9-7e05-000522d951e6412e.journal PASS: /var/log/journal/2e7a303bb598373e73b04ccb5176b123/user-1001.journal # -- Edward Allcutt
Bug#801860: /bin/journalctl: journalctl --list-boots is too slow and memory hungry
On Thu, 15 Oct 2015, Michael Biebl wrote: Can you move /var/log/journal away for testing purposes (don't delete the journal files!) and create a fresh /var/log/journal directory. Then do a couple of reboots. Is the speed reasonable then? I'll do this but it'll have to wait for the end of the work week. :-) Maybe there is something specific about those journal files which break journalctl. In that case, would you be willing to share those journal files? Possibly, I'll have to review that. -- Edward Allcutt
Bug#749405: [Resolvconf-devel] Bug#749405: Bug#749405: Current Status + Moving Forward?
On Tue, 24 Jun 2014, Thomas Hood wrote: Here is a patch which survives some basic testing. diff --git a/debian/resolvconf.service b/debian/resolvconf.service index 2a7285d..94fde69 100644 --- a/debian/resolvconf.service +++ b/debian/resolvconf.service @@ -11,4 +11,4 @@ ExecStart=/sbin/resolvconf --enable-updates ExecStop=/sbin/resolvconf --disable-updates [Install] -WantedBy=network.target +WantedBy=sysinit.target I'm still convined that Before=networking.service is necessary in the [Unit] section. Without it `systemctl list-dependencies --after networking.service` does not list resolvconf.service. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749405: [Resolvconf-devel] Bug#749405: Bug#749405: Current Status + Moving Forward?
Hi Thomas, On Mon, 23 Jun 2014, Thomas Hood wrote: I think it just needs to be tested. Have you tested the proposed fix at all? I've been using the below minimal patch locally for a few weeks now. It works for me in the just-plain-ifupdown configuration use-case. == $ diff -u /lib/systemd/system/resolvconf.service /etc/systemd/system/resolvconf.service --- /lib/systemd/system/resolvconf.service 2014-06-23 14:24:03.306557959 +0100 +++ /etc/systemd/system/resolvconf.service 2014-06-23 14:17:55.006474686 +0100 @@ -2,6 +2,7 @@ Description=Nameserver information manager Documentation=man:resolvconf(8) DefaultDependencies=no +Before=networking.service [Service] RemainAfterExit=yes @@ -11,4 +12,4 @@ ExecStop=/sbin/resolvconf --disable-updates [Install] -WantedBy=network.target +WantedBy=sysinit.target == nb. WantedBy=sysinit.target matches the Default-Start: S from the old init script and Before=networking.service corresponds to X-Start-Before:networking. My earlier waffling about hotplugging is about a potential problem (which I'm not sure really exists). It shouldn't block this bug from being resolved. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749405: [Resolvconf-devel] Bug#749405: resolvconf: /etc/resolvconf/run/interface either does not exist or is not a directory
Beck, Andre [2014-06-01 16:24 +0200]: Pondering this a bit more, I've changed my copy in /etc/systemd/system to now read WantedBy=sysinit.target as this is reflecting better where Debian has placed networking and resolvconf traditionally - in rcS.d. Right, agreed. The attached debdiff adjusts the WantedBy and cleans up the symlinks on upgrade. It's not actively harmful to have two, but it might look a bit confusing. Note that systemctl reenable also works when systemd is not running, thus the postinst only checks if the systemctl command exists. I think the additional explicit Before=networking.service (and possibly others) is also necessary since networking is also ordered before sysinit.target. Thinking about it slightly more, what is really needed (for the networking/ifupdown case) is to ensure that resolvconf.service is started before any invocation of ifup, including by hotplugging/udev. As far as I can work out, even with sysv-rc there's a potential race for hotplugged interfaces to be started before the resolvconf init script. Has this already been solved somehow? Does ifupdown defer hotplugged configuration until after the networking script? I can't see any such mechanism.. There used to be an ifupdown(.sh?) init script but I can't remember precisely what that did. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749405: resolvconf: /etc/resolvconf/run/interface either does not exist or is not a directory
Package: resolvconf Version: 1.75 Followup-For: Bug #749405 Dear Maintainer, I generally concur with Andre, with one exception. I believe the WantedBy line should reference networking.service as that will be pulled in on any normal Debian system (whereas network.target is only pulled in in some configurations). -- Ed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719996: jitsi: Display broken with jdk7
On Fri, 23 Aug 2013, Damian Minkov wrote: could you also add what is the desktop environment you use? I don't use a DE. Just a traditional .xsession (with a session bus and so forth as set up by /etc/X11/Xsession) which starts awesome. Using latest sid of debian-7 with jre7 and gnome3 works fine. Any exceptions in the logs? I've attached a log of the stderr. It contains no errors that aren't also present with jre6. However, digging into /etc/X11/Xsession.d I noticed 55awesome-javaworkaround which attempts to set _JAVA_AWT_WM_NONREPARENTING=1 if the started session is awesome. Since I'm using a .xsession this detection fails and the variable isn't being set. Running jitsi with _JAVA_AWT_WM_NONREPARENTING=1 and jre7 seems to work fine although this seems to inidicate a regression in Java rather than anything else since that hint clearly hasn't been needed for some time with jre6. I've added this workaround to my .xsession for now. -- Edward AllcuttAuto-properties install: reference:file:sc-bundles/galagonotification.jar (org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar - java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar) org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar at org.apache.felix.framework.Felix.installBundle(Felix.java:2703) at org.apache.felix.framework.BundleContextImpl.installBundle(BundleContextImpl.java:165) at org.apache.felix.main.AutoProcessor.processAutoProperties(AutoProcessor.java:296) at org.apache.felix.main.AutoProcessor.process(AutoProcessor.java:79) at org.apache.felix.main.Main.main(Main.java:292) at net.java.sip.communicator.launcher.SIPCommunicator.main(SIPCommunicator.java:153) Caused by: java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar at org.apache.felix.framework.cache.BundleArchive.createRevisionFromLocation(BundleArchive.java:852) at org.apache.felix.framework.cache.BundleArchive.reviseInternal(BundleArchive.java:550) at org.apache.felix.framework.cache.BundleArchive.init(BundleArchive.java:153) at org.apache.felix.framework.cache.BundleCache.create(BundleCache.java:277) at org.apache.felix.framework.Felix.installBundle(Felix.java:2699) ... 5 more Auto-properties start: reference:file:sc-bundles/galagonotification.jar (org.osgi.framework.BundleException: Unable to cache bundle: reference:file:sc-bundles/galagonotification.jar - java.io.IOException: Referenced file does not exist: sc-bundles/galagonotification.jar) ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe ALSA lib pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side ALSA lib pcm_dmix.c:961:(snd_pcm_dmix_open) The dmix plugin supports only playback stream 12:28:53.191 SEVERE: [13] org.jitsi.impl.neomedia.device.DeviceConfiguration.error() Failed to register custom Renderer org.jitsi.impl.neomedia.jmfext.media.renderer.audio.PulseAudioRenderer with JMF. java.lang.IllegalStateException: audioSystem at org.jitsi.impl.neomedia.jmfext.media.renderer.audio.PulseAudioRenderer.init(PulseAudioRenderer.java:105) at org.jitsi.impl.neomedia.jmfext.media.renderer.audio.PulseAudioRenderer.init(PulseAudioRenderer.java:85) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:525) at java.lang.Class.newInstance0(Class.java:374) at java.lang.Class.newInstance(Class.java:327) at org.jitsi.impl.neomedia.device.DeviceConfiguration.registerCustomRenderers(DeviceConfiguration.java:1060) at org.jitsi.impl.neomedia.device.DeviceConfiguration.init(DeviceConfiguration.java:368) at org.jitsi.impl.neomedia.MediaServiceImpl.init(MediaServiceImpl.java:132) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:525) at java.lang.Class.newInstance0(Class.java:374) at java.lang.Class.newInstance(Class.java:327) at org.jitsi.impl.libjitsi.LibJitsiImpl.getService(LibJitsiImpl.java:133) at org.jitsi.impl.libjitsi.LibJitsiOSGiImpl.getService(LibJitsiOSGiImpl.java:86) at
Bug#719996: jitsi: Display broken with jdk7
Package: jitsi Version: 2.3.4687.9786-1 Severity: normal Dear Maintainer, After installing openjdk-7-jre, on starting jitsi the main window displays just a grey box. Switching back to java6 with update-alternatives currently works as a workaround. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.9-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 jitsi depends on: ii default-jre [java6-runtime]1:1.7-49 ii libbcprov-java 1.44+dfsg-3.1 ii libcommons-codec-java 1.8-1 ii libcommons-logging-java1.1.3-1 ii libdbus-java 2.8-4 ii libdnsjava-java2.1.5-0.1 ii libfelix-framework-java4.0.1-2 ii libfelix-main-java 4.0.1-2 ii libhttpclient-java 4.2.5-2 ii libhttpcore-java 4.3-1 ii libhttpmime-java 4.2.5-2 ii libjgoodies-forms-java 1.6.0-4 ii libjitsi-jni 2.3.4687.9786-1 ii libjmdns-java 3.4.1-2 ii libjna-java3.2.7-4+b1 ii libjson-simple-java1.1-dfsg1-2 ii libjzlib-java 1.1.2-1 ii liblaf-widget-java 4.3-2 ii liblog4j1.2-java 1.2.17-3 ii libmac-widgets-java0.9.5+svn369-dfsg1-3 ii libunixsocket-java 0.7.3-1 ii libxpp3-java 1.1.4c-2 ii openjdk-6-jre [java6-runtime] 6b27-1.12.5-2 ii openjdk-7-jre [java6-runtime] 7u21-2.3.9-5 jitsi recommends no packages. jitsi 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#665693: e1000 WARNING and INFO: task kworker blocked for more than ..
On Mon, 12 Aug 2013, Moritz Muehlenhoff wrote: Just updated linux kernel from 3.2.9-1 to 3.2.12-1. [...] Does this still occur with the Wheezy kernel or later? No. I'd completely forgotten about this actually. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705301: login: Please enable pam_limits for su
Package: login Version: 1:4.1.5.1-1 Severity: normal Dear Maintainer, /etc/pam.d/su contains a line for pam_limits.so but it is commented out by default. This is in contrast to all the other new session type services (atd cron login sshd *dm) which have it enabled by default. It would be nice to have more consistency to reduce the amount of local configuration needed. I'm somewhat surprised pam_limits.so isn't in the common-session* files rather than individually in those for the login-type programs. Is there some reason a PAM session created by su (particularly su -l) should differ from those created by cron or login? -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 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 login depends on: ii libc6 2.13-38 ii libpam-modules 1.1.3-7.1 ii libpam-runtime 1.1.3-7.1 ii libpam0g1.1.3-7.1 login recommends no packages. login 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#701219: Crashes on startup
Package: crawl
Version: 2:0.11.2-2
Severity: important
eg.
===
$ crawl
Writing crash info to /home/edward/.crawl/morgue/crash--20130223-012455.txt
Floating point exception
$
===
-- System Information:
Debian Release: 7.0
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-4-486
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 crawl depends on:
ii crawl-common 2:0.11.2-2
ii libc6 2.13-38
ii libgcc1 1:4.7.2-5
ii liblua5.1-0 5.1.5-4
ii libncursesw5 5.9-10
ii libsqlite3-0 3.7.13-1
ii libstdc++64.7.2-5
ii libtinfo5 5.9-10
ii zlib1g1:1.2.7.dfsg-13
crawl recommends no packages.
crawl suggests no packages.
-- no debconf information
Version: Dungeon Crawl Stone Soup 0.11.2
Platform: unix
Bits: 32
Game mode: normal
Tiles: no
Command line: crawl
RC options:
restart_after_game = false
Crash caused by signal #8: Floating point exception
Obtained 36 stack frames.
crawl(_Z17write_stack_traceP8_IO_FILEi+0x1a) [0x8304a3f]: write_stack_trace(_IO_FILE*, int)
crawl(_Z13do_crash_dumpv+0x2e8) [0x833081e]: do_crash_dump()
crawl() [0x83321c2]
[0xb7781400]
/lib/i386-linux-gnu/libgcc_s.so.1(__divdi3+0x9b) [0xb74f8d2b]:
crawl(_Z18get_skill_progress10skill_typeiii+0x53) [0x8219945]: get_skill_progress(skill_type, int, int, int)
crawl(_Z18get_skill_progress10skill_typei+0x30) [0x821]: get_skill_progress(skill_type, int)
crawl(_ZNK6player5skillE10skill_typeib+0x50) [0x821d3b2]: player::skill(skill_type, int, bool) const
crawl() [0x821d851]
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0xa17f) [0xb774817f]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0x14fcd) [0xb7752fcd]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0xa5f8) [0xb77485f8]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0x48e0) [0xb77428e0]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0x9820) [0xb7747820]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0xa7cf) [0xb77487cf]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(lua_pcall+0x74) [0xb7743eb4]:
crawl(_ZN4CLua6callfnEPKcii+0xaa) [0x8329a48]: CLua::callfn(char const*, int, int)
crawl(_ZN7map_def7run_luaEb+0x172) [0x83b5c6e]: map_def::run_lua(bool)
crawl(_ZN7map_def16validate_map_defERK12depth_ranges+0x2b) [0x82b99c3]: map_def::validate_map_def(depth_ranges const)
crawl(_Z7yyparsev+0x5b2) [0x82ba3fd]: yyparse()
crawl(_Z8read_mapRKSs+0x338) [0x82bbc58]: read_map(std::string const)
crawl() [0x82b4f24]
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0xa17f) [0xb774817f]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0x14fcd) [0xb7752fcd]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0xa5f8) [0xb77485f8]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0x48e0) [0xb77428e0]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0x9820) [0xb7747820]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(+0xa7cf) [0xb77487cf]:
/usr/lib/i386-linux-gnu/liblua5.1.so.0(lua_pcall+0x74) [0xb7743eb4]:
crawl(_ZN4CLua8execfileEPKcbbb+0xd1) [0x8327b8d]: CLua::execfile(char const*, bool, bool, bool)
crawl(_Z9read_mapsv+0x21) [0x8327c26]: read_maps()
crawl(_Z12startup_stepv+0x176) [0x812e0b9]: startup_step()
crawl() [0x822a05d]
crawl(main+0x2ed) [0x80e6fbf]:
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6) [0xb738ae46]:
crawl() [0x80e72b9]
Compilation info:
Compiled with GCC 4.7.2 on Feb 20 2013 at 15:13:16
Build platform: i486-linux-gnu
Platform: i486-linux-gnu
CFLAGS: -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,-z,relro -D_FORTIFY_SOURCE=2 -Os -flto=jobserver -pipe -Wall -Wformat-security -Wundef -Wno-array-bounds -Wno-parentheses -Wno-unused-parameter -Wwrite-strings -Wshadow -Wuninitialized -Icontrib/install/i486-linux-gnu/include -Iutil -I. -I/usr/include/lua5.1 -I/usr/include -Irltiles -I/usr/include/ncursesw -DWIZARD -DASSERTS -DCLUA_BINDINGS -DSAVE_DIR_PATH=~/.crawl -DDATA_DIR_PATH=/usr/share/crawl/
LDFLAGS: -rdynamic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wl,-z,relro -D_FORTIFY_SOURCE=2 -Os -flto=jobserver
Place info:
branch = 0, depth = 1
Level id: D:1
Level build method = ABSENT, level layout type = ABSENT, absdepth0 = 0
Markers:
Messages:
Game state:
mouse_enabled: 0, waiting_for_command: 0, terminal_resized: 0
io_inited: 0, need_save: 0, saving_game: 0, updating_scores: 0:
seen_hups: 0, map_stat_gen: 0, type: 1, arena_suspended: 0
prev_cmd = CMD_NO_CMD
repeat_cmd = CMD_NO_CMD
Player:
{{{
Name: []
Species:Yak
Job:Unemployed
class_name:
HP: 0/0; mods: 0/0
MP: 0/0; mods: 0/0
Stats: 0 (0) 0 (0) 0 (0)
Position: (0, 0) OoB, god:No God (0), turn_is_over: 0, banished: 0
Skills (mode: auto)
Name| can_train | train | training | level | points | progress
Fighting| | 0 | 0|0 | 0 | 0/0
Short Blades| | 0 | 0|0 | 0 | 0/50
Long Blades | | 0 |
Bug#695873: memtest86+: Serial console does not work
Package: memtest86+ Version: 4.20-1.1 Severity: normal Dear Maintainer, When recompiled with SERIAL_CONSOLE_DEFAULT=1 and other settings in config.h the serial console works fine. However setting the parameters from the boot prompt with lilo (or pxelinux) does not. In particular these settings do not work (lilo version): append=console=ttyS1,115200n8 and similarly console=ttyS1 console=ttyS0 etc. From a brief poke at the code I suspect that the commandline is not successfully being passed from the bootloader to memtest. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/4 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 memtest86+ depends on: ii debconf [debconf-2.0] 1.5.46 memtest86+ recommends no packages. Versions of packages memtest86+ suggests: ii grub-pc 1.99-23 pn hwtools none pn kernel-patch-badram none pn memtest86none pn memtesternone ii mtools 4.0.17-1 -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690681: linux-image-2.6.32-5-amd64: newer hardware support
Package: linux-2.6 Version: 2.6.32-46 Severity: normal The latest squeeze kernel fails to detect both RAID and Ethernet controllers on this system. The current wheezy kernel (used to bootstrap) and vanilla v3.2.6 (currently running) both work fine. -- Package-specific info: ** Kernel log: boot messages should be attached ** Model information sys_vendor: Dell Inc. product_name: PowerEdge R720xd product_version: chassis_vendor: Dell Inc. chassis_version: bios_vendor: Dell Inc. bios_version: 1.2.6 board_vendor: Dell Inc. board_name: 0VWT90 board_version: A02 ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Sandy Bridge DMI2 [8086:3c00] (rev 07) Subsystem: Dell Device [1028:0528] Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 0 Capabilities: access denied 00:01.0 PCI bridge [0604]: Intel Corporation Sandy Bridge IIO PCI Express Root Port 1a [8086:3c02] (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Memory behind bridge: dc00-dc7f Prefetchable memory behind bridge: d900-d90f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:01.1 PCI bridge [0604]: Intel Corporation Sandy Bridge IIO PCI Express Root Port 1b [8086:3c03] (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: dc80-dcff Prefetchable memory behind bridge: d910-d91f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort+ SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:02.0 PCI bridge [0604]: Intel Corporation Sandy Bridge IIO PCI Express Root Port 2a [8086:3c04] (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:02.2 PCI bridge [0604]: Intel Corporation Sandy Bridge IIO PCI Express Root Port 2c [8086:3c06] (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: f000- Memory behind bridge: dd00-ddff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity+ SERR+ NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- Capabilities: access denied Kernel driver in use: pcieport 00:03.0 PCI bridge [0604]: Intel Corporation Sandy Bridge IIO PCI Express Root Port 3a in PCI Express Mode [8086:3c08] (rev 07) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Bus: primary=00, secondary=05, subordinate=05, sec-latency=0 Secondary status: 66MHz-
Bug#665693: e1000 WARNING and INFO: task kworker blocked for more than ..
Package: linux-2.6 Version: 3.2.12-1 Severity: important Just updated linux kernel from 3.2.9-1 to 3.2.12-1. On ifup, after a seemingly successful DHCP REQUEST+ACK networking completely fell over. The no IPv6 routers log line is notable since there is working native IPv6 here. The first noticable symptom however was DNS requests failing. Subsequently, netlink requests seemed to hang: ip address show blocked indefinitely. Rebooting blocked after the usual Rebooting the system message, there were some task hung warnings and I forced it to reboot with sysrq. I've fallen back to the previous ABI kernel, so the Kernel: line below is wrong. Manually added kernel logs since reportbug can't read them as normal user. Obviously missing messages after klogd was killed. It gets interesting from 360 onwards, I started the reboot before 480. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 3.2.0-2-486 (Debian 3.2.12-1) (debian-ker...@lists.debian.org) (gcc version 4.6.3 (Debian 4.6.3-1) ) #1 Tue Mar 20 18:45:21 UTC 2012 [0.00] Disabled fast string operations [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f000 (usable) [0.00] BIOS-e820: 0009f000 - 000a (reserved) [0.00] BIOS-e820: 000dc000 - 0010 (reserved) [0.00] BIOS-e820: 0010 - 1f6e (usable) [0.00] BIOS-e820: 1f6e - 1f6f7000 (ACPI data) [0.00] BIOS-e820: 1f6f7000 - 1f6f9000 (ACPI NVS) [0.00] BIOS-e820: 1f70 - 2000 (reserved) [0.00] BIOS-e820: fec0 - fec1 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: ff80 - 0001 (reserved) [0.00] Notice: NX (Execute Disable) protection missing in CPU! [0.00] DMI present. [0.00] DMI: IBM 2386H6G/2386H6G, BIOS 1UETD3WW (2.08 ) 12/21/2006 [0.00] e820 update range: - 0001 (usable) == (reserved) [0.00] e820 remove range: 000a - 0010 (usable) [0.00] last_pfn = 0x1f6e0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C write-protect [0.00] D-DBFFF uncachable [0.00] DC000-D write-back [0.00] E-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask FE000 write-back [0.00] 1 base 01FF0 mask 0 uncachable [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] PAT not supported by CPU. [0.00] initial memory mapped : 0 - 0180 [0.00] Base memory trampoline at [c009c000] 9c000 size 12288 [0.00] init_memory_mapping: -1f6e [0.00] 00 - 40 page 4k [0.00] 40 - 001f40 page 2M [0.00] 001f40 - 001f6e page 4k [0.00] kernel direct mapping tables up to 1f6e @ 17fb000-180 [0.00] RAMDISK: 1e6b6000 - 1efbc000 [0.00] ACPI: RSDP 000f6d10 00024 (v02 IBM ) [0.00] ACPI: XSDT 1f6e7e57 00054 (v01 IBMTP-1U2080 LTP ) [0.00] ACPI: FACP 1f6e7f00 000F4 (v03 IBMTP-1U2080 IBM 0001) [0.00] ACPI Warning: 32/64X length mismatch in Gpe1Block: 0/32 (20110623/tbfadt-529) [0.00] ACPI Warning: Optional field Gpe1Block has zero address or length: 0x102C/0x0 (20110623/tbfadt-560) [0.00] ACPI: DSDT 1f6e80e7 0ECE9 (v01 IBMTP-1U2080 MSFT 010E) [0.00] ACPI: FACS 1f6f8000 00040 [0.00] ACPI: SSDT 1f6e80b4 00033 (v01 IBMTP-1U2080 MSFT 010E) [0.00] ACPI: ECDT 1f6f6dd0 00052 (v01 IBMTP-1U2080 IBM 0001) [0.00] ACPI: TCPA 1f6f6e22 00032 (v01 IBMTP-1U2080 PTL 0001) [0.00] ACPI: APIC 1f6f6e54 0005A (v01 IBMTP-1U2080 IBM 0001) [0.00] ACPI: BOOT 1f6f6fd8 00028 (v01 IBMTP-1U2080 LTP 0001) [0.00] ACPI: Local APIC address 0xfee0 [0.00] 0MB HIGHMEM available. [0.00] 502MB LOWMEM available. [0.00] mapped low ram: 0 - 1f6e [0.00] low ram: 0 - 1f6e [0.00] Zone PFN ranges: [0.00] DMA 0x0010 - 0x1000 [0.00] Normal 0x1000 - 0x0001f6e0 [0.00] HighMem empty [0.00] Movable zone start PFN for each node [0.00] early_node_map[2] active PFN
Bug#641479: Ping: alpine: Contains non-free code
This is RC and appears to need a maintainer upload with a repacked upstream tarball, regardless of whether upstream will accept patches. Are any of the maintainers planning to handle this soon? -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#574990: Ping: nscd crashes after moderate use
Is this reproducible in squeeze or later? -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#650063: debian/copyright refers to outdated download location
user debian-rele...@lists.debian.org usertags 650063 + bsp-2012-03-gb-cambridge limit package powertop severity 650063 minor thanks It is not clear that the upstream tarball was not downloaded from the URI given in debian/copyright. That the URI is no longer working does not seem itself to be a policy violoation. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644138: Bug 644138: kcc and heimdal-client both install /usr/bin/kcc
Hi devel, These packages do not remotely have the same functionality: kcc: Kanji code filter heimdal-clients: Heimdal Kerberos - clients kcc appears to have shipped /usr/bin/kcc approximately since 1997. heimdal-clients introduced /usr/bin/kcc in September 2011 and #644138 was filed shortly thereafter. The bug was closed by upload: * Add conflicts with kcc to heimdal-clients. Closes: #644138 and reopened the next day as not an appropriate use of Conflicts. Quoting policy 10.1: Two different packages must not install programs with different functionality but with the same filenames. (The case of two programs having the same functionality but different implementations is handled via alternatives or the Conflicts mechanism. See Section 3.9, `Maintainer Scripts' and Section 7.4, `Conflicting binary packages - `Conflicts'' respectively.) If this case happens, one of the programs must be renamed. The maintainers should report this to the `debian-devel' mailing list and try to find a consensus about which program will have to be renamed. If a consensus cannot be reached, _both_ programs must be renamed. It has now been five months without either maintainer raising this. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636621: Re. debconf (purging /var/cache/debconf)
limit package debconf severity 636621 minor thanks Quoting fhs-2.3 /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. The data must remain valid between invocations of the application and rebooting the system. Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage). No other requirements are made on the data format of the cache directories. The accepted interpretation of the FHS distinguishes normal files from directories. In particular it is not unusual for directories under /var/cache to be shipped by a package and owned by a user or group other than root. Such directories cannot by design be recreated on demand. This is not a policy violation. Downgrading accordingly but leaving open as Joey may want to work around this anyway since debconf is one of the packages that is in a position to handle this. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582975: drm/i915: Hangcheck timer elapsed... GPU hung
On Fri, 10 Feb 2012, Jonathan Nieder wrote: Ping. Do you still have access to this hardware, and if so, are you still interested in pursuing this? I do and I am. This hasn't happened lately but I a) am tracking unstable and b) haven't been running any 3d games that might have been responsible for exercising that code. I can't remember now if this bug was related to running warzone... I obviously should have said what I was doing (if anything) on the original report. See also #592586 I'll try running warzone on the current kernel (3.2.4-1) and if that has no problems I'll attempt to get the latest squeeze kernel on here. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582975: drm/i915: Hangcheck timer elapsed... GPU hung
limit package linux-2.6 fixed 582975 3.2.4-1 thanks On Sat, 11 Feb 2012, Jonathan Nieder wrote: Edward Allcutt wrote: I'll try running warzone on the current kernel (3.2.4-1) and if that has no problems I'll attempt to get the latest squeeze kernel on here. Running warzone for 20 minutes or so didn't trigger it. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#655087: obnam --dump-memory-profile=heapy backup fails with NameError
Package: obnam
Version: 0.24.1-1
Severity: normal
And a stack trace:
File /usr/lib/python2.7/dist-packages/cliapp/app.py, line 141, in _run
self.process_args(args)
File /usr/lib/python2.7/dist-packages/obnamlib/app.py, line 127, in
process_args
cliapp.Application.process_args(self, args)
File /usr/lib/python2.7/dist-packages/cliapp/app.py, line 318, in
process_args
method(args[1:])
File /usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py,
line 124, in backup
self.backup_roots(roots)
File /usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py,
line 190, in backup_roots
metadata.md5 = self.backup_file_contents(pathname)
File /usr/lib/python2.7/dist-packages/obnamlib/plugins/backup_plugin.py,
line 342, in backup_file_contents
filename)
File /usr/lib/python2.7/dist-packages/cliapp/app.py, line 459, in
dump_memory_profile
logging.debug('# objects: %d' % len(gc.get_objects()))
NameError: global name 'gc' is not defined
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 3.1.0-1-486
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 obnam depends on:
ii libc6 2.13-24
ii python2.7.2-9
ii python-cliapp 0.23-1
ii python-larch 0.26-1
ii python-paramiko 1.7.7.1-2
ii python-tracing0.6-2
ii python-ttystatus 0.15-1
ii python2.6 2.6.7-4
ii python2.7 2.7.2-8
obnam recommends no packages.
obnam 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#655091: --dump-memory-profile should log at info level
Package: obnam Version: 0.24.1-1 Severity: wishlist Since the default is to log memory profiles at debug level. Specifying the option explicitly should log it even if the log-level is below debug. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 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 obnam depends on: ii libc6 2.13-24 ii python2.7.2-9 ii python-cliapp 0.23-1 ii python-larch 0.26-1 ii python-paramiko 1.7.7.1-2 ii python-tracing0.6-2 ii python-ttystatus 0.15-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-8 obnam recommends no packages. obnam 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#655093: obnam ls should respect --generation
Package: obnam Version: 0.24.1-1 Severity: normal Because it's mighty helpful to see what you're going to restore beforehand. In general, it would be helpful if a warning were issued when an option is used with a command that doesn't heed it. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 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 obnam depends on: ii libc6 2.13-24 ii python2.7.2-9 ii python-cliapp 0.23-1 ii python-larch 0.26-1 ii python-paramiko 1.7.7.1-2 ii python-tracing0.6-2 ii python-ttystatus 0.15-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-8 obnam recommends no packages. obnam 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#655094: Use local on-disk cache for btree nodes
Package: obnam Version: 0.24.1-1 Severity: wishlist When the repository is remote and high latency or low bandwidth the existing lru cache and upload queue have obvious benefits. However when this is combined with a low memory local system, the large in-memory cache can have an adverse effect on the system as a whole. An intermediary local disk-backed cache could relieve memory pressure while still cutting down on remote IO and associated latency. On the other hand, this may not ever do any better than the OS paging heuristics... -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 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 obnam depends on: ii libc6 2.13-24 ii python2.7.2-9 ii python-cliapp 0.23-1 ii python-larch 0.26-1 ii python-paramiko 1.7.7.1-2 ii python-tracing0.6-2 ii python-ttystatus 0.15-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-8 obnam recommends no packages. obnam 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#655095: alternative format for obnam ls
Package: obnam Version: 0.24.1-1 Severity: minor obnam ls mimicks ls -lAR, eg. /: drwxr-xr-x 19 root root 20480 2012-01-08 14:22:09 root /root: -rw--- 1 root root 10453 2012-01-03 14:39:29 .bash_history drwxr-xr-x 2 root root 80 2011-10-08 21:40:26 .vim drwxr-xr-x 2 root root 1 2010-07-20 11:18:29 .debtags -rw-r--r-- 1 root root230 2005-10-15 21:36:32 .mime.types -rw-r--r-- 1 root root167 2008-08-23 20:17:26 .vimrc -rw--- 1 root root 16391 2012-01-08 14:22:09 .viminfo -rw-r--r-- 1 root root110 2004-11-10 16:10:03 .profile drwxr-xr-x 3 root root 8 2011-08-25 08:15:47 .config -rw-r--r-- 1 root root452 2007-06-09 13:09:22 .bashrc drwx-- 2 root root 61440 2012-01-08 11:42:02 .aptitude drwx-- 2 root root 4096 2012-01-02 11:55:42 .ssh -rw--- 1 root root888 2012-01-08 14:22:22 .lesshst This format is not so easy to interpret for scripts, and to my eyes is rather ugly. I'd much prefer something imitating find -ls, eg. 28 drwxr-xr-x 21 root root 4096 Jun 14 2011 / 12330 28 drwxr-xr-x 18 root root20480 Jan 8 14:44 /root 417893 64 drwx-- 2 root root61440 Jan 8 11:42 /root/.aptitude 417908 7368 -rw-r--r-- 1 root root 7535616 Dec 22 07:24 /root/.aptitude/cache 4179254 -rw-r--r-- 1 root root 305 Jan 8 11:42 /root/.aptitude/config 151557 12 -rw--- 1 root root10453 Jan 3 14:39 /root/.bash_history 3401694 -rw-r--r-- 1 root root 452 Jun 9 2007 /root/.bashrc 3449450 drwxr-xr-x 3 root root8 Aug 25 09:15 /root/.config 2211890 drwxr-xr-x 2 root root1 Jul 20 2010 /root/.debtags 1433664 -rw--- 1 root root 903 Jan 8 14:35 /root/.lesshst 2424804 -rw-r--r-- 1 root root 230 Oct 15 2005 /root/.mime.types 369584 -rw-r--r-- 1 root root 110 Nov 10 2004 /root/.profile 390534 drwx-- 2 root root 4096 Jan 2 11:55 /root/.ssh 5496544 -rw-r--r-- 1 root root 18 May 21 2011 /root/.ssh/config 390544 -rw--- 1 root root 3243 Jan 2 11:55 /root/.ssh/id_rsa 390614 -rw-r--r-- 1 root root 735 Jan 2 11:55 /root/.ssh/id_rsa.pub 5326154 -rw-r--r-- 1 root root 419 May 21 2011 /root/.ssh/known_hosts 4478060 drwxr-xr-x 2 root root 80 Oct 8 22:40 /root/.vim 709725 16 -rw--- 1 root root16335 Jan 8 14:30 /root/.viminfo 6390004 -rw-r--r-- 1 root root 167 Aug 23 2008 /root/.vimrc Two advantages off the top of my head are: * One line per file, including directories, easing parsing. * Included inode number, allowing for hardlink detection. The former's timestamp format does look nicer though. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 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 obnam depends on: ii libc6 2.13-24 ii python2.7.2-9 ii python-cliapp 0.23-1 ii python-larch 0.26-1 ii python-paramiko 1.7.7.1-2 ii python-tracing0.6-2 ii python-ttystatus 0.15-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-8 obnam recommends no packages. obnam 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#644788: Bug#654116: RFH: screen -- terminal multiplexor with VT100/ANSI terminal emulation
On Tue, 3 Jan 2012, Marco d'Itri wrote: It does not matter, this is needed strictly for the time of the upgrade process. Just how short do you expect this to be? I'm sure many of us dist-upgrade daily and (shock! horror!) don't reboot after each upgrade. We also don't expect existing processes to break or become inaccessible after an upgrade. I mean, I'll probably cope, but it's not quite the smooth, seamless experience that I generally expect. -- Edward Allcutt Who doesn't expect to reboot unless the kernel has changed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#654207: would be nice if --pretend worked with backup
Package: obnam Version: 0.24.1-1 Severity: wishlist -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 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 obnam depends on: ii libc6 2.13-23 ii python2.7.2-9 ii python-cliapp 0.23-1 ii python-larch 0.26-1 ii python-paramiko 1.7.7.1-2 ii python-tracing0.6-1 ii python-ttystatus 0.15-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-8 obnam recommends no packages. obnam 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#654211: backup of individual file fails with ENOENT
Package: obnam Version: 0.24.1-1 Severity: normal Apparently because it's not a directory, the ENOTDIR getting lost somewhere in the layers. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.1.0-1-486 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 obnam depends on: ii libc6 2.13-23 ii python2.7.2-9 ii python-cliapp 0.23-1 ii python-larch 0.26-1 ii python-paramiko 1.7.7.1-2 ii python-tracing0.6-1 ii python-ttystatus 0.15-1 ii python2.6 2.6.7-4 ii python2.7 2.7.2-8 obnam recommends no packages. obnam 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#638322: nfs-common: rpc.statd binds to udp port 631 preventing cups startup
On Thu, 18 Aug 2011, Ben Hutchings wrote: On Thu, Aug 18, 2011 at 05:39:16PM +0200, Jan Möbius wrote: sometimes rpc.statd binds to port 631 udp which is used by cups. Therefore cups is unable to bind to its port and no printers get discovered. Rebooting the system helps as rpc.statd uses another port afterwards. This is a fundamental problem of the bindresvport() function, and not specific to rpc.statd. Reassigning to general. Sure, bindresvport is archaic, but workarounds already exist. In particular, Debian already adds /etc/bindresvport.blacklist and the default already contains port 631. Does the submitter have this file in place with the default contents? The 'portreserve' package provides a kluge to avoid this, but it requires other packages to register the ports that must be reserved. It also won't work reliably, because insserv runs init scripts in parallel and there is thus a race condition in the way services claim their ports from the portreserve daemon. That seems like a much worse kluge than the existing blacklist. Allowing packages to register reserved ports however seems a useful feature. Reassign to eglibc as request for supporting /etc/bindresvport.blacklist.d ? A proper fix probably involves using systemd's socket-activation. Yes, I said systemd - which presumably means we'll have to wait another 5 years for this to be fixed. Irrelevant. Promoting systemd for its side-effect as an amelioration for an ureliable kluge is not a strong argument. ;) [0] [0] Not intended as an argument against systemd either. -- Edward Allcutt
Bug#556045: [Resolvconf-devel] Processed: reassign
On Wed, 20 Jul 2011, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
reopen 556045
Bug #556045 {Done: Marco d'Itri m...@linux.it} [udev] udev: please provide a
way to override system keymaps in a safe way
reassign 556045 resolvconf
Bug #556045 [udev] udev: please provide a way to override system keymaps in a
safe way
Bug reassigned from package 'udev' to 'resolvconf'.
What does this bug have to do with resolvconf?
--
Edward Allcutt
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627404: klogd: pid file location changed incompatibly
Package: klogd Version: 1.5-6.1 Severity: normal Previously klogd used /var/run/klogd.pid (the compiled-in default). The new init script forces /var/run/klogd/klogd.pid and does not check for the old default. On upgrade the postinst attemts to stop and start klogd. The stop fails (silently) due to the pidfile mismatch. The start fails with a warning. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 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 klogd depends on: ii adduser 3.112+nmu2 add and remove users and groups ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip ii sysklogd [system-log-daemon] 1.5-6.1System Logging Daemon klogd recommends no packages. klogd 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#623723: remove Lock = Caps_Lock (from xmodmap) has no effect anymore
Package: xorg Version: 1:7.6+6 Followup-For: Bug #623723 I am also having this problem. Here's the output of xmodmap and part of xev by way of illustration: = == xmodmap == = xmodmap: up to 5 keys per modifier, (keycodes in parentheses): shift Shift_L (0x32), Shift_R (0x3e) lock control Control_L (0x25), Control_R (0x69) mod1Alt_L (0x40), Meta_L (0xcd) mod2Num_Lock (0x4d) mod3 mod4Caps_Lock (0x42), Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf) mod5ISO_Level3_Shift (0x5c), Mode_switch (0xcb) = = == xev == = KeyPress event, serial 25, synthetic NO, window 0x121, root 0x9a, subw 0x0, time 147127, (428,168), root:(429,188), state 0x0, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x121, root 0x9a, subw 0x0, time 147335, (428,168), root:(429,188), state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 28, synthetic NO, window 0x121, root 0x9a, subw 0x0, time 147933, (428,168), root:(429,188), state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 28, synthetic NO, window 0x121, root 0x9a, subw 0x0, time 148173, (428,168), root:(429,188), state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False = When Caps_Lock is pressed, I expect it to act as mod4, which I use for WM keys. Previously this worked, now it acts unconditionally as shift lock. -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jun 3 2006 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2018824 May 1 11:21 /usr/bin/Xorg VGA-compatible devices on PCI bus: -- 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/i915-kms.conf: options i915 modeset=1 Kernel version (/proc/version): --- Linux version 2.6.38-2-686 (Debian 2.6.38-4) (b...@decadent.org.uk) (gcc version 4.4.6 (Debian 4.4.6-2) ) #1 SMP Sat Apr 23 19:04:20 UTC 2011 Xorg X server log files on system: -- -rw-r--r-- 1 root root 25800 Feb 12 23:55 /var/log/Xorg.1.log -rw-r--r-- 1 root root 21605 May 7 17:06 /var/log/Xorg.0.log Contents of most recent Xorg X server log file (/var/log/Xorg.0.log): - [32.531] X.Org X Server 1.10.1 Release Date: 2011-04-15 [32.531] X Protocol Version 11, Revision 0 [32.531] Build Operating System: Linux 2.6.32-5-686-bigmem i686 Debian [32.531] Current Operating System: Linux jago 2.6.38-2-686 #1 SMP Sat Apr 23 19:04:20 UTC 2011 i686 [32.532] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.38-2-686 root=UUID=43c39ab8-a297-45d5-a2f6-4fd419c58689 ro quiet [32.532] Build Date: 01 May 2011 10:14:44AM [32.532] xorg-server 2:1.10.1-2 (Julien Cristau jcris...@debian.org) [32.532] Current version of pixman: 0.21.8 [32.532]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [32.532] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [32.606] (==) Log file: /var/log/Xorg.0.log, Time: Sat May 7 17:06:21 2011 [32.746] (==) Using system config directory /usr/share/X11/xorg.conf.d [32.794] (==) No Layout section. Using the first Screen section. [32.794] (==) No screen section available. Using defaults. [32.794] (**) |--Screen Default Screen Section (0) [32.794] (**) | |--Monitor default monitor [32.794] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [32.794] (==) Automatically adding devices [32.794] (==) Automatically enabling devices [33.071] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [33.071]Entry deleted from font path. [33.582] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi,
Bug#623041: Incorrect TLS certificate validation failure
Package: alpine Version: 2.02-3+b1 Severity: normal When connecting, fails with message unable to get local issuer certificate. Manually checking the certificate chain with openssl s_client and gnutls-cli shows no problems. The CN correctly matches the hostname and the root cert is in my /etc/ssl/certs/ca-certificates.crt and linked from /etc/ssl/certs. I could not ascertain precisely from where alpine gets it root cert list.. This seems to have started since the last upgrade to 2.02-3+b1 which seems relevant. Downgrading to 2.02-3 fixes the issue. Random aside: alpine is linked against both libssl.so.1.0.0 and libgnutls.so.26 !?! Let me know if you want the hostname and certificate chain and I'll forward that privately. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core) 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 alpine depends on: ii libc6 2.11.2-11 Embedded GNU C Library: Shared lib ii libgssapi-krb5-2 1.9+dfsg-1+b1 MIT Kerberos runtime libraries - k ii libkrb5-3 1.9+dfsg-1+b1 MIT Kerberos runtime libraries ii libldap-2.4-2 2.4.23-7 OpenLDAP libraries ii libncurses5 5.7+20100313-5 shared libraries for terminal hand ii libpam0g 1.1.2-2Pluggable Authentication Modules l ii libssl1.0.0 1.0.0d-2 SSL shared libraries Versions of packages alpine recommends: pn alpine-docnone (no description available) Versions of packages alpine suggests: ii aspell0.60.6-6 GNU Aspell spell-checker ii esmtp-run [mail-transport-age 1.2-5 user configurable relay-only MTA - -- 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#622305: [Pkg-urxvt-maintainers] Bug#622305: urxvt segfaults on startup
limit package rxvt-unicode fixed 622305 9.10-1 thanks On Tue, 12 Apr 2011, Ryan Kavanagh wrote: Thanks for the bug report. Thanks for the quick response. On Mon, Apr 11, 2011 at 11:29:37PM +0100, Edward Allcutt wrote: Version: 9.09-3 [...] This started happening in the last couple days. I haven't upgraded rxvt recently [...] Could you please check whether or not you can reproduce this with urxvt 9.10-1 (the current version in Debian unstable)? I can not. 9.10-1 does not segfault on startup. Thanks. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622305: urxvt segfaults on startup
Package: rxvt-unicode
Version: 9.09-3
Severity: normal
As follows:
=
$ gdb urxvt 2/dev/null | tee trace
Reading symbols from /usr/bin/urxvt...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/urxvt
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0xb79a973f in Perl_pp_require () from /usr/lib/libperl.so.5.10
(gdb) bt
#0 0xb79a973f in Perl_pp_require () from /usr/lib/libperl.so.5.10
#1 0xb79083d2 in Perl_call_sv () from /usr/lib/libperl.so.5.10
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) quit
=
Including my X resources since perl seems to be involved:
=
$ xrdb -query | fgrep -i rxvt
URxvt.background: black
URxvt.color0: black
URxvt.color1: red3
URxvt.color10: green
URxvt.color11: yellow
URxvt.color12: rgb:5c/5c/ff
URxvt.color13: magenta
URxvt.color14: cyan
URxvt.color15: white
URxvt.color2: green3
URxvt.color3: yellow3
URxvt.color4: blue2
URxvt.color5: magenta3
URxvt.color6: cyan3
URxvt.color7: gray90
URxvt.color8: gray50
URxvt.color9: red
URxvt.cutchars: BACKSLASH ‘''’()*,;:=?@[]{│}
URxvt.font: -misc-fixed-medium-r-semicondensed--13-120-75-75-c-60-iso10646-1
URxvt.foreground: gray90
URxvt.perl-ext: selection
URxvt.perl-ext-common: selection
URxvt.scrollBar:false
URxvt.termName: rxvt
URxvt.urgentOnBell: true
URxvt.visualBell: true
=
although removing the *.perl* options from the X resources doesn't help..
This started happening in the last couple days. I haven't upgraded rxvt recently
but here's a log of the upgrades I have done:
=
Aptitude 0.6.3: log report
Sun, Apr 10 2011 11:12:17 +0100
IMPORTANT: this log only lists intended actions; actions which fail due to
dpkg problems may not be completed.
Will install 34 packages, and remove 1 packages.
2,957 kB of disk space will be used
===
[REMOVE, NOT USED] libpango1.0-common
[HOLD, DEPENDENCIES] libpcsclite1
[INSTALL, DEPENDENCIES] gir1.2-freedesktop
[INSTALL, DEPENDENCIES] gir1.2-glib-2.0
[INSTALL, DEPENDENCIES] gir1.2-pango-1.0
[INSTALL, DEPENDENCIES] libgirepository-1.0-1
[UPGRADE] cpp-4.4 4.4.5-14 - 4.4.5-15
[UPGRADE] feh 1.11.2-1 - 1.12-1
[UPGRADE] g++-4.4 4.4.5-14 - 4.4.5-15
[UPGRADE] gcc-4.4 4.4.5-14 - 4.4.5-15
[UPGRADE] gcc-4.4-base 4.4.5-14 - 4.4.5-15
[UPGRADE] gstreamer0.10-plugins-base 0.10.30-1 - 0.10.32-2
[UPGRADE] gstreamer0.10-x 0.10.30-1 - 0.10.32-2
[UPGRADE] libatk1.0-0 1.32.0-1+sid1 - 1.32.0-3
[UPGRADE] libatk1.0-data 1.32.0-1+sid1 - 1.32.0-3
[UPGRADE] libatk1.0-dev 1.32.0-1+sid1 - 1.32.0-3
[UPGRADE] libgssdp-1.0-2 0.8.0-2 - 0.8.2-2
[UPGRADE] libgstreamer-plugins-base0.10-0 0.10.30-1 - 0.10.32-2
[UPGRADE] libgstreamer0.10-0 0.10.32-4 - 0.10.32-6
[UPGRADE] libgudev-1.0-0 166-1 - 167-1
[UPGRADE] libgupnp-1.0-3 0.14.0-2 - 0.14.1-2
[UPGRADE] libpango1.0-0 1.28.3-1+squeeze2 - 1.28.3-6
[UPGRADE] libpango1.0-dev 1.28.3-1+squeeze2 - 1.28.3-6
[UPGRADE] libpolkit-agent-1-0 0.99-3 - 0.101-2
[UPGRADE] libpolkit-backend-1-0 0.99-3 - 0.101-2
[UPGRADE] libpolkit-gobject-1-0 0.99-3 - 0.101-2
[UPGRADE] libstdc++6-4.4-dev 4.4.5-14 - 4.4.5-15
[UPGRADE] libudev0 166-1 - 167-1
[UPGRADE] libwebkit-1.0-2 1.2.7-1 - 1.2.7-2
[UPGRADE] libwebkit-1.0-common 1.2.7-1 - 1.2.7-2
[UPGRADE] libwebkit-dev 1.2.7-1 - 1.2.7-2
[UPGRADE] mercurial 1.8.1-1 - 1.8.1-3
[UPGRADE] mercurial-common 1.8.1-1 - 1.8.1-3
[UPGRADE] policykit-1 0.99-3 - 0.101-2
[UPGRADE] udev 166-1 - 167-1
[UPGRADE] xorg-sgml-doctools 1:1.6-1 - 1:1.7-1
===
Log complete.
=
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.38-2-686 (SMP w/1 CPU core)
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 rxvt-unicode depends on:
ii base-passwd 3.5.22 Debian base system master password
ii libafterimage0 2.2.11-3 imaging library designed for After
ii libc6 2.11.2-11Embedded GNU C Library: Shared lib
ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra
ii libfontconfig1 2.8.0-2.1generic font configuration library
ii libfreetype62.4.4-1 FreeType 2 font engine, shared lib
ii libgcc1 1:4.6.0-2GCC support library
ii libglib2.0-02.28.4-1 The GLib library of C routines
ii libgtk2.0-0 2.24.3-1~sid1The GTK+ graphical user interface
ii libice6 2:1.0.7-1X11 Inter-Client Exchange library
Bug#612179: [Resolvconf-devel] Bug#612179: resolvconf tries to awaken fetchmail even if its not running leading to failed service at boot
package resolvconf reassign 612179 fetchmail 6.3.18-2 thanks On Sun, 6 Feb 2011, kiu wrote: While booting a failed service is shown because resolvconf tries to awaken fetchmail which is not running yet. /etc/resolvconf/update-libc.d/fetchmail That update script is provided by the fetchmail package. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607814: cgroup-bin: cgred init script sources wrong defaults file
Package: cgroup-bin Version: 0.37-1 Severity: normal /etc/init.d/cgred sources /etc/default/cgred.conf but the package installs /etc/default/cgred ... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 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 cgroup-bin depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcgroup10.37-1 A library to control and monitor c cgroup-bin recommends no packages. cgroup-bin suggests no packages. -- Configuration Files: /etc/cgconfig.conf changed [not included] -- 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#607816: cgroup-bin: cgred init script uses signal number 12
Package: cgroup-bin Version: 0.37-1 Severity: normal /etc/init.d/cgred runs kill -s 12 ... Signal 12 is SIGUSR2 on x86 and some others but appears to be SIGSYS on alpha, sparc and mips[0]. This might lead to trouble on those architectures... [0] signal(7) -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 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 cgroup-bin depends on: ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib ii libcgroup10.37-1 A library to control and monitor c cgroup-bin recommends no packages. cgroup-bin suggests no packages. -- Configuration Files: /etc/cgconfig.conf changed [not included] -- 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#595521: bug 595521
On Mon, 6 Sep 2010, Borden Rhodes wrote: Yes. We'll sort things out before release, but from KMS is not a critical kernel bug. Well it's critical that our computers return to a _bootable_ state and not locking up where everything, including the keyboard, is unresponsive. May we at least get a workaround until the higher brains decide what to do? I'd suggest either downgrading the kernel or forcing the vesa driver if you can live without accelerated video. Put this in /etc/X11/xorg.conf: Section Device Identifier foo Driver vesa EndSection -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595521: i915: system locks up when starting X
On Sun, 5 Sep 2010, Cesare Leonardi wrote: Unfortunately this is a common problem that i855 owners are facing: look at #595511. Thanks for the pointer. It looks as though that one went in after I'd checked for recent bugs but before I finished composing my report. I also managed to miss all the reports against xserver-xorg-video-intel as I only looked at those against the kernel. Kernel-team: to me these two bugs could be merged. Since #594623 is considered grave (same issue reported against X driver), any objection to upping the severity of #595511/#595521 which was downgraded to important by the forcemerge? -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#595521: i915: system locks up when starting X
Package: linux-2.6 Version: 2.6.32-21 Severity: critical Justification: breaks the whole system By locks up I mean: * Screen blanks * Unresponsive to network * Unresponsive to sysrq * No disk activity * No logs written to disk after that point in time I have xserver-xorg-video-intel 2:2.12.0+legacy1-1 installed. Before rebooting today I was previously running with this version of the X driver and the previous version (2.6.32-20) of the kernel. I had noted with some trepidation the changelog entry about disabling KMS for i855 as I've been using that with great success for months. I have noted that the current X package still ships /etc/modprobe.d/i915-kms.conf which forces modeset=1. I have attempted loading the driver with modeset=0 instead but it yields the same result. Looking at the closed bugs in the changelog, only #582105 seems to bear on i855 directly and the information there seems insufficient to warrant disabling KMS support entirely. lspci -nn = 00:00.0 Host bridge [0600]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3580] (rev 02) 00:00.1 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3584] (rev 02) 00:00.3 System peripheral [0880]: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller [8086:3585] (rev 02) 00:02.0 VGA compatible controller [0300]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:02.1 Display controller [0380]: Intel Corporation 82852/855GM Integrated Graphics Device [8086:3582] (rev 02) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 01) 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 01) 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 01) 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 01) 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 81) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 01) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 01) 00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] (rev 01) 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 01) 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 01) 02:00.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev 8d) 02:00.1 SD Host controller [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 13) 02:01.0 Ethernet controller [0200]: Intel Corporation 82541GI Gigabit Ethernet Controller [8086:1077] 02:02.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection [8086:4220] (rev 05) = -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-21) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Wed Aug 25 14:28:12 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=43c39ab8-a297-45d5-a2f6-4fd419c58689 ro quiet ** Not tainted ** Kernel log: [1.401739] uhci_hcd :00:1d.2: setting latency timer to 64 [1.401744] uhci_hcd :00:1d.2: UHCI Host Controller [1.401758] uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 4 [1.401787] uhci_hcd :00:1d.2: irq 18, io base 0x1860 [1.401827] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 [1.401831] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.401834] usb usb4: Product: UHCI Host Controller [1.401838] usb usb4: Manufacturer: Linux 2.6.32-5-686 uhci_hcd [1.401841] usb usb4: SerialNumber: :00:1d.2 [1.401962] usb usb4: configuration #1 chosen from 1 choice [1.402040] hub 4-0:1.0: USB hub found [1.402049] hub 4-0:1.0: 2 ports detected [1.402277] ata_piix :00:1f.1: version 2.13 [1.402288] ata_piix :00:1f.1: enabling device (0005 - 0007) [1.402294] ata_piix :00:1f.1: PCI INT A - GSI 18 (level, low) - IRQ 18 [1.402337] ata_piix :00:1f.1: setting latency timer to 64 [1.402855] sdhci: Secure Digital Host Controller Interface driver [1.402858] sdhci: Copyright(c) Pierre Ossman [1.405856] scsi0 : ata_piix [1.406467] scsi1 : ata_piix [1.407657] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x1810 irq 14 [1.407661] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x1818 irq 15 [1.637426] e1000: :02:01.0: e1000_probe: (PCI:33MHz:32-bit)
Bug#592586: xserver-xorg-video-intel: Rendering issues: Detected a hung GPU, disabling acceleration
Package: xserver-xorg-video-intel Version: 2:2.12.0-1 Severity: important This seems to be triggered by apps using accelerated video or 3d. This time it was warzone2100 but I've seen it before with just a few terminals and a web browser. The first symptom is that the (fullscreen) display of the game seems to freeze. The mouse cursor is not drawn although I can tell from audible feedback that the game is still running and keypresses seem to have the expected effect. I'm using the awesome window manager. Switching to another tag displays the desktop background fine. The awesome toolbars and widgets are drawn but with some gaps and any text is quite fuzzy as though being drawn multiple times at slightly differing pixel offsets. At this point I can see the mouse cursor again. Other (less-accelerated) apps show different levels of corruption. For example, in rxvt, the cursor and any ncurses-drawn widgets are missing, but text is for the most part ok. xterm on the other hand appears to have no problems at all. Switching VT and the text framebuffer console seems to work with no issues. The included Xorg.0.log in the Package-specific info is for X after being restarted twice. Unfortunately the log for the original problem occurence is gone. After restarting X once I tried to run warzone2100 again at which point X crashed. The log for that brief session includes these lines: === BEGIN == (EE) intel(0): Detected a hung GPU, disabling acceleration. Backtrace: 0: /usr/bin/X (xorg_backtrace+0x3b) [0x80d91fb] 1: /usr/bin/X (0x8048000+0x581d5) [0x80a01d5] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xb771340c] 3: /usr/lib/xorg/modules/extensions/libdri2.so (0xb7343000+0x1d8c) [0xb7344d8c] 4: /usr/bin/X (0x8048000+0x38067) [0x8080067] 5: /usr/bin/X (0x8048000+0x1e92a) [0x806692a] 6: /lib/i686/cmov/libc.so.6 (__libc_start_main+0xe6) [0xb744ac76] 7: /usr/bin/X (0x8048000+0x1e511) [0x8066511] Segmentation fault at address (nil) Fatal server error: Caught signal 11 (Segmentation fault). Server aborting === END == Some interesting lines from the kernel log: (edited to remove wireless decrypt failures) === BEGIN == [ 11.151745] [drm] Initialized drm 1.1.0 20060810 [ 11.808500] i915 :00:02.0: power state changed by ACPI to D0 [ 11.808551] i915 :00:02.0: power state changed by ACPI to D0 [ 11.808560] i915 :00:02.0: PCI INT A - GSI 16 (level, low) - IRQ 16 [ 11.808567] i915 :00:02.0: setting latency timer to 64 [ 11.813074] [drm] set up 7M of stolen space [ 11.842095] [drm] initialized overlay support [ 12.967093] Console: switching to colour frame buffer device 128x48 [ 12.977492] fb0: inteldrmfb frame buffer device [ 12.977495] registered panic notifier [ 12.980259] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 [ 13.652816] Intel ICH :00:1f.5: PCI INT B - GSI 17 (level, low) - IRQ 17 [ 13.652846] Intel ICH :00:1f.5: setting latency timer to 64 [168514.348021] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung [168514.348034] render error detected, EIR: 0x [168514.348047] [drm:i915_do_wait_request] *ERROR* i915_do_wait_request returns -5 (awaiting 13806744 at 13806727) === END == I previously reported a similar issue as #582975. That got no response and the symptoms were different enough that I thought a separate report was in order. -- Package-specific info: /var/lib/x11/X.roster does not exist. /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Jun 3 2006 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1725304 Jul 15 17:15 /usr/bin/Xorg /var/lib/x11/xorg.conf.roster does not exist. VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) /etc/X11/xorg.conf does not exist. Kernel version (/proc/version): Linux version 2.6.32-5-686 (Debian 2.6.32-18) (b...@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-2) ) #1 SMP Sat Jul 24 02:27:10 UTC 2010 Xorg X server log files on system: -rw-r--r-- 1 root root 25676 Aug 11 09:41 /var/log/Xorg.0.log Contents of most recent Xorg X server log file /var/log/Xorg.0.log: X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.26-2-amd64 i686 Debian Current Operating System: Linux jago 2.6.32-5-686 #1 SMP Sat Jul 24 02:27:10 UTC 2010 i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=43c39ab8-a297-45d5-a2f6-4fd419c58689 ro quiet Build Date: 15 July 2010 04:10:53PM xorg-server 2:1.7.7-3 (Cyril Brulebois k...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning,
Bug#591341: luakit: segfaults on startup
On Fri, 6 Aug 2010, Clint Adams wrote: On Mon, Aug 02, 2010 at 11:04:49PM +0100, Edward Allcutt wrote: D: luakit: luaH_parserc:556: Program received signal SIGSEGV, Do you have an rc.lua file? Initially I did not. Now I do. It doesn't seem to make much difference. I do notice that running the recompiled version prints quite a bit of debug/trace info. The first line is D: luakit: luaH_parserc:568: Loading rc file: /home/ema29/.config/luakit/rc.lua anyway. Does 0~20100806-1 fare any better? Yes. I'd close it now but the problems seems to have been with the specific build rather than anything in the old source package. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#591341: luakit: segfaults on startup
Package: luakit Version: 0~20100725-1 Severity: normal As follows: $ luakit D: luakit: luaH_parserc:566: Segmentation fault $ Rebuilding from the source package seems to fix it. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages luakit depends on: ii libatk1.0-0 1.30.0-1 The ATK accessibility toolkit ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libfontconfig12.8.0-2.1 generic font configuration library ii libfreetype6 2.4.0-2FreeType 2 font engine, shared lib ii libglib2.0-0 2.24.1-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii liblua5.1-0 5.1.4-5Simple, extensible, embeddable pro ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii libsoup2.4-1 2.30.2-1 an HTTP library implementation in ii libwebkit-1.0-2 1.2.1-2Web content engine library for Gtk ii libxdg-basedir1 1.0.2-1implementation of the XDG Base Dir luakit recommends no packages. luakit 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#591341: luakit: segfaults on startup
On Mon, 2 Aug 2010, Clint Adams wrote: On Mon, Aug 02, 2010 at 11:02:24AM +0100, Edward Allcutt wrote: As follows: $ luakit D: luakit: luaH_parserc:566: Segmentation fault $ Rebuilding from the source package seems to fix it. Could you run it in gdb and get a backtrace for us? Sure, but since it's stripped it didn't seem very useful: $ gdb luakit Reading symbols from /usr/bin/luakit...(no debugging symbols found)...done. # run Starting program: /usr/bin/luakit [Thread debugging using libthread_db enabled] D: luakit: luaH_parserc:556: Program received signal SIGSEGV, Segmentation fault. 0xb67e760b in vfprintf () from /lib/i686/cmov/libc.so.6 # bt #0 0xb67e760b in vfprintf () from /lib/i686/cmov/libc.so.6 #1 0xb67e8fc2 in ?? () from /lib/i686/cmov/libc.so.6 #2 0xb67e3f13 in vfprintf () from /lib/i686/cmov/libc.so.6 #3 0xb69b044f in g_vfprintf () from /lib/libglib-2.0.so.0 #4 0x0804f385 in ?? () #5 0x0804c033 in ?? () #6 0x0804d4bc in ?? () #7 0x0804d726 in ?? () #8 0xb67bdc76 in __libc_start_main () from /lib/i686/cmov/libc.so.6 #9 0x0804be01 in ?? () # I tried to rebuild it with debugging symbols but was unable to reproduce the problem. Installing the rebuilt (unmodified) source package made the problem go away. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584572: symbol lookup error: undefined symbol
On Fri, 4 Jun 2010, Matthias Klose wrote:
works for me, can anybody else reproduce this?
On a different machine, also mostly testing/unstable
with libstdc++6 from experimental:
$ cat test.cpp
#include cstdio
int main() {
puts(Hello World!\n);
return 0;
}
$ g++ -o test test.cpp
$ ./test
./test: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4
$
Additionally, with v4.5.0-5
$ readelf -aW /usr/lib/libstdc++.so.6 | fgrep
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE@@GLIBCXX_3.4
144: 000e9734 4 OBJECT UNIQUE DEFAULT 28
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE@@GLIBCXX_3.4
$
but with v4.4.4-1
$ readelf -aW /usr/lib/libstdc++.so.6 | fgrep
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE@@GLIBCXX_3.4
144: 000ef6b4 4 OBJECT WEAK DEFAULT 28
_ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE@@GLIBCXX_3.4
$
I don't know whether the WEAK/UNIQUE difference is significant, I just happened
to notice it.
--
Edward Allcutt
Network Operations
Gleim Publications
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#584572: symbol lookup error: undefined symbol
Package: libstdc++6 Version: 4.5.0-5 Severity: critical Tags: experimental After upgrading libstdc++6 this morning, various C++ software began failing. The original version upgraded from was 4.5.0-4 so the problem appears to be introduced in this specific version. Following is a transcript of reproducing the problem. = # apt-cache policy libstdc++6 libstdc++6: Installed: 4.4.4-1 Candidate: 4.4.4-1 Version table: 4.5.0-5 0 700 http://dpkg.teamgleim.com rc-buggy/main Packages 4.4.4-4 0 800 http://dpkg.teamgleim.com sid/main Packages *** 4.4.4-1 0 900 http://dpkg.teamgleim.com squeeze/main Packages 100 /var/lib/dpkg/status # aptitude install libstdc++6/experimental Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information... Done Initializing package states... Done The following packages will be upgraded: libstdc++6 1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Need to get 345kB of archives. After unpacking 16.4kB will be freed. Do you want to continue? [Y/n/?] Writing extended state information... Done Get:1 http://dpkg.teamgleim.com rc-buggy/main libstdc++6 4.5.0-5 [345kB] Fetched 345kB in 0s (8,694kB/s) Reading changelogs... Done (Reading database ... 137430 files and directories currently installed.) Preparing to replace libstdc++6 4.4.4-1 (using .../libstdc++6_4.5.0-5_i386.deb) ... Unpacking replacement libstdc++6 ... Setting up libstdc++6 (4.5.0-5) ... Reading package lists... Done Building dependency tree Reading state information... Done Reading extended state information... Done Initializing package states... Done Writing extended state information... Done Current status: 0 updates [-1]. # apt-cache policy libstdc++6 apt-cache: symbol lookup error: /usr/lib/libstdc++.so.6: undefined symbol: _ZNSt7num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE2idE, version GLIBCXX_3.4 # = I'm going to downgrade to the version in squeeze now, but I can reupgrade any time if more details are needed. -- System Information: Debian Release: squeeze/sid Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libstdc++6 depends on: ii gcc-4.5-base 4.5.0-5The GNU Compiler Collection (base ii libc6 2.10.2-9 Embedded GNU C Library: Shared lib ii libgcc1 1:4.5.0-5 GCC support library libstdc++6 recommends no packages. libstdc++6 suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#582975: drm/i915: Hangcheck timer elapsed... GPU hung
Issue still reproducible with kernel version 2.6.32-15. I've additionally attached my latest Xorg.0.log as it seems to have some possibly related errors towards the end. -- Edward Allcutt X.Org X Server 1.7.7 Release Date: 2010-05-04 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.32-4-686 i686 Debian Current Operating System: Linux jago 2.6.32-5-686 #1 SMP Tue Jun 1 04:59:47 UTC 2010 i686 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=43c39ab8-a297-45d5-a2f6-4fd419c58689 ro quiet Build Date: 04 May 2010 03:43:42PM xorg-server 2:1.7.7-1 (Julien Cristau jcris...@debian.org) Current version of pixman: 0.16.4 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Fri Jun 4 23:38:12 2010 (==) Using system config directory /usr/share/X11/xorg.conf.d (==) No Layout section. Using the first Screen section. (==) No screen section available. Using defaults. (**) |--Screen Default Screen Section (0) (**) | |--Monitor default monitor (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. (==) Automatically adding devices (==) Automatically enabling devices (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. Entry deleted from font path. (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins (==) ModulePath set to /usr/lib/xorg/modules (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. (II) Loader magic: 0x81ea020 (II) Module ABI versions: X.Org ANSI C Emulation: 0.4 X.Org Video Driver: 6.0 X.Org XInput driver : 7.0 X.Org Server Extension : 2.0 (++) using VT number 7 (WW) xf86OpenConsole: setpgid failed: Operation not permitted (WW) xf86OpenConsole: setsid failed: Operation not permitted (--) PCI:*(0:0:2:0) 8086:3582:1014:0557 Intel Corporation 82852/855GM Integrated Graphics Device rev 2, Mem @ 0xe000/134217728, 0xd000/524288, I/O @ 0x1800/8 (--) PCI: (0:0:2:1) 8086:3582:1014:0557 Intel Corporation 82852/855GM Integrated Graphics Device rev 2, Mem @ 0xe800/134217728, 0xd008/524288 (II) Open ACPI successful (/var/run/acpid.socket) (II) LoadModule: extmod (II) Loading /usr/lib/xorg/modules/extensions/libextmod.so (II) Module extmod: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension SELinux (II) Loading extension MIT-SCREEN-SAVER (II) Loading extension XFree86-VidModeExtension (II) Loading extension XFree86-DGA (II) Loading extension DPMS (II) Loading extension XVideo (II) Loading extension XVideo-MotionCompensation (II) Loading extension X-Resource (II) LoadModule: dbe (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so (II) Module dbe: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DOUBLE-BUFFER (II) LoadModule: glx (II) Loading /usr/lib/xorg/modules/extensions/libglx.so (II) Module glx: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (==) AIGLX enabled (II) Loading extension GLX (II) LoadModule: record (II) Loading /usr/lib/xorg/modules/extensions/librecord.so (II) Module record: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.13.0 Module class: X.Org Server Extension ABI class: X.Org Server Extension, version 2.0 (II) Loading extension RECORD (II) LoadModule: dri (II) Loading /usr/lib/xorg/modules/extensions/libdri.so (II) Module dri: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.0.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension XFree86-DRI (II) LoadModule: dri2 (II) Loading /usr/lib/xorg/modules/extensions/libdri2.so (II) Module dri2: vendor=X.Org Foundation compiled for 1.7.7, module version = 1.1.0 ABI class: X.Org Server Extension, version 2.0 (II) Loading extension DRI2 (==) Matched intel as autoconfigured driver 0 (==) Matched vesa as autoconfigured driver 1 (==) Matched fbdev as autoconfigured driver 2 (==) Assigned the driver to the xf86ConfigLayout (II) LoadModule
Bug#582975: drm/i915: Hangcheck timer elapsed... GPU hung
Package: linux-2.6 Version: 2.6.32-13 Severity: important X session appears to hang. Switching to VT still works fine. Switching back to X shows same screen contents from VT. X cursor is drawn and changes depending on window with focus (eg. text cursor over rxvt). Am able to switch between virtual desktops and close apps and WM (awesome) via keyboard shortcuts (deduced by mouse cursor changing and by ps output on VT). KMS is enabled. lspci output below: 00:00.0 Host bridge: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.1 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:00.3 System peripheral: Intel Corporation 82852/82855 GM/GME/PM/GMV Processor to I/O Controller (rev 02) 00:02.0 VGA compatible controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:02.1 Display controller: Intel Corporation 82852/855GM Integrated Graphics Device (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 (rev 01) 00:1d.1 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 (rev 01) 00:1d.2 USB Controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 (rev 01) 00:1d.7 USB Controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller (rev 01) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge (rev 01) 00:1f.1 IDE interface: Intel Corporation 82801DBM (ICH4-M) IDE Controller (rev 01) 00:1f.3 SMBus: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller (rev 01) 00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 01) 00:1f.6 Modem: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller (rev 01) 02:00.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 8d) 02:00.1 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 13) 02:01.0 Ethernet controller: Intel Corporation 82541GI Gigabit Ethernet Controller 02:02.0 Network controller: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection (rev 05) Let me know if I can provide any more details. -- Package-specific info: ** Version: Linux version 2.6.32-5-686 (Debian 2.6.32-13) (m...@debian.org) (gcc version 4.3.4 (Debian 4.3.4-10) ) #1 SMP Wed May 19 19:51:54 UTC 2010 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-686 root=UUID=43c39ab8-a297-45d5-a2f6-4fd419c58689 ro quiet ** Not tainted ** Kernel log: [1.617358] hub 3-0:1.0: USB hub found [1.617367] hub 3-0:1.0: 2 ports detected [1.617417] uhci_hcd :00:1d.2: PCI INT C - GSI 18 (level, low) - IRQ 18 [1.617426] uhci_hcd :00:1d.2: setting latency timer to 64 [1.617430] uhci_hcd :00:1d.2: UHCI Host Controller [1.617439] uhci_hcd :00:1d.2: new USB bus registered, assigned bus number 4 [1.617468] uhci_hcd :00:1d.2: irq 18, io base 0x1860 [1.617505] usb usb4: New USB device found, idVendor=1d6b, idProduct=0001 [1.617509] usb usb4: New USB device strings: Mfr=3, Product=2, SerialNumber=1 [1.617513] usb usb4: Product: UHCI Host Controller [1.617516] usb usb4: Manufacturer: Linux 2.6.32-5-686 uhci_hcd [1.617519] usb usb4: SerialNumber: :00:1d.2 [1.617604] usb usb4: configuration #1 chosen from 1 choice [1.617641] hub 4-0:1.0: USB hub found [1.617649] hub 4-0:1.0: 2 ports detected [1.780378] ata1.00: ATA-5: HITACHI_DK13FA-40B, 00MCA0B4, max UDMA/100 [1.780383] ata1.00: 78140160 sectors, multi 16: LBA [1.790157] ata1.00: configured for UDMA/100 [1.790304] scsi 0:0:0:0: Direct-Access ATA HITACHI_DK13FA-4 00MC PQ: 0 ANSI: 5 [1.799296] e1000: eth0: e1000_probe: Intel(R) PRO/1000 Network Connection [1.801110] sdhci-pci :02:00.1: SDHCI controller found [1180:0822] (rev 13) [1.801130] sdhci-pci :02:00.1: PCI INT B - GSI 17 (level, low) - IRQ 17 [1.803222] Registered led device: mmc0:: [1.804315] mmc0: SDHCI controller on PCI [:02:00.1] using PIO [1.812584] sd 0:0:0:0: [sda] 78140160 512-byte logical blocks: (40.0 GB/37.2 GiB) [1.812660] sd 0:0:0:0: [sda] Write Protect is off [1.812665] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [1.812697] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [1.812874] sda: sda1 sda2 [1.955081] sd 0:0:0:0: [sda] Attached SCSI disk [2.175783] JFS: nTxBlock = 3949, nTxLock = 31593 [2.180054] usb 4-1: new full speed USB device using uhci_hcd and address 2 [2.384052] usb 4-1: New USB device found, idVendor=1668, idProduct=2441 [2.384057] usb 4-1: New USB device strings: Mfr=0, Product=0, SerialNumber=3 [2.384061] usb 4-1: SerialNumber: 〳㈴〱〳㈱㜴 [2.384196] usb 4-1:
Bug#575941: No manual entry for nxproxy
Package: nxproxy Version: 3.2.0-1-1 Severity: normal If (as mentioned in README.Debian) it really should not be called directly by a user then don't put it in all user's default PATH. Otherwise some sort of man page would be nice. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.32-4-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nxproxy depends on: ii libc62.10.2-6Embedded GNU C Library: Shared lib ii libgcc1 1:4.4.2-9 GCC support library ii libstdc++6 4.4.2-9 The GNU Standard C++ Library v3 ii libxcomp33.2.0-7-1.1 NX X compression library Versions of packages nxproxy recommends: pn qtnx none (no description available) nxproxy 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#566304: javac -source does not implicitly set default for -target
Package: openjdk-6-jdk
Version: 6b11-9.1+lenny2
Severity: normal
File: /usr/lib/jvm/java-6-openjdk/bin/javac
Specifically, compiling with -source 1.5 does not produce class files
compatible with a 1.5 jvm. Compiling with -target 1.5 does.
From javac(1): The default for -target depends on the value of -source:
[...] For all other values of -source, the value of -target is the value
of -source.
Reproduction steps:
$ javac -source 1.5 HelloWorld.java
$ javap -verbose HelloWorld | fgrep 'major version:'
major version: 50
$ javac -target 1.5 HelloWorld.java
$ javap -verbose HelloWorld | fgrep 'major version:'
major version: 49
From the documentation, (and apparently from the Java Specification, but I
haven't looked that up personally), we would expect both compilations to
produce class files with major version 49.
-- System Information:
Debian Release: 5.0.3
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-686 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages openjdk-6-jdk depends on:
ii dpkg 1.14.25 Debian package management system
ii libc6 2.7-18GNU C Library: Shared libraries
ii libx11-6 2:1.1.5-2 X11 client-side library
ii openjdk-6-jre 6b11-9.1+lenny2 OpenJDK Java runtime, using Hotspo
ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime
Versions of packages openjdk-6-jdk recommends:
pn libxt-dev none (no description available)
Versions of packages openjdk-6-jdk suggests:
pn openjdk-6-demonone (no description available)
pn openjdk-6-source none (no description available)
-- no debconf information
public class HelloWorld {
public static void main(String[] args) {
System.out.println(Hello World!);
}
}
Bug#534964: marked as done (Please enable CONFIG_CGROUP_MEM_RES_CTLR)
reopen 534964 thanks Please do not close bugs until a package that includes the bug fix enters the Debian archive. [0] This should usually be achieved by including a note in the new changelog entry. [0] - http://www.debian.org/Bugs/Developer#closing -- Edward Allcutt Network Operations Gleim Publications -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550963: maatkit: mk-table-checksum fails with Useless use of a constant in void context
Package: maatkit Version: 4334-1 Severity: important Full error: Useless use of a constant in void context at /usr/bin/mk-table-checksum line 1056. This happens with all combinations of arguments I tried. It was working yesterday. Probably related that I upgraded perl packages from 5.10.0-25 to 5.10.1-5 yesterday evening. Commenting out all instances of use strict and use warnings FATAL = 'all' seems to be usable as a workaround. -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.30-2-686+mem (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages maatkit depends on: ii libdbd-mysql-perl 4.012-1+b1 A Perl5 database interface to the ii libdbi-perl 1.609-1Perl Database Interface (DBI) ii libterm-readkey-perl 2.30-4 A perl module for simple terminal ii perl 5.10.1-5 Larry Wall's Practical Extraction maatkit recommends no packages. maatkit 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#514807: a proposal for consideration for V1 CA certs in Etch (and Lenny?)
Simon Josefsson wrote: Daniel Kahn Gillmor d...@fifthhorseman.net writes: 0) Leave the library as it is; tools must use GnuTLS in the documented way (by setting GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT) if they want to trust V1 certificates as certificate authorities. This appears to be the Right Thing in general, and happens to also be the simplest for me as GnuTLS maintainer, so it is what the upstream GnuTLS package will use. Or rather, it is what upstream will continue to use, nothing in the documentation or intended behaviour has changed in the last few years here. This seems like a reasonable approach for upstream. For etch I believe it's too disruptive a change. For lenny... well I'm not sure. It may be possible to patch all the relevant apps for the first point release but: a) I don't know if this is an acceptable fix now that lenny is stable. b) A number of systems will break on upgrade until the fixes get out. c) This should probably be added to the release notes, is that still possible? 1) same as 0, but we special-case the limited set of publically-known V1 CA certificates shipped in the ca-certificates package: if any of those exact certificates are included in the trusted certificates list, they will be accepted as CAs even if GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT is not set. Sounds pragmatic to me, although somewhat complex and I suspect we'll see increasing requests to add to that list of exceptions. I won't produce a patch for this, it seems somewhat messy. Too messy to get into etch certainly. Probably too messy for lenny too. 2) same as 1, but rather than test exact matches against the specific V1 CA certs in ca-certificates, allow the use of V1 certificates as CAs if they meet the following requirements: Sounds reasonable, but I'm suspicious that these special case rules won't turn out to match the exact set of certs that we'd wish. It also sounds less messy than 1) but still adding a big chunk of new code. 3) default to having GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT be set This is essentially the (untested) patch I proposed earlier. I have tested it. See http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=144;bug=514807 I've had no issues in my (limited) testing. I'm going to deploy it to a more heavily used system and see if anything crops up. Also: maybe we want to use one approach for etch, and a different one for lenny. With a well-thought out transition strategy, we could minimize some of the potential pain. Yes, I am beginning to think that possibly 3) may be appropriate for etch, although I'm not sure how large of a problem this actually is. If it is not a large problem, maybe the answer should just be that they need to renew their certificates with a better CA (or set up their own CA). I think my views for etch are clear. I should add that this is not simply an issue with checking my own organization's certificates. Some libgnutls-linked apps need to verify 3rd-party certificates which I (and other Debian users) have no control over. I think mail.google.com was mentioned as an example. For lenny I'm far more flexible. So long as the issue gets resolved (soon) I don't particularly mind how. Whether 0) or 3) or some compromise is chosen will depend more on what changes are acceptable now that lenny is stable. PS i really don't like the monopolistic/money-grubbing/unethical behavior of most of the dominant commercial CAs; i feel like their general motives are at odds with my personal goals of having end-to-end secure connections available for any netizen. So explicitly grandfathering these groups into gnutls X.509 verification (option 1) irks me not a little bit. However, newer CAs can (and do) use V3 root certs, so i don't feel that we would be further entrenching the 800-pound gorillas. I don't disagree with your views of the big players, however I think this is a red herring. There does seem to be an ongoing transition away from v1 certs but it appears to be rather a slow process. I don't think GnuTLS is really in a position to strong-arm the big players into hurrying things along. -- Edward Allcutt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
Simon Josefsson wrote: Florian Weimer f...@deneb.enyo.de writes: There doesn't seem to be industry consensus that X.509v1 root certificates are a bad idea. This means that users have little leverage against CAs and server operators when confronted with problematic certificates. Doesn't the same hold for RSA-MD5 signatures? I'm not sure industry consensus is a good measure here. What we are relying on here is this part of RFC 5280: Considering that gnutls is aiming to interoperate with software and certificates produced by this industry (including OpenSSL and yaSSL) I'd say consensus is of the utmost importance. Despite what we may wish about conformance with published standards, the de facto standards don't exclude v1 certs or RSA-MD5, although the latter is certainly on the way out. (k) If certificate i is a version 3 certificate, verify that the basicConstraints extension is present and that cA is set to TRUE. (If certificate i is a version 1 or version 2 certificate, then the application MUST either verify that certificate i is a CA certificate through out-of-band means or reject the certificate. Conforming implementations may choose to reject all version 1 and version 2 intermediate certificates.) GnuTLS doesn't have any API to provide this out-of-band information, so we simply reject version 1 certificates (unless a flag is set). That seems like a good enough API to me. If the application is providing a list of CA certs then it should set the flag. That is, however unintentionally, an API change that shouldn't get pushed out silently as a stable security update. Hm. It is interesting that it says 'intermediate certificates' in the last sentence. I think this is mistaken, the part of the algorithm applies to root certificates as well as end-entity certificates too. I think it is not mistaken. To me it looks precise: Intermediate certificates MAY be rejected but out-of-band-verified root certificates MAY NOT be. I've tested the previously posted patch which adds GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT to verify_flags. This restores the previous behavior of trusting v1 certs on the trusted list. I tested for the versions in etch (1.4.4-3+etch3) and lenny (2.6.4-1). Both nss_ldap and apache mod_ldap began working again with the patched libgnutls installed. Is there anything else I can do to get this regression fixed at least in etch? I'd rather not maintain my own patched version of gnutls. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
Florian Weimer wrote: * Edward Allcutt: I believe this is a significant regression in stable because at least one widely used CA (godaddy) still issues certificates with a chain ending in a v1 root (ValiCert Class 2). Are we talking about this certificate? Subject: L=ValiCert Validation Network, O=ValiCert, Inc., OU=ValiCert Class 2 Policy Validation Authority, CN=http://www.valicert.com//emailaddress=i...@valicert.com That's the one. It's not just a X.509v1 certificate. It's ten years old, it's just 1024 bits, and ValiCert does not exist anymore as an organization (thus the DN is invalid). I'm not any happier about it than you are, but it seems godaddy are still issuing certs using that root. Simon, could we make the harmless variant (X.509v1 certificate set as trusted is accepted as a root CA, but intermediate X.509v1 certificates aren't accepted) the default in etch? Godaddy appears to have a newer v3 root but I don't know how widely deployed this is. It is not in the etch ca-certificates package for example. Which root are you referring to? They're all available at https://certs.godaddy.com/Repository.go. The main new one seems to be Go Daddy Class 2 CA which is in lenny ca-certificates as /usr/share/ca-certificates/mozilla/Go_Daddy_Class_2_CA.crt The other new one is Starfield Services which is in lenny ca-certificates as /usr/share/ca-certificates/mozilla/Starfield_Class_2_CA.crt Neither of these are in etch, and in fact neither of them seem to have the critical flag set for their X509v3 Basic Constraints, which I've seen mentioned as an issue in other bug reports. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Simon Josefsson wrote: Edward Allcutt emall...@gleim.com writes: retitle 514807 X.509v1 CA certs no longer trusted implicitly thanks This didn't appear to work for me. Would someone mind pointing out my mistake? Simon Josefsson wrote: I believe the problem is that you have a V1 CA, which isn't permitted by default by libgnutls. Only since this security update. I'm not saying that not trusting VA CAs shouldn't be the correct ideal behavior but it does seem very impractical right now. At the very least, can you postpone this change in functionality until lenny? That's not my call to make, but haven't this fixed been rolled out for etch already? Anyway, I believe it is the right fix too: otherwise etch users are left vulnerable. It has been release for etch, that's the main cause of my problems right now. I don't recommend doing the same in other applications, and we should probably remove it from gnutls-cli too. It may be useful to create a parameter in other tools to enable the flag on a per-case basis, though. Those applications which need to change their flags should of course be patched to do so, but not in stable. This seems like a change in the API of libgnutls. A change towards what is documented, granted, but a change nonetheless and away from what most applications seem to expect. The behaviour you have been seeing has always been the documented and intended behaviour. The _implementation_ had a security bug, which caused these certificate chains to be accepted anyway. And several applications depended on this bug. If there are other applications which are actually more secure because of the change should we instead release security updates for the apps which were depending on the bug? That seems acceptable to me. What does the security team think of this approach? I agree that whether this is a ABI change or not is a rather subtle issue. The patch does change what the user is seeing, so there is some externally visible change. Usually that means the ABI version has to be incremented. On the other hand, _any_ security patch is in the same situation. When you close a security hole, you change how users can interact with the software. However I don't think a security patch is a valid reason to bump the ABI version. Debian etc need to be able to fix security problems without bumping the ABI version of a library and re-linking every application. I believe the ideal goal is that security patches don't have side effects that alter behavior unexpectedly (and hence no ABI/API change etc.). That constraint doesn't seem to have been met in this case, which is why I'm asking either for the patch to be modified (which seems simpler) or additional patches for all the affected apps. I'm willing to try and produce patches for nss_ldap, pam_ldap and possibly apache but not to go hunting for other apps that might be affected. For explanation of why V1 CA's are bad, see: I understand that. The argument against GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is very strong, but the argument against GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT seems rather weak, especially given most applications give a list of trusted CAs, not non-CAs. I think the argument applies equally strong to both flags. What difference do you see? In the applications I'm concerned with, the trusted list is explicitly used only for CA certs. Arguably they should be using GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Simon Josefsson wrote: Edward Allcutt emall...@gleim.com writes: That's all very well, but it's a rather big change in functionality for stable. I doubt it would be acceptable to patch all the relevant apps which assume that their list of trusted CAs will actually be used as such. Right, and I don't think these applications should be patched for two reasons: 1) That would open up for security problems. Are there any problems other than trusting the V1 certs as CAs? Because that's what the apps seem to expect. 2) The GnuTLS documentation and API has a flag to enable V1 CAs to be valid as a CA root, and another flag to enable V1 CAs to be valid as an intermediate CA cert. This implies the default is that the certs are intended to be disallowed. I see that as a reason to patch, not a reason not to patch. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Simon Josefsson wrote: Simon Josefsson si...@josefsson.org writes: The reason gnutls-cli doesn't complain is because it contains this code: /* there are some CAs that have a v1 certificate *%@#*% */ gnutls_certificate_set_verify_flags (xcred, GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT); I don't recommend doing the same in other applications, and we should probably remove it from gnutls-cli too. It may be useful to create a parameter in other tools to enable the flag on a per-case basis, though. FWIW, I've worked on this in the gnutls 2.7.x branch. gnutls-cli no longer accepts V1 CAs by default, and there is a new --priority token %VERIFY_ALLOW_X509_V1_CA_CRT to enable it for those that needs it. The priority string approach is what we recommend applications expose to their users for configuring GnuTLS internal details. That's all very well, but it's a rather big change in functionality for stable. I doubt it would be acceptable to patch all the relevant apps which assume that their list of trusted CAs will actually be used as such. I can see the same change has been made in libgnutls26 in lenny. Should I file several RC bugs against the various modules affected? Bear in mind that their documented semantics are a list of trusted CAs so I think GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT would be entirely appropriate in those cases. Are there any apps which provide a list of trusted certs which should not all be considered trusted CAs? If not then perhaps GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT should be the default. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
retitle 514807 X.509v1 CA certs no longer trusted implicitly thanks Simon Josefsson wrote: Edward Allcutt emall...@gleim.com writes: Simon Josefsson wrote: I suspect the problem is that you have a RSA-MD5 signature somewhere in the certificate chain. Nope, already checked that... gnutls-cli does work after all. It's the other modules linked to libgnutls that are failing. I believe the problem is that you have a V1 CA, which isn't permitted by default by libgnutls. Only since this security update. I'm not saying that not trusting VA CAs shouldn't be the correct ideal behavior but it does seem very impractical right now. At the very least, can you postpone this change in functionality until lenny? I don't recommend doing the same in other applications, and we should probably remove it from gnutls-cli too. It may be useful to create a parameter in other tools to enable the flag on a per-case basis, though. Those applications which need to change their flags should of course be patched to do so, but not in stable. This seems like a change in the API of libgnutls. A change towards what is documented, granted, but a change nonetheless and away from what most applications seem to expect. For explanation of why V1 CA's are bad, see: I understand that. The argument against GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT is very strong, but the argument against GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT seems rather weak, especially given most applications give a list of trusted CAs, not non-CAs. In addition, at least one very popular CA still seems to use a v1 cert as their root. They have new v3 root certs however these aren't included in ca-certificates until lenny. I'm tagging this as wontfix since this is the documented and intended behaviour. I am sorry you had to notice it through an upgrade -- however the reason for the upgrade was to close this hole. Hmm, I thought the reason for the upgrade was to close this hole: CVE-2008-4989. Fixing this deviation from documentation was just a side-effect. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
Dear team, The recent updates for libgnutls fixed CVE-2008-4989. Unfortunately (at least in my opinion) this also subtly changed the semantics of trusted certificate lists. Version 1 X509 certificates in the list are no longer trusted as CAs unless an extra flag is set. Several users of libgnutls (I've had the problem with nss_ldap, pam_ldap and apache2 mod_authnz_ldap) assume that all certificates in the list will be implicitly trusted. See #514807. This change actually brings gnutls in line with its documentation, however it is still a change in behavior that I think is unsuitable for a stable security update. I believe this is a significant regression in stable because at least one widely used CA (godaddy) still issues certificates with a chain ending in a v1 root (ValiCert Class 2). Godaddy appears to have a newer v3 root but I don't know how widely deployed this is. It is not in the etch ca-certificates package for example. This also affects the same set of packages in lenny. I suppose the right way to solve it in lenny would be to patch all the libgnutls users which assume v1 CAs should be trusted. However I'm not sure of the reaction to filing several possibly RC bugs at this point. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: Regression in libgnutls security update
Simon Josefsson wrote: The CVE-2008-4989 problem was that parts of the chain validation algorithm was not executed properly. Rejecting V1 CA's is one of those parts, so I believe this is the intended consequence of the CVE-2008-4989 fix. I understood the primary problem to be that if the last (root) cert was self-signed then its signature of the next-to-last cert would not be checked. The other checks on the last cert would also not occur but these were relatively minor. This change actually brings gnutls in line with its documentation, however it is still a change in behavior that I think is unsuitable for a stable security update. This is my main emphasis. Whatever happens with lenny, changing this behavior in etch breaks existing setups. This also affects the same set of packages in lenny. I suppose the right way to solve it in lenny would be to patch all the libgnutls users which assume v1 CAs should be trusted. However I'm not sure of the reaction to filing several possibly RC bugs at this point. This would leave users exposed to the security problems inherent with V1 CAs, which seems like a bad thing. The proper fix is for users to move away from all V1 CAs. What are the other significant problems with v1 CAs? Trusting a CA in a list of certs which is provided with the understanding that they are to be trusted doesn't seem a huge problem. (That being my interpretation of the semantics of the configuration of nss_ldap etc.) What can be done here is to produce better documentation, perhaps in release notes. People must be aware that trusting X.509 certificate chains containing RSA-MD5 signatures or V1 CAs is insecure. I don't disagree, but breaking working configurations, not all of which are as insecure as you fear, doesn't seem like the best plan, especially since there was no advance warning. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#514807: libgnutls13: Security update causes TLS certificate verification: Error, Unknown error
Package: libgnutls13 Version: 1.4.4-3+etch3 Severity: important After the upgrade all embedded uses of LDAP fail with connection errors. On investigations these seem to be caused by certificate validation problems. This was first noticed with nss_ldap. After enabling debugging, running `getent group` produced error messages like: TLS certificate verification: depth: 0, err: 130, subject: snip DN/ TLS certificate verification: Error, Unknown error Similar problems occur for pam_ldap and apache mod_authnz_ldap. Strangely, gnutls-cli verifies the server certificate with no problems. The error was first seen in a STARTTLS only configuration. I have since enabled ldaps to ease testing with gnutls-cli and confirmed it still affects nss_ldap and apache switched to ldaps. The root (trusted) certificate of our cert chain is an x509v1 cert, however I'd expect gnutls-cli to complain if this were the issue. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-xen-amd64 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Versions of packages libgnutls13 depends on: ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries ii libgcrypt111.2.3-2 LGPL Crypto library - runtime libr ii libgpg-error0 1.4-1 library for common error values an ii liblzo11.08-3data compression library (old vers ii libopencdk80.5.9-2 Open Crypto Development Kit (OpenC ii libtasn1-3 0.3.6-2 Manage ASN.1 structures (runtime) ii zlib1g 1:1.2.3-13compression library - runtime libgnutls13 recommends 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#512055: osirisd: Doesn't properly close stdio
It appears that the main reason it doesn't happen every time is that a substantial fraction of the time it just fails to restart with no error messages on the console or in syslog. Every time I've verified that osirisd has properly restarted it is holding open stdio. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#512055: osirisd: Doesn't properly close stdio
Package: osirisd Version: 4.2.0-2 Severity: normal On restarting osirisd via the init script it often holds open my pseudo-terminal instead of properly disassociating. This causes annoying behavior in remote shell programs which don't close after exiting the remote shell since there's still something connected to the child pty. This doesn't happen every time, but with enough frequency to be annoying. It seems to happen on some servers more than others. Here's an example: vpn:~# lsof /dev/pts/0 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME bash28562 emallcut0u CHR 136,0 2 /dev/pts/0 bash28562 emallcut1u CHR 136,0 2 /dev/pts/0 bash28562 emallcut2u CHR 136,0 2 /dev/pts/0 bash28562 emallcut 255u CHR 136,0 2 /dev/pts/0 bash28580 root0u CHR 136,0 2 /dev/pts/0 bash28580 root1u CHR 136,0 2 /dev/pts/0 bash28580 root2u CHR 136,0 2 /dev/pts/0 bash28580 root 255u CHR 136,0 2 /dev/pts/0 lsof28589 root0u CHR 136,0 2 /dev/pts/0 lsof28589 root1u CHR 136,0 2 /dev/pts/0 lsof28589 root2u CHR 136,0 2 /dev/pts/0 vpn:~# /etc/init.d/osirisd restart Restarting Osiris scanning agent: osirisd. vpn:~# lsof /dev/pts/0 COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME bash28562 emallcut0u CHR 136,0 2 /dev/pts/0 bash28562 emallcut1u CHR 136,0 2 /dev/pts/0 bash28562 emallcut2u CHR 136,0 2 /dev/pts/0 bash28562 emallcut 255u CHR 136,0 2 /dev/pts/0 bash28580 root0u CHR 136,0 2 /dev/pts/0 bash28580 root1u CHR 136,0 2 /dev/pts/0 bash28580 root2u CHR 136,0 2 /dev/pts/0 bash28580 root 255u CHR 136,0 2 /dev/pts/0 osirisd 28594 osirisd0u CHR 136,0 2 /dev/pts/0 osirisd 28594 osirisd1u CHR 136,0 2 /dev/pts/0 osirisd 28594 osirisd2u CHR 136,0 2 /dev/pts/0 osirisd 28595 osirisd0u CHR 136,0 2 /dev/pts/0 osirisd 28595 osirisd1u CHR 136,0 2 /dev/pts/0 osirisd 28595 osirisd2u CHR 136,0 2 /dev/pts/0 lsof28598 root0u CHR 136,0 2 /dev/pts/0 lsof28598 root1u CHR 136,0 2 /dev/pts/0 lsof28598 root2u CHR 136,0 2 /dev/pts/0 -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-6-xen-amd64 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Versions of packages osirisd depends on: ii adduser3.102 Add and remove users and groups ii libc6 2.3.6.ds1-13etch8 GNU C Library: Shared libraries ii libssl0.9.80.9.8c-4etch4 SSL shared libraries osirisd recommends 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#504929: balazar3-2d: Missing Depends on python-soya
Package: balazar3-2d Version: 0.1-2 Severity: grave Justification: renders package unusable On running balazar3 I get the following output: * Balazar 3 * Balazar 3 lives in /usr/share/games * Balazar 3 * (Psyco not found; if you are using an x86 processor, installing psyco can speed up Balazar 3) Traceback (most recent call last): File /usr/games/balazar3, line 125, in module from balazar3.game import * File /usr/share/games/balazar3/game.py, line 24, in module exec import balazar3.driver_%s as driver % globdef.DRIVER File string, line 1, in module File /usr/share/games/balazar3/driver_3d.py, line 19, in module import soya, soya.gui, soya.opengl as opengl, soya.label3d as label3d ImportError: No module named soya After manually installing python-soya it complains ImportError: No module named gui instead. The python-soya package I have (0.13.2-5) does not appear to have a gui module. Perhaps a versioned depends is necessary? The balazar3-3d package depends on python-soya but balazar3-2d does not. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages balazar3-2d depends on: ii balazar3-common 0.1-2dungeon adventure game with multip ii python-pygame 1.7.1release-4.2 SDL bindings for games development balazar3-2d recommends no packages. balazar3-2d suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: fix for /boot/grub/core.img issue
Robert Millan wrote: We believe that these three bugs are all caused by the same problem, which is now fixed in latest upload to experimental (1.96+20080826-1). Tested using 1.96+20080831-1, 1.96+20080826-1 seems to have disappeared from the Debian changelog. If you can, please try that version and confirm that the problem is fixed for you. If it's not, tell us about it as soon as you can. It seems to work fine. I disabled the bios_grub flag on the gpt partition I'd created; I assume this will force grub to fall back to using a blocklist. I then ran grub-install and it reported success. Booting had no issues either although that was never a problem. I've now switched back to using the bios_grub partition as that seems a far superior solution. -- Edward Allcutt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-setup fails with error message = file not found
I initially reported this as Debian bug #494589 [0] Felix Zielcke asked me to forward this report to this mailing list. Reproduced with latest upstream SVN (rebuilt r1802 today). Failing command: grub-setup -vv --directory=/boot/grub --device-map=/boot/grub/device.map '(hd0)' grub-setup.log 21 grub-setup.log is available at [1] /boot/grub/core.img exists and was created normally by grub-install. I looked at the parameters passed to grub-mkimage and it was using the correct modules (ext2 gpt biosdisk). I've run sync and unmounted/remounted /boot but that doesn't help. grub-fstest seems to have no problem with reading from the filesystem: # grub-fstest /dev/sda1 ls /grub/core.img core.img # grub-fstest /dev/sda1 blocklist /grub/core.img 655432+55,655487[0-414] # grub-fstest /dev/sda1 cmp /grub/core.img /boot/grub/core.img; echo $? 0 /dev/sda is partitioned using GPT. /boot is a normal ext3 filesystem on /dev/sda1. I've made the MBR [2] and sda1 (about 38MB) [3] available. Final note: this exact setup worked just fine when I installed this system in mid-June. I can probably figure out the version of grub2 on the install CD if that would help. [0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494589 [1] http://dev.teamgleim.com/~emallcut/grub2/grub-setup.log [2] http://dev.teamgleim.com/~emallcut/grub2/sda.mbr.gz [3] http://dev.teamgleim.com/~emallcut/grub2/sda1.gz -- Edward Allcutt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-setup fails with error message = file not found
Robert Millan wrote: On Wed, Aug 13, 2008 at 11:53:27AM -0400, Edward Allcutt wrote: [1] http://dev.teamgleim.com/~emallcut/grub2/grub-setup.log grub-setup: info: will leave the core image on the filesystem The blocklist approach should still work, but it's not recommended. I was actually unaware that grub2 was using a blocklist. I thought it always embedded the core image. I suggest you allow GRUB to embed core.img instead by adding a BIOS boot partitition using Parted. We still need to trace down the problem with blocklists, but this will tell us whether the problem is related to this or something else. I set the boot flag for /dev/sda1 using parted. I hope this is what you meant. grub-setup still fails with the same error and it still mentions will leave the core image on the filesystem. -- Edward Allcutt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-setup fails with error message = file not found
Robert Millan wrote: On Wed, Aug 13, 2008 at 11:53:27AM -0400, Edward Allcutt wrote: [2] http://dev.teamgleim.com/~emallcut/grub2/sda.mbr.gz [3] http://dev.teamgleim.com/~emallcut/grub2/sda1.gz Those scattered pieces of disk are not very useful. My suspicion is that grub-setup has trashed your GPT metadata. Can you verify that all your partitions are still readable from real GRUB, and that files are accessible as well? (from a rescue disk or so) Just booted from a floppy image created by latest upstream. It read the GPT data just fine. I'll see if I can juggle the existing partitions sufficiently to fit a dedicated boot partition. -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-setup fails with error message = file not found
Robert Millan wrote: On Wed, Aug 13, 2008 at 01:04:14PM -0400, Edward Allcutt wrote: Robert Millan wrote: I suggest you allow GRUB to embed core.img instead by adding a BIOS boot partitition using Parted. We still need to trace down the problem with blocklists, but this will tell us whether the problem is related to this or something else. I set the boot flag for /dev/sda1 using parted. I hope this is what you meant. grub-setup still fails with the same error and it still mentions will leave the core image on the filesystem. The boot flag on GPT means EFI system partition (this is admittedly confusing). There's a flag for bios boot, but only in recent versions of Parted. But of course, I wouldn't do that to your existing sda1 unless you want it to be wiped with GRUB code. I wish there were another tool supporting GPT. parted is a real pain to use. Still I've got a dedicated BIOS boot partition now and grub-setup seems happy to embed core.img on it without any errors. While my problem is resolved it seems like there's still an annoying bug in either the ext2 driver or whatever else is involved in generating blocklists. Thanks for the quick responses :) -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-pc: grub-install fails on GPT volume
Felix Zielcke wrote: Am Sonntag, den 10.08.2008, 16:22 -0400 schrieb Edward Allcutt: So it looks like fs/ext2.c isn't that correct for the extN you have on /boot The best would be probable if you could reproduce with a small filesystem image and would send that to [EMAIL PROTECTED], you need to be subscribed though. With recompiling from source you can specify ./configure --enable-grub-fstest, then you get grub-fstest which might help in finding out what's wrong. I've just rebuilt 1.96+20080724-5 with --enable-grub-fstest grub-setup fails in exactly the same way, however grub-fstest seems to have no problem at all with the new core.img: [EMAIL PROTECTED]:~# grub-fstest -vvv /dev/sda1 cmp /grub/core.img \ /boot/grub/core.img; echo $? 0 Am I using grub-fstest wrong or does this imply grub-setup is broken? I'll try the latest upstream next I guess. Thanks, Edward Allcutt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#494589: grub-pc: grub-install fails on GPT volume
Felix Zielcke wrote: Am Sonntag, den 10.08.2008, 16:22 -0400 schrieb Edward Allcutt: I looked at the changelog for 1.96+20080724-6 from sid but it doesn't seem to contain anything relevant. You could try current upstream SVN[0], which is a bit more recent (i.e. last change today) then the 0724-X which we currently stick for lenny. The 0730-1 in experimental isn't that much newer as you can see and it has not a few bugfixes backported from upstream for the recent 0724-X releases. Just built the latest upstream. Again, grub-fstest cmp seems to work fine but grub-setup fails with: grub-setup: info: couldn't open the core image grub-setup: info: error message = file not found grub-setup: error: Cannot read `/boot/grub/core.img' correctly I've also noticed that when using grub-emu I get other errors: grub insmod (hd0,1)/grub/gpt.mod error: invalid arch independent ELF magic For all I know this is normal but it seemed worth mentioning. The best would be probable if you could reproduce with a small filesystem image and would send that to [EMAIL PROTECTED], you need to be subscribed though. Would `dd bs=512 if=/dev/sda1 | gzip sda1` be sufficient as the filesystem image or would the GPT table be necessary too? -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480954: [debian-mysql] Bug#480954: Acknowledgement (mysql-server-5.0: Incorrect query results with CONST join compared to RANGE or ALL)
Monty Taylor wrote: Edward Allcutt wrote: Context: mtaylor committed r1228 to pkg-mysql (http://svn.debian.org/viewsvn/pkg-mysql?rev=1228view=rev) This looks like the right patch, but isn't trunk the wrong place to apply it? It looks to me like it's being prepared for the next release to unstable, but mysqld in unstable (5.0.51) already has this issue fixed upstream (has been fixed since 5.0.40). Heh. /me slaps himself in the face. How did I actually commit that? Just so long as this gets fixed in etch soon I'm happy :) -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480954: Acknowledgement (mysql-server-5.0: Incorrect query results with CONST join compared to RANGE or ALL)
Context: mtaylor committed r1228 to pkg-mysql (http://svn.debian.org/viewsvn/pkg-mysql?rev=1228view=rev) This looks like the right patch, but isn't trunk the wrong place to apply it? It looks to me like it's being prepared for the next release to unstable, but mysqld in unstable (5.0.51) already has this issue fixed upstream (has been fixed since 5.0.40). Apologies if I've completely misunderstood your workflow :) -- Edward Allcutt Network Operations -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480954: mysql-server-5.0: Incorrect query results with CONST join compared to RANGE or ALL
Package: mysql-server-5.0 Version: 5.0.32-7etch5 Severity: important Upstream bug #26963 (http://bugs.mysql.com/bug.php?id=26963) According to upsteam, it is fixed in 5.0.40 I've set this to important as it results in plain wrong answers to fairly simple queries. Depending on the application this could easily be a major issue. There is a patch at http://lists.mysql.com/commits/21697 which looks fairly trivial. Please consider including a fix in an etch point release. -- 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-686 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Versions of packages mysql-server-5.0 depends on: ii adduser3.102 Add and remove users and groups ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch5 GNU C Library: Shared libraries ii libdbi-perl1.53-1etch1 Perl5 database interface by Tim Bu ii libgcc11:4.1.1-21GCC support library ii libmysqlclient15off5.0.32-7etch5 mysql database client library ii libncurses55.5-5 Shared libraries for terminal hand ii libreadline5 5.2-2 GNU readline and history libraries ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libwrap0 7.6.dbs-13Wietse Venema's TCP wrappers libra ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii mysql-client-5.0 5.0.32-7etch5 mysql database client binaries ii mysql-common 5.0.32-7etch5 mysql database common files (e.g. ii passwd 1:4.0.18.1-7 change and administer password and ii perl 5.8.8-7etch3 Larry Wall's Practical Extraction ii psmisc 22.3-1Utilities that use the proc filesy ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages mysql-server-5.0 recommends: ii mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent -- debconf information: mysql-server-5.0/really_downgrade: false mysql-server-5.0/need_sarge_compat: false mysql-server-5.0/start_on_boot: true mysql-server/error_setting_password: mysql-server-5.0/nis_warning: mysql-server-5.0/postrm_remove_databases: false mysql-server-5.0/need_sarge_compat_done: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468366: vim: Wrong highlighting for sh arithmetic expressions
Package: vim Version: 1:7.1-241+1 Severity: minor The following is highlighted badly: start file #!/bin/bash echo $(( ( 2 5 ) + 1 )) echo foo bar end file == The 5 is the wrong colour and everything following until the end of file is highlighted as if it were quoted text. Removing the parentheses around the sub-expression corrects the highlighting but changes the meaning of the expression. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing'), (800, 'unstable'), (700, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-3-686 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages vim depends on: ii libc6 2.7-6 GNU C Library: Shared libraries ii libgpmg1 1.19.6-25 General Purpose Mouse - shared lib ii libncurses5 5.6+20080119-1 Shared libraries for terminal hand ii vim-common1:7.1-241+1Vi IMproved - Common files ii vim-runtime 1:7.1-241+1Vi IMproved - Runtime files vim recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#464218: mysql-server-5.0: Crashes while EXPLAINing Sub-query with GROUP BY clause
Package: mysql-server-5.0 Version: 5.0.32-7etch4 Severity: important I'm fairly certain this is the same as upstream bug #27807 (http://bugs.mysql.com/bug.php?id=27807) The issues does not occur with the latest upstream binary release. I've attached two files. One is the smallest set of SQL I've come up with to reproduce the crash. The other is a resolved stack trace. The crash occurs only when running EXPLAIN. Executing the actual query produces the expected results. I'd be gratified if a fix could be included in an etch point release. Unfortunately there are no less than four commits mentioned in the upstream bug report so I'm not sure how easy it will be to backport the fix. -- 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-5-686 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Versions of packages mysql-server-5.0 depends on: ii adduser3.102 Add and remove users and groups ii debconf [debconf-2.0] 1.5.11etch1 Debian configuration management sy ii libc6 2.3.6.ds1-13etch4 GNU C Library: Shared libraries ii libdbi-perl1.53-1etch1 Perl5 database interface by Tim Bu ii libgcc11:4.1.1-21GCC support library ii libmysqlclient15off5.0.32-7etch4 mysql database client library ii libncurses55.5-5 Shared libraries for terminal hand ii libreadline5 5.2-2 GNU readline and history libraries ii libstdc++6 4.1.1-21 The GNU Standard C++ Library v3 ii libwrap0 7.6.dbs-13Wietse Venema's TCP wrappers libra ii lsb-base 3.1-23.2etch1 Linux Standard Base 3.1 init scrip ii mysql-client-5.0 5.0.32-7etch4 mysql database client binaries ii mysql-common 5.0.32-7etch4 mysql database common files (e.g. ii passwd 1:4.0.18.1-7 change and administer password and ii perl 5.8.8-7etch1 Larry Wall's Practical Extraction ii psmisc 22.3-1Utilities that use the proc filesy ii zlib1g 1:1.2.3-13compression library - runtime Versions of packages mysql-server-5.0 recommends: ii mailx1:8.1.2-0.20050715cvs-1 A simple mail user agent -- debconf information excluded CREATE DATABASE crash; USE crash; CREATE TABLE `PV` ( `pvID` int(11) NOT NULL auto_increment, `wID` int(11) unsigned NOT NULL, PRIMARY KEY (`pvID`), KEY `wID` (`wID`) ); CREATE TABLE `WO` ( `woID` int(11) NOT NULL auto_increment, `wID` int(11) NOT NULL, `oID` int(11) NOT NULL, PRIMARY KEY (`woID`), KEY `wID` (`wID`), KEY `oID` (`oID`) ); INSERT INTO WO SET wID=1, oID=1; INSERT INTO WO SET wID=2, oID=2; INSERT INTO PV SELECT 0 AS pvID, wID AS wID FROM WO; SELECT wID FROM PV WHERE pvID = (SELECT MAX(pvID) FROM WO NATURAL JOIN PV WHERE oID=1 GROUP BY WO.wID); EXPLAIN SELECT wID FROM PV WHERE pvID = (SELECT MAX(pvID) FROM WO NATURAL JOIN PV WHERE oID=1 GROUP BY WO.wID); 0x81c0619 handle_segfault + 681 0x821edbc select_describe(JOIN*, bool, bool, bool, char const*) + 4316 0x8220392 JOIN::exec() + 1890 0x82221c0 _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_sel + 304 0x82228e3 mysql_explain_union(THD*, st_select_lex_unit*, select_result*) + 547 0x821e055 select_describe(JOIN*, bool, bool, bool, char const*) + 885 0x8220392 JOIN::exec() + 1890 0x82221c0 _Z12mysql_selectP3THDPPP4ItemP13st_table_listjR4ListIS1_ES2_jP8st_orderSB_S2_SB_yP13select_resultP18st_select_lex_unitP13st_sel + 304 0x82228e3 mysql_explain_union(THD*, st_select_lex_unit*, select_result*) + 547 0x81da0a9 mysql_execute_command(THD*) + 20329 0x81dbba7 mysql_parse(THD*, char*, unsigned int) + 471 0x81dc060 dispatch_command(enum_server_command, THD*, char*, unsigned int) + 1120 0x81dd328 do_command(THD*) + 136 0x81ddd34 handle_one_connection + 2308 0xb7f9b240 _end + -1349833552 0xb7dd649e _end + -1351688434
Bug#460943: mercurial: kdiff3 should not be first in the list
Package: mercurial Version: 0.9.5-2 Followup-For: Bug #460943 I run a large number of servers which all use mercurial for managing various web-app deployments and configurations. I would be most gratified if installing mercurial did not pull in half of KDE with it. I (and my users) find the rcs provided merge to be quite sufficient the vast majority of the time. Those who wish can run graphical merge programs on their own workstations or on servers with X libs installed. While I can work around this manually, I've had to clean up a few systems already where others just accepted the default Recommends from apt/aptitude. Please strongly consider putting rcs first in that list, as it provides the minimal functionality with no extra dependencies. Similarly, please make tk a Suggests rather than a Recommends. I've no need for it (or the rest of X) and it's not hard for those who do want it to find it. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-xen-686 (SMP w/1 CPU core) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages mercurial depends on: ii libc6 2.7-6 GNU C Library: Shared libraries ii python2.4.4-6An interactive high-level object-o ii python-support0.7.6 automated rebuilding support for p ii python2.5 2.5.1-6An interactive high-level object-o Versions of packages mercurial recommends: ii rcs 5.7-21 The GNU Revision Control System pn tk8.4 | wish none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#453868: unfixed in etch, sarge
According to http://security-tracker.debian.net/tracker/CVE-2007-5794 this bug is still an issue in stable and oldstable. Is a backported patch feasible? signature.asc Description: This is a digitally signed message part
Bug#453127: mysql-common: preinst breaks on upgrade if datadir not set
Package: mysql-common Version: 5.0.32-7etch1 Severity: normal I run multiple mysqld instances on the same machine. Each uses a separate config file. None of them use /etc/mysql/my.cnf which doesn't exist on this system. On upgrade, the mysql-common preinst gets the datadir from /etc/mysql/my.cnf (mysqld --print-defaults | ...) then runs find on the result. Since there is no my.cnf the resultant shell variable is empty and find uses $PWD (which seems to be /). As this was taking rather a long time I just killed find. I've worked around this by creating a dummy my.cnf containing a fake datadir entry. I've also prepared a fix to the preinst which checks that the datadir exists before running find: --- mysql-common.preinst2007-11-27 10:00:14.0 -0500 +++ mysql-common.preinst.fixed 2007-11-27 10:17:25.0 -0500 @@ -150,7 +150,7 @@ if [ $1 = upgrade ] [ -x /usr/sbin/mysqld ]; then cvt_datadir=`cvt_get_param datadir` # test for ISAM tables, which we must convert NOW - if [ -n `find $cvt_datadir -name '*.ISM' 2/dev/null` ]; then + if [ -n $cvt_datadir ] [ -d $cvt_datadir ] [ -n `find $cvt_datadir -name '*.ISM' 2/dev/null` ]; then pidfile=`cvt_get_param pid-file` if [ $pidfile ] [ -f $pidfile ]; then server_pid=`cat $pidfile` -- 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-5-686 Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#412040: smlnj: Upstream changelog missing
Package: smlnj Version: 110.62-1 Severity: normal I just upgraded this package. Being the sad individual that I am I attempted to read the changelog (/usr/share/doc/smlnj/changelog.gz) Lo and behold it vanished before my eyes. It was there in the previous version of the package (110.52-1) -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.18-3-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages smlnj depends on: ii smlnj-runtime 110.62-1 Standard ML of New Jersey runtime smlnj recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390723: smlnj: lacks basic line editing and command history
Package: smlnj Version: 110.52-1 Severity: wishlist It would be nice to be able to recall and edit previously issued lines of input. Currently, using the cursor keys yields only the usual ^[[A^[[D type response. A later version of this software has this facility, at least under cmd.exe on win32 -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages smlnj depends on: ii smlnj-runtime 110.52-1 Standard ML of New Jersey runtime smlnj recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#384558: module-assistant build ieee80211-source fails
Package: ieee80211-source
Version: 1.1.14-1
Severity: important
the error module-assistant reports is:
debian/rules:6: /usr/share/dpatch/dpatch.make: No such file or directory
make: *** No rule to make target `/usr/share/dpatch/dpatch.make'. Stop.
after installing dpatch building fails somewhat more verbosely,
see attached file
as an aside, reportbug tells me:
Your version of ieee80211-source (1.1.14-1) is newer than that in Debian!
despite me getting it from ftp.us.debian.org 10 minutes ago.
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (900, 'testing'), (800, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.17-1-686
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Versions of packages ieee80211-source depends on:
ii bzip2 1.0.3-3high-quality block-sorting file co
ii debhelper 5.0.37.3 helper programs for debian/rules
ii make 3.81-2 The GNU version of the make util
ii module-assistant 0.10.6 tool to make module package creati
ieee80211-source recommends no packages.
-- no debconf information
dpatch deapply-all
rm -rf patch-stamp patch-stampT debian/patched
dh_testdir
#dh_testroot
rm -f build-arch-stamp build-indep-stamp
# Cleaning package
/usr/bin/make clean
make[1]: Entering directory `/usr/src/modules/ieee80211'
rm -f *.mod.c *.mod *.o *.ko .*.cmd .*.flags *.lst *~ .#*
rm -rf /usr/src/modules/ieee80211/tmp .tmp_versions
for file in *.{c,h} net/*.h; do \
if [ -e $file ]; then \
sed -i -e s:\ *$::g -e s:\t*$::g $file; \
fi \
done
make[1]: Leaving directory `/usr/src/modules/ieee80211'
rm -f *.ko-* debian/*postrm debian/*preinst
dh_clean
/usr/bin/make -f debian/rules clean
make[1]: Entering directory `/usr/src/modules/ieee80211'
dpatch deapply-all
rm -rf patch-stamp patch-stampT debian/patched
dh_testdir
#dh_testroot
rm -f build-arch-stamp build-indep-stamp
# Cleaning package
/usr/bin/make clean
make[2]: Entering directory `/usr/src/modules/ieee80211'
rm -f *.mod.c *.mod *.o *.ko .*.cmd .*.flags *.lst *~ .#*
rm -rf /usr/src/modules/ieee80211/tmp .tmp_versions
for file in *.{c,h} net/*.h; do \
if [ -e $file ]; then \
sed -i -e s:\ *$::g -e s:\t*$::g $file; \
fi \
done
make[2]: Leaving directory `/usr/src/modules/ieee80211'
rm -f *.ko-* debian/*postrm debian/*preinst
dh_clean
make[1]: Leaving directory `/usr/src/modules/ieee80211'
/usr/bin/make -f debian/rules kdist_clean kdist_config binary-modules
make[1]: Entering directory `/usr/src/modules/ieee80211'
dpatch deapply-all
rm -rf patch-stamp patch-stampT debian/patched
dh_testdir
#dh_testroot
rm -f build-arch-stamp build-indep-stamp
# Cleaning package
/usr/bin/make clean
make[2]: Entering directory `/usr/src/modules/ieee80211'
rm -f *.mod.c *.mod *.o *.ko .*.cmd .*.flags *.lst *~ .#*
rm -rf /usr/src/modules/ieee80211/tmp .tmp_versions
for file in *.{c,h} net/*.h; do \
if [ -e $file ]; then \
sed -i -e s:\ *$::g -e s:\t*$::g $file; \
fi \
done
make[2]: Leaving directory `/usr/src/modules/ieee80211'
rm -f *.ko-* debian/*postrm debian/*preinst
dh_clean
/usr/bin/make -w -f debian/rules clean
make[2]: Entering directory `/usr/src/modules/ieee80211'
dpatch deapply-all
rm -rf patch-stamp patch-stampT debian/patched
dh_testdir
#dh_testroot
rm -f build-arch-stamp build-indep-stamp
# Cleaning package
/usr/bin/make clean
make[3]: Entering directory `/usr/src/modules/ieee80211'
rm -f *.mod.c *.mod *.o *.ko .*.cmd .*.flags *.lst *~ .#*
rm -rf /usr/src/modules/ieee80211/tmp .tmp_versions
for file in *.{c,h} net/*.h; do \
if [ -e $file ]; then \
sed -i -e s:\ *$::g -e s:\t*$::g $file; \
fi \
done
make[3]: Leaving directory `/usr/src/modules/ieee80211'
rm -f *.ko-* debian/*postrm debian/*preinst
dh_clean
make[2]: Leaving directory `/usr/src/modules/ieee80211'
make[1]: Nothing to be done for `kdist_config'.
dh_testroot
dh_clean -k
dh_installdirs
# Build the module
/usr/bin/make modules KERNEL_DIR=/lib/modules/2.6.17-1-686/build
KVERS=2.6.17-1-686
make[2]: Entering directory `/usr/src/modules/ieee80211'
/usr/bin/make -C /lib/modules/2.6.17-1-686/build M=/usr/src/modules/ieee80211
modules
make[3]: Entering directory `/usr/src/linux-headers-2.6.17-1-686'
CC [M] /usr/src/modules/ieee80211/ieee80211_module.o
CC [M] /usr/src/modules/ieee80211/ieee80211_tx.o
CC [M] /usr/src/modules/ieee80211/ieee80211_rx.o
CC [M] /usr/src/modules/ieee80211/ieee80211_wx.o
CC [M] /usr/src/modules/ieee80211/ieee80211_geo.o
LD [M] /usr/src/modules/ieee80211/ieee80211.o
CC [M] /usr/src/modules/ieee80211/ieee80211_crypt.o
CC [M] /usr/src/modules/ieee80211/ieee80211_crypt_wep.o
CC [M]
Bug#383003: empire: error in man page
Package: empire Version: 1.7-2 Severity: minor In the table of combat probabilities, the entries in the first row appear to be one column to the left of where they should be. Edward. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages empire depends on: ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libncurses5 5.5-2 Shared libraries for terminal hand empire recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367532: galeon: Letter s before letter t is not rendered
Package: galeon Version: 2.0.1-3 Followup-For: Bug #367532 I'm having a similar problem. In some cases the where the html contains an 'st' the s is just being omitted entirely. I think I've tracked this down to code sections. Copying and pasting from the page works properly, it's just the rendering that is broken. I've prepared an example of a page that renders incorrectly: http://www.allcutt.me.uk/demo.html The first test renders properly, the second (in a code block) renders as 'tet'. Setting MOZ_DISABLE_PANGO=1 lets the page render properly. Ed. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages galeon depends on: ii galeon-common 2.0.1-3 GNOME web browser for advanced use ii libart-2.0-2 2.3.17-1 Library of functions for 2D graphi ii libatk1.0-01.11.4-2 The ATK accessibility toolkit ii libbonobo2-0 2.14.0-1 Bonobo CORBA interfaces library ii libbonoboui2-0 2.14.0-3 The Bonobo UI library ii libc6 2.3.6-15 GNU C Library: Shared libraries ii libcairo2 1.2.0-2 The Cairo 2D vector graphics libra ii libfontconfig1 2.3.2-7 generic font configuration library ii libgcc11:4.1.1-5 GCC support library ii libgconf2-42.14.0-1 GNOME configuration database syste ii libglade2-01:2.5.1-2 library to load .glade files at ru ii libglib2.0-0 2.10.2-1 The GLib library of C routines ii libgnome-desktop-2 2.14.2-2 Utility library for loading .deskt ii libgnome-keyring0 0.4.9-1 GNOME keyring services library ii libgnome2-02.14.1-2 The GNOME 2 library - runtime file ii libgnomecanvas2-0 2.14.0-2 A powerful object-oriented display ii libgnomeui-0 2.14.1-2 The GNOME 2 libraries (User Interf ii libgnomevfs2-0 2.14.2-1 GNOME virtual file-system (runtime ii libgtk2.0-02.8.18-1 The GTK+ graphical user interface ii libice61:1.0.0-3 X11 Inter-Client Exchange library ii libmozjs0d 1.8.0.4-1 The Mozilla SpiderMonkey JavaScrip ii libnspr4-0d1.8.0.4-1 NetScape Portable Runtime Library ii liborbit2 1:2.14.0-2libraries for ORBit2 - a CORBA ORB ii libpango1.0-0 1.12.3-1 Layout and rendering of internatio ii libpopt0 1.10-2lib for parsing cmdline parameters ii libsm6 1:1.0.0-4 X11 Session Management library ii libstartup-notification0 0.8-1 library for program launch feedbac ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3 ii libx11-6 2:1.0.0-7 X11 client-side library ii libxcursor11.1.5.2-5 X cursor management library ii libxext6 1:1.0.0-4 X11 miscellaneous extension librar ii libxi6 1:1.0.0-5 X11 Input extension library ii libxinerama1 1:1.0.1-4 X11 Xinerama extension library ii libxml22.6.26.dfsg-1 GNOME XML library ii libxrandr2 2:1.1.0.2-4 X11 RandR extension library ii libxrender11:0.9.0.2-4 X Rendering Extension client libra ii libxul0d 1.8.0.4-1 Gecko engine library ii procps 1:3.2.7-2 /proc file system utilities ii zlib1g 1:1.2.3-11compression library - runtime Versions of packages galeon recommends: pn capplets none (no description available) ii gnome-icon-theme 2.14.2-1 GNOME Desktop icon theme ii iso-codes 0.51-1.1 ISO language, territory, currency ii scrollkeeper 0.3.14-11 A free electronic cataloging syste ii yelp 2.14.2-2 Help browser for GNOME 2 -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367532: galeon: Letter s before letter t is not rendered
On Fri, 2006-07-14 at 22:12 +0200, Loïc Minier wrote: Hi, On Fri, Jul 14, 2006, Edward Allcutt wrote: I'm having a similar problem. In some cases the where the html contains an 'st' the s is just being omitted entirely. I think I've tracked this down to code sections. Copying and pasting from the page works properly, it's just the rendering that is broken. This is specific to your font, I suggest you find out which font causes this and reassign the bug to this font. st is ligatured, so it might need a particular character in the font to be drawn properly. Googling for ligature got me this: http://savannah.nongnu.org/bugs/?func=detailitemitem_id=16253 which led to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=358526 It looks like a fix has already been uploaded. Should this bug be merged with 358526 then? signature.asc Description: This is a digitally signed message part
Bug#292845: dynamically created files
Package: slapd Version: 2.3.24-1 Followup-For: Bug #292845 In addition to the pid file, the slapd.args file should also be relocated to /var/run/slapd Otherwise slapd fails silently (unless you manually enable logging) when running as a non-root user. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#364788: evilwm: some keyboard controls do not work with dvorak keymap
Package: evilwm Version: 0.99.21-1 Severity: normal I am using 'setxkbmap dvorak' to set the X keymap to the standard dvorak layout. The system-wide XkbLayout is gb. I am running evilwm with the command 'evilwm -snap 3 -bw 0' from my .Xsession. After switching keymaps, some of the keyboard controls for evilwm behave in unexpected ways. Those commands with keys which are not remapped are unaffected. These are: Ctrl+Alt+(Return, Escape, Insert, 1-8, Left, Right) and Alt+Tab Some keys which are remapped continue to behave normally. These are: Ctrl+Alt+(F, X, H, U, B, N) The following behave oddly: Ctrl+Alt+(I, =, J, K, L, Y) They do not perform the expected window manager functions but instead seem to send various control characters, some of which are interpreted by the shell and some which have no visible effect. Where I refer to eg. Ctrl+Alt+H, I mean the keys Ctrl and Alt (which are not remapped) and the key which produces a 'h' when pressed. ie. the key marked 'j' on my qwerty keyboard. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (900, 'testing'), (800, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.15-1-686 Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Versions of packages evilwm depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries ii libx11-6 6.9.0.dfsg.1-6 X Window System protocol client li ii libxext6 6.9.0.dfsg.1-6 X Window System miscellaneous exte evilwm recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330727: libapache-mod-auth-mysql: postrm script fails
Package: libapache-mod-auth-mysql Version: 4.3.9-2 Severity: important The postrm runs /usr/sbin/modules-config. since libapache-mod-auth-mysql depends on apache-common which owns this, this is probably fine. However /usr/sbin/modules-config fails if apache is not installed which results in the postrm failing and hence the package is uninstallable. This may of course be a bug with apache-common, but I think the postrm should allow for this possible failure. -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.4.26 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libapache-mod-auth-mysql depends on: ii apache-common 1.3.33-6sarge1 support files for all Apache webse ii libc6 2.3.2.ds1-22 GNU C Library: Shared libraries an ii libmysqlclient12 4.0.24-10 mysql database client library -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
