Bug#611351: blueman: Unable to save Network settings after enabling PAN
Package: blueman Version: 1.21-4.1 Severity: normal Blueman 1.21 does not allow me to enable NAP in Network settings. Steps to reproduce: applet menu - Local services - Network - check Enable NAP and Enable NAT, select dnsmasq and PAN support: blueman (dnsmasq), press Apply. As soon as you select PAN support: blueman (dnsmasq) radio button, blueman-applet produces the following traceback: Traceback (most recent call last): File /usr/lib/python2.6/dist-packages/blueman/plugins/services/Network.py, line 251, in pan_support_toggled applet.SetPluginConfig(NMPANSupport, False) File /usr/lib/pymodules/python2.6/dbus/proxies.py, line 140, in __call__ **keywords) File /usr/lib/pymodules/python2.6/dbus/connection.py, line 630, in call_blocking message, timeout) dbus.exceptions.DBusException: org.freedesktop.DBus.Python.TypeError: Traceback (most recent call last): File /usr/lib/pymodules/python2.6/dbus/service.py, line 702, in _message_cb retval = candidate_method(self, *args, **keywords) File string, line 2, in SetPluginConfig File /usr/lib/python2.6/dist-packages/blueman/plugins/applet/DBusService.py, line 97, in SetPluginConfig self.Applet.Plugins.SetConfig(plugin, value) File /usr/bin/blueman-applet, line 257, in SetConfig self.__config.props.applet_plugins = plugins File /usr/lib/python2.6/dist-packages/blueman/plugins/ConfigPlugin.py, line 37, in __setattr__ self.__dict__[Config]().set(key, value) File /usr/lib/python2.6/dist-packages/blueman/plugins/config/Gconf.py, line 81, in set func(BLUEMAN_PATH + self.section + / + key, value) File /usr/lib/python2.6/dist-packages/blueman/plugins/config/Gconf.py, line 76, in x self.client.set_list(key, gconf.VALUE_STRING, val) TypeError: value should be a string If I try to select any other radio button in the window, this traceback will be produces after each selection (modulo first arg of SetPluginConfig). When I press Apply, the following message is displayed: Failed to apply network settings: 'org.freedesktop.DBus.Python.dbus.exceptions.DBusException: Not authorized'. However, dbus-monitor shows no dbus activity after I press Apply. hciconfig -a: hci0: Type: BR/EDR Bus: USB BD Address: 00:03:7A:E3:02:1D ACL MTU: 384:8 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:14194 acl:108 sco:0 events:789 errors:0 TX bytes:19167 acl:165 sco:0 commands:400 errors:0 Features: 0xff 0xff 0x8f 0xfe 0x9b 0xf9 0x00 0x80 Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 Link policy: RSWITCH HOLD SNIFF PARK Link mode: SLAVE ACCEPT Name: 'dimail-0' Class: 0x5a010c Service Classes: Networking, Capturing, Object Transfer, Telephony Device Class: Computer, Laptop HCI Version: 2.0 (0x3) Revision: 0x77b LMP Version: 2.0 (0x3) Subversion: 0x77b Manufacturer: Cambridge Silicon Radio (10) -- System Information: Debian Release: 6.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') 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/bash Versions of packages blueman depends on: ii bluez 4.70-1 Bluetooth tools and daemons ii dbus 1.2.24-4 simple interprocess messaging syst ii hicolor-icon-theme0.12-1 default fallback theme for FreeDes ii libbluetooth3 4.70-1 Library to use the BlueZ Linux Blu ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libcairo2 1.8.10-4 The Cairo 2D vector graphics libra ii libglib2.0-0 2.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-1 The GTK+ graphical user interface ii libpango1.0-0 1.28.1-1 Layout and rendering of internatio ii librsvg2-common 2.26.3-1 SAX-based renderer library for SVG ii libstartup-notificati 0.10-1 library for program launch feedbac ii notification-daemon 0.5.0-2daemon to displays passive pop-up ii obex-data-server 0.4.5-1+b1 D-Bus service for OBEX client and ii python2.6.6-3+squeeze3 interactive high-level object-orie ii python-central0.6.16+nmu1register and build utility for Pyt ii python-dbus 0.83.1-1 simple interprocess messaging syst ii python-gobject2.21.4+is.2.21.3-1 Python bindings for the GObject li ii python-gtk2 2.17.0-4 Python bindings for the GTK+ widge ii python-notify 0.1.1-2+b2 Python bindings for libnotify Versions of packages blueman recommends: ii libpulse-mainloop-glib0 0.9.21-1.2 PulseAudio client libraries (glib ii policykit-1 0.96-4 framework for managing administrat ii python-gconf
Bug#611351: Acknowledgement (blueman: Unable to save Network settings after enabling PAN)
I've tested version 1.22~bzr707-1 from experimental, and bug is present there as well. -- Dmitry Astapov
Bug#592211: mhddfs-related entries in fstab are not processed under dependency-driven boot (insserv)
On Wed, Oct 27, 2010 at 8:03 AM, Dmitry E. Oboukhov un...@debian.orgwrote: DA It is not a bug of insserv per se. Rather, insserv needs to be notified that when mhddfs mounts are present, fuse becomes a pre-requisite for mounting them. See bug #41 for similar discussion for another filesystem implementation. I doubt that *each* fuse filesystem should notify insserv. I think that this notification should be placed into fuse-package (fuse-utils). And only if a filesystem requires additional services, then it should provide such notifies. What kind of additional services you have in mind, exactly? I am not a DD, but in my opinion the following makes sense: If starting up fuse early has no adverse side-effects, then it is the proper way to go, and this bug should be merged with #41. Otherwise (assuming there are some side-effects) the following seems to be the proper course: 1)Fuse should be started early only if there are some fuse-based mounts in /etc/fstab 2)Fuse-utils could not possibly know how to detect all possible syntaxes for fuse-based filesystems in /etc/fstab 3)Therefore, it falls on prospective filesystem packages to provide init.d scripts that would either implicitly mount fstab entries or bump up dependencies on fuse so that it would be started earlier. Upon short investigation, I see no obvious problems in just starting fuse early. However, again, I am not a Debian Developer. Could you please take this up with maintainer of fuse-utils? Does fuse-utils has a filled bug for this subject? Seems like #41 and #526115 talk about this very same matter. -- ... mpd is off . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkzHspwACgkQq4wAz/jiZTdv0gCg2y8aAjJ9MC/YLkL+KZfFHMGA pqUAn1+FP6jb1mjNNxoQZNcfHIUPBj7F =FMPs -END PGP SIGNATURE- -- Dmitry Astapov
Bug#601546: initscripts: /etc/init.d/mountall.sh should depend on fuse to allow fuse-based FS mounts in /etc/fstab
Package: initscripts Version: 2.88dsf-12 Severity: normal Tags: sid When /etc/fstab contains fuse-based filesystem mounts AND insserv is used, all fuse-based mounts are not being mounted during boot. Bugs #592211, #41 could be seen as an example of this. At a first glance, there should be no harm in bringing fuse up early during boot, before mountall.sh executes. If this is indeed the case, then fuse should be added to Require-Start: header of mountall.sh to allow fuse filesystems in /etc/fstab. Thank you! -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-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 initscripts depends on: ii coreutils 8.5-1 GNU core utilities ii debianutils 3.4Miscellaneous utilities specific t ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii lsb-base 3.2-23 Linux Standard Base 3.2 init scrip ii mount 2.17.2-3.3 Tools for mounting and manipulatin ii sysv-rc 2.87dsf-6 System-V-like runlevel change mech ii sysvinit-utils2.88dsf-12 System-V-like utilities Versions of packages initscripts recommends: ii e2fsprogs 1.41.12-2 ext2/ext3/ext4 file system utiliti ii psmisc22.8-1 utilities that use the proc file s initscripts suggests no packages. -- Configuration Files: /etc/default/bootlogd changed: BOOTLOGD_ENABLE=Yes -- 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#592211: mhddfs-related entries in fstab are not processed under dependency-driven boot (insserv)
On Tue, Oct 26, 2010 at 4:41 PM, Dmitry E. Oboukhov un...@debian.orgwrote: Hi, Dmitry! I don't reproduce the problem. I use mhddfs only from fstab: home.uvw.ru:[~]$ grep mhddfs /etc/fstab mhddfs#/mnt/first_1T,/mnt/second_1T,/mnt/fourth/common /share/share fuse user,allow_other,default_permissions,exec 0 0 mhddfs#/mnt/third/common,/mnt/hda3,/share/hdd1 /share/common fuse user,allow_other,default_permissions,exec 0 0 And it is mounted fine for each booting. So I set unreproducible tag for this bugreport. Pleace, show me a configuration which can't mount mhdd filesystem in booting. Configuration: ~$ grep mhddfs /etc/fstab mhddfs#/storage-1Tb,/storage-500Gb /storage fuse allow_other,mlimit=15G 0 2 Insserv version: $ apt-cache policy insserv insserv: Installed: 1.14.0-2 Maybe your configuration does not use insserv? Does your configuration include some hint files for insserv in /etc/init.d? (is dpkg -L mhddfs | grep etc empty or not?) If not, could you please verify that your installation lists fuse as prerequisite for any of the moun* scripts like this: $ grep '^mount[^:]*:' /etc/init.d/.depend.boot | grep fuse This was producing empty output for me, until I fixed the bug with quick workaround: $ cat /etc/init.d/mount-mhddfs #! /bin/sh ### BEGIN INIT INFO # Provides: mount-storage # Required-Start:$network fuse # Required-Stop: # Default-Start: S # Default-Stop: # Short-Description: Force mount of mhddfs filesystem on boot ### END INIT INFO mount /storage Notice the Required-Start:$network fuse. HTH, Dmitry. On 11:29 Sun 08 Aug , Dmitry Astapov wrote: DA Package: mhddfs DA Version: 0.1.37 DA Severity: important DA Since recently, insserv (a.k.a. dependency-driven boot) is the DA preferred way of booting up Debian machines. DA With default insserv setup, fuse is started after the local and remote DA filesystems are mounted up, which means that fuse is not available at DA the time mhddfs-related entries in /etc/fstab are processed. DA As a result, none of mhddfs filesystems in /etc/fstab are not mounted at DA the end of boot up. DA Bug #41 seems to contain a recipe for fixing this (it is related DA to another fuse-based filsystem, but root cause seems to be the same) DA -- System Information: DA Debian Release: squeeze/sid DA APT prefers unstable DA APT policy: (500, 'unstable'), (500, 'testing') DA Architecture: i386 (i686) DA Kernel: Linux 2.6.30-1-686 (SMP w/2 CPU cores) DA Locale: LANG=en_US.UTF8, LC_CTYPE=en_US.UTF8 (charmap=UTF-8) DA Shell: /bin/sh linked to /bin/bash DA Versions of packages mhddfs depends on: DA ii fuse-utils2.8.4-1Filesystem in USErspace (utilities DA ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib DA ii libfuse2 2.8.4-1Filesystem in USErspace library DA mhddfs recommends no packages. DA mhddfs suggests no packages. DA -- no debconf information -- ... mpd playing: U.D.O. - They Want War . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkzG2msACgkQq4wAz/jiZTdTfQCgzhr8Xp8DQFdcmfT3gprnVfgS +bIAn0UeMSGrs7gIa7rfXsH1JVWx6G79 =MdVJ -END PGP SIGNATURE- -- Dmitry Astapov
Bug#592211: mhddfs-related entries in fstab are not processed under dependency-driven boot (insserv)
On Tue, Oct 26, 2010 at 8:12 PM, Dmitry E. Oboukhov un...@debian.orgwrote: DA Configuration: DA ~$ grep mhddfs /etc/fstab DA mhddfs#/storage-1Tb,/storage-500Gb /storage fuse allow_other,mlimit=15G 0 2 DA Insserv version: DA $ apt-cache policy insserv DA insserv: DA Installed: 1.14.0-2 DA Maybe your configuration does not use insserv? Yes, Now I hear about insserv for the first time :) I use lenny/squeeze mix on my server. Well, unless I am much mistaken, all boxes installed with squeeze would have insserv enabled by default, so it is better to be prepared. May be it is a bug of insserv? It is not a bug of insserv per se. Rather, insserv needs to be notified that when mhddfs mounts are present, fuse becomes a pre-requisite for mounting them. See bug #41 for similar discussion for another filesystem implementation. DA Does your configuration include some hint files for insserv in /etc/init.d? (is dpkg -L mhddfs | grep etc empty or not?) empty, of course :) DA If not, could you please verify that your installation lists fuse as prerequisite for any of the moun* scripts like this: DA $ grep '^mount[^:]*:' /etc/init.d/.depend.boot | grep fuse /etc/init.d/.depend.boot - file not found :) -- ... mpd playing: U.D.O. - Raiders Of Beyond . ''`. Dmitry E. Oboukhov : :’ : email: un...@debian.org jabber://un...@uvw.ru `. `~’ GPGKey: 1024D / F8E26537 2006-11-21 `- 1B23 D4F8 8EC0 D902 0555 E438 AB8C 00CF F8E2 6537 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEUEAREDAAYFAkzHDAcACgkQq4wAz/jiZTc+1ACfcckEHCJoICEXGj5D0MSjfaim iIAAl0qZXheAanTV/VL3wnBEXbPbLU4= =OGY7 -END PGP SIGNATURE- -- Dmitry Astapov
Bug#594092: initramfs-tools: Detection of resume device could terminate prematurely
Package: initramfs-tools Version: 0.98 Severity: normal Hi, My configuration includes (among other things) encrypted swap + uswsusp. Within last month one of the initrams-tools upgrades rendered my setup unusable: resume device (/dev/mapper/swap) was not available during boot. I went and peppered /usr/share/initramfs-tools/hooks/cryptroot with debug output and found out that: 1)I have (orphaned) /etc/suspend.conf lying around since Good Olde Times which lists /dev/sda8 as resume target 2)All other (proper) places list /dev/mapper/swap as resume target 3)cryptroot hook terminates prematurely trying to find canonical name for /dev/sda8. Specifically, line 97 of cryptroot: device=$(canonical_device $device) || return 0 causes hook to terminate prematurely, broking the resume process. I think that old config files lying around are not the only possible cause for breakage in this place, so other users might be affected as well - for example, if they made errors in their config files. I think that either user should be warned (Resume device ... is not available, fix manually) or more sensible approach to error handling should be employed. Thank you! -- Package-specific info: -- initramfs sizes -rw-r--r-- 1 root root 8.8M Aug 23 18:59 /boot/initrd.img-2.6.30-1-686 -rw-r--r-- 1 root root 8.6M Aug 10 15:04 /boot/initrd.img-2.6.30-1-686.bak -- /proc/cmdline root=/dev/sda1 ro ramdisk_size=8192 resume=/dev/mapper/swap -- resume RESUME=/dev/mapper/swap -- /proc/filesystems ext2 ext3 fuseblk -- lsmod Module Size Used by iwl394561064 0 omnibook 47824 0 sco 8832 2 rfcomm 30368 14 bnep 10860 4 l2cap 18120 19 rfcomm,bnep vboxnetadp 6428 0 vboxnetflt 12324 0 vboxdrv 155584 2 vboxnetadp,vboxnetflt acpi_cpufreq7640 0 cpufreq_powersave 1292 0 cpufreq_userspace 2768 0 cpufreq_stats 3520 0 cpufreq_conservative 6256 2 autofs420544 1 irda 95720 0 crc_ccitt 1816 1 irda binfmt_misc 7120 1 vmnet 33260 13 parport_pc 22420 0 parport31144 1 parport_pc vmblock11256 1 vmci 42584 0 vmmon 59876 0 kvm_intel 39744 0 kvm 138608 1 kvm_intel fuse 47752 1 nfsd 204900 0 exportfs3792 1 nfsd nfs 221580 0 lockd 57972 2 nfsd,nfs fscache34440 1 nfs nfs_acl 2640 2 nfsd,nfs auth_rpcgss31416 2 nfsd,nfs sunrpc163772 6 nfsd,nfs,lockd,nfs_acl,auth_rpcgss ext3 107172 3 jbd41036 1 ext3 btusb 10276 2 bluetooth 47060 9 sco,rfcomm,bnep,l2cap,btusb visor 13812 0 usbserial 27456 1 visor coretemp5176 0 ip_tables 10188 0 x_tables 14108 1 ip_tables sha256_generic 11216 0 cbc 3012 1 aes_i5868092 4 aes_generic27436 1 aes_i586 dm_crypt 11092 3 dm_mod 49992 7 dm_crypt snd_hda_codec_si3054 4024 1 snd_hda_codec_realtek 178472 1 snd_hda_intel 22192 0 snd_hda_codec 63580 3 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel snd_hwdep 6120 1 snd_hda_codec arc41560 2 snd_pcm_oss32232 0 snd_mixer_oss 12368 1 snd_pcm_oss ecb 2368 4 snd_pcm62420 4 snd_hda_codec_si3054,snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_midi5688 0 snd_rawmidi18596 1 snd_seq_midi iwlcore92264 1 iwl3945 snd_seq_midi_event 6212 1 snd_seq_midi pcmcia 24280 0 snd_seq42436 2 snd_seq_midi,snd_seq_midi_event snd_timer 17436 2 snd_pcm,snd_seq snd_seq_device 6136 3 snd_seq_midi,snd_rawmidi,snd_seq joydev 8576 0 snd49060 12 snd_hda_codec_si3054,snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device mac80211 142848 2 iwl3945,iwlcore yenta_socket 21168 1 tifm_7xx1 4864 0 intel_agp 22900 0 rsrc_nonstatic 9664 1 yenta_socket soundcore 6184 1 snd i2c_i8018564 0 nvidia 8869740 31 pcmcia_core31212 3 pcmcia,yenta_socket,rsrc_nonstatic pcspkr 2104 0 rng_core3672 0 rfkill 9668 2 iwlcore snd_page_alloc
Bug#592211: mhddfs-related entries in fstab are not processed under dependency-driven boot (insserv)
Package: mhddfs Version: 0.1.37 Severity: important Since recently, insserv (a.k.a. dependency-driven boot) is the preferred way of booting up Debian machines. With default insserv setup, fuse is started after the local and remote filesystems are mounted up, which means that fuse is not available at the time mhddfs-related entries in /etc/fstab are processed. As a result, none of mhddfs filesystems in /etc/fstab are not mounted at the end of boot up. Bug #41 seems to contain a recipe for fixing this (it is related to another fuse-based filsystem, but root cause seems to be the same) -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.30-1-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 mhddfs depends on: ii fuse-utils2.8.4-1Filesystem in USErspace (utilities ii libc6 2.11.1-3 Embedded GNU C Library: Shared lib ii libfuse2 2.8.4-1Filesystem in USErspace library mhddfs recommends no packages. mhddfs 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#529920: libneon27-gnutls: Can confirm and provide strace log
Package: libneon27-gnutls
Severity: normal
I observe this bug here with 2.6.24 kernel. Downgrading helps.
Looks like the libneon messes with sockets somehow: here is what I got
with strace -e network -f -o LOG svn ls http://any/url/here:
21133 socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
21133 socket(PF_NETLINK, SOCK_RAW, 0) = 4
21133 bind(4, {sa_family=AF_NETLINK, pid=0, groups=}, 12) = 0
21133 getsockname(4, {sa_family=AF_NETLINK, pid=21133, groups=}, [12])
= 0
21133 sendto(4, \24\0\0\0\26\0\1\3\340\31\33J\0\0\0\0\0\0\0\0, 20, 0,
{sa_family=AF_NETLINK, pid=0, groups=}, 12) = 20
21133 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{0\0\0\0\24\0\2\0\340\31\33J\215R\0\0\2\10\200\376\1\0\0\0\10\0\1\0\177\0\0\1...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 280
21133 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{@\0\0\0\24\0\2\0\340\31\33J\215R\0\0\n\200\200\376\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 256
21133 recvmsg(4, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=},
msg_iov(1)=[{\24\0\0\0\3\0\2\0\340\31\33J\215R\0\0\0\0\0\0\1\0\0\0\24\0\1\0\0\0\0\0...,
4096}], msg_controllen=0, msg_flags=0}, 0) = 20
21133 socket(PF_INET, 0x80001 /* SOCK_??? */, IPPROTO_TCP) = -1 EINVAL (Invalid
argument)
Looks like args to the socket call on the last line are FUBAR. Hope
this helps.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-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 libneon27-gnutls depends on:
ii libc6 2.9-12GNU C Library: Shared libraries
ii libcomerr2 1.41.5-1 common error description library
ii libgnutls262.6.6-1 the GNU TLS library - runtime libr
ii libgssapi-krb5-2 1.7dfsg~beta2-4 MIT Kerberos runtime libraries - k
ii libk5crypto3 1.7dfsg~beta2-4 MIT Kerberos runtime libraries - C
ii libkrb5-3 1.7dfsg~beta2-4 MIT Kerberos runtime libraries
ii libxml22.7.3.dfsg-1 GNOME XML library
ii zlib1g 1:1.2.3.3.dfsg-13 compression library - runtime
Versions of packages libneon27-gnutls recommends:
ii ca-certificates 20081127 Common CA certificates
libneon27-gnutls 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#416360: gnus-pers.el: gnus-functionp is absent in Oort Gnus
Package: gnus-bonus-el Version: 26.9-1 Severity: important Tags: patch Current Gnus does not have gnus-functionp anymore. Plain functionp should be used instead. Current version of gnus-pers.el is unuseable on current gnus, but fix is trivial: sed -i.bak -e 's/gnus-functionp/functionp/g' gnus-pers.el -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=ru_UA.KOI8-U, LC_CTYPE=ru_UA.KOI8-U (charmap=KOI8-U) Versions of packages gnus-bonus-el depends on: ii gnus5.11+v0.5.dfsg-3 A versatile news and mail reader f ii xemacs2121.4.19-1highly customizable text editor ii xemacs21-mule [xemacs21 21.4.19-1highly customizable text editor -- gnus-bonus-el recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320458: xlibs-data: Couple of amendments: this is xserver-xorg bug, and it is still not fixed in 6.9.0.dfsg.1-3
Package: xlibs-data
Version: 6.9.0.dfsg.1-3
Followup-For: Bug #320458
As I said in the previous followup to this bug
(http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=320458;msg=58), the problem
is really in libfreetype.{a,so}, which resides in the xserver-xorg package
(so, maybe the bug should be reassigned?):
`-- dlocate /usr/X11R6/lib/modules/fonts/libfreetype.so
xserver-xorg: /usr/X11R6/lib/modules/fonts/libfreetype.so
In the previous version of xserver-xorg, this library was built as '.a' and it
was possible to replace it with libfreetype.a from
xserver-xfree86_4.3.0.dfsg.1-14sarge1_i386.deb and get freetype rendering
working properly.
However, in the recent build (6.9.0.dfsg.1-3) the library is built as '.so'
and there is no easy workaround possible anymore.
I've searched in the X Task Force list archives, thinking that maybe there is
some kind of obscure policy/licensing issue/reason for NOT enabling bytecode
interpreter in xorg's libfreetype (while it IS enabled in the
libfreetype.*deb), but haveb't found anything.
Could this be fixed? Pretty please? It is a matter of uncommenting a single
#define, and the only possible forkaround for now is custom building of the
whole xorg, which is not for the weak of heart ...
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-2-686
Locale: LANG=ru_UA.KOI8-U, LC_CTYPE=ru_UA.KOI8-U (charmap=KOI8-U)
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#343186: nvidia-kernel-source: Confirmed also for 8178 on Toshiba 5100
Package: nvidia-kernel-source Version: 1.0.7174-4 Followup-For: Bug #343186 I've tried 8178, either pre-built (from debian archive) or locally built with module-assistant. nvidia-glx was upgraded to proper version (8178). My card is supported by the drivers (GeForce 2Go 440, pci id 0x0174). Attempt to start X with new nvidia.ko results in immediate hard lockup (even before nvidia logo is shown). /var/log/Xorg.0.log does not survive subsequent fsck or not created at all. Attempt to start X from remote machine (over ssh) shows only first 10 or so lines of Xorg log, which does not say anything. I'v tried this: * with all options for Device nvidia in xorg.cong commented out. * with NvAGP set to 0, 1 or 2 * with agpgart/intel_agp loaded or without them Every time the outcome is the same - hard lockup. Apparently, filesystem caches are not flushed properly, since fsck reports a lot of lost/orphaned inodes each time, and sometimes removes xorg.conf to /lost+found. Being afraid for my filesystem integrity, I haven't done any further checks. Could provide you with additional info, if any is required. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=ru_UA.KOI8-U, LC_CTYPE=ru_UA.KOI8-U (charmap=KOI8-U) Versions of packages nvidia-kernel-source depends on: ii debhelper 5.0.15 helper programs for debian/rules ii dpatch2.0.16 patch maintenance system for Debia ii make 3.80+3.81.b4-1 The GNU version of the make util ii sed 4.1.4-5The GNU sed stream editor Versions of packages nvidia-kernel-source recommends: ii devscripts2.9.10 Scripts to make the life of a Debi ii kernel-package10.031 A utility for building Linux kerne ii nvidia-glx1.0.7174-4 NVIDIA binary XFree86 4.x driver -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#330161: I'd like to second that - logjam DOES NOT use http proxy no matter what
Package: logjam Version: 4.5.1-4 Followup-For: Bug #330161 I tried every conceivable way: export http_proxy in the shell, changing settings in logjam, changing various proxy-related setting via gconf-editor (like syste/proxy and system/http-proxy). No matter what I tried, logjam always tries to connect directly. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.4-1-686 Locale: LANG=ru_UA.KOI8-U, LC_CTYPE=ru_UA.KOI8-U (charmap=KOI8-U) Versions of packages logjam depends on: ii libaspell15 0.60.3-5 GNU Aspell spell-checker runtime l ii libatk1.0-0 1.10.1-2 The ATK accessibility toolkit ii libc6 2.3.5-4GNU C Library: Shared libraries an ii libglib2.0-0 2.8.3-1The GLib library of C routines ii libgnutls11 1.0.16-13.1GNU TLS library - runtime library ii libgtk2.0-0 2.6.10-1 The GTK+ graphical user interface ii libgtkspell0 2.0.10-2 a spell-checking addon for GTK's T ii libpango1.0-0 1.8.2-1Layout and rendering of internatio ii libsoup2.2-8 2.2.6-1an HTTP library implementation in ii libx11-6 6.8.2.dfsg.1-9 X Window System protocol client li ii libxml2 2.6.22-1 GNOME XML library ii xlibs 6.8.2.dfsg.1-9 X Window System client libraries m ii zlib1g1:1.2.3-3 compression library - runtime logjam recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#320458: xlibs-data: ugly TTF rendering is an xserver-xorg/freetype bug
Package: xlibs-data Version: 6.8.2.dfsg.1-9 Followup-For: Bug #320458 I agree with previous posters that this is an xserver-xorg bug, and not an xlibs-data bug. Cause of the bug: disabled bytecode interpreter in the xorg's own freetype causes TTF's from msttcorefonts to be ugly-rendered for core protocol clients like xemacs(xaw) or tkabber(tk). How to verify: According to the sources of libfreetype6, bytecode interpreter module, ttinterp.c defines, among other things, symbol 'Interp'. Doing nm /usr/lib/libfreetype.a | grep Interp shows that indeed it does. Now, let's check 'libfreetype6.a from xserver-xorg: nm /usr/X11R6/lib/modules/fonts/libfreetype.a | grep Interp show that bytecode interpreter is not enabled/compiled in. Then again, in the xserver-xfree from stable, bytecode interpreter is present (check is the same as above). Thus, downgrade to xserver-xfree86 from stable fixes the problem (I did exactly that). Strange thing is, according to the file ./debian/tmp/usr/X11R6/lib/X11/config/xorgsite.def from the xorg's source package, bytecode interpreter should be enabled. See line: #define Freetype2BuildDefines -DTT_CONFIG_OPTION_BYTECODE_INTERPRETER However, for some reason this setting fail to propagate to proper place during build stage. It would be nice if this is fixed :) TIA -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.4-1-686 Locale: LANG=ru_UA.KOI8-U, LC_CTYPE=ru_UA.KOI8-U (charmap=KOI8-U) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
