Bug#630629: fex: Does not work properly through apache (ProxyPass / http://127.0.0.1:8888)
Package: fex
Version: 20110610-1
Severity: normal
I have set up fex as a virtualhost in my apache. With a somewhat hackish
config (attached) it works. On the version in Debian Stable, it does
not, but the version from sid does.
The two lines needed in apache:
ProxyPass SID http://127.0.0.1:/
ProxyPass / http://127.0.0.1:/
This works fine for the web interface, but not for fexsend/fexget/fix.
These clients do not send the hostname. My apache logs contain:
client sent HTTP/1.1 request without hostname (see RFC2616 section 14.23)
The fix and fex* clients should be updated to send this header. This
applies to both package fex and fex-utils.
-- System Information:
Debian Release: 6.0.1
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages fex depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii libdigest-md5-file-perl 0.07-1 Perl extension for getting MD5 sum
ii perl 5.10.1-17 Larry Wall's Practical Extraction
ii xinetd1:2.3.14-7 replacement for inetd with many en
Versions of packages fex recommends:
ii fex-utils20100208+debian1-1+squeeze1 web service for transfering very l
ii libnet-dns-p 0.66-2 Perform DNS queries from a Perl sc
ii perl-modules 5.10.1-17 Core Perl modules
fex suggests no packages.
-- Configuration Files:
/etc/fex/fex.ph changed:
$hostname = 'fex.8d.no';
$reverse_proxy_ip = '127.0.0.1';
$ENV{HTTP_HOST} = $hostname . ':443';
$ENV{PROTO} = 'https';
$fakehost = $hostname;
$admin = 'f...@8d.no';
$admin_pw = 'I removed this =)';
$ENV{SERVER_ADMIN} = $admin;
$bcc = 'f...@8d.no';
$mdomain = '8d.no';
$spooldir = $ENV{HOME}.'/spool';
$logdir = $spooldir;
$recipient_quota = 0;
$sender_quota = 0;
$keep = 14;
$autodelete = 'NO';
@local_hosts = qw(127.0.0.1);
@local_domains = qw(akuma.no 8d.no ak47.no);
@local_rdomains = qw(samfundet.no);
@public_recipients = qw(m...@8d.no);
/etc/xinetd.d/fex changed:
service fex
{
socket_type = stream
wait= no
type= unlisted
protocol= tcp
port=
cps = 5 10
user= fex
groups = yes
server = /usr/share/fex/bin/fexsrv
nice= 0
disable = no
bind= 127.0.0.1
}
-- 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#630630: Anacron cross-building patch
Subject: anacron: Package needs patching to cross-build Package: anacron Version: 2.3-14 Severity: normal We are working on making core debian packages cross-buildable. Anacron needs a minor patch in order to cross-build correctly: diff -urN /home/wookey/debian/unstable/crossfixes/origs/anacron-2.3/debian/changelog /home/wookey/debian/unstable/crossfixes/patched/anacron-2.3/debian/changelog --- /home/wookey/debian/unstable/crossfixes/origs/anacron-2.3/debian/changelog 2011-06-14 16:26:09.0 +0100 +++ /home/wookey/debian/unstable/crossfixes/patched/anacron-2.3/debian/changelog 2011-06-14 16:27:03.843835156 +0100 @@ -1,3 +1,10 @@ +anacron (2.3-14.1) UNRELEASED; urgency=low + + * Non-maintainer upload. + * Cross-building fix to rules file + + -- Wookey woo...@debian.org Tue, 14 Jun 2011 16:26:41 +0100 + anacron (2.3-14) unstable; urgency=low * New maintainers (closes: #546169, #548777) diff -urN /home/wookey/debian/unstable/crossfixes/origs/anacron-2.3/debian/rules /home/wookey/debian/unstable/crossfixes/patched/anacron-2.3/debian/rules --- /home/wookey/debian/unstable/crossfixes/origs/anacron-2.3/debian/rules 2011-06-14 16:26:09.0 +0100 +++ /home/wookey/debian/unstable/crossfixes/patched/anacron-2.3/debian/rules 2011-06-14 16:24:28.627835155 +0100 @@ -5,12 +5,17 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE) +DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) +ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_BUILD_GNU_TYPE))) +MAKEFLAGS = CC=$(DEB_HOST_GNU_TYPE)-gcc +endif build: build-stamp build-stamp: dh_testdir - $(MAKE) + $(MAKE) $(MAKEFLAGS) touch build-stamp -- System Information: Debian Release: 6.0 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.37-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630632: python-llfuse: provide doc package to get rid of dependency on libjs-jquery
Package: python-llfuse Version: 0.32-1 Severity: normal python-llfuse depends on libjs-jquery because of the provided docs. Please provide a doc package so one can use python-llfuse without having to install libjs-jquery. thanks regards, -mika- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/2011-06-15t19-42...@devnull.michael-prokop.at
Bug#630633: pitivi 0.14.0-2 dies instantly, while 0.13.5-2 doesn't
Package: pitivi
Version: 0.14.0-2
Severity: important
Hi there.
I upgraded my system to pitivi 0.14.0-2 from 0.13.5-2 and, now, when I try to
start it, I get:
,[ pitivi ]
| Traceback (most recent call last):
| File /usr/bin/pitivi, line 132, in module
| _run_pitivi()
| File /usr/bin/pitivi, line 127, in _run_pitivi
| sys.exit(ptv.main(sys.argv))
| File /usr/lib/pitivi/python/pitivi/application.py, line 531, in main
| ptv = StartupWizardGuiPitivi(debug=options.debug)
| File /usr/lib/pitivi/python/pitivi/application.py, line 382, in __init__
| FullGuiPitivi.__init__(self, debug)
| File /usr/lib/pitivi/python/pitivi/application.py, line 275, in __init__
| InteractivePitivi.__init__(self, debug)
| File /usr/lib/pitivi/python/pitivi/application.py, line 223, in __init__
| Pitivi.__init__(self)
| File /usr/lib/pitivi/python/pitivi/application.py, line 135, in __init__
| self.effects = EffectsHandler()
| File /usr/lib/pitivi/python/pitivi/effects.py, line 123, in __init__
| self._setAllEffects()
| File /usr/lib/pitivi/python/pitivi/effects.py, line 141, in _setAllEffects
| added = self.addStreams(element_factory, effect)
| File /usr/lib/pitivi/python/pitivi/effects.py, line 192, in addStreams
| stream = get_stream_for_pad(pad)
| File /usr/lib/pitivi/python/pitivi/stream.py, line 362, in
get_stream_for_pad
| stream.pad_id = pad_id
| AttributeError: 'NoneType' object has no attribute 'pad_id'
`
If I downgrade to pitivi 0.13.5-2, then I can start pitivi without any
problems.
If you need further information, please let me know.
Thanks.
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf-8, LC_CTYPE=pt_BR.utf-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages pitivi depends on:
ii gnome-icon-theme2.30.3-2 GNOME Desktop icon theme
ii gstreamer0.10-alsa [gstream 0.10.34-1GStreamer plugin for ALSA
ii gstreamer0.10-gconf [gstrea 0.10.29-2GStreamer plugin for getting the s
ii gstreamer0.10-gnonlin 0.10.17-2non-linear editing module for GStr
ii gstreamer0.10-plugins-bad [ 0.10.22-2GStreamer plugins from the bad s
ii gstreamer0.10-plugins-base 0.10.34-1GStreamer plugins from the base
ii gstreamer0.10-plugins-good 0.10.29-2GStreamer plugins from the good
ii gstreamer0.10-pulseaudio [g 0.10.29-2GStreamer plugin for PulseAudio
ii gstreamer0.10-x [gstreamer0 0.10.34-1GStreamer plugins for X11 and Pang
ii libgstreamer-plugins-base0. 0.10.34-1GStreamer libraries from the base
ii libgstreamer0.10-0 0.10.34-1Core GStreamer libraries and eleme
ii python 2.6.6-14 interactive high-level object-orie
ii python-cairo1.8.8-1+b2 Python bindings for the Cairo vect
ii python-central 0.6.17 register and build utility for Pyt
ii python-dbus 0.84.0-1 simple interprocess messaging syst
ii python-gconf2.28.1-3 Python bindings for the GConf conf
ii python-glade2 2.24.0-2 GTK+ bindings: Glade support
ii python-gst0.10 0.10.21-2+b1 generic media-playing framework (P
ii python-gtk2 2.24.0-2 Python bindings for the GTK+ widge
ii python-pkg-resources0.6.16-1 Package Discovery and Resource Acc
ii python-pygoocanvas 0.14.1-1+b2 GooCanvas Python bindings
ii python-xdg 0.19-3 Python library to access freedeskt
ii python-zope.interface 3.6.1-1 Interfaces for Python
pitivi recommends no packages.
Versions of packages pitivi suggests:
ii frei0r-plugins 1.1.22git20091109-1.1 minimalistic plugin API for video
ii gstreamer0.10-ffmp 1:0.10.11-4.1 FFmpeg plugin for GStreamer
ii gstreamer0.10-plug 0.10.22-2 GStreamer plugins from the bad s
ii gstreamer0.10-plug 0.10.18-1 GStreamer plugins from the ugly
-- no debconf information
--
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://rb.doesntexist.org : Packages for LaTeX : algorithms.berlios.de
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630634: RFP: ding-libs -- ding-libs is a set of helpful libraries used by SSSD and other projects.
Package: wnpp Severity: wishlist * Package name: ding-libs Version : 0.1.2 Upstream Author : Dmitri Pal d...@redhat.com * URL : https://fedorahosted.org/sssd/ * License : LGPL Programming Lang: C Description : ding-libs is a set of helpful libraries used by SSSD and other projects. ding-libs provides utility functions to manipulate filesystem pathnames, a hash table which dynamically resizes to achieve optimal storage and access time properties, a data type to collect data in a hierarchical structure for easy iteration and serialization, a dynamically growing, reference-counted array, and a library to process configuration files in initialization format (INI) into a library collection data structure. It is required to upgrade the sssd package to 1.5.x -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624369: winff now builds, severity lowered
severity 624369 normal retitle 624369 winff should not depend on fp-utils thanks As a work around for the original bug, winff build depends on fp-utils now. Once bug 624361 is solved, it should not. signature.asc Description: OpenPGP digital signature
Bug#630628: old processes
Fix is looking through ps output and killing everything that looks remotely like a KDE thing. After that everything's back working. So it's just really bad diagnostics (not working and spewing some strange error messages somewhere). Regards Christoph -- 9FED 5C6C E206 B70A 5857 70CA 9655 22B9 D49A E731 Debian Developer | Lisp Hacker | CaCert Assurer A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? pgppCMEmhyzJv.pgp Description: PGP signature
Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
[Michael Biebl] For the examples I mentioned, those files don't need to be persistent, so /var/tmp would not be the right place. I must have been unclear. /var/tmp/ is not for persistent data. It is for temporary data, but not expected to disappear during boot. /tmp/ is for temporary data which is expected to disappear during boot. Persistent data go in /var/lib/ or another more sensible location. :) Well, I don't consider programs using /tmp for large temporary files as buggy as long as someone can provide reference for it. I am not trying to convince you, I am just trying to explain how things work. These days, I do not have the spare time available that is needed to try to convince you. :) It might interest you to know that on Solaris, /tmp/ has been a RAM file system for probably 15 years now, and any portable program need to take the simple fact that /tmp/ is not for large files. Happy hacking, -- Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609316: Segmentation fault during fingerprinting on 32 installations machines with sse2
forcemerge 609316 537082 tags 609316 + squeeze patch retitle 609316 Segmentation fault during fingerprinting on 32 installations machines with sse2 thanks Tested the patch from http://bazaar.launchpad.net/~musicbrainz-developers/picard/trunk/revision/947 and it fixes both bugs. Kind regards, Frank Eckelmann signature.asc Description: This is a digitally signed message part.
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Maik Zumstrull wrote: Package: unbound Version: 1.4.10-1 Severity: normal I've noticed this on my home router, which has a fairly fresh dnsmasq. Apparently, unbound can't resolve through this and just SERVFAILs for everything. Obviously, this is primarily a problem in dnsmasq (I assume). But since dnsmasq is in tons of home routers and unbound uses forwarding by default in Debian, I think it's important to have a workaround in place. it would be useful if you could get a packet trace of the failure. run something like: # tcpdump -s1518 -pni any -w dnsmasq-failure.pcap 'tcp port 53 or udp port 53' and send the pcap file to this bug report. (unfortunately that bpf expression will miss non-initial UDP fragments but that's not all that important for tracking this down.) I think a good solution would be for unbound to detect when it can't reliably resolve through one of the forwarding hosts and stop using it, falling back to normal recursion if they all end up being dropped. Ideally, this would happen before the user experiences lookup failures, for example by immediately resolving a bunch of well-known hosts after adding new forwarders, so that they will already be dropped with a high probability if they are broken. this problem affects not only unbound, so unbound isn't really the right place to implement a hack like that. the reality is that just about every public wifi access point intercepts and mangles DNS packets in some fashion. detecting whether an internet link is safe for full recursive and/or forwarding only DNS/DNSSEC operation is an interesting problem. there has been a little bit of work in this area -- e.g., windows 7's network awareness feature does a simple DNS lookup and checks for an expected answer, and there is an ldns-test-edns utility in the ldnsutils package which checks if a recursive server is EDNS/DNSSEC transparent. but a more comprehensive, stand-alone test utility/library would be a useful thing to have, and it could hopefully be integrated into resolvconf or the system's network interface manager. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#629956: apt: apt-cache fails with current fakeroot
On Wed, Jun 15, 2011 at 03:22:51PM +, Clint Adams wrote: On Wed, Jun 15, 2011 at 02:41:01PM +0200, Martin Pitt wrote: I tracked this down to apt-cache now failing to work under fakeroot: $ fakeroot apt-cache policy coreutils E: Could not open file /var/cache/apt/pkgcache.bin - open (13: Permission denied) E: Failed to truncate file - ftruncate (9: Bad file descriptor) E: The package lists or status file could not be parsed or opened. This isn't relevant to the more general problem, but I have to wonder why apt-cache policy would ever need to write to /var/cache/apt/pkgcache.bin If mtime on any index or the list of indexes changed changed, the cache must be rebuilt (index=Packages list or status file). -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. pgpgZ0YsQLSpT.pgp Description: PGP signature
Bug#615007: reassign 615007 to tasksel
reassign 615007 tasksel thanks -- -- .''`. Alice Ferrazzi aliceinw...@gnumerica.org Related projects: : :' : proud Debian volunteer QA http://goo.gl/I6FCB blog: http://goo.gl/UuRDh `- Debian - when you have better things to do than watching the monitor -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606656: MTXrun | resolvers: warning: no lua configuration files found
Hello, While following http://wiki.contextgarden.net/Debian_installation for installing context_2010.07.30-1_all.deb did bring the step mtxrun --generate me this output: MTXrun | resolvers: variable 'SELFAUTOLOC' set to '/usr/bin' MTXrun | resolvers: variable 'SELFAUTODIR' set to '/usr' MTXrun | resolvers: variable 'SELFAUTOPARENT' set to '.' MTXrun | resolvers: variable 'TEXMFCNF' set to '' MTXrun | resolvers: variable 'TEXMF' set to '' MTXrun | resolvers: variable 'TEXOS' set to '/usr' MTXrun | resolvers MTXrun | resolvers: warning: no lua configuration files found MTXrun | resolvers MTXrun | resolvers Executing context --help gives me MTXrun | forcing cache reload MTXrun | resolvers: warning: no lua configuration files found MTXrun | resolvers MTXrun | resolvers MTXrun | the resolver databases are not present or outdated MTXrun | resolvers: using suffix based filetype 'lua' MTXrun | resolvers: using suffix based filetype 'lua' MTXrun | resolvers: remembering file 'mtx-context.lua' MTXrun | resolvers: using suffix based filetype 'lua' MTXrun | unknown script 'context.lua' or 'mtx-context.lua' What should I do to get the lua configuration files? Groeten Stappers -- And is there a policy on top-posting vs. bottom-posting? Yes. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
On Wed, Jun 15, 2011 at 20:05, Robert Edmonds edmo...@debian.org wrote: Maik Zumstrull wrote: I've noticed this on my home router, which has a fairly fresh dnsmasq. Apparently, unbound can't resolve through this and just SERVFAILs for everything. Obviously, this is primarily a problem in dnsmasq (I assume). But since dnsmasq is in tons of home routers and unbound uses forwarding by default in Debian, I think it's important to have a workaround in place. it would be useful if you could get a packet trace of the failure. run something like: # tcpdump -s1518 -pni any -w dnsmasq-failure.pcap 'tcp port 53 or udp port 53' Sure, no problem. Attached. The trace leads me to assume that this might not be dnsmasq's fault, but this: https://groups.google.com/d/topic/public-dns-discuss/9vXr9AJny4w/discussion On the other hand, forwarding from dnsmasq to a different server that can return DS records doesn't fix it. So maybe it's double-broken: Google doesn't deliver the DS records, but dnsmasq would trash them if they did. dnsmasq-failure.pcap Description: Binary data
Bug#630523: (forw) Bug#630523: [INTL:ru] Incorrect translation of Detecting link on ${interface}
15.06.2011 18:39, Sergey Alyoshin пишет:
2011/6/15 Nick Shaforostoffsha...@ukr.net:
please change it to Поиск сигнала через интерфейс ${interface}
or Поиск сигнала в ${interface} if you need a shorter alternative
Может лучше проверка сигнала?
Проверка наличия подключения или Проверка наличия соединения?
Bug#630635: hardcodes log_level
Package: planet-venus Version: 0~bzr95-2+lenny1 Severity: important The patch command-improvement.patch appears to harcode WARNING as the value of log_level, which is a real pain on a production machine like this one. (Apparently, the problem persists in sid.) -- System Information: Debian Release: 5.0.8 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (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/bash Versions of packages planet-venus depends on: ii python 2.5.2-3 An interactive high-level object-o ii python-chardet 1.0.1-1.1universal character encoding detec ii python-html5lib 0.11.1-1 HTML parser/tokenizer based on the ii python-htmltmpl 1.22-10 Templating engine for separation o ii python-httplib2 0.2.0-2 A comprehensive HTTP client librar ii python-librdf 1.0.7.1-1+b1 Python language bindings for the R ii python-libxml2 2.6.32.dfsg-5+lenny4 Python bindings for the GNOME XML ii python-support 0.8.4lenny2 automated rebuilding support for P ii python-utidylib 0.2-3.2 Python wrapper for TidyLib Versions of packages planet-venus recommends: ii python-libxslt1 1.1.24-2 Python bindings for libxslt1 Versions of packages planet-venus suggests: pn python-django none (no description available) ii python-genshi 0.5.1-1Python XML-based template engine -- 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#630225: [nvidia-installer-cleanup] Does not install correctly, though nvidia works!
On Wednesday 13 Sivan 5771 11:18:53 Andreas Beckmann wrote: On 2011-06-12 15:32, David Baron wrote: The nvidia-alternatives package, superseded by this one, yields the following error on installation of nvidia-glx: You didn't post the error message why nvidia-installer-cleanup didn't configure properly. Without nvidia-installer-cleanup being configured successfully, all the other packages can't be configured. Try dpkg-reconfigure nvidia-installer-cleanup Andreas Did this OK. Did not change anything.
Bug#625877: Problems of using the beta driver, as I use the nvidia-kernel-dkms
Dear all, After needing to reboot my machine, I got a strange error when I try to enable desktop effects, or even glxgears or glxinfo: glxgears: Error: couldn't get an RGB, Double-buffered visual glxinfo: name of display: :0 Error: couldn't find RGB GLX visual or fbconfig and compositing is not working on KDE, saying that it cannot enable the OpenGL renderer. All the nvidia packages are in the 275.09.04 version: dpkg -l | grep nvidia ii libgl1-nvidia-alternatives 275.09.04-1 simplifies replacing MESA libGL with GPU vendor libraries ii libgl1-nvidia-alternatives-ia32 275.09.04-1 simplifies replacing MESA libGL with GPU vendor libraries (32-bit) ii libgl1-nvidia-glx275.09.04-1 NVIDIA binary OpenGL libraries ii libgl1-nvidia-glx-ia32 275.09.04-1 NVIDIA binary OpenGL 32-bit libraries ii libglx-nvidia-alternatives 275.09.04-1 simplifies replacing Xorg module libglx.so with GPU vendor library ii nvidia-glx 275.09.04-1 NVIDIA binary Xorg driver ii nvidia-installer-cleanup 20110515+1 Cleanup after driver installation with the nvidia-installer ii nvidia-kernel-common 20110515+1 NVIDIA binary kernel module support files ii nvidia-kernel-dkms 275.09.04-1 NVIDIA binary kernel module DKMS source ii nvidia-settings 270.41.06-1 Tool for configuring the NVIDIA graphics driver ii nvidia-support 20110515+1 NVIDIA binary graphics driver support files ii nvidia-xconfig 270.41.06-1 X configuration tool for non-free NVIDIA drivers I have a suspicion that the mesa packages are the ones giving trouble: dpkg -l | grep mesa ii libgl1-mesa-dri 7.10.2-4 free implementation of the OpenGL API -- DRI modules ii libgl1-mesa-glx 7.10.2-4 free implementation of the OpenGL API -- GLX runtime ii libglu1-mesa 7.10.2-4 The OpenGL utility library (GLU) ii mesa-utils 8.0.1-2 Miscellaneous Mesa GL utilities But if I try to remove any one of them, apt-get tries to desinstall all my KDE. How can I help? What can be done? Thanks. 2011/6/8 M. infinity.probabil...@gmail.com: Thanks for your answer. The nvidia-kernel-dkms with the correction were uploaded to the repository yesterday, and now I can confirm that with the nvidia-kernel-dkms and nvidia-glx packages from experimental (275.09.04) KDE is very pleased :-). Everything seems to be working fine - resizing konsole, and so on - and I feel it a little bit faster too. Thanks! 2011/6/8 Andreas Beckmann deb...@abeckmann.de: On 2011-06-07 23:25, M. wrote: as I use the nvidia-kernel-dkms system and even if I try to remove the relevant packages the beta driver directly from Nvidia would not install. If you want us to look into this issue, please open a new bug report and give detailed lists of *nvidia* packages you installed and removed, as well as the error messages from nvidia-installer. The nvidia-installer probably won't work properly as long as any *nvidia* package is still installed, eventually they even need to be purged. Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627751: emacs23-el: octave-mode aligns comments poorly (fixed-column)
Hi Drew, On Tue, May 24, 2011 at 06:44:37PM +1000, Drew Parsons wrote: On Tue, 2011-05-24 at 18:22 +1000, Drew Parsons wrote: octave-mode appears to be configured to align comments to a fixed column. Pressing TAB on a line containing a comment (prefixed by # or %) pushes the comment symbol out to column 32. You need to enter two characters before TAB, so either ## TAB or %% TAB Regards, Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630552: linux-image-2.6.32-5-amd64: K8 ECC error
On Wed, 2011-06-15 at 07:50 +0200, Dario Minnucci wrote: Hi again, I've found a reference to this error [0] providing and a possible patch is provided. Regards, [0] https://patchwork.kernel.org/patch/67658/ I've reopened the bug and will check how it got fixed in mainline Linux (not sure whether that patch was applied or not). Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Maik Zumstrull wrote: On Wed, Jun 15, 2011 at 20:05, Robert Edmonds edmo...@debian.org wrote: it would be useful if you could get a packet trace of the failure. run something like: # tcpdump -s1518 -pni any -w dnsmasq-failure.pcap 'tcp port 53 or udp port 53' Sure, no problem. Attached. The trace leads me to assume that this might not be dnsmasq's fault, but this: https://groups.google.com/d/topic/public-dns-discuss/9vXr9AJny4w/discussion On the other hand, forwarding from dnsmasq to a different server that can return DS records doesn't fix it. So maybe it's double-broken: Google doesn't deliver the DS records, but dnsmasq would trash them if they did. ok, i assume in this trace 192.168.47.197 is the address of your unbound server, and 192.168.47.254 is the address of your dnsmasq server, and 127.0.0.1 is the address you are sending recursive queries to? and your dnsmasq server is forwarding all queries to google's public DNS servers? you're most likely running unbound in the default debian config which enables DNSSEC validation. if you comment out the auto-trust-anchor-file line in /etc/unbound/unbound.conf and restart unbound, does it start working with your dnsmasq server? if so, this would indicate that dnsmasq is broken. you can see in the trace that unbound is (repeatedly) attempting to find the DS record for com, and dnsmasq is responding with NXDOMAIN: [179] [2011-06-15 18:16:08.802882000] [1:9 ISC dnsqr] [] [] [] type: UDP_QUERY_RESPONSE query_ip: 192.168.47.197 response_ip: 192.168.47.254 proto: UDP (17) query_port: 20873 response_port: 53 id: 64244 qname: com. qclass: IN (1) qtype: DS (43) rcode: NXDOMAIN (3) delay: 0.002946 udp_checksum: CORRECT query: [32 octets] ;; -HEADER- opcode: QUERY, rcode: NOERROR, id: 64244 ;; flags: rd cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;com. IN DS ;; ANSWER SECTION: ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: --- response: [21 octets] ;; -HEADER- opcode: QUERY, rcode: NXDOMAIN, id: 64244 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;com. IN DS ;; ANSWER SECTION: ;; AUTHORITY SECTION: ;; ADDITIONAL SECTION: --- note that dnsmasq is responding with NXDOMAIN for com. this is hilariously wrong, as it means that dnsmasq claims that com does not exist. but apart from that, unbound is unable to find the DS record for com and thus DNSSEC validation fails. i suspect that if you configure your dnsmasq server to forward to a server that supports DNSSEC (e.g., level3's 4.2.2.2) that your unbound forwarder may work, otherwise there are more bugs in dnsmasq. -- Robert Edmonds edmo...@debian.org signature.asc Description: Digital signature
Bug#616150: Workaround found
Hi Micha, Micha Lenk mi...@debian.org schrieb am 13.06.2011 um 20:52: thank you for investigating all this. This is very helpful and very much appreciated. Unfortunately I can't reproduce the described problems with the instructions you and Stefan gave with the current version from Debian unstable (1:2.4.6-2). Can you please try again to crash Gnucash with a more recent version and report back whether the bug simply was fixed upstream by a newer version already? At the moment I have version 1:2.4.6-3 installed and the crash is still there. I have this /tmp/gnucash.trace: * 21:18:12 WARN Gnome Accessibility: failed to find module 'libgail-gnome' which is needed to make this application accessible * 21:18:12 WARN atk-bridge AT_SPI_REGISTRY was not started at session startup. * 21:18:12 WARN atk-bridge IOR not set. * 21:18:12 WARN atk-bridge Could not locate registry * 21:18:13 WARN gnc.backend.dbi [gnc_module_init_backend_dbi()] No DBD drivers found * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 WARN Pango Invalid UTF-8 string passed to pango_layout_set_text() * 21:18:31 CRIT GLib g_utf8_casefold: assertion `str != NULL' failed Feel free to ask if I can assist in anything. Thanks for your efforts Stefan signature.asc Description: Digital signature
Bug#623560: Problem in finding OCC
OCC is not found during configuration process: checking whether OCC libs are available... no configure: WARNING: Cannot find OpenCASCADE devel files. Modules that depend on this library cannot be built. And then compilation fails, because empty -I parameter is added to g++ command: g++ -DHAVE_CONFIG_H -I. -I../../.. -I -I././inc/ -D_OCC64 -g -D_DEBUG -D_REENTRANT -Wall -Wno-sign-compare -Wno-switch -Wno-reorder -Wno-unused -Wno-parentheses -Wno-comment -Wall -g -O2 -Wno-deprecated -frtti -c -o Driver_Document.lo `test -f '././src/Driver/Driver_Document.cpp' || echo './'`././src/Driver/Driver_Document.cpp libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I -I././inc/ -D_OCC64 -g -D_DEBUG -D_REENTRANT -Wall -Wno-sign-compare -Wno-switch -Wno-reorder -Wno-unused -Wno-parentheses -Wno-comment -Wall -g -O2 -Wno-deprecated -frtti -c ././src/Driver/Driver_Document.cpp -fPIC -DPIC -o .libs/Driver_Document.o ././src/Driver/Driver_Document.cpp:22:29: fatal error: Driver_Document.h: No such file or directory Now we have: -I. -I../../.. -I -I././inc/ -D_OCC64 -g -D_DEBUG But it should be: -I. -I../../.. -I/usr/include/opencascade -I././inc/ -D_OCC64 -g -D_DEBUG Has anybody an idea, how to fix it? Patch ./configure file? Thanks [1] https://buildd.debian.org/status/fetch.php?pkg=freecadarch=kfreebsd-amd64ver=0.11.4446-dfsg-1stamp=1307997225 Anton -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630627: Fixed patch
Just a minor glitch in my patch... See attached.
--
Luboš Doležel
--- live-0.2.0/setup.cpp.orig 2008-04-23 01:01:53.0 +0200
+++ live-0.2.0/setup.cpp 2011-06-15 20:22:36.577961061 +0200
@@ -151,13 +151,28 @@
bool Setup::CheckServerIps()
{
+ bool v6supported = false;
+ int s = socket(AF_INET6, SOCK_STREAM, 0);
+
+ if (s != -1) {
+ close(s);
+ v6supported = true;
+ }
+
if ( m_serverIps.empty() ) {
- m_serverIps.push_back( 0.0.0.0 );
+ if (v6supported)
+ m_serverIps.push_back( :: );
+ else
+ m_serverIps.push_back( 0.0.0.0 );
return true;
}
+union {
+ in_addr in4;
+ in6_addr in6;
+ };
for ( IpList::const_iterator ip = m_serverIps.begin(); ip != m_serverIps.end(); ++ip ) {
- if ( inet_addr( ip-c_str() ) == static_cast in_addr_t ( -1 ) ) {
+ if ( !inet_pton(AF_INET, ip-c_str(), in4) !inet_pton(AF_INET6, ip-c_str(), in6) ) {
esyslog( ERROR: live server ip %s is not a valid ip address, ip-c_str() );
cerr ERROR: live server ip *ip is not a valid ip address endl;
return false;
Bug#630636: mockito ftbfs (missing b-d on default-jdk)
Package: mockito Version: 1.8.5+ds1-2 Severity: serious the package b-d's on openjdk-6-jdk, but uses the JAVA_HOME for default-jdk. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616318: Depends not Build-Depends
found 616318 1.34 thank you Hi, Thanks for looking into this issue. I think Martin was raising the issue of Depends not Build-Depends which has been changed with this upload. It seems the Depends on dpkg(-dev) is not required at all. Thanks. Kind Regards, Dave Walker -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
On Wed, Jun 15, 2011 at 21:16, Robert Edmonds edmo...@debian.org wrote: you're most likely running unbound in the default debian config which enables DNSSEC validation. if you comment out the auto-trust-anchor-file line in /etc/unbound/unbound.conf and restart unbound, does it start working with your dnsmasq server? Yes. For the record, with validation enabled: No forwarding: works Forwarding to 8.8.8.8: fails Forwarding to 4.2.2.1: works Forwarding to dnsmasq which forwards to 8.8.8.8: fails Forwarding to dnsmasq which forwards to 4.2.2.1: fails So, breakage at dnsmasq and 8.8.8.8, I think, the latter officially being a known issue. you can see in the trace that unbound is (repeatedly) attempting to find the DS record for com, and dnsmasq is responding with NXDOMAIN: Yes. Google DNS fails differently, by the way: no record, NOERROR, authority section for google.com. note that dnsmasq is responding with NXDOMAIN for com. this is hilariously wrong, as it means that dnsmasq claims that com does not exist. but apart from that, unbound is unable to find the DS record for com and thus DNSSEC validation fails. Yes. The problem with DS is, of course, that it is an authoritative member of the parent zone only, so you have to ask the com. nameservers for the DS record of google.com., not the google.com. nameservers. Recursors have to just know that, it isn't covered by basic forwards compatibility like any other new record type. Google's DNS apparently doesn't, and dnsmasq is even more broken. (I'm trying to point out that you may assume I have a detailed understanding of DNS and DNSsec for the purposes of this discussion, without being a dick about it. I don't think it's working.) i suspect that if you configure your dnsmasq server to forward to a server that supports DNSSEC (e.g., level3's 4.2.2.2) that your unbound forwarder may work, otherwise there are more bugs in dnsmasq. See above; doesn't fix it, as far as I can tell. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628357: tct: possible patch to solve FTBFS
tags 628357 + patch
thanks
Dear maintainer,
The problems seems to be parsing the ouptut of perl -v when a binary
for perl 5 is found. Changing the invocation to awk as in attached
patch would fix.
Note I have attached patch as nmu-diff, but I have not taken yet any
further actions. I too converted for my test the package to '3.0
(quilt)'.
The relevant part is only:
+--- a/reconfig
b/reconfig
+@@ -59,7 +59,7 @@
+ while ($dir/perl5* $dir/perl*) {
+ if (-x $_) {
+ $perl_version=`($_ -v 2 /dev/null) |
+- awk '/This is perl, v.*5/ { print $NF }'`;
++ awk '/This is perl 5, version/ { print $NF }'`;
+ if ($perl_version) {
+ $PERL=$_;
+ $pflag=1;
Furthermore I refreshed the 01-conglomeration.patch patch.
Regards.
Salvatore
diff -Nru tct-1.19/debian/changelog tct-1.19/debian/changelog
--- tct-1.19/debian/changelog 2011-06-15 21:31:04.0 +0200
+++ tct-1.19/debian/changelog 2011-06-15 21:30:01.0 +0200
@@ -1,3 +1,14 @@
+tct (1.19-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Refresh offsets for 01-conglomeration.patch.
+ * Add 03-check-for-perl5-fix.patch to adapt check for perl 5
+(Closes: #628357).
+ * Covert to '3.0 (quilt)' source package format and drop quilt framework
+from debian/control and debian/rules.
+
+ -- Salvatore Bonaccorso car...@debian.org Wed, 15 Jun 2011 21:29:36 +0200
+
tct (1.19-1) unstable; urgency=low
* Merging upstream version 1.19
diff -Nru tct-1.19/debian/control tct-1.19/debian/control
--- tct-1.19/debian/control 2011-06-15 21:31:04.0 +0200
+++ tct-1.19/debian/control 2011-06-15 21:29:06.0 +0200
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Debian Forensics forensics-de...@lists.alioth.debian.org
Uploaders: Christophe Monniez christophe.monn...@fccu.be
-Build-Depends: debhelper (= 7.0.50~), quilt, e2fslibs-dev
+Build-Depends: debhelper (= 7.0.50~), e2fslibs-dev
Standards-Version: 3.8.3
Homepage: http://www.porcupine.org/forensics/tct.html
Vcs-Browser: http://git.debian.org/?p=forensics/tct.git
diff -Nru tct-1.19/debian/patches/01-conglomeration.patch tct-1.19/debian/patches/01-conglomeration.patch
--- tct-1.19/debian/patches/01-conglomeration.patch 2011-06-15 21:31:04.0 +0200
+++ tct-1.19/debian/patches/01-conglomeration.patch 2011-06-15 21:23:22.0 +0200
@@ -1,16 +1,15 @@
Author: n/a
Description: Needs to be broken out (FIXME).
-diff -Naurp tct.orig/bin/grave-robber tct/bin/grave-robber
tct.orig/bin/grave-robber 2007-01-21 22:18:00.0 +
-+++ tct/bin/grave-robber 2008-11-28 07:58:27.0 +
+--- a/bin/grave-robber
b/bin/grave-robber
@@ -1,4 +1,4 @@
-#!/usr/bin/perl5
+#!/usr/bin/perl
#
# Usage: $0 [-filmnpstvDEFIMOPVS] [-b body_file] [-c corpse_dir]
-@@ -118,7 +118,7 @@ else {
+@@ -118,7 +118,7 @@
$TCT_HOME = ;
}
@@ -19,7 +18,7 @@
#
# get user input on what the program should do...
-@@ -415,10 +415,10 @@ print going into grave_robber_init()\n
+@@ -415,10 +415,10 @@
#
log_init_path($logfile);
@@ -34,9 +33,8 @@
if (!$TCT_HOME) {
die Can't find TCT_HOME - did you run reconfig?\n;
-diff -Naurp tct.orig/bin/mactime tct/bin/mactime
tct.orig/bin/mactime 2007-01-21 22:18:00.0 +
-+++ tct/bin/mactime 2008-11-28 07:58:27.0 +
+--- a/bin/mactime
b/bin/mactime
@@ -1,5 +1,5 @@
-#!/usr/bin/perl5
-#
@@ -54,18 +52,16 @@
}
require body_init.pl;
-diff -Naurp tct.orig/bin/strip_tct_home tct/bin/strip_tct_home
tct.orig/bin/strip_tct_home 2007-01-21 22:18:00.0 +
-+++ tct/bin/strip_tct_home 2008-11-28 07:58:27.0 +
+--- a/bin/strip_tct_home
b/bin/strip_tct_home
@@ -1,4 +1,4 @@
-#!/usr/bin/perl5
+#!/usr/bin/perl
#
# NOTE!!!
#
-diff -Naurp tct.orig/conf/coroner.cf tct/conf/coroner.cf
tct.orig/conf/coroner.cf 2007-01-21 22:18:00.0 +
-+++ tct/conf/coroner.cf 2008-11-28 07:58:27.0 +
+--- a/conf/coroner.cf
b/conf/coroner.cf
@@ -4,9 +4,9 @@
$TCT_HOME = ;
@@ -78,10 +74,9 @@
#
# Where all the full pathnames to the various shell binaries used live
-diff -Naurp tct.orig/conf/grave-robber.cf tct/conf/grave-robber.cf
tct.orig/conf/grave-robber.cf 2007-01-21 22:18:00.0 +
-+++ tct/conf/grave-robber.cf 2008-11-28 07:58:27.0 +
-@@ -9,7 +9,7 @@ $BIN= $TCT_HOME/bin unless $BIN;
+--- a/conf/grave-robber.cf
b/conf/grave-robber.cf
+@@ -9,7 +9,7 @@
$ETC= $TCT_HOME/etc unless $ETC;
$CONFIG = $TCT_HOME/conf unless $CONFIG;
@@ -90,7 +85,7 @@
#
# Where all the full pathnames to the various shell
Bug#630552: linux-image-2.6.32-5-amd64: K8 ECC error
Hi Ben, On 06/15/2011 09:13 PM, Ben Hutchings wrote: On Wed, 2011-06-15 at 07:50 +0200, Dario Minnucci wrote: Hi again, I've found a reference to this error [0] providing and a possible patch is provided. Regards, [0] https://patchwork.kernel.org/patch/67658/ I've reopened the bug and will check how it got fixed in mainline Linux (not sure whether that patch was applied or not). Ben. I've got me RAM replaced a while ago and no sign og the flloding yet, so I guess no further testing will be posible on my side. :( Thanks for your interest anyway. Regards, -- Dario Minnucci mid...@debian.org Phone: +34 902884117 | Fax: +34 902024417 | Support: (+34) 80745 Key fingerprint = BAA1 7AAF B21D 6567 D457 D67D A82F BB83 F3D5 7033 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#616150: Workaround found
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Stefan, thank you for the confirmation, that the issue is still present in gnucash 1:2.4.6-3. You wrote: Feel free to ask if I can assist in anything. Can you please send me the output of the command 'locale' on your system? Thanks in advance and regards, Micha -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk35DCAACgkQWN0/4pnhQbSCOgCfWBiHQkLIFEwA+gbhmrZACKa7 qZsAnRdMt66vsdgu5SfmfZcSj+ejhA76 =gr2n -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
clone 629290 -1 reassign -1 dnsmasq retitle -1 dnsmasq: not DNSSEC transparent severity -1 important thanks Maik Zumstrull wrote: On Wed, Jun 15, 2011 at 21:16, Robert Edmonds edmo...@debian.org wrote: you're most likely running unbound in the default debian config which enables DNSSEC validation. if you comment out the auto-trust-anchor-file line in /etc/unbound/unbound.conf and restart unbound, does it start working with your dnsmasq server? Yes. For the record, with validation enabled: No forwarding: works Forwarding to 8.8.8.8: fails Forwarding to 4.2.2.1: works Forwarding to dnsmasq which forwards to 8.8.8.8: fails Forwarding to dnsmasq which forwards to 4.2.2.1: fails So, breakage at dnsmasq and 8.8.8.8, I think, the latter officially being a known issue. so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630552: linux-image-2.6.32-5-amd64: K8 ECC error
On Wed, 2011-06-15 at 21:38 +0200, Dario Minnucci wrote: Hi Ben, On 06/15/2011 09:13 PM, Ben Hutchings wrote: On Wed, 2011-06-15 at 07:50 +0200, Dario Minnucci wrote: Hi again, I've found a reference to this error [0] providing and a possible patch is provided. Regards, [0] https://patchwork.kernel.org/patch/67658/ I've reopened the bug and will check how it got fixed in mainline Linux (not sure whether that patch was applied or not). Ben. I've got me RAM replaced a while ago and no sign og the flloding yet, so I guess no further testing will be posible on my side. :( So we don't know whether those were genuine ECC error reports...? Ben. -- Ben Hutchings Never put off till tomorrow what you can avoid all together. signature.asc Description: This is a digitally signed message part
Bug#630638: pidgin-sipe: FTBFS with pdigin 2.8.0-1 in unstable
Package: pidgin-sipe Version: 1.11.2-1 Severity: serious Tags: patch Justification: fails to build from source I was trying to rebuild pidgin-sipe against the latest pidgin in unstable and it failed with the following error : . mv -f .deps/libsipe_backend_la-purple-debug.Tpo .deps/libsipe_backend_la- purple-debug.Plo /bin/bash ../../libtool --tag=CC --mode=compile x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Werror -Wall -Wextra -Werror=declaration- after-statement -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpurple -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./../api -DLOCALEDIR=\/usr/share/locale\ -Wall -g -O2 -MT libsipe_backend_la-purple-dnsquery.lo -MD -MP -MF .deps/libsipe_backend_la- purple-dnsquery.Tpo -c -o libsipe_backend_la-purple-dnsquery.lo `test -f 'purple-dnsquery.c' || echo './'`purple-dnsquery.c libtool: compile: x86_64-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../.. -Werror -Wall -Wextra -Werror=declaration-after-statement -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libpurple -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I./../api -DLOCALEDIR=\/usr/share/locale\ -Wall -g -O2 -MT libsipe_backend_la-purple-dnsquery.lo -MD -MP -MF .deps /libsipe_backend_la-purple-dnsquery.Tpo -c purple-dnsquery.c -fPIC -DPIC -o ..libs/libsipe_backend_la-purple-dnsquery.o In file included from purple-dnsquery.c:25:0: /usr/include/libpurple/dnssrv.h:115:51: error: unknown type name 'PurpleAccount' In file included from purple-dnsquery.c:25:0: /usr/include/libpurple/dnssrv.h:150:51: error: unknown type name 'PurpleAccount' purple-dnsquery.c: In function 'sipe_backend_dns_query': purple-dnsquery.c:60:28: error: assignment from incompatible pointer type [-Werror] cc1: all warnings being treated as errors make[4]: *** [libsipe_backend_la-purple-dnsquery.lo] Error 1 make[4]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2/src/purple' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/iamer/tmp/pidgin-sipe-1.11.2' make: *** [build-stamp] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 Using a patch from archlinux I found at http://aur.archlinux.org/packages.php?ID=16170comments=alldetail=0 it was able to build -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (200, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/4 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 pidgin-sipe depends on: ii libc62.13-7 Embedded GNU C Library: Shared lib ii libcomerr2 1.41.12-4 common error description library ii libglib2.0-0 2.28.6-2GLib library of C routines ii libgmime-2.4-2 2.4.25-1MIME message parser and creator li ii libgssapi-krb5-2 1.9.1+dfsg-1+b1 MIT Kerberos runtime libraries - k ii libk5crypto3 1.9.1+dfsg-1+b1 MIT Kerberos runtime libraries - C ii libkrb5-31.9.1+dfsg-1+b1 MIT Kerberos runtime libraries ii libnspr4-0d 4.8.8-1 NetScape Portable Runtime Library ii libnss3-1d 3.12.10-1 Network Security Service libraries ii libpurple0 2.8.0-1 multi-protocol instant messaging l ii libxml2 2.7.8.dfsg-3GNOME XML library pidgin-sipe recommends no packages. pidgin-sipe suggests no packages. -- no debconf information diff -drupN pidgin-sipe-1.11.2/src/purple/purple-dnsquery.c pidgin-sipe-1.11.2-new/src/purple/purple-dnsquery.c --- pidgin-sipe-1.11.2/src/purple/purple-dnsquery.c 2010-11-03 05:13:51.0 +0100 +++ pidgin-sipe-1.11.2-new/src/purple/purple-dnsquery.c 2011-06-11 00:14:57.0 +0200 @@ -22,6 +22,10 @@ #include glib.h +#include version.h +#if PURPLE_VERSION_CHECK(2,8,0) +#include account.h +#endif #include dnssrv.h #include sipe-backend.h diff -drupN pidgin-sipe-1.11.2/src/purple/purple-plugin.c pidgin-sipe-1.11.2-new/src/purple/purple-plugin.c --- pidgin-sipe-1.11.2/src/purple/purple-plugin.c 2010-11-03 05:13:51.0 +0100 +++ pidgin-sipe-1.11.2-new/src/purple/purple-plugin.c 2011-06-10 23:58:20.0 +0200 @@ -506,6 +506,10 @@ static PurplePluginProtocolInfo prpl_inf NULL, /* get_moods */ NULL, /* set_public_alias */ NULL, /* get_public_alias */ +#if PURPLE_VERSION_CHECK(2,8,0) + NULL, /* add_buddy_with_invite */ + NULL, /* add_buddies_with_invite */ +#endif #endif #endif #endif diff -drupN pidgin-sipe-1.11.2/src/purple/purple-private.h pidgin-sipe-1.11.2-new/src/purple/purple-private.h ---
Bug#619272: [Pkg-oss4-maintainers] Bug#619272: oss4-dkms: Current kernel in archive is 2.6.39 which is still not supported.
This is fixed in 4.2-build2004-1 which was uploaded yesterday. Romain 2011/6/14 Michal Suchanek hramr...@centrum.cz: Package: oss4-dkms Version: 4.2-build2003-1.1 Followup-For: Bug #619272 oss4-dkms sitll does not build with curent kernel. Setting up oss4-base (4.2-build2003-1.1) ... Setting up oss4-dkms (4.2-build2003-1.1) ... Loading new oss4-4.2-build2003 DKMS files... First Installation: checking all kernels... Building only for 2.6.39-1-amd64 Building initial module for 2.6.39-1-amd64 Error! Bad return status for module build on kernel: 2.6.39-1-amd64 (x86_64) Consult the make.log in the build directory /var/lib/dkms/oss4/4.2-build2003/build/ for more information. dpkg: error processing oss4-dkms (--configure): subprocess installed post-installation script returned error exit status 10 cat /var/lib/dkms/oss4/4.2-build2003/build/make.log DKMS make.log for oss4-4.2-build2003 for kernel 2.6.39-1-amd64 (x86_64) make: Entering directory `/usr/src/linux-headers-2.6.39-1-amd64' CC [M] /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.o /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c: In function ‘alloc_fop’: /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:956: error: ‘struct file_operations’ has no member named ‘ioctl’ /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:960: warning: assignment from incompatible pointer type /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c: In function ‘oss_pci_read_devpath’: /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1634: warning: return discards qualifiers from pointer target type /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c: In function ‘oss_fp_check’: /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1858: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1860: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1860: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1860: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1862: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1867: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1867: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1867: warning: comparison of distinct pointer types lacks a cast /var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.c:1869: warning: comparison of distinct pointer types lacks a cast make[3]: *** [/var/lib/dkms/oss4/4.2-build2003/build/core/oss_core.o] Error 1 make[2]: *** [_module_/var/lib/dkms/oss4/4.2-build2003/build/core] Error 2 make[1]: *** [sub-make] Error 2 make: *** [all] Error 2 make: Leaving directory `/usr/src/linux-headers-2.6.39-1-amd64' -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable'), (395, 'experimental'), (300, 'stable-i386'), (300, 'oldstable'), (280, 'testing-i386'), (270, 'unstable-i386'), (150, 'experimental-i386'), (65, 'oldstable-i386') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages oss4-dkms depends on: ii 2.1.1.2-6 Dynamic Kernel Module Support Fram ii 2.6.39+35 Header files for Linux 2.6-amd64 ( ii 2.6.26-13lenny2 Header files for Linux 2.6.26-1-am ii 3.local Header files related to Linux kern ii 2.6.32-34squeeze1 Header files for Linux 2.6.32-5-am ii 2.6.32-30~bpo50+1 Header files for Linux 2.6.32-bpo. ii 2.6.34-1~experimenta Header files for Linux 2.6.34-1-am ii 2.6.34-rc4-amd64-10. Header files related to Linux kern ii 2.6.35-0-amd64-10.00 Header files related to Linux kern ii 2.6.36-r600fence-amd Header files related to Linux kern ii 2.6.36-rc4-r600fence Header files related to Linux kern ii 2.6.37-2 Header files for Linux 2.6.37-2-am ii 2.6.38-1 Header files for Linux 2.6.38-1-am ii 2.6.38-5 Header files for Linux 2.6.38-2-am ii 2.6.39-1+b1 Header files for Linux 2.6.39-1-am ii 4.2-build2003-1.1 Open Sound System - base package oss4-dkms
Bug#630639: [INTL:sv] Swedish strings for ntfs-3g debconf
package: ntfs-3g severity: wishlist tags: patch l10n Please consider to add this file to translation of debconf. -- brother http://sis.bthstuden.se sv.po Description: Binary data
Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant DNSSEC-conformant recursive nameserver here, not validating recursive nameserver. the level3 open recursives (4.2.2.X) don't perform validation. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630552: linux-image-2.6.32-5-amd64: K8 ECC error
Hi again Ben, I've got me RAM replaced a while ago and no sign og the flloding yet, so I guess no further testing will be posible on my side. :( So we don't know whether those were genuine ECC error reports...? These are the only references reported by dmesg now so, I guess (as you both suggested) was related to faulty RAM modules. [3.769065] EDAC MC: Ver: 2.1.0 May 18 2011 [3.781850] EDAC amd64_edac: Ver: 3.2.0 May 18 2011 [3.781932] EDAC amd64: ECC is enabled by BIOS. [3.781991] EDAC MC: Rev F or later detected [3.782061] EDAC MC0: Giving out device to 'amd64_edac' 'RevF': DEV :00:18.2 [3.782091] EDAC PCI0: Giving out device to module 'amd64_edac' controller 'EDAC PCI controller': DEV ':00:18.2' (POLLED) Feel free to review the patch under you consideration. Despite my new RAM, I'm open for testing if needed. Thanks again. Regards, -- Dario Minnucci mid...@debian.org Phone: +34 902884117 | Fax: +34 902024417 | Support: (+34) 80745 Key fingerprint = BAA1 7AAF B21D 6567 D457 D67D A82F BB83 F3D5 7033 signature.asc Description: OpenPGP digital signature
Bug#625922: Failures with ST2000DL003-9VT166
I upgraded my raid disks to 4 ST32000644NS (Seagate Constellation 2TB) and I haven't had an issue since. I have also moved the cheaper ST2000DL003-9VT166 disks to a Windows XP box (in a non raid environment) and haven't seen a problem in days now. There are plenty of references online now popping up saying that green disks are not designed or supported in a raid environment. Weather or not that's because of a physical issue, or a software issue, im not sure. Paul -- To unsubscribe, send mail to 625922-unsubscr...@bugs.debian.org. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630569: [php-maint] Bug#630569: php5-pgsql and postgresql-9.0 seem to collude never to close idle persistent connections
reassign 630569 postgresql-8.4, postgresql-9.0, php5-pgsql thanks On Wed, Jun 15, 2011 at 12:32:35PM +0200, Ondřej Surý wrote: My first question would be if you can repeat same behaviour under unstable (and/or wheezy). Before going forward to wheeze, I first tried to reproduce it on clean squeeze because this is affecting my production machines... Unfortunately, I'm seeing the same problem with PostgreSQL 8.4 which is in stable. :( As I mentioned earlier, this is what happens on a separate machine that has been largely upgraded to squeeze, but left with the lenny pgsql server: % dpkg -s libapache2-mod-php5 php5-pgsql postgresql-8.3 | grep Version Version: 5.3.3-7+squeeze1 Version: 5.3.3-7+squeeze1 Version: 8.3.14-0lenny1 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 7 7 7 7 7 7 7 7 7 7 7 7 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 7 7 7 7 7 7 7 7 7 7 7 7 So, the spooling works normally and no excess connections are being left behind. Whereas on a squeeze machine: % dpkg -s libapache2-mod-php5 php5-pgsql postgresql-8.4 | grep Version Version: 5.3.3-7+squeeze1 Version: 5.3.3-7+squeeze1 Version: 8.4.7-0squeeze2 % sudo apache2ctl graceful % ps -C postgres | tail -n +2 | wc -l 5 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 6 7 8 9 10 11 12 13 14 15 16 17 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 18 19 20 21 22 23 24 24 24 24 24 24 % for i in $(seq 1 12); do wget -q -O /dev/null website-using-local-pgsql; ps -C postgres | tail -n +2 | wc -l; done 24 24 24 24 24 24 24 24 24 25 25 25 After that it levels off. And, just to confirm: % sudo -u postgres psql template1 -c 'select datname,usename,current_query from pg_stat_activity;' | sort | uniq -c | sort -n 1 1 datname | usename |current_query 1 template1 | postgres | select datname,usename,current_query from pg_stat_activity; 1 (21 rows) 1 +--+- 20 db1| web | IDLE -- 2. That which causes joy or happiness. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629371: usb-modeswitch: Devices no longer detected when plugged in at boot-time
Am 07.06.2011 01:45, schrieb Christian Kastner: I rebuilt the package with (eventually) all patches dropped, unfortunately to no avail: /dev/ttyUSB[0-2] and /dev/gsmmodem are still not present at boot, and there is no log file in /var/log/ with EnableLogging=1. The main inconvenience is the problem that it's hard to get any log if you plug before booting. The file system is mounted read-only first, so switching may succeed but there is no logging at all. Are you sure the switching itself is not happening? Did you check the device ID after booting with the stick? Josua Dietze -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant DNSSEC-conformant recursive nameserver here, not validating recursive nameserver. the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for .com hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#506992: libvtk5-dev: linking against VTK using cmake broken because of multiarch
forcemerge 506992 630559 severity 506992 serious usertags 506992 multiarch tags 506992 sid wheezy thanks Hi there, Bug #630559 is effectively a duplicate of the much-earlier-filed 506992. It is also effectively a release-critical bug, because these hard-coded paths to dependent libraries that have moved as a result of multiarch will now cause any reverse-dependency of vtk to fail to build in unstable. It is /possible/ to solve this by having vtk rebuilt against the libraries in their new paths; however, that's not a very permanent solution, as each of the dependent libs will be moved to multiarch paths one by one over time, which makes for a lot of unnecessary rebuilds of vtk. To avoid this bug from popping back open again, I recommend enacting the complete fix of not exporting dependent library information via cmake when linking. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ slanga...@ubuntu.com vor...@debian.org signature.asc Description: Digital signature
Bug#630325: [ovs-dev] Bug#630325: Bug#630325: openvswitch: FTBFS on big-endian architectures
On Tue, Jun 14, 2011 at 10:05:35PM -0700, Ben Pfaff wrote:
On Wed, Jun 15, 2011 at 02:04:39PM +0900, Simon Horman wrote:
On Tue, Jun 14, 2011 at 07:56:52PM -0700, Ben Pfaff wrote:
On Wed, Jun 15, 2011 at 10:51:24AM +0900, Simon Horman wrote:
Unfortunately I'm not familiar enough with the output to determine
the problem without digging much further. Perhaps you have some ideas.
The detailed output from sparc is below.
I believe that the output is similar if not the same
on the other three architectures.
Yes, I looked at this today. I'll send out a fix for it tomorrow.
It's a bug in the testsuite, I think, not in OVS itself.
Understood.
Could you CC me or this bug on the fix? Then I can push it into
an upload to Debian.Org and the buildds can verify the change.
Of course. Will do.
Simon, looking closer, this was fixed on branch-1.1 by the following
commit, made on April 18. (The fix is to sort the output of
dump-flows.) This fix is already in OVS 1.1.1. This bug is reported
against OVS 1.1.0, so it should be obsoleted by the OVS version
currently in Debian. Indeed, when I look at the current buildd status
at https://buildd.debian.org/status/package.php?p=openvswitchsuite=sid
I don't see any relevant failures.
I think we can close this.
Thanks,
Ben.
--8--cut here--8--
From: Ben Pfaff b...@nicira.com
Date: Mon, 18 Apr 2011 10:11:43 -0700
Subject: [PATCH] ofp-util: Properly handle tun_ids in tun_id_from_cookie
flows.
Just setting the tun_id field isn't enough--it's also necessary to set
the tun_id_mask. Otherwise the call to cls_rule_zero_wildcarded_fields()
at the end of ofputil_cls_rule_from_match() will zero out the tun_id again.
This was broken by commit 8368c090cab Implement arbitrary bitwise masks
for tun_id field back in January. (This makes me wonder whether we can
drop support for tun_id_from_cookie now.)
Reported-by: Dan Wendlandt d...@nicira.com
---
lib/ofp-util.c |2 +-
tests/ofproto.at |8 ++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/lib/ofp-util.c b/lib/ofp-util.c
index cc448bc..5c95270 100644
--- a/lib/ofp-util.c
+++ b/lib/ofp-util.c
@@ -136,7 +136,7 @@ ofputil_cls_rule_from_match(const struct ofp_match *match,
wc-nw_dst_mask = ofputil_wcbits_to_netmask(ofpfw OFPFW_NW_DST_SHIFT);
if (flow_format == NXFF_TUN_ID_FROM_COOKIE !(ofpfw NXFW_TUN_ID)) {
-rule-flow.tun_id = htonll(ntohll(cookie) 32);
+cls_rule_set_tun_id(rule, htonll(ntohll(cookie) 32));
}
if (ofpfw OFPFW_DL_DST) {
diff --git a/tests/ofproto.at b/tests/ofproto.at
index 9506756..fc7ff57 100644
--- a/tests/ofproto.at
+++ b/tests/ofproto.at
@@ -48,10 +48,14 @@ AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS], [0],
[NXST_FLOW reply:
])
AT_CHECK([echo 'in_port=1,actions=0' | ovs-ofctl add-flows br0 -])
AT_CHECK([ovs-ofctl add-flow br0 in_port=0,actions=1])
-AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS | STRIP_DURATION], [0], [dnl
-NXST_FLOW reply:
+dnl Tests for a bug in which ofproto ignored tun_id in tun_id_from_cookie
+dnl flow_mod commands.
+AT_CHECK([ovs-ofctl add-flow -F tun_id_from_cookie br0
tun_id=1,actions=mod_vlan_vid:4])
+AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS | STRIP_DURATION | sort], [0],
[dnl
cookie=0x0, duration=?s, table_id=0, n_packets=0, n_bytes=0, in_port=1
actions=output:0
cookie=0x0, duration=?s, table_id=0, n_packets=0, n_bytes=0, in_port=65534
actions=output:1
+ cookie=0x1, duration=?s, table_id=0, n_packets=0, n_bytes=0,
tun_id=0x1 actions=mod_vlan_vid:4
+NXST_FLOW reply:
])
AT_CHECK([ovs-ofctl del-flows br0])
AT_CHECK([ovs-ofctl dump-flows br0 | STRIP_XIDS], [0], [NXST_FLOW reply:
--
1.7.4.4
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628288: FTBFS: [javac] /build/user-lucene2_2.9.4+ds1-1-amd64-JNLFNr/lucene2-2.9.4+ds1/contrib/db/bdb/src/java/org/apache/lucene/store/db/DbDirectory.java:201: cannot find symbol
Package: lucene2 Severity: normal The correct patch was provided in #621398, I have also informed you to wait for libdb-java (= 5.1.4), so you get the correct version with 'db.jar'. Please apply the former patch and it will fix this error. And really please do Build-Depend just on libdb-java, so we don't have to open new bug for every Berkeley DB transition we do. Thanks, -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630604: LB_PARENT_ARCHIVE_AREAS default handling is wrong
tag 630604 pending
thanks
On 06/15/2011 04:18 PM, Colin Watson wrote:
--parent-archive-areas seems to be broken, because the default for
LB_PARENT_ARCHIVE_AREAS checks whether LB_ARCHIVE_AREAS is already set,
not whether LB_PARENT_ARCHIVE_AREAS is already set. Patch attached.
applied, thanks.
(Or is --parent-archive-areas deprecated? I notice that it isn't
documented. But then, why does the LB_MODE=progress case do
LB_PARENT_ARCHIVE_AREAS=${LB_PARENT_ARCHIVE_AREAS:-main}?)
the derivatives handling is rather experimental and only minimally
tested yet. even, there might be intrusive changes, so it's not yet
advertised and documented. that will come with the next couple of uploads.
--
Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern
Email: daniel.baum...@progress-technologies.net
Internet: http://people.progress-technologies.net/~daniel.baumann/
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619272: [Pkg-oss4-maintainers] Bug#619272: oss4-dkms: Current kernel in archive is 2.6.39 which is still not supported.
On 15 June 2011 21:51, Romain Beauxis to...@rastageeks.org wrote: This is fixed in 4.2-build2004-1 which was uploaded yesterday. Yes, tried installing the oss packages before the updated package was on my mirror. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630641: gem2deb: duplicate install of files in lib/
Package: gem2deb Version: 0.2.4 Severity: important Hi, for ruby-xmlparser (found in the pkg-ruby-extras repo, not uploaded yet because of that problem), gem2deb installs the files in lib/ to /usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/ and /usr/lib/ruby/vendor_ruby/1.8/x86_64-linux/. This might be related to the fact that extconf.rb is in the root dir. Lucas -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (800, 'stable'), (300, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gem2deb depends on: ii build-essential 11.5 Informational list of build-essent ii debhelper 8.1.3helper programs for debian/rules ii devscripts 2.10.72 scripts to make the life of a Debi ii perl5.10.1-20Larry Wall's Practical Extraction ii ruby1.8 1.8.7.334+svn31904-1 Interpreter of object-oriented scr ii ruby1.8-dev 1.8.7.334+svn31904-1 Header files for compiling extensi ii ruby1.9.1 1.9.2.180+svn31745-1 Interpreter of object-oriented scr ii ruby1.9.1-dev 1.9.2.180+svn31745-1 Header files for compiling extensi ii rubygems1.8 1.6.2-1 package management framework for R gem2deb recommends no packages. gem2deb 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#608808: ITA: pacpl -- multi-purpose audio converter/ripper/tagger script
retitle 608808 ITA: pacpl -- multi-purpose audio converter/ripper/tagger script owner 608808 ! thanks Hi, I wish to maintain this package. I use it, and I want that it stay in Debian. Progress will follow. xakz. -- Maxime Chatelle, human from earth, 01000 | cm94IGxvdmVyCg==mchatelle ↯ linux-france ↯ org mmyc ↯ gmx ↯ com gpl-kpr gpg: 79E0 25F5 06C5 5C7F F57C BADD 13EE 911A 8A1A 9DE9 pgpuJtQVoCwfj.pgp Description: PGP signature
Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote: On Wed, Jun 15, 2011 at 05:56:59PM +0200, Petter Reinholdtsen wrote: [Michael Biebl] the default for new installations is to use RAMTMP=yes. Hm, do not remember doing this change. Anyone know when it happened? This was done as part of the /run work a couple of months back. This was done following the discussion about default size limits for the various tmpfses in use (/run, /run/lock, /run/shm, and /tmp) on the debian-devel list, and also on #debian-devel. At the time, the consensus appeared to be generally in favour of the change. I'll follow up to the other messages in this one mail. Discussion on -devel (all in the same thread): http://lists.debian.org/debian-devel/2011/04/msg00554.html http://lists.debian.org/debian-devel/2011/04/msg00615.html http://lists.debian.org/debian-devel/2011/04/msg00703.html Note that the dicussion at the time was not initially proposing to make it the default, merely a configurable option, but consenus appeared to change in favour of making it the default as well. I don't have any IRC logs from the time in question I'm afraid. It might have been mentioned in other threads as well. The FHS defines the persistence/lifetime for /tmp and /var/tmp. It does not make any recommendations about size. /tmp contents are not guaranteed to be preserved across reboots /var/tmp contents are preserved across reboots (but may still be cleaned after a certain time duration). Historical practice is that /tmp is small, and /var/tmp is rather larger. When using Sun/Solaris systems back around 2000, /tmp was always a tmpfs (it's the default), and /var/tmp was disc. Solaris tmpfs didn't have size limits (filling it would hang the system--I remember an undergrad being told off for trying to download a RedHat ISO image to /tmp and killing the system). On these systems files in /tmp were cleaned hourly, and files in /var/tmp weekly. Files needing longer-term storage went in /var/preserve (cleaned every few months) or on other storage. There are three possibilities for /tmp: - as a subdirectory of the root filesystem - as a separately mounted filesystem - as a tmpfs All three have pros and cons. 1) Subdirectory of the root filesystem This can be a very large filesystem if you install using just one large filesystem, or with /home separate. But it's not guaranteed. Example: rootfs contains only / and /usr: % df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/ravenclaw-root 9611492 8364556758696 92% / % df / Filesystem 1K-blocks Used Available Use% Mounted on /dev/mapper/hufflepuff-root 19223252 7026936 11219832 39% / Allowing for the 5% reserved blocks, the first doesn't have much free space to accommodate /tmp at all. The second has many gigabytes free though (despite being a much smaller system). The point I'm trying to make here is that there are no guarantees at all about how much free space the root filesystem has to accomodate /tmp. And changes in usage post-install may greatly reduce its capacity. 2) Separately mounted filesystem This needs manual setup: a filesystem needs making, and this needs mounting in /etc/fstab. Its size is exactly as large as the admin chooses. 3) As a tmpfs The default size is 20% of the core memory. This may vary significantly depending upon the amount of memory installed in the system: % mount | grep /tmp tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=1639592k) % df /tmp Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 163959260 1639532 1% /tmp % mount | grep /tmp tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime,size=206248k) % df /tmp Filesystem 1K-blocks Used Available Use% Mounted on tmpfs 206248 0206248 0% /tmp This is using the same two examples as above. The systems have 8 GiB and 1 GiB core memory, respectively. Customisation: just add an fstab entry like this: tmpfs /tmp tmpfs nosuid,nodev,size=8g,mode=1777 0 0 (note, this is all documented) This requires that you have the memory and/or swap to back the size specified. The bug: The RAMTMP feature as implemented is working exactly as designed. It is not buggy in itself. The question is whether it should be the default or not. Expectations: What is the minimum size that an application should expect /tmp to be, and how much of that space should an application expect to be available to satisfy its needs? Tricky question. The simple fact of the matter is, however, we don't make /any/ guarantees regarding minimum size and available space. Depending upon the partitioning scheme used, and the free space on the partition containing /tmp, there may be GiB of free space, or little or no space at all. Other applications and users may use all the space leaving nothing for you.
Bug#630642: oss4-base: Does not include upstream utilities soundon/soundoff
Package: oss4-base Version: 4.2-build2004-1 Severity: normal Upstream provides soundon and soundoff utilities that unload and reload the OSS modules enabling system suspend and resume. The debian OSS packages do not include these, and the README.Debian does not mention what replaces them. -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable'), (395, 'experimental'), (300, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages oss4-base depends on: ii libc6 2.13-4Embedded GNU C Library: Shared lib ii linux-sound-base 1.0.23+dfsg-4 base package for ALSA and OSS soun Versions of packages oss4-base recommends: pn pm-utils none (no description available) Versions of packages oss4-base suggests: ii oss4-dkms [oss4-modules] 4.2-build2004-1 Open Sound System - DKMS module so -- 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#627179: multistrap: Using retainsources=dir does not retain some sources
On Wed, 15 Jun 2011 17:49:50 +0200 David Kuehling dvdkh...@gmx.de wrote: Neil Williams codeh...@debian.org writes: On Wed, 18 May 2011 15:09:44 +0200 David Kuehling dvdkh...@gmx.de wrote: Think about this more carefully. The situation is that multistrap is stateless and something can have happened which means that the run when the packages are actually downloaded failed at a later stage (e.g. in the hooks or setupscript) and then got fixed. So a later run of multistrap still needs to go through the status file (because the .debs have been unpacked and deleted) to check if some source packages still need to be downloaded. apt-get install will check the status file and report that it the packages are already at the newest version, without downloading anything, so the list has to come from somewhere else. i.e. the list of downloaded debs is untrustworthy and must be regarded as incomplete. Ok, if this is the case, then why do we have to collect source packages (dsclist) at 3 places in multistrap.conf . Won't it be sufficient to just do it once, when parsing the status file? Error handling is the main reason. Unpacking might fail, the archives might be the only source of data. Could you have a look at the current SVN revision and let me know how that matches your tests? The patch also fixes another bug, not yet reported: multistrap could have fetched source packages versions that differ from the binary package versions. That is more about differences in aptsources and debootstrap lines than anything to do with specifying the version. I don't think your patch actually works here. apt-get source will get the latest, just as apt-get install will get the latest. What changes is whether the call is made when aptsources are active or when bootstrap sources are active. It needs to be bootstrap sources. I'd need to have a real example of where apt-get install will download a different version to what apt-get source will download for the same sources - that would be a bug in apt, not multistrap. (Multistrap creates deb-src lines for each source specified, so the versions are expected to be the same from deb to deb-src or else there are problems with the archive.) That's exactly the problem: inconsistent versions in the archive or archive updates while multistrap runs. That sounds like a broken archive. I haven't implemented the versioned source call - I remain unconvinced that a valid archive would cause the download of a source package of a different version to the binary package. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpYd785Swt9j.pgp Description: PGP signature
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 14.06.2011 12:06, schrieb Didier Raboud: Thanks for your time and skills ! Just want to let you know that I'm on the job now and following this exchange. Originally, the packed config file was not intended for default use on desktop systems. It kind of amazed me to see this happening on today's resource-loaded devices. Well, now we have it and it makes sense to consider a mix of packed and unpacked configurations, particularly when adding new device data or changing existing entries. I don't like the folder splitting though; the unpacked/edited files should be close to the other configurations. Why not use the /usr/share/usb_modeswitch folder, alongside the package? I propose to drop the check for the old config folder (/etc/usb_modeswitch.d) in the upcoming wrapper version altogether. Also, I think we can agree that in the now possible case of duplicate configurations (one unpacked, one packed) the unpacked file should have the higher priority. What do you think? Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630424: Maybe a Problem with tip22
Hi, On Tue, Jun 14, 2011 at 02:22:17AM -0700, Edwin Kwan wrote: Hi, The screen shot in Attilio's bug report was done by me on my Indy. I am not experienced in this beginning of the universe kind of code. But I found the following clues which may be useful. I can reproduce the problem here now. A the same kernel+initrd that works with 0.3.12 doesn't with 0.3.13 (unlucky number it seems). I try come up with a patch during the next couple of days. BTW can I directlry fetch the initrd and kernel that was used to build: http://ftp.nl.debian.org/debian/dists/squeeze/main/installer-mips/current/images/r4k-ip22/netboot-boot.img I thought these used to be on the mirrors but can't seem to find them. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
On Wednesday 15 June 2011, Josua Dietze wrote: Why not use the /usr/share/usb_modeswitch folder, alongside the package? I propose to drop the check for the old config folder (/etc/usb_modeswitch.d) in the upcoming wrapper version altogether. Also, I think we can agree that in the now possible case of duplicate configurations (one unpacked, one packed) the unpacked file should have the higher priority. What do you think? IMHO I think the folder change is not a good idea. The /usr/share folder is supposed to be under package manager control, not user control. I think overriding packaged configurations do belong in /etc. The current package (with this bug fixed) fits my use case perfectly and I think it also fits the Debian way of configuring software. An override config file should have higher priority than shipped config ofcourse. Alex (not related to, nor speaking on behalf of, Debian; just long-term user). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#629936: oss4-base: works now
Package: oss4-base Followup-For: Bug #629936 This was fixed in build 2004. -- System Information: Debian Release: wheezy/sid APT prefers stable APT policy: (990, 'stable'), (500, 'testing'), (400, 'unstable'), (395, 'experimental'), (300, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages oss4-base depends on: ii libc6 2.13-4Embedded GNU C Library: Shared lib ii linux-sound-base 1.0.23+dfsg-4 base package for ALSA and OSS soun Versions of packages oss4-base recommends: pn pm-utils none (no description available) Versions of packages oss4-base suggests: ii oss4-dkms [oss4-modules] 4.2-build2004-1 Open Sound System - DKMS module so -- 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#630542: yui-compressor: mangles strings containing backslash
Hi Jakub, Le mercredi 15 juin 2011 01:22:12, Jakub Wilk a écrit : Package: yui-compressor Version: 2.4.6+debian1-1 Severity: grave $ cat tmp.js x = \\; $ yui-compressor tmp.js; echo x=\; Thanks for you feedback, I can confirm that this break badly with jQuery. It seems regression testsuite in yui-compressor is not sufficient to check this case. Can you provide me a working compressed-jQuery so I can compare and check there is no others regressions ? For now, you can just use previous release (2.4.6-1) from testing. (Severity grave, because this badly breaks jQuery, and possibly lots of other code.) ACK. Cheers, -- Damien signature.asc Description: This is a digitally signed message part.
Bug#630643: adduser: Cancelling with Ctrl+C still adds entries to /etc/{passwd,group}
Package: adduser Version: 3.112+nmu2 Severity: normal Cancelling adduser part way through the creation of a new user results in entries being written to /etc/passwd and /etc/group. This behaviour is a) not what is normally expected when using Ctrl+C to cancel a command, and b) results in a potentially unconfigured but still existant user and group on a system. The script should be modified to only write to passwd/group files *after* a user confirms with 'Y'. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/4 CPU cores) 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 adduser depends on: ii debconf [debconf-2.0 1.5.39 Debian configuration management sy ii passwd 1:4.1.4.2+svn3283-3 change and administer password and ii perl-base5.12.3-7+b1 minimal Perl system adduser recommends no packages. Versions of packages adduser suggests: ii liblocale-gettext-perl1.05-6+b1 Using libc functions for internati ii perl-modules 5.12.3-7 Core Perl modules -- debconf information: adduser/homedir-permission: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628357: tct: possible patch to solve FTBFS
Okay, I read some older bug reports on tct: BTW: The clean target of the tct Debian package is broken, the strange upstream mechanism (reconfig) conflicts with debian/rules and debian/patches/01-conglomeration.patch. IMO we should sort this out... in http://bugs.debian.org/532342 So maybe before uploading a fix for #628357 this should probably be cleaned up to? Regards Salvatore signature.asc Description: Digital signature
Bug#629956: apt: apt-cache fails with current fakeroot
Hi, Clint Adams wrote: On Wed, Jun 15, 2011 at 02:41:01PM +0200, Martin Pitt wrote: I tracked this down to apt-cache now failing to work under fakeroot: $ fakeroot apt-cache policy coreutils E: Could not open file /var/cache/apt/pkgcache.bin - open (13: Permission denied) E: Failed to truncate file - ftruncate (9: Bad file descriptor) E: The package lists or status file could not be parsed or opened. [...] It's a bit hard to say whether this is a bug in apt, or whether fakeroot shouldn't claim that access() works when it doesn't. Clint seems to have anticipated that in [2] already. Yikes, thanks for a heads up. One approach would be to say that running a typical test suite is not something fakeroot can fully support, and the behavior of fakeroot should be tuned for whatever is done outside the testsuite. Unfortunately, both of the motivating examples were testsuites, so that doesn't really give an answer. access() seems to be used in build processes in two ways: - on one hand, it can be used as the git test suite uses it, to tell if a process has too much permission to test permissions problems (i.e., in order to say this environment is too crazy --- let's _skip_ some tests); - on the other hand, it can be used as in Martin's example test suite, to opportunistically say If I have permission to make something --- e.g., a cache --- in the system a little better, let me actually do that. In an ideal world, the latter is a bug. Permissions can change between time of check and time of use, so if the operation requiring permission is not essential then later access errors should induce warnings, not errors. But we live in the real world. Maybe it would be best to revert the change in sid and introduce it in experimental, to get a better sense of whether the weight of the impact goes one way or another. Anyway, Clint, please feel free to revert the change. I'll think more. Regards, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#619067: gallery2: Cannot add photos to albums
On Sun, Mar 20, 2011 at 10:08:54PM +, Chris Carr wrote: Package: gallery2 Version: 2.3.1.dfsg-1 Severity: normal I haven't visited my gallery2 install for a year or so, but my ~5000 photos are still there and looking fine. Unfortunately, if I click on Add Items in any album, I get this: Error Detail - Error (ERROR_BAD_PATH) : Invalid path: modules/remote/ItemAddGalleryRemote.inc I have exactly the same situation here. It says in README.Debian: The Debian gallery2 package does not include the uploadapplet, slideshowapplet, remote, or panorama modules nor the DB2 storage support. This support can be re-enabled using the module downloader built into Gallery2. And the issue is that gallery2 is trying to use the remote module. So go to site admin, then select plugins from the left menu, Get More Plugins and install the remote plugin. Then it works! Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant DNSSEC-conformant recursive nameserver here, not validating recursive nameserver. the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for .com hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. from the man page: -D, --domain-needed Tells dnsmasq to never forward queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a not found answer is returned. um, i think i know what a plain name, without dots or domain parts is, but dnsmasq is a DNS server and deals with wire-format domain names, right? does dnsmasq seriously respond with NXDOMAIN to queries for the wire-format name \x03com\x00 (presentation format: com.) because it has only a single label? that is beyond broken. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630534: libpam-modules: could not identify user
On Wed, 2011-06-15 at 01:05 +0200, f...@fkoop.de wrote: I configured nsswitch.conf in the following way: passwd: compat ldap group: compat ldap shadow: compat ldap Is there a particular reason you use compat here? I would recommend using: files ldap unless you also use NIS. If I use the command getent passwd I get all of the passwd entries of the local system and additionally the information about the users stored on the ldap server. Any idea how I can further debug the situation? If you run getent shadow as root do you also get all users? Shadow information needs to be present for pam_unix to work currently. If you're using nslcd, could you provide the contents of /etc/nslcd.conf. Also, are you using nscd or unscd? Some users seem to have problems with that. Does getent passwd fkoop produce the output you expect? -- -- arthur - adej...@debian.org - http://people.debian.org/~adejong -- signature.asc Description: This is a digitally signed message part
Bug#630453: the tutorial's license don't pass the free island test
Hello David, thank you for your fast response! You probably have heard of the Debian guidelines about free software (DFSG), they try to define most clearly the frontier between free and non-free software. In real life, things are not either black or white: black and white are united by a continuous series of grey tones. The desert island test is one of the touchstones we use to decide whether something is free or non-free. Here is a simple version of this test: please imagine that you live in a desert island, and that you got the software X, possibly enclosed in a floating bottle. Then you examine the software, and the license says that you must communicate with its author to be authorized to use this software (for any usage which is possible in the case of free software: running it, reading its source, modifying it). If the license compells you to communicate with the author, it is no more DFSG-free. You license still contains one phrase which does not pass this test: If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer. The words it's requested are compelling. Hence this tutorial falls into the category of non-DFSG-free documents. Please consider some rewording, for example: s/it's requested that you/you are strongly encouraged to/ For how many people would the modified version of the licence change their behavior? I believe that there are plenty of people who do not take serously the licenses: those won't read your license, either in its compelling form or in its milder form. However which such a rewording, your license would definitely belong to the category of FDSG-free documents. Timo, Berndt, what is your mind about this? Best regards, Georges. Kicad a écrit : Hi, I have deleted the offending line from the current version of the document, which was updated this year. Does this resolve the issue? You can find copies of the modified document here: http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.pdf http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.odt Kind Regards, David On 15/06/2011 7:24 AM, Georges Khaznadar wrote: Hi, thank you for your fast reply Timo. Let us wait some time for David's response. Best regards,Georges. Timo Juhani Lindfors a écrit : Hi, Georges Khaznadargeorges.khazna...@free.fr writes: is it possible to have a single source package, giving two output packages in different sections like main and non-free? my idea is that it is not allowed, this is not possible indeed since non-free stuff is not ok in the source package either. so I should withdraw the conflicting file from kicad's source, to build a package kicad-X.XX+dfsg, and upload a package kicad-tutorial to the NEW queue. Sounds possible. I would rather see the license fixed though. I already started updating the tutorial with screenshots from a more recent kicad before I noticed the first page banner. -Timo -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70 signature.asc Description: Digital signature
Bug#627179: multistrap: Using retainsources=dir does not retain some sources
Neil == Neil Williams codeh...@debian.org writes: Error handling is the main reason. Unpacking might fail, the archives might be the only source of data. Could you have a look at the current SVN revision and let me know how that matches your tests? I'm going to have a look at it and test this stuff on friday. That's exactly the problem: inconsistent versions in the archive or archive updates while multistrap runs. That sounds like a broken archive. I haven't implemented the versioned source call - I remain unconvinced that a valid archive would cause the download of a source package of a different version to the binary package. Are you assuming a non-changing archive? As soon as the archive changes non-atomically (with locking applied by the client) I think we're doomed. As we're building images from debian sid, changes will be pretty common. I'm not sure how many times 'multistrap' performs 'apt-get update'. Even if it only does it once, the source and binary package indices are distinct files, and they are retrieved by distinct transaction from the ftp/http server, so I see no way that you can guarantee consistency during mirror pushes. The only atomicity you have is for updating a single index file via 'mv'. The following scenario: * mirror gets updated, probably first new files put into the pool, then the new indices follow, then even later, it's going to delete the files no longer referenced by the indices. * Concurrently I run 'multistrap' which runs 'apt-get update', fetching dists/sid/main/binary-amd64/Packages.bz2 and sid/main/source/Sources.bz2 . * Now I get Packages.bz2 from before the mirror update, and Sources.bz2 from after the mirror update. Sources.bz2 is going to have some packages updated to newer versions, and won't correspond 100% to binaries from Packages.bz2, thus violating the GPL Of course I guess the error rate will not be too high, at least not over a normal high-rate internet connection. cheers, David -- GnuPG public key: http://dvdkhlng.users.sourceforge.net/dk.gpg Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40 pgpjbDIxwAMg7.pgp Description: PGP signature
Bug#630608: [bash] Everything Segfaults After lib6 -7 Upgrade
reassign 630608 libc6 2.13-7 quit Hi David, David Baron wrote: After upgrading lib6 to current Sid (-7), everything, I mean everything segfaults. System will boot up very normally but as soon as I log in, the fun begins. There are numerous error messages from the bashrc or conf. Then, once again, everything segfaults. Big red switch time. Since everything in bootup ran normally, and only when I enter a sh do I get the problem, I am filing this on bash. Re-route if I am mistaken. Could you send some error messages, for example by taking a photograph of the screen? Also if you remember the order of events and when exactly the segfaults started, that would be very helpful. Thanks for reporting, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: Simon Kelley wrote: Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant DNSSEC-conformant recursive nameserver here, not validating recursive nameserver. the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for .com hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. from the man page: -D, --domain-needed Tells dnsmasq to never forward queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a not found answer is returned. um, i think i know what a plain name, without dots or domain parts is, but dnsmasq is a DNS server and deals with wire-format domain names, right? does dnsmasq seriously respond with NXDOMAIN to queries for the wire-format name \x03com\x00 (presentation format: com.) because it has only a single label? that is beyond broken. ok, now that i look in the dnsmasq debian changelog i see this option started defaulting to disabled in 2006. still... -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Le mercredi, 15 juin 2011 22.33:29, Josua Dietze a écrit : Am 14.06.2011 12:06, schrieb Didier Raboud: Thanks for your time and skills ! Just want to let you know that I'm on the job now and following this exchange. Hi Josua, nice to see you ring in ! Originally, the packed config file was not intended for default use on desktop systems. It kind of amazed me to see this happening on today's resource-loaded devices. Eh, disk space being cheap doesn't mean we can waste it for free. :-) Well, now we have it and it makes sense to consider a mix of packed and unpacked configurations, particularly when adding new device data or changing existing entries. I don't like the folder splitting though; the unpacked/edited files should be close to the other configurations. Why not use the /usr/share/usb_modeswitch folder, alongside the package? While I understand your feelings, unfortunately, the [FHS] forbids this: /usr/share is for read-only architecture-independent shared user data, while /etc is for host-specific system-wide configuration files. I think configuration files overrides fall in the second category. I propose to drop the check for the old config folder (/etc/usb_modeswitch.d) in the upcoming wrapper version altogether. No no no. :- Also, I think we can agree that in the now possible case of duplicate configurations (one unpacked, one packed) the unpacked file should have the higher priority. Sure; that sounds logical. What do you think? The most important thing IMHO is to limit the use of overrides to the minimum: working configurations should be merged to the tarball, to benefit the FLOSS community at large. Cheers, OdyX [FHS] http://en.wikipedia.org/wiki/Filesystem_Hierarchy_Standard -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: Simon Kelley wrote: Robert Edmonds wrote: Robert Edmonds wrote: so unbound forwarding to 4.2.2.1 works, but unbound forwarding to dnsmasq which forwards to 4.2.2.1 does not work. so dnsmasq is not fully transparent when forwarding between a validating forwarder and a validating recursive nameserver. ugh, i meant DNSSEC-conformant recursive nameserver here, not validating recursive nameserver. the level3 open recursives (4.2.2.X) don't perform validation. A quick query on the dnsmasq configuration in use here: is the --domain-needed flag set in /etc/dnsmasq.conf? I think that's causing the problem because the DS query for .com hits the filter. There are already exceptions on this filter for SOA and NS queries, the DNSSEC era requires that DS queries are added to that list. Assuming I've diagnosed this right, removing --domain-needed is a quick and simple workaround. from the man page: -D, --domain-needed Tells dnsmasq to never forward queries for plain names, without dots or domain parts, to upstream nameservers. If the name is not known from /etc/hosts or DHCP then a not found answer is returned. um, i think i know what a plain name, without dots or domain parts is, but dnsmasq is a DNS server and deals with wire-format domain names, right? does dnsmasq seriously respond with NXDOMAIN to queries for the wire-format name \x03com\x00 (presentation format: com.) because it has only a single label? that is beyond broken. Some implementations of gethostbyname, given the name com or mycomputer will attempt to look it up in the DNS with just such a query, thus wasting upstream bandwidth and leaking internal network information. It's sometimes useful to pre-empt that, so there's a configuration option. It's not the default behaviour. NXDOMAIN is wrong here, NODATA would be better, but historically dnsmasq was fielding queries from stub resolvers, so nobody every noticed the difference. Cheers, Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630081: Overriding via /etc/usb-modeswitch.d doesn't work
Am 15.06.2011 21:56, schrieb Alex Hermann: On Wednesday 15 June 2011, Josua Dietze wrote: Why not use the /usr/share/usb_modeswitch folder, alongside the package? IMHO I think the folder change is not a good idea. The /usr/share folder is supposed to be under package manager control, not user control. I think overriding packaged configurations do belong in /etc. The current package (with this bug fixed) fits my use case perfectly and I think it also fits the Debian way of configuring software. You may have a point there; I'm not familiar enough with the package conventions. OdyX has just confirmed that fact :-) An override config file should have higher priority than shipped config of course. O.K., so let's assume a user puts a changed/added config file into /etc/usb_modeswitch.d. It is preferred over the files in the package. One day there is a package update, and the new/changed configuration now comes included with the new package, probably improved over the manual file or with new parameters. What should happen then? The priority would have to be reversed ... Or the package install routine should notice the conflict and ask about a user decision. For a moment I thought about checking file mod time. But it's very error-prone too. It's getting a wee bit messy, I'm afraid. Josh -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Robert Edmonds wrote: ok, now that i look in the dnsmasq debian changelog i see this option started defaulting to disabled in 2006. still... Probably best not to look at filterwin2k then. Not the finest hour. Simon. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630644: valgrind: strspn needs suppression with recent glibc
Package: valgrind
Version: 1:3.6.1-5
Severity: minor
Tags: patch
I get false positives with a simple use of strspn:
$ cat foo.c 'EOF'
#include string.h
int main(void)
{
char buf[32];
strcpy(buf, foo);
if (strspn(buf, o))
return 0;
return 1;
}
EOF
$ gcc -g -o foo foo.c
$ valgrind ./foo
...
==5854== Conditional jump or move depends on uninitialised value(s)
==5854==at 0x4B3623E: __strspn_sse42 (strspn-c.c:142)
==5854==by 0x400509: main (foo.c:8)
...
Looks like it was reported elsewhere with a patch a few months ago:
https://bugs.kde.org/show_bug.cgi?id=270925
I tried the version of valgrind in experimental, but it shows the same
behavior.
-Peff
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.39-2-amd64 (SMP w/8 CPU cores)
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 valgrind depends on:
ii libc6 2.13-7 Embedded GNU C Library: Shared lib
ii libc6-dbg 2.13-7 Embedded GNU C Library: detached d
Versions of packages valgrind recommends:
ii gdb 7.2-1 The GNU Debugger
Versions of packages valgrind suggests:
pn alleyoop none (no description available)
pn kcachegrind none (no description available)
pn valkyrie none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630645: yabause does not run
Package: yabause Justification: renders package unusable Severity: grave *** Please type your report below this line *** After installing the package the frontent of the emulator starts. You can also edit the settings and give a valid bios, that runs perfect in the windows version. But when you try to start nothing happens. When you try to click on open iso you get the attached error message. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash attachment: Not-initialized.png
Bug#630615: [Pkg-sysvinit-devel] Bug#630615: RAMTMP should default to no
Hi Roger! Thanks for answering in such detail. I'll try to comment on a few points. Am 15.06.2011 22:46, schrieb Roger Leigh: On Wed, Jun 15, 2011 at 05:33:59PM +0100, Roger Leigh wrote: The FHS defines the persistence/lifetime for /tmp and /var/tmp. It does not make any recommendations about size. Yep, that's also how I read and understand the FHS. Historical practice is that /tmp is small, and /var/tmp is rather larger. When using Sun/Solaris systems back around 2000, /tmp was always a tmpfs (it's the default), and /var/tmp was disc. Solaris tmpfs didn't have size limits (filling it would hang the system--I remember an undergrad being told off for trying to download a RedHat ISO image to /tmp and killing the system). On these systems files in /tmp were cleaned hourly, and files in /var/tmp weekly. Files needing longer-term storage went in /var/preserve (cleaned every few months) or on other storage. As a fun fact, I made the opposite experience. At university (where $HOME was shared via NFS and had rather strict quotas) students where told to use /tmp for larger downloads. But then, this was not on a Solaris system. In the IRC discussion, it was mentioned that some DVD authoring applications were using /tmp to create/store 4GiB disc images. Also, backup software used /tmp to store multi-gigabyte backups during its operation. I would argue that any application expecting to be able to store such large files in /tmp has wholly unrealistic expectations. If I look at todays installers for Linux distros, like openSUSE, Redhat, Ubuntu or Debian, the default option creates a large /tmp, as it is a subdirectory of /. I don't know of any Linux distribution which uses tmpfs for /tmp. /tmp on a separate partition is an option which not all installers offer and needs to be chosen explicitly. So while we don't guarantee any minimum sizes for /tmp, applications expecting a large /tmp is not completely unrealistic. I acknowledge that my concern is more targetted at a typical desktop/laptop user, which certainly has different usage of software than a server installation. Initial setup: I would like to see the Debian installer support setup of /tmp to permit - disabling of /tmp on tmpfs - setting of a tmpfs size other than 20% core - allocation of sufficient backing store (swap) during partitioning If we wanted to guarantee a minimum tmpfs size here, we could ensure that there's sufficient swap to up the limit from 20% to something more, or an absolute value rather than a percentage. Having RAMTMP=no and letting d-i enable it if it finds a minimum amount of ram would be a good compromise imho. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#630534: libpam-modules: could not identify user
Am Mittwoch, den 15.06.2011, 23:19 +0200 schrieb Arthur de Jong: On Wed, 2011-06-15 at 01:05 +0200, f...@fkoop.de wrote: I configured nsswitch.conf in the following way: passwd: compat ldap group: compat ldap shadow: compat ldap Is there a particular reason you use compat here? I would recommend using: files ldap unless you also use NIS. I tried with both with the same results. Before I had the problems (starting about 2 days ago) I remembered that there was an entry called compat ldap, that's basically while I used it. But as I do not use NIS , I will change that to files ldap. If I use the command getent passwd I get all of the passwd entries of the local system and additionally the information about the users stored on the ldap server. Any idea how I can further debug the situation? If you run getent shadow as root do you also get all users? Shadow information needs to be present for pam_unix to work currently. No entries for shadow in ldap. Is that the reason why it stopped working? If so, is that documented somewhere? I wasn't aware that I need to add shadow information in ldap to be able to use my setup, which has worked for several months before. If you're using nslcd, could you provide the contents of /etc/nslcd.conf. Here it is: # /etc/nslcd.conf # nslcd configuration file. See nslcd.conf(5) # for details. # The user and group nslcd should run as. uid nslcd gid nslcd # The location at which the LDAP server(s) should be reachable. uri ldap://192.168.8.3/ # The search base that will be used for all queries. base dc=fkoop,dc=de # The LDAP protocol version to use. ldap_version 3 # The DN to bind with for normal lookups. #binddn cn=annonymous,dc=example,dc=net #bindpw secret # SSL options #ssl off #tls_reqcert never # The search scope. #scope sub Also, are you using nscd or unscd? Some users seem to have problems with that. Does getent passwd fkoop produce the output you expect? I am using nscd and yes, getent passwd fkoop produces the expected output. -- Mit freundlichen Grüßen Felix Koop -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630646: Selecting Hibernate for When the power button is pressed takes no effect
Package: gnome-shell Version: 3.0.2-1 Severity: normal 1. Click your name on the top bar and select System Settings. 2. Open Power. 3. Select Hibernate for When the power button is pressed. When one actually uses the power button, the dialogue doesn't contain a Hibernate option: Power Off The system will power off automatically in 60 seconds. Cancel | Restart | Power Off -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (990, 'stable'), (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.38-1-686 (SMP w/2 CPU cores) Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-shell depends on: ii dconf-gsettings-backend [gs 0.7.5-2 simple configuration storage syste ii gconf2 2.32.3-2 GNOME configuration database syste ii gir1.2-atk-1.0 2.0.0-1 The ATK accessibility toolkit (GOb ii gir1.2-clutter-1.0 1.6.14-1 GObject introspection data for the ii gir1.2-freedesktop 0.10.8-1 Introspection data for some FreeDe ii gir1.2-gconf-2.02.32.3-2 GNOME configuration database syste ii gir1.2-gdkpixbuf-2.02.23.3-3 GDK Pixbuf library - GObject-Intro ii gir1.2-gkbd-3.0 3.0.0.1-1GObject introspection data for the ii gir1.2-glib-2.0 0.10.8-1 Introspection data for GLib, GObje ii gir1.2-gnomebluetooth-1.0 3.0.0-1 Introspection data for GnomeBlueto ii gir1.2-gtk-3.0 3.0.10-1 GTK+ graphical user interface libr ii gir1.2-json-glib-1.00.13.2-1 GLib JSON manipulation library (in ii gir1.2-mutter-3.0 3.0.2.1-1GObject introspection data for Mut ii gir1.2-networkmanager-1.0 0.8.9997-1 GObject introspection data for Net ii gir1.2-pango-1.01.28.3-6 Layout and rendering of internatio ii gir1.2-polkit-1.0 0.101-4 GObject introspection data for Pol ii gir1.2-telepathyglib-0.12 0.15.1-1 GLib Telepathy connection manager ii gir1.2-telepathylogger-0.2 0.2.10-1 Telepathy logger service - introsp ii gir1.2-upowerglib-1.0 0.9.11-1 GObject introspection data for upo ii gjs 0.7.14-1 Mozilla-based javascript bindings ii gnome-bluetooth 3.0.0-1 GNOME Bluetooth tools ii gnome-icon-theme-symbolic 3.0.0-1 GNOME Desktop icon theme (symbolic ii gnome-settings-daemon 3.0.2-1 daemon handling the GNOME session ii gsettings-desktop-schemas 3.0.1-1 GSettings deskop-wide schemas ii libatk1.0-0 2.0.0-1 The ATK accessibility toolkit ii libc6 2.13-7 Embedded GNU C Library: Shared lib ii libcairo-gobject2 1.10.2-6 The Cairo 2D vector graphics libra ii libcairo2 1.10.2-6 The Cairo 2D vector graphics libra ii libcamel1.2-19 2.32.3-1 Evolution MIME message handling li ii libcanberra00.24-1 a simple abstract interface for pl ii libclutter-1.0-01.6.14-1 Open GL based interactive canvas l ii libcroco3 0.6.2-1 a generic Cascading Style Sheet (C ii libdbus-1-3 1.2.24-4 simple interprocess messaging syst ii libdbus-glib-1-20.88-2.1 simple interprocess messaging syst ii libdconf0 0.7.5-2 simple configuration storage syste ii libdrm2 2.4.25-3 Userspace interface to kernel DRM ii libebook1.2-10 3.0.0-1 Client library for evolution addre ii libecal1.2-83.0.0-1 Client library for evolution calen ii libedataserver1.2-143.0.0-1 Utility library for evolution data ii libedataserverui-3.0-0 3.0.0-1 GUI utility library for evolution ii libffi5 3.0.9-3 Foreign Function Interface library ii libfontconfig1 2.8.0-2.1generic font configuration library ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii libgconf2-4 2.32.3-2 GNOME configuration database syste ii libgdk-pixbuf2.0-0 2.23.3-3 GDK Pixbuf library ii libgirepository-1.0-1 0.10.8-1 Library for handling GObject intro ii libgjs0b0.7.14-1 Mozilla-based javascript bindings ii libgl1-mesa-glx [libgl1]7.7.1-4 A free implementation of the OpenG ii libglib2.0-02.28.6-1 The GLib library of C routines ii libgnome-desktop-3-03.0.2-2 Utility library for loading .deskt ii libgnome-menu2 2.30.3-1 an implementation of the freedeskt ii libgstreamer0.10-0 0.10.34-1Core GStreamer libraries and eleme ii libgtk-3-0 3.0.10-1 GTK+ graphical user interface libr ii libical00.44-3
Bug#630647: Finnish translation uses %1$d syntax not supported by grub_printf
Package: grub-common Version: 1.98+20100804-14 Severity: minor File: /usr/share/locale/fi/LC_MESSAGES/grub.mo Tags: l10n -- Steps to reproduce: 0. Have a partition containing an ext2 or ext3 file system that has been written to. (In case it matters, my disk has a GUID partition table.) 1. Get to the GRUB command prompt, in grub-pc or grub-emu. 2. Execute set lang=fi. 3. Type ls (hd0, or similar, substituting the name of the disk. Do not press Enter. 4. Press the Tab key. -- Actual results: GRUB displays something like: grub ls (hd0, Mahdollisia osioita ovat: Osio hd0,gpt1: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt2: Tiedostoj?rjestelm?tyyppi ext2 - Nimi? ?boot? - Viimeinen muokkausaika $d.$d.$d $d:$d:$d $s, UUID 2097e2f5-7cc4-4fc0-84bc-7780ae74edd5 Osio hd0,gpt3: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt4: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt5: Tuntematon tiedostoj?rjestelm? Note the $d.$d.$d $d:$d:$d $s part. (The question marks appear in grub-emu; I don't remember whether they do in grub-pc too.) -- Expected results: GRUB should have instead displayed a date and a time. Like this, for example: grub ls (hd0, Mahdollisia osioita ovat: Osio hd0,gpt1: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt2: Tiedostoj?rjestelm?tyyppi ext2 - Nimi? ?boot? - Viimeinen muokkausaika 15.6.2011 07:17:24 Wednesday, UUID 2097e2f5-7cc4-4fc0-84bc-7780ae74edd5 Osio hd0,gpt3: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt4: Tuntematon tiedostoj?rjestelm? Osio hd0,gpt5: Tuntematon tiedostoj?rjestelm? (Localizing Wednesday is not in the scope of this bug report.) -- Cause: po/fi.po in the source tree does: #: normal/misc.c:88 #, c-format msgid - Last modification time %d-%02d-%02d %02d:%02d:%02d %s msgstr - Viimeinen muokkausaika %3$d.%2$d.%1$d %4$d:%5$d:%6$d %7$s However, grub_vsnprintf_real in kern/misc.c does not support numbered argument conversion specifications like %1$d. Only this one translation in po/fi.po has the bug. There are dollar signs in po/zh_CN.po too but they have been commented out. -- Change request: Please either change the C code to support numbered arguments, or change the translation not to use them. The easiest fix would be to make the Finnish msgstr use the same %d-%02d-%02d %02d:%02d:%02d %s format as the msgid. Although the year-month-day format is not widely used in Finland, it would surely be better than not seeing the date at all. -- System Information: Debian Release: 6.0.1 APT prefers oldstable APT policy: (500, 'oldstable'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages grub-common depends on: ii base-files 6.0squeeze1 Debian base system miscellaneous f ii dpkg1.15.8.10Debian package management system ii gettext-base0.18.1.1-3 GNU Internationalization utilities ii install-info4.13a.dfsg.1-6 Manage installed documentation in ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libdevmapper1.02.1 2:1.02.48-5 The Linux Kernel Device Mapper use ii libfreetype62.4.2-2.1FreeType 2 font engine, shared lib ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages grub-common recommends: pn os-prober none (no description available) Versions of packages grub-common suggests: pn grub-emu none (no description available) pn multiboot-doc none (no description available) pn xorriso none (no description available) -- no debconf information pgppgiyYp1wVw.pgp Description: PGP signature
Bug#630619: [imagemagick] Will fix asap
Package: imagemagick Version: 8:6.6.0.4-3+b1 Will fix asap. i have cherry picket the fix from new revisions. Will post a version in mentors in a few minutes. Bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630409: sphinx: Please backport docstring parsing
* Nikolaus Rath nikol...@rath.org, 2011-06-15, 12:57:
==
FAIL: test_autodoc.test_generate
--
Traceback (most recent call last):
File /usr/lib/pymodules/python2.6/nose/case.py, line 187, in runTest
self.test(*self.arg)
File /home/nikratio/tmp/sphinx/tests/test_autodoc.py, line 486, in
test_generate
assert_processes([('function', 'time.asctime')], 'function', 'asctime')
File /home/nikratio/tmp/sphinx/tests/test_autodoc.py, line 351, in
assert_processes
assert_works(objtype, name, **kw)
File /home/nikratio/tmp/sphinx/tests/test_autodoc.py, line 345, in
assert_works
assert len(_warnings) == 0, _warnings
AssertionError: [error while formatting arguments for time.asctime:
method-wrapper '__init__' of builtin_function_or_method object at
0x7f1f5b049a28 is not a Python function]
--
I stared at this for quite a while, but I don't understand what's going on.
This hunk looks fishy:
| @@ -847,8 +893,8 @@
| def format_args(self):
| if inspect.isbuiltin(self.object) or \
| inspect.ismethoddescriptor(self.object):
| -# can never get arguments of a C function or method
| -return None
| +# cannot introspect arguments of a C function or method
| +pass
| try:
| argspec = inspect.getargspec(self.object)
| except TypeError:
If it is intentional that format_args raises an exception on builtins
etc., then the whole if statement could be removed. If this is not the
case, the change is incorrect.
I think we have to wait for upstream to fix this bug, or just accept
upstream's default. Would the later be possible?
I'd rather reluctant to enable it by default.
Note that this patch really only becomes effective if Sphinx did not
find any other way to retrieve a signature,
This is not my understanding. AFAICS it always tries to extract
signature form docstrings and only falls back to introspection, not the
other way round.
--
Jakub Wilk
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#620988: py.test -- new release available
Package: python-py Version: 1.3.4-2 Followup-For: Bug #620988 Hi ! It looks like pylib is now in version 1.4.3[1], and that the py.test part has become a separate project[2][3][4], as did pycmd[5]. I am a mere user of py.test, and I do not have a lot of packaging experience (close to none, to be honest), but if need help to package those extra sources, I gladly volunteer myself :-). Cheers, Simon Chopin [1] https://bitbucket.org/hpk42/py/src/9950bf9d684a [2] http://readthedocs.org/docs/pylib/en/1.4.3/ [3] https://bitbucket.org/hpk42/pytest [4] http://pytest.org/ [5] https://bitbucket.org/hpk42/pycmd -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-rc2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages python-py depends on: ii python2.6.6-14 interactive high-level object-orie ii python-pkg-resources 0.6.16-1 Package Discovery and Resource Acc ii python-support1.0.13 automated rebuilding support for P python-py recommends no packages. Versions of packages python-py suggests: pn python-pytest-xdist none (no description available) ii subversion 1.6.17dfsg-1 Advanced version control system -- 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#630648: hplip: Wrong udev rules makes HP Laserjet P1102 unusable
Package: hplip
Version: 3.11.5-1
Severity: important
Tags: patch
After the last update of udev the current rules for the hp printers in
/etc/udev/rules.d results in a /usr/lib/cups/backend/hp failed error. The
printer is set to inactive an hp-toolbox gives a 5012 Error which says, that no
connection to the printerdevice is possible. Of course it is impossible to
print anything. hp-setup was unable to find the device except the bus, device
and id is manually given.
The solution for this problem is the replacment of the old rules for udev, with
new ones, that uses attr and attrs instead of sysfs. I found a file in the
official tarball of the hplib source, that can replace all old rulefiles. After
replacing the rules, my printer works fine like before
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages hplip depends on:
ii adduser 3.112+nmu2 add and remove users and groups
ii coreutils 8.5-1 GNU core utilities
ii cups 1.4.6-6Common UNIX Printing System(tm) -
ii cups-client 1.4.6-6Common UNIX Printing System(tm) -
ii hplip-cups3.11.5-1 HP Linux Printing and Imaging - CU
ii hplip-data3.11.5-1 HP Linux Printing and Imaging - da
ii libc6 2.13-4 Embedded GNU C Library: Shared lib
ii libcups2 1.4.6-6Common UNIX Printing System(tm) -
ii libdbus-1-3 1.4.8-3simple interprocess messaging syst
ii libhpmud0 3.11.5-1 HP Multi-Point Transport Driver (h
ii libsane 1.0.22-3 API library for scanners
ii libsane-hpaio 3.11.5-1 HP SANE backend for multi-function
ii libssl1.0.0 1.0.0d-2 SSL shared libraries
ii lsb-base 3.2-27 Linux Standard Base 3.2 init scrip
ii policykit-1 0.101-4framework for managing administrat
ii python2.6.6-14 interactive high-level object-orie
ii python-dbus 0.84.0-1 simple interprocess messaging syst
ii python-imaging1.1.7-2+b1 Python Imaging Library
ii python-pexpect2.3-1 Python module for automating inter
ii python-support1.0.13 automated rebuilding support for P
ii wget 1.12-3.1 retrieves files from the web
Versions of packages hplip recommends:
ii avahi-daemon 0.6.30-3 Avahi mDNS/DNS-SD daemon
ii sane-utils1.0.22-3 API library for scanners -- utilit
Versions of packages hplip suggests:
pn hplip-doc none (no description available)
pn hplip-gui none (no description available)
ii python-notify 0.1.1-2+b3 Python bindings for libnotify
ii system-config-printer 1.2.3-3graphical interface to configure t
# HPLIP udev rules file for HP printer and all-in-one products.
#
# The 40-hplip.rules file replaces the 55-hpmud.rules on newer distros with
udev ACL support.
# For older distros that use HAL ACL support use the 55-hpmud.rules.
#
ACTION!=add, GOTO=hpmud_rules_end
SUBSYSTEM==usb, ENV{DEVTYPE}==usb_device, GOTO=pid_test
SUBSYSTEM!=usb_device, GOTO=hpmud_rules_end
LABEL=pid_test
# Check for AiO products (0x03f0xx11).
ATTRS{idVendor}==03f0, ATTRS{idProduct}==??11, GROUP=lp, ENV{ID_HPLIP}=1
# Check for Photosmart products without wildcard since cameras and scanners
also used (0x03f0xx02).
# The xx02 pid has been retired so this explicit list should not change.
# photosmart_d2300_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==c302, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_100
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3802, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_1115
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3402, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_1215
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3202, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_1218
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3302, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_130
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3902, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_1315
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3602, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_140_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1002, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_230
ATTRS{idVendor}==03f0, ATTRS{idProduct}==3502, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_240_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1102, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_320_series
ATTRS{idVendor}==03f0, ATTRS{idProduct}==1202, GROUP=lp, ENV{ID_HPLIP}=1
# photosmart_330_series
ATTRS{idVendor}==03f0,
Bug#630637: Bug#629290: unbound: Forwarding doesn't work if the target nameserver is broken
Simon Kelley wrote: Some implementations of gethostbyname, given the name com or mycomputer will attempt to look it up in the DNS with just such a query, thus wasting upstream bandwidth and leaking internal network information. hm, so? a heuristic based solely on the number of labels in the qname is a rather blunt tool here. far better to fix the misconfigured client than to guess at what the stub resolver might have meant. It's sometimes useful to pre-empt that, so there's a configuration option. It's not the default behaviour. NXDOMAIN is wrong here, NODATA would be better, but historically dnsmasq was fielding queries from stub resolvers, so nobody every noticed the difference. i disagree. the existence of an option that pre-empts queries for one-label qnames (and the comment at the top of the example config file encouraging one to turn it on) harms interoperability. i'd recommend deprecating and removing the domain-needed option altogether but if you're not going to do that i'd at least make the filtering logic conditional. from looking at the source it appears qtype=NS is exempted from the filter, maybe you could invert the logic and make it apply only to qtype=A and perhaps qtype=. -- Robert Edmonds edmo...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630649: nautilus-share: not add user in samba
Package: nautilus-share Version: 0.7.2-14 Severity: important allow shared directory, but not allow open when ask pass -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 2.6.38-2-amd64 (SMP w/2 CPU cores) Locale: LANG=es_CO.utf8, LC_CTYPE=es_CO.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages nautilus-share depends on: ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libglib2.0-0 2.28.6-1 The GLib library of C routines ii libgnomeui-0 2.24.3-1 The GNOME libraries (User Interfac ii libgtk2.0-0 2.24.4-3 The GTK+ graphical user interface ii libnautilus-extension12.30.1-3 libraries for nautilus components ii nautilus 2.30.1-3 file manager and graphical shell f ii samba-common 2:3.5.8~dfsg-1 common files used by both the Samb ii samba-common-bin 2:3.5.8~dfsg-1 common files used by both the Samb nautilus-share recommends no packages. Versions of packages nautilus-share suggests: ii samba 2:3.5.8~dfsg-1 SMB/CIFS file, print, and login se -- 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#630000: d-i cannot receive an IP address from Mac OS X
tags 63 + patch thanks And here is quilt patch for 1.17.1-8. -- Kenshi Muto km...@debian.org udhcpc-emit-correct-secs-field.patch Description: Binary data
Bug#630650: The parameter net.ipv4.ip_forward = 0 does not work, still allows network traffic to 192.168.0.x 130.11.xx/16 unlike
Package: base Severity: critical Tags: security -- System Information: Debian Release: 6.0.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 CPU cores) Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630651: update-notifier: Tooltip error when an apt preferences file is unreadable.
Package: update-notifier Version: 0.99.3debian8 Severity: minor I have a file in /etc/apt/preferences.d/, pinning a certain package to -1 to prevent installation. This file is owned by root:root, and has 0600 as its permissions. I noticed today, that the toolip for the update-notifier is far longer than it usually is. This is how it reads: , | An error occurred, please run Package Manager from the right-click | menu or apt-get in a terminal to see what is wrong. | | The error message was: 'Error: Opening the cache (E:Could not open | file /etc/apt/preferences.d/ign-Vsk0V3 - open (13: Permission | denied))'This usually means that your installed packages have unmet | dependencies. ` There's a few problems with this tooltip: First of all, the formatting is a bit off: there's no newline after the quoted error message. Second, the cache has nothing to do with my preferences file, I believe. Nor does it have anything to do with unmet dependencies. I'm not quite sure where the error message in the tooltip comes from, whether it is apt or a script that update-notifier uses - nevertheless, the tooltip could be formatted and worded better. I'd remove the last sentence, to be honest, but that might be just me. -- System Information: Debian Release: 6.0.1 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) 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 update-notifier depends on: ii gconf2 2.28.1-6 GNOME configuration database syste ii gksu2.0.2-5 graphical frontend to su ii libc6 2.11.2-10Embedded GNU C Library: Shared lib ii libdbus-glib-1-20.88-2.1 simple interprocess messaging syst ii libgconf2-4 2.28.1-6 GNOME configuration database syste ii libgdu0 2.30.1-2 GObject based Disk Utility Library ii libglib2.0-02.24.2-1 The GLib library of C routines ii libgtk2.0-0 2.20.1-2 The GTK+ graphical user interface ii libgudev-1.0-0 164-3GObject-based wrapper library for ii libnotify1 [libnotify1- 0.5.0-2 sends desktop notifications to a n ii libx11-62:1.3.3-4X11 client-side library ii notification-daemon 0.5.0-2 daemon to displays passive pop-up ii python 2.6.6-3+squeeze6 interactive high-level object-orie ii update-manager-gnome0.200.5-1GNOME application that manages sof ii update-notifier-common 0.99.3debian8Files shared between update-notifi Versions of packages update-notifier recommends: ii anacron2.3-14cron-like program that doesn't go pn apport-gtk none(no description available) ii software-properties-gtk0.60.debian-3 manage the repositories that you i ii synaptic 0.70~pre1+b1 Graphical package manager Versions of packages update-notifier suggests: pn ubuntu-system-service none (no description available) -- no debconf information -- |8] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630652: bjam: define the right OS name on Hurd
Package: boost1.46 Version: 1.46.1-6 Severity: normal Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, currently bjam does not identify Hurd when using e.g. os.name in jam scripts: $ bjam -v | head -n1 Boost.Jam Version 3.1.19. OS=UNKNOWN. The attached patch (which should be suitable for upstream inclusion) sets the correct #define's for Hurd in bjam, adding also the path detection for the bjam test suite. $ bjam -v | head -n1 Boost.Jam Version 3.1.19. OS=HURD. Thanks, -- Pino Description: bjam: define the right OS variable on Hurd Author: Pino Toscano toscano.p...@tiscali.it --- a/tools/build/v2/engine/src/jam.h +++ b/tools/build/v2/engine/src/jam.h @@ -391,6 +391,10 @@ #define OSMINOR OS=KFREEBSD #define OS_KFREEBSD #endif +#ifdef __GNU__ +#define OSMINOR OS=HURD +#define OS_HURD +#endif #ifndef OSMINOR #define OSMINOR OS=UNKNOWN #endif --- a/tools/build/v2/test/BoostBuild.py +++ b/tools/build/v2/test/BoostBuild.py @@ -240,6 +240,12 @@ jam_build_dir = bin.freebsd elif os.uname()[0] == OSF1: jam_build_dir = bin.osf +elif os.uname()[0] == GNU: +cpu = os.uname()[4] +if re.match(i.86.*, cpu): +jam_build_dir = bin.hurdx86; +else: +jam_build_dir = bin.hurd + os.uname()[4] else: raise Don't know directory where Jam is built for this system: + os.name + / + os.uname()[0] else:
Bug#630653: ITP: libbencode-perl -- BitTorrent serialisation format
Package: wnpp Severity: wishlist Owner: Fabrizio Regalli fab...@fabreg.it * Package name: libbencode-perl Version : 1.4 Upstream Author : Aristotle Pagaltzis pagalt...@gmx.de * URL : http://search.cpan.org/dist/Bencode/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : BitTorrent serialisation format -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630654: pidgin must build depend on libgadu-dev (= 1:1.11.0)
Package: pidgin Version: 2.8.0-1 Severity: important The security team is surely not happy that currently an internal version of libgadu is used. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630655: libgadu: New upstream version available
Package: libgadu Version: 1:1.10.1-1 Severity: wishlist libgadu 1.11.0 is available at http://toxygen.net/libgadu/ Could you package this version? TIA Adrian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630619: [imagemagick] Could you test with version on mentors
Hi, I have just uploaded a new version on mentors. Could you test please ? bastien -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630656: ITP: libdata-taxi-perl -- Taint-aware, XML-ish data serialization
Package: wnpp Severity: wishlist Owner: Fabrizio Regalli fab...@fabreg.it * Package name: libdata-taxi-perl Version : 0.96 Upstream Author : Miko O'Sullivan m...@idocs.com * URL : http://search.cpan.org/dist/Data-Taxi/ * License : Artistic or GPL-1+ Programming Lang: Perl Description : Taint-aware, XML-ish data serialization -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630453: the tutorial's license don't pass the free island test
Hi it's requested has been replaced with it's strongly encouraged. You can find copies of the modified document here: http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.pdf http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.odt Regards, David On 16/06/2011 7:20 AM, Georges Khaznadar wrote: Hello David, thank you for your fast response! You probably have heard of the Debian guidelines about free software (DFSG), they try to define most clearly the frontier between free and non-free software. In real life, things are not either black or white: black and white are united by a continuous series of grey tones. The desert island test is one of the touchstones we use to decide whether something is free or non-free. Here is a simple version of this test: please imagine that you live in a desert island, and that you got the software X, possibly enclosed in a floating bottle. Then you examine the software, and the license says that you must communicate with its author to be authorized to use this software (for any usage which is possible in the case of free software: running it, reading its source, modifying it). If the license compells you to communicate with the author, it is no more DFSG-free. You license still contains one phrase which does not pass this test: If you're considering making a derived work other than a translation, it's requested that you discuss your plans with the current maintainer. The words it's requested are compelling. Hence this tutorial falls into the category of non-DFSG-free documents. Please consider some rewording, for example: s/it's requested that you/you are strongly encouraged to/ For how many people would the modified version of the licence change their behavior? I believe that there are plenty of people who do not take serously the licenses: those won't read your license, either in its compelling form or in its milder form. However which such a rewording, your license would definitely belong to the category of FDSG-free documents. Timo, Berndt, what is your mind about this? Best regards, Georges. Kicad a écrit : Hi, I have deleted the offending line from the current version of the document, which was updated this year. Does this resolve the issue? You can find copies of the modified document here: http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.pdf http://www.iridec.com.au/Kicad/KiCad_Tutorial_2011.odt Kind Regards, David On 15/06/2011 7:24 AM, Georges Khaznadar wrote: Hi, thank you for your fast reply Timo. Let us wait some time for David's response. Best regards, Georges. Timo Juhani Lindfors a écrit : Hi, Georges Khaznadargeorges.khazna...@free.fr writes: is it possible to have a single source package, giving two output packages in different sections like main and non-free? my idea is that it is not allowed, this is not possible indeed since non-free stuff is not ok in the source package either. so I should withdraw the conflicting file from kicad's source, to build a package kicad-X.XX+dfsg, and upload a package kicad-tutorial to the NEW queue. Sounds possible. I would rather see the license fixed though. I already started updating the tutorial with screenshots from a more recent kicad before I noticed the first page banner. -Timo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630657: apt: [l10n:ca] Updated Catalan translation
Package: apt Version: 0.8.15~exp1 Severity: wishlist Tags: l10n Hi, Attached is a Catalan update for apt. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-1-amd64 (SMP w/2 CPU cores) Locale: LANG=ca_ES.UTF-8@valencia, LC_CTYPE=ca_ES.UTF-8@valencia (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages apt depends on: ii debian-archive-keyring 2010.08.28 GnuPG archive keys of the Debian a ii gnupg 1.4.11-3 GNU privacy guard - a free PGP rep ii libc6 2.13-4 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-11 GCC support library ii libstdc++6 4.6.0-11 The GNU Standard C++ Library v3 ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime apt recommends no packages. Versions of packages apt suggests: pn apt-doc none (no description available) ii aptitude 0.6.4-1terminal-based package manager (te ii bzip2 1.0.5-6high-quality block-sorting file co ii dpkg-dev 1.16.0.3 Debian package development tools ii lzma 4.43-14Compression method of 7z format in ii python-apt0.8.0 Python interface to libapt-pkg ii synaptic 0.75.1 Graphical package manager -- no debconf information ca.po.gz Description: GNU Zip compressed data
Bug#630566: linux-source-2.6.39: 2.6.39-2 : bluetooth broken
Am Mittwoch, 15. Juni 2011, 13:26:50 schrieben Sie: did you try 3.0-rc2 in experimental? thanks I tried it now and the problem is the same (same error). btw. I had trouble to compile the 3.0 kernel. I needed to remove the modules apm and lguest. It also uses much more ram than 2.6.39. Probably it needs an updated kernel-package and some more work but that has nothing to do with the bluetooth problem of course. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630118: closed by Bart Martens ba...@debian.org (updated checksums)
Perhaps you can use WWW::Mechanize and a cron job to always keep everything up to date? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630641: gem2deb: duplicate install of files in lib/
Lucas Nussbaum escreveu isso aí: Package: gem2deb Version: 0.2.4 Severity: important Hi, for ruby-xmlparser (found in the pkg-ruby-extras repo, not uploaded yet because of that problem), gem2deb installs the files in lib/ to /usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/ and /usr/lib/ruby/vendor_ruby/1.8/x86_64-linux/. This might be related to the fact that extconf.rb is in the root dir. It happens exactly because of that. The extconf.rb in the root dir will be invoked once for each supported Ruby interpreter, and it will install the lib/ files in the arch-specific dirs. And if I am not mistaken, gem2deb itself will *also* install the files under lib/ to the arch-independent dir ... Moving extconf.rb and the C files to an ext/ dir it probably the best solution, and will work ok for Rubygems as well. I don't know if there is a sane way to handle this in gem2deb ... the problem is a broken upstream build system. -- Antonio Terceiro terce...@softwarelivre.org http://softwarelivre.org/terceiro signature.asc Description: Digital signature
Bug#630579: nvidia-glx: glx cannot be utilised
Is there a workaround we can do in the meantime, eg changing symlinks? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606309: trang ends with Bus error on kfreebsd-amd64
Hello, Ondřej Surý, le Wed 08 Dec 2010 10:30:46 +0100, a écrit : Trang fails with Bus error when rebuilding rng files for opendnssec on kfreebsd-amd64: and it doesn't happen on kfreebsd-i386. I'm getting the following backtrace on asdfasdf.debian.net: 0x000803cfa2c7 in __pthread_sigsuspend () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 (gdb) bt #0 0x000803cfa2c7 in __pthread_sigsuspend () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #1 0x000803cf93b8 in __pthread_wait_for_restart_signal () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #2 0x000803cf9f8c in pthread_create@@GLIBC_2.3 () from /lib/x86_64-kfreebsd-gnu/libpthread.so.0 #3 0x0008029884c2 in ?? () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #4 0x0008020104cf in _Jv_ThreadStart(java::lang::Thread*, _Jv_Thread_t*, void (*)(java::lang::Thread*)) () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #5 0x0008020078ea in void java::lang::Thread::start() () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #6 0x000801fbc55a in _Jv_CreateJavaVM () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #7 0x000801fbc637 in _Jv_RunMain(_Jv_VMInitArgs*, java::lang::Class*, char const*, int, char const**, bool) () from /usr/lib/x86_64-kfreebsd-gnu/libgcj.so.12 #8 0x000800820ce1 in main () from /usr/lib/x86_64-kfreebsd-gnu/libgij.so.12 #9 0x0008049f61e9 in __libc_start_main () from /lib/x86_64-kfreebsd-gnu/libc.so.0.1 #10 0x0040060c in ?? () #11 0x7fffeb38 in ?? () #12 0x001c in ?? () #13 0x in ?? () (gdb) disassemble 0x000803cfa2c7 Dump of assembler code for function __pthread_sigsuspend: 0x000803cfa2c0 +0: mov$0x155,%eax 0x000803cfa2c5 +5: syscall = 0x000803cfa2c7 +7: retq i.e. the segfault is triggered from the kernel itself. Does anybody has any idea? I'd tend to reassign this to libgcj12 or kfreebsd-8, since there doesn't seem to be anything specific to trang in this backtrace. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626172: aptitude, elinks: something is wrong here
Hi again, something has been done – elinks dropped the firefox dependency, which made it, and thus aptitude, buildable (although with not all B-Ds in their latest versions) on m68k again. (Haven’t got a chance to test it in action yet though, but next cowbuilder update I’ll ask one of my machines to use it for build dependency resolving again.) I still think the presence of a package that occasionally build-depends on firefox out of all things is a mistake, but feel free to reduce the severity on this one. bye, //mirabilos -- Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL. -- Henry Nelson, March 1999 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#630658: sbuild-createchroot succfails badly with invalid user
Package: sbuild Version: 0.62.2-1 Severity: grave Justification: Unusable, unable to create a chroot, also highly confusing. Hi. So, having faith, I purged sbuild and schroot entirely (yay for the failing delgroup call, by the way, and a different error than #619892 -- sbuild being the last remaining group for the sbuild user or something similar), trying to start afresh and without any prejudices. Now, even creating a chroot fails, or succeeds, depending on which line one reads: | [config file excerpt] | I: Please rename and modify this file as required. | mkdir /etc/sbuild/chroot | I: sudo chroot configuration linked as | /etc/sbuild/chroot/sid-amd64-sbuild. | chown: invalid user: `sbuild:sbuild' | E: Failed to set sbuild:sbuild ownership on /build | Failed to set up chroot | E: Error creating chroot session: skipping apt update | I: Successfully set up sid chroot. | I: Run sbuild-adduser to add new sbuild users. Looks like yet another proof of sbuild's extreme fragility. :( -- System Information: Debian Release: sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.39-2-amd64 (SMP w/2 CPU cores) 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 sbuild depends on: ii adduser 3.113 add and remove users and groups ii libc62.13-7 Embedded GNU C Library: Shared lib ii libgcc1 1:4.6.0-13 GCC support library ii libsbuild-perl 0.62.2-1Tool for building Debian binary pa ii libstdc++6 4.6.0-13GNU Standard C++ Library v3 ii perl 5.12.3-7+b1 Larry Wall's Practical Extraction ii perl-modules 5.12.3-7Core Perl modules Versions of packages sbuild recommends: ii debootstrap 1.0.32 Bootstrap a basic Debian system ii fakeroot 1.16-1 tool for simulating superuser priv Versions of packages sbuild suggests: pn deborphan none (no description available) ii wget 1.12-3.1 retrieves files from the web -- Configuration Files: /etc/schroot/buildd/config changed [not included] /etc/schroot/buildd/copyfiles changed [not included] /etc/schroot/buildd/fstab changed [not included] /etc/schroot/buildd/nssdatabases changed [not included] ^ Also, lies. I never touched those files. -- 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
