Bug#358183: mono-winforms2.0: System.EntryPointNotFoundException: GdipGetFontHeightGivenDPI
Package: libmono-winforms2.0-cil Version: 1.1.13.4-1 Severity: important Update from libgdiplus-1.1.13.2-1 to 1.1.13.4-1 did help; but the dependencies did not require that: Unhandled Exception: System.EntryPointNotFoundException: GdipGetFontHeightGivenDPI in (wrapper managed-to-native) System.Drawing.GDIPlus:GdipGetFontHeightGivenDPI (intptr,single,single) in 0x00022 System.Drawing.Font:GetHeight (Single dpi) in 0x00020 System.Drawing.Font:GetHeight () in 0xd System.Drawing.Font:get_Height () in (wrapper remoting-invoke-with-check) System.Drawing.Font:get_Height () in 0x0007e System.Windows.Forms.Form:GetAutoScaleSize (System.Drawing.Graphics g, System.Drawing.Font font) in 0x0003e System.Windows.Forms.Form:.ctor () [ ... ] -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (990, 'testing'), (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16 Locale: [EMAIL PROTECTED], [EMAIL PROTECTED] (charmap=ISO-8859-15) Versions of packages libmono-winforms2.0-cil depends on: ii libgdiplus1.1.13.2-1 interface library for Mono class S ii libmono-corlib2.0-cil 1.1.13.4-1 Mono core library (2.0) ii mono-classlib-1.0 1.1.13.4-1 Mono class library (1.0) libmono-winforms2.0-cil recommends no packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#520124: lighttpd: please release ...
Don't wait for this bug. As long as no one has a good idea how to handle this, there will be no patch. Here the commit message for the revert: Revert url decoding+simplifying before matching of mod_rewrite/mod_redirect - Lot of regressions (we forgot to reencode the result) - Generic problem: after decode and rewrite a?b?c: which '?' was the path?query seperator? - Possible solution: only decode printable characters (without '?'), and encode the result; do not encode the '%' of a not decoded character. - Still a problem with path simplifying, it seems many people use urls like this: http://server1/http%3a//server2/xxx and rewrite the path into the querystring. - Probably only usable with an extra config option = Do NOT use rewrite/redirect to protect specific urls. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609095: tinyproxy: Bind cannot be used with transparent support enabled error message
Hi, very broken bug report... a) The error message is: # /etc/init.d/tinyproxy restart Restarting tinyproxy: Bind cannot be used with transparent support enabled. Syntax error on line 37 Unable to parse config file. Not starting. Not without - with! b) The configure option is --enable-transparent (it had a different name: --enable-transparent-proxy, see https://banu.com/git/?p=tinyproxy.git;a=commitdiff;h=58ac635a17dcfe8add856fea5af9faacf56aca16) Renaming this to something unrecognized does turn that option off ofcourse (removing would be the correct way...) c) The check was inserted here: https://banu.com/git/?p=tinyproxy.git;a=commitdiff;h=febb521bfd36ae0d647a42bbf7618f57928e9d38 configure.ac says version was 1.7.0 d) I see no reason why Bind shouldn't work in transparent proxies too, so i think it is a bug in tinyproxy (probably removing that config check should fix it). But this does *not* render the package unusable. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565502: certificate based authentication doesn't work
Perhaps this package should be dropped, as the maintainers don't even fix very basic and easy bugs - and they probably won't in the future, as upstream is far ahead. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611462: apt-dater-host config/postinst broken
Package: apt-dater-host
Version: 0.8.4-3
Hi, the line
sed s/^\$ASSUMEYES=.*/\$ASSUMEYES=${ASSUME_YES}/ -i
/etc/apt-dater-host.conf
in the .postinst script is broken; it deletes the ; at the end of the line,
which is needed as the config file is evald in the perl script.
this should work i guess:
sed s/^\$ASSUMEYES=.*/\$ASSUMEYES=${ASSUME_YES};/ -i
/etc/apt-dater-host.conf
- stefan
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611088: apt-dater-host silently ignores ABI-incompatible
Hi, shouldn't the do_upgrade method use dist-upgrade too then? I guess it would be at least nice to have the option to run dist-upgrade instead of (safe-)upgrade in the frontend. - stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#611968: apt-dater-host config broken
Package: apt-dater-host Version: 0.8.4-4 Hi again, after updating all my configs were broken again; i think this time it is the config script, which overwrites the debconf entry with 1 or 0, and it should probably be true or false instead. the postinst script checks only for true/false, not for 1/0, so ASSUME_YES is empty. after dpkg-reconfigure it works again, as this enforces the dialog, which sets true or false instead of 1/0. - stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612735: imvirt misses pciutils dependency
Package: imvirt Version: 0.9.0-2 Without pciutils i got the following error on a xen guest: # imvirt Can't exec lspci: No such file or directory at /usr/share/perl5/ImVirt/Utils/pcidevs.pm line 68. Error loading ImVirt::VMD::KVM: Cannot exec lspci: No such file or directory Compilation failed in require at /usr/share/perl5/ImVirt/VMD/KVM.pm line 35. BEGIN failed--compilation aborted at /usr/share/perl5/ImVirt/VMD/KVM.pm line 35. Compilation failed in require at (eval 16) line 1. BEGIN failed--compilation aborted at (eval 16) line 1. Compilation failed in require at /usr/bin/imvirt line 31. BEGIN failed--compilation aborted at /usr/bin/imvirt line 31. Xen PV 3.2 So either it shouldn't handle missing lspci or depend on pciutils. - stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612735: imvirt misses pciutils dependency
On 02/10/2011 12:16 PM, Thomas Liske wrote: Hi, IMHO imvirt should not depend on pciutils (I would prefer a Suggests or Recommends) as this might be useless for some virtualization containers. I am not sure what the goal of the project is; but if you already know which container you are on (and therefore don't install some packages needed for some detections), the detection is not that useful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607438: ares_expand_name bug
Package: c-ares
Version: 1.7.3-1
Hi,
c-ares has a bug in ares_expand_name: it assumes the encoded length of
. is always 1 (as it should be a single null byte), but it could be
an indirect . too, which is 2 bytes long (in most cases 0xc0 0x0c,
referring to the question name).
So it cannot parse responses to queries like (dig) NS .
Btw: I think there are many ugly casts in the source, like
char *buf;
unsigned short x = ntohs(*(unsigned short*) buf);
These should be fixed (with memcpy for example), as not all platform support
unaligned memory access.
See https://github.com/bagder/c-ares/pull/2
diff --git a/ares_expand_name.c b/ares_expand_name.c
index 2af6b2a..8f40b58 100644
--- a/ares_expand_name.c
+++ b/ares_expand_name.c
@@ -87,7 +87,12 @@ int ares_expand_name(const unsigned char *encoded, const
unsigned char *abuf,
* Since this function strips trailing dots though, it becomes
*/
q[0] = '\0';
-*enclen = 1; /* the caller should move one byte to get past this */
+/* indirect root label (like 0xc0 0x0c) is 2 bytes long (stupid, but
valid) */
+if ((*encoded INDIR_MASK) == INDIR_MASK) {
+ *enclen = 2;
+} else {
+ *enclen = 1; /* the caller should move one byte to get past this */
+}
return ARES_SUCCESS;
}
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#481317: Bug in Lighttpd
Lighttpd doesn't properly support IPv6, it just listens on AF_INET6 and accepts both IPv4 and IPv6 on it. That is bullshit. Lighttpd does support IPv6 properly, but the old default for listening to ::0 included listening to mapped-IPv4 too (not on *BSD afaik, this was a linux only feature), and that isn't lighttpd's fault. This has been changed in netbase now anyway. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565502: certificate based authentication doesn't work
Package: openvas-server Version: 2.0.3-3 This feature was probably broken during the switch from OpenSSL to GnuTLS. (see http://lists.wald.intevation.org/pipermail/openvas-devel/2009- September/001812.html) There was a patch to fix this: http://lists.wald.intevation.org/pipermail/openvas-devel/2009- September/001811.html I added some error handling to re-enable certificate based authentication in the source and to use the gnutls subject format in the scripts (see 20_certauth.dpatch) I think a second patch is needed, as on my system gnutls didn't accept md5 as method in the certificates: 30_use_sha1.dpatch (yes, this patches a file in debian/ - you probaby should apply that part directly) lintian gives a warning for the Default-Stop: in the init script, i think 0 1 6 should be ok for that. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560837: lighttpd listened on ipv6 only after upgrade
Looks like you don't understand the problem. We (upstream) know perfectly well that IPV6_V6ONLY would have made things easier, but we don't like breaking existing setups, so we didn't change it. In our next version (lighttpd sandbox/2.0) we already use IPV6_V6ONLY, and have a better syntax for listening to multiple sockets. I would recommend to just drop the ipv6-enabled script. The people who care about ipv6 listening should just enable it manually; i think it is bad style to silently change existing setups to listen to ipv6, as it might circumvent access restrictions. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#565502: certificate based authentication doesn't work
Looks like i forgot to add the patches in the mail... Sorry. 20_certauth.dpatch Description: application/shellscript 30_use_sha1.dpatch Description: application/shellscript
Bug#565502: certificate based authentication doesn't work
As mwiegand pointed out to me on irc the patch breaks password authentication. Fixed patch is attached, upstream fixed trunk/ already (but not the 2.0 branch and i don't know the status of the mkcert-client/adduser scripts) http://wald.intevation.org/plugins/scmsvn/viewcvs.php/trunk/openvas- scanner/openvassd/openvassd.c?root=openvasrev=6037r1=6463r2=6037 20_certauth.dpatch Description: application/shellscript
Bug#529285: libmemcached: please add a debug symbols package
Package: libmemcached Version: 0.28-1 Severity: wishlist There is no libmemcached2-dbg package, it would be nice if you could add it. Thx! Greetings, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537049: luasocket exports unneeded (and unprefixed) symbols leading to segfaults due to name collissions
Package: luasocket
Version: 2.0.2-3
A lua library it should only support its luaopen_* functions, but it exports
many other symbols, including for example buffer_init.
The other exported symbols are used (and exported to support loading plugins)
in other binaries, for example in lighttpd; if now one loads the lua socket
library via mod_magnet in lighty, the lua socket library will use the
buffer_init from lighty, leading to segfaults in the lua library.
The solution is to only export the luaopen_* functions.
Btw: installing the unix.h header is pointless as i needs other headers as
well. Perhaps installing a different header as unix.h would be better to only
provide luaopen_socket_unix().
If you want to test this yourself, make a simple binary loading the echo-
server example from the luasocket homepage and export a buffer_init in it;
compile with -export-dynamic.
For now i have a simple example:
http://stbuehler.de/tmp/luasockettest.tar.bz2
Greetings,
Stefan
commit 5440201de4bcfc0fcfbc1f735465e82b08c74cf3
Author: Stefan Bühler stbueh...@web.de
Date: Tue Jul 14 16:59:49 2009 +0200
Use a map for exported symbols
diff --git a/Makefile.Debian b/Makefile.Debian
index 88a1d21..2b4ae84 100644
--- a/Makefile.Debian
+++ b/Makefile.Debian
@@ -40,15 +40,15 @@ lua50/liblua50-socket.la: $(SOCKET_OBJS_50)
lua50/liblua50-mime.la: $(MIME_OBJS_50)
lua50/liblua50-unix.la: $(UNIX_OBJS_50)
lua5.1/%.lo: src/%.c
- $(LBTL) --mode=compile $(CC) -c $(GCC_FLAGS_51) -o $@ $
+ $(LBTL) --mode=compile $(CC) -c $(GCC_FLAGS_51) -o $@ $
lua50/%.lo: src/%.c
$(LBTL) --mode=compile $(CC) -c $(GCC_FLAGS_50) -o $@ $
lua50/%.la:
- $(LBTL) --mode=link $(CC) \
- -rpath $(LUA_RPATH_50) -o $@ -version-info $(VERSION_INFO) $^
+ $(LBTL) --mode=link $(CC) -llua50 \
+ -rpath $(LUA_RPATH_50) -o $@ -version-info $(VERSION_INFO) $^ -Wl,--version-script=src/export.map
lua5.1/%.la:
$(LBTL) --mode=link $(CC) \
- -rpath $(LUA_RPATH_51) -o $@ -version-info $(VERSION_INFO) $^
+ -rpath $(LUA_RPATH_51) -llua5.1 -o $@ -version-info $(VERSION_INFO) $^ -Wl,--version-script=src/export.map
install-bin: install-bin50 install-bin51
install-bin50:
mkdir -p $(DESTDIR)/usr/lib/
diff --git a/config b/config
index 49958eb..81ac6da 100644
--- a/config
+++ b/config
@@ -52,7 +52,7 @@ INSTALL_EXEC=cp
CC=gcc
DEF=-DLUASOCKET_DEBUG
CFLAGS= $(LUAINC) $(DEF) -pedantic -Wall -O2 -fpic
-LDFLAGS=-O -shared -fpic
+LDFLAGS=-O -shared -fpic -Wl,--version-script=export.map
LD=gcc
#--
diff --git a/src/export.map b/src/export.map
new file mode 100644
index 000..71ee4f3
--- /dev/null
+++ b/src/export.map
@@ -0,0 +1,4 @@
+{
+ global: luaopen_*;
+ local: *;
+};
Bug#537788: php5 + suhosin with suhosin.session.encrypt = On segfaults
Package: php5 Version: 5.2.10.dfsg.1-2 + suhosin (0.9.27-1) Hi! On debian (sid) with above version of php5 suhosin seems to cause a segfault if suhosin.session.encrypt = On is set and an app starts a new session. Disabling suhosin completely or setting suhosin.session.encrypt = Off it works as expected. I´m running lighttpd + php5-cgi. http://bugs.gentoo.org/show_bug.cgi?id=276583 -- looks very similar, i found the solution with suhosin.session.encrypt = Off there. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537788: [php-maint] Bug#537788: php5 + suhosin with suhosin.session.encrypt = On segfaults
Jan Wagner w...@cyconet.org wrote: Hi, Do you have any steps to reproduce the issue? Possible any scripts or anything? See attachment. attachment: test.php
Bug#564556: lighttpd: can't bind to port: :: 80 Address
I think i already wrote this: I don't think it is a good idea to
automatically enable ipv6: it neither works with the wrong bindv6only
nor with server.port != 80.
Dropping the script would fix these issues; providing a simple example
line in the default config should be enough imho (the people who want
ipv6 know they have to configure most services to use it anyway):
# uncomment to listen to ipv6:
# (if you still have bindv6only=0 use
# server.use-ipv6 = enable instead)
# $SERVER[socket] == [::]:80 { }
Stefan
(upstream dev)
PS: We still think about enforcing BINDV6ONLY upstream (we probably
would add a use-the-old-way option for some time) in 1.4.x; but
I don't think it will come in 1.4.27, perhaps 1.4.28.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564556: [pkg-lighttpd] Bug#564556: lighttpd: can't bind to port: :: 80 Address
On 05/23/2010 11:26 AM, Olaf van der Spek wrote: http://wiki.debian.org/ReleaseGoals/FullIPv6Support Debian's goal is to have out-of-the-box IPv6 support in all daemons. Not enabling IPv6 is not a solution. Olaf I think there is a difference between supporting something and enabling it by default. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571559: lighttpd: fastcgi bin-environment variable not set
Hi, this is not a bug in lighttpd; FCGI_Accept() overrides the process enviroment with the (Fast)CGI environment, so you have to get the value before calling FCGI_Accept(). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#570355: lighttpd: postinstst script chowns dirs to www-data:www-data
Hi, the postinst script certainly should not parse the lighttpd config (could be in any shell include...); you could argue the script shouldn't modify the existing owner. Imho you should choose a different doc-root (/srv/www, ...) if you don't want to use system standards like a www-data user. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#457290: invoke-rc.d lighttpd stop does not stop php-cgi
Hi, socket = /tmp/php-cgi.socket + var.PID this is a really stupid idea: that way you just keep spawning new backends with every lighttpd restart, and the old backends will still be running too. Recommended way is to use runit or daemontools/supervise with spawn-fcgi, that way you can restart php without lighttpd (and the other way round), and have php run with a different user (always a good thing for security). I'd love to have some useful debug info on this, so if you can reproduce it and get a strace of it (lighttpd *and* php), that would be very nice. The last strace someone had showed that lighttpd did the correct kill(...) call (there was no strace of the corresponding php backend). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521770: lighttpd: should provide a -dev package for development header files
Hi, debian/lighttpd-dev.install: config.h /usr/lib/lighttpd src/*.h /usr/lib/lighttpd ... I hope that was just a typo. Anyway, i think you should first try get support for a -dev package in upstream; although i am not sure whether this is a good idea - i prefer to have plugins directly in the source, so there are no dependency problems. That way there would be no need for a -dev package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#568519: lighttpd fails proxy connections when upgraded to 1.4.19-5+lenny1
Hi, you both didn't describe the lighttpd side of your configuration; and you didn't mention anything else like: * does redmine still work when you connect to lighttpd directly (test with curl -v please) * is there anything in the error.log/access.log of lighty? So you should paste a little bit more details. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#406338: lighttpd: /var/log/ligghtpd/*.log is readable by www-data
Hi, as lighttpd needs to be able to reopen the logfiles after logrotate, the www- data user needs +rw. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#389700: mod_geoip would be very useful
Hi, the module was *not* added upstream, it is just a 3rd party module. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#575102: mumble-django shouldn't depend on apache
Package: mumble-django Version: 2.0-1 There are other webservers which are capable of handling wsgi applications, and there is no need to run the webserver on the same host, so i think it should be a recommend dependency. I run it myself with lighttpd2, and it works fine. I use exec /usr/bin/spawn-fcgi -s /var/run/lighttpd/mumble-django.sock -n -u mumble-server -U www-data -- /usr/share/mumble-django/mumble- django.fastcgi in my supervise run script and the following /usr/share/mumble-django/mumble-django.fastcgi: #!/usr/bin/python # -*- coding: utf-8 -*- # Set this to the same path you used in settings.py, or None for auto-detection. MUMBLE_DJANGO_ROOT = None; ### DO NOT CHANGE ANYTHING BELOW THIS LINE ### import os, sys from os.path import join, dirname, abspath, exists # Path auto-detection if not MUMBLE_DJANGO_ROOT or not exists( MUMBLE_DJANGO_ROOT ): MUMBLE_DJANGO_ROOT = dirname(abspath(__file__)); # environment variables sys.path.append( MUMBLE_DJANGO_ROOT ) sys.path.append( join( MUMBLE_DJANGO_ROOT, 'pyweb' ) ) os.environ['DJANGO_SETTINGS_MODULE'] = 'pyweb.settings' # If you get an error about Python not being able to write to the Python # egg cache, the egg cache path might be set awkwardly. This should not # happen under normal circumstances, but every now and then, it does. # Uncomment this line to point the egg cache to /tmp. #os.environ['PYTHON_EGG_CACHE'] = '/tmp/pyeggs' from django.core.servers.fastcgi import runfastcgi runfastcgi(method=threaded, daemonize=false) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#571272: fglrx doesn't build with linux 2.6.33
Package: fglrx-driver
Version: 1:10-2-1
Hi,
fglrx doesn't build with linux 2.6.33, as some internal cmpxchg macro is used
which got changed.
The attached patch uses the real cmpxchg macro, which needs some casting
before, depending on the size of the data.
# Fix broken usage of internal macro; fixes compiling with 2.6.33
diff -Naur fglrx-driver-10-2.orig/common/lib/modules/fglrx/build_mod/firegl_public.c fglrx-driver-10-2/common/lib/modules/fglrx/build_mod/firegl_public.c
--- fglrx-driver-10-2.orig/common/lib/modules/fglrx/build_mod/firegl_public.c 2010-02-17 20:34:34.0 +0100
+++ fglrx-driver-10-2/common/lib/modules/fglrx/build_mod/firegl_public.c 2010-02-24 21:23:51.580872456 +0100
@@ -1472,7 +1472,16 @@
#ifndef __HAVE_ARCH_CMPXCHG
return __fgl_cmpxchg(ptr,old,new,size);
#else
-return __cmpxchg(ptr,old,new,size);
+switch (size) {
+case 1: { volatile u8 *_ptr = ptr; return cmpxchg(_ptr, old, new); }
+case 2: { volatile u16 *_ptr = ptr; return cmpxchg(_ptr, old, new); }
+case 4: { volatile u32 *_ptr = ptr; return cmpxchg(_ptr, old, new); }
+#ifdef __x86_64__
+case 8: { volatile u64 *_ptr = ptr; return cmpxchg(_ptr, old, new); }
+#endif
+default:
+return old;
+}
#endif
}
Bug#578042: korganizer segfault/stackoverflow on startup
Package: korganizer Version: 4:4.3.4-2 Severity: grave qt version 4:4.6.2-4 $ gdb --args korganizer --nofork (gdb) run ... (gdb) bt #0 QAlgorithmsPrivate::qSortHelperQListQGraphicsItem*::iterator, QGraphicsItem*, bool (*)(QGraphicsItem const*, QGraphicsItem const*) (start=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at ../../include/QtCore/../../src/corelib/tools/qalgorithms.h:343 #1 0x756b83ec in QAlgorithmsPrivate::qSortHelperQListQGraphicsItem*::iterator, QGraphicsItem*, bool (*)(QGraphicsItem const*, QGraphicsItem const*) (start=DWARF-2 expression error: DW_OP_reg operations must be used either alone or in conjuction with DW_OP_piece. ) at ../../include/QtCore/../../src/corelib/tools/qalgorithms.h:385 #2 0x756b85c8 in qSortQListQGraphicsItem*::iterator, bool (*) (QGraphicsItem const*, QGraphicsItem const*) (start=value optimized out, end=value optimized out, lessThan=0x756b1eb0 qt_closestItemFirst) at ../../include/QtCore/../../src/corelib/tools/qalgorithms.h:187 #3 0x756b7c31 in QGraphicsSceneBspTreeIndexPrivate::sortItems (itemList=0x7f7ff2c0, order=value optimized out, sortCacheEnabled=value optimized out, onlyTopLevelItems=value optimized out) at graphicsview/qgraphicsscenebsptreeindex.cpp:434 #4 0x756b7e69 in QGraphicsSceneBspTreeIndex::items (this=value optimized out, order=Qt::DescendingOrder) at graphicsview/qgraphicsscenebsptreeindex.cpp:572 #5 0x756924ca in QGraphicsScene::items (this=value optimized out) at graphicsview/qgraphicsscene.cpp:1900 #6 0x75698fb9 in QGraphicsScene::itemsBoundingRect (this=0x7f7ff070) at graphicsview/qgraphicsscene.cpp:1887 #7 0x7569fc41 in QGraphicsScene::sceneRect (this=0xba6360) at graphicsview/qgraphicsscene.cpp:1636 #8 0x76be4c0f in ?? () from /usr/lib/libkorganizerprivate.so.4 #9 0x76be4c79 in ?? () from /usr/lib/libkorganizerprivate.so.4 #10 0x76be2ba3 in ?? () from /usr/lib/libkorganizerprivate.so.4 #11 0x75667fa1 in QGraphicsItem::sceneBoundingRect (this=0x7f7ff070) at graphicsview/qgraphicsitem.cpp:4545 #12 0x75699058 in QGraphicsScene::itemsBoundingRect (this=value optimized out) at graphicsview/qgraphicsscene.cpp:1888 #13 0x7569fc41 in QGraphicsScene::sceneRect (this=0xba6360) at graphicsview/qgraphicsscene.cpp:1636 ... #5534 0x76be4c0f in ?? () from /usr/lib/libkorganizerprivate.so.4 #5535 0x76be4c79 in ?? () from /usr/lib/libkorganizerprivate.so.4 #5536 0x76be2ba3 in ?? () from /usr/lib/libkorganizerprivate.so.4 #5537 0x75667fa1 in QGraphicsItem::sceneBoundingRect (this=0x7f7ff070) at graphicsview/qgraphicsitem.cpp:4545 #5538 0x75699058 in QGraphicsScene::itemsBoundingRect (this=value optimized out) at graphicsview/qgraphicsscene.cpp:1888 #5539 0x7569fc41 in QGraphicsScene::sceneRect (this=0xba6360) at graphicsview/qgraphicsscene.cpp:1636 #5540 0x76be4c0f in ?? () from /usr/lib/libkorganizerprivate.so.4 #5541 0x76be4c79 in ?? () from /usr/lib/libkorganizerprivate.so.4 #5542 0x76be2ba3 in ?? () from /usr/lib/libkorganizerprivate.so.4 #5543 0x75667fa1 in QGraphicsItem::sceneBoundingRect (this=0x7f7ff070) at graphicsview/qgraphicsitem.cpp:4545 #5544 0x75699058 in QGraphicsScene::itemsBoundingRect (this=value optimized out) at graphicsview/qgraphicsscene.cpp:1888 #5545 0x7569fc41 in QGraphicsScene::sceneRect (this=0xba6360) at graphicsview/qgraphicsscene.cpp:1636 #5546 0x76be4c0f in ?? () from /usr/lib/libkorganizerprivate.so.4 #5547 0x76be4c79 in ?? () from /usr/lib/libkorganizerprivate.so.4 #5548 0x76be2ba3 in ?? () from /usr/lib/libkorganizerprivate.so.4 #5549 0x75667fa1 in QGraphicsItem::sceneBoundingRect (this=0x7f7ff070) at graphicsview/qgraphicsitem.cpp:4545 #5550 0x75699058 in QGraphicsScene::itemsBoundingRect (this=value optimized out) at graphicsview/qgraphicsscene.cpp:1888 #5551 0x7569fc41 in QGraphicsScene::sceneRect (this=0xba6360) at graphicsview/qgraphicsscene.cpp:1636 #5552 0x76be4c0f in ?? () from /usr/lib/libkorganizerprivate.so.4 #5553 0x76be4c79 in ?? () from /usr/lib/libkorganizerprivate.so.4 #5554 0x76be2ba3 in ?? () from /usr/lib/libkorganizerprivate.so.4 ... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#573171: lighttpd: $HTTP[url] contains full URI when using GET https in lenny
Hi, Johannes Weißl jar...@molb.org wrote: Package: lighttpd Version: 1.4.19-5+lenny1 Severity: important $HTTP[url] contains full URI (https://host:443/somefile) when using an https request like this: GET https://host:443/somefile HTTP/1.1 Host: host:443 while it should only contain /somefile. It works if a relative path for GET is used or in unencrypted http. It works in squeeze, so the bug is fixed somewhere between 1.4.19-5+lenny1 and 1.4.26. It is important because it breaks all $HTTP[url] =~ ^... checks in the config. see http://redmine.lighttpd.net/issues/show/1937, fixed in 1.4.24. If you think every bug fix is important (as obviously every bug breaks something) you probably should use the latest release. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560837: lighttpd listened on ipv6 only after upgrade
Hi, this is due to an update to netbase unstable: * Create /etc/sysctl.d/bindv6only.conf on upgrades and new installs to set net.ipv6.bindv6only=1. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560837: lighttpd listened on ipv6 only after upgrade
$SERVER[socket] == [::]:80 { }
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#598709: [pkg-lighttpd] Bug#598709: lighttpd: workaround for acrobat + msie pdf download bug
On 10/01/2010 01:53 PM, Jérémy Lal wrote: Correction : 8.2.4 is the latest of the 8.x, and is still affected. We can't ask clients to update their software, so even if it's fixed in a newer Reader, the problem will remain for years. Apache, IIS are already working around that issue, why not lighttpd ? Providing a workaround has been stupid in the first place, and it is still stupid. Why support software which hasn't been able to fix a known bug in more than 5 years? Every time you start providing such workarounds it is your fault too if the original bug doesn't get fixed! /me blames apache + IIS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#601177: [pkg-lighttpd] Bug#601177: (connections.c.1228) connection closed: poll() - ERR
On 10/24/2010 04:13 PM, Olaf van der Spek wrote: On Sun, Oct 24, 2010 at 3:58 PM, Marco d'Itrim...@linux.it wrote: On Oct 24, Olaf van der Spekolafvds...@gmail.com wrote: http://redmine.lighttpd.net/issues/2257 What that patch still be accepted into squeeze? It just suppresses the message, so I expect that it will. Are you sure? http://lists.debian.org/debian-devel-announce/2010/10/msg2.html I think you could argue that log-file spamming is a serious issue :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#603670: early kernel panic as node under kvm (div-by-zero in pvclock_tsc_khz)
Package: linux-image-2.6.32-5-amd64 Version: 2.6.32-27 Severity: important Found: linux-image-2.6.30-2-amd64/2.6.30-8squeeze1 Found: linux-image-2.6.36-trunk-amd64/2.6.36-1~experimental.1 Hi, I get an early kernel panic when i try to run testing/unstable/experimental kernels in a vm under kvm. The physical host runs 2.6.32-5-amd64, and uses qemu-kvm/0.12.5+dfsg-4 with libvirt 0.8.3-4. The stable kernel does not panic: linux-image-2.6.26-2-amd64 2.6.26-25 Example log for 2.6.32-5-amd64 (experimental has similar backtrace); the panic is caused by a div-by-zero in pvclock_tsc_khz here (v2.6.36 source): http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/x86/kernel/pvclock.c;h=239427ca02af05f8671aacaf9820aa298e94bff1;hb=f6f94e2ab1b33f0082ac22d71f66385a60d8157f#l113 [0.00] kvm-clock: cpu 0, msr 0:14f1701, boot clock PANIC: early exception 00 rip 10:8102cd63 error 0 cr2 0 [0.00] Pid: 0, comm: swapper Not tainted 2.6.32-5-amd64 #1 [0.00] Call Trace: [0.00] [814f319e] ? early_idt_handler+0x5e/0x71 [0.00] [8102cd63] ? pvclock_tsc_khz+0x13/0x2a [0.00] [81503f17] ? kvmclock_init+0x133/0x18c [0.00] [8150ccbe] ? parse_crashkernel+0x46/0x23f [0.00] [814f75f8] ? setup_arch+0x8f6/0x9cb [0.00] [811f6a9f] ? extract_entropy+0x6a/0x125 [0.00] [814f3140] ? early_idt_handler+0x0/0x71 [0.00] [814f39d0] ? start_kernel+0xdb/0x3e8 [0.00] [814f33b7] ? x86_64_start_kernel+0xf9/0x106 [0.00] RIP pvclock_tsc_khz+0x13/0x2a Regards, Stefan Loading Linux 2.6.32-5-amd64 ... Loading initial ramdisk ... [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.32-5-amd64 (Debian 2.6.32-27) (m...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Sat Oct 30 14:18:21 UTC 2010 [0.00] Command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/mapper/vg0-stefan ro single console=tty0 console=ttyS0,38400 earlyprintk=ttyS0 [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] Centaur CentaurHauls [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009f000 (usable) [0.00] BIOS-e820: 0009f000 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fffb000 (usable) [0.00] BIOS-e820: 3fffb000 - 4000 (reserved) [0.00] BIOS-e820: fffbc000 - 0001 (reserved) [0.00] bootconsole [earlyser0] enabled [0.00] DMI 2.4 present. [0.00] last_pfn = 0x3fffb max_arch_pfn = 0x4 [0.00] x86 PAT enabled: cpu 0, old 0x0, new 0x7010600070106 [0.00] init_memory_mapping: -3fffb000 [0.00] RAMDISK: 2f87f000 - 3003c109 [0.00] ACPI: RSDP 000f8830 00014 (v00 BOCHS ) [0.00] ACPI: RSDT 3fffde30 00034 (v01 BOCHS BXPCRSDT 0001 BXPC 0001) [0.00] ACPI: FACP 3e70 00074 (v01 BOCHS BXPCFACP 0001 BXPC 0001) [0.00] ACPI: DSDT 3fffdfd0 01E22 (v01 BXPC BXDSDT 0001 INTL 20090123) [0.00] ACPI: FACS 3e00 00040 [0.00] ACPI: SSDT 3fffdf90 00037 (v01 BOCHS BXPCSSDT 0001 BXPC 0001) [0.00] ACPI: APIC 3fffdeb0 00072 (v01 BOCHS BXPCAPIC 0001 BXPC 0001) [0.00] ACPI: HPET 3fffde70 00038 (v01 BOCHS BXPCHPET 0001 BXPC 0001) [0.00] No NUMA configuration found [0.00] Faking a node at -3fffb000 [0.00] Bootmem setup node 0 -3fffb000 [0.00] NODE_DATA [9000 - 00010fff] [0.00] bootmap [00011000 - 00018fff] pages 8 [0.00] (7 early reservations) == bootmem [00 - 003fffb000] [0.00] #0 [00 - 001000] BIOS data page == [00 - 001000] [0.00] #1 [006000 - 008000] TRAMPOLINE == [006000 - 008000] [0.00] #2 [000100 - 0001688414]TEXT DATA BSS == [000100 - 0001688414] [0.00] #3 [002f87f000 - 003003c109] RAMDISK == [002f87f000 - 003003c109] [0.00] #4 [09f000 - 10]BIOS reserved == [09f000 - 10] [0.00] #5 [0001689000 - 0001689071] BRK == [0001689000 - 0001689071] [0.00] #6 [008000 - 009000] PGTABLE == [008000 - 009000] [0.00] found SMP MP-table at [880f8880] f8880 [0.00] kvm-clock: cpu 0, msr 0:14f1701, boot clock PANIC: early exception 00 rip 10:8102cd63 error 0 cr2 0 [
Bug#603670: early kernel panic as node under kvm (div-by-zero in pvclock_tsc_khz)
Hi again, with qemu-kvm from experimental (0.13.0+dfsg-2) you can use: -cpu kvm64,-kvmclock as kvm option to disable kvmclock. for libvirt use the following in your domain config: domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0' ... qemu:commandline qemu:arg value='-cpu'/ qemu:arg value='kvm64,-kvmclock'/ /qemu:commandline /domain (You may have to replace kvm64 with another cpu model) I tried using clocksource= in the linux boot commandline, and had no luck with any value i tried. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#509355: cpufreqd: segfault while reading acpi battery info
The problem is that check_timeout is reset after the first battery got
updated, so the values for the second battery are never read.
This results in status-value == NULL, and strncmp segfaults.
The solution is to update check_timeout after all battery values are updated.
kind regards
Stefan
---
diff -r -u -b cpufreqd-2.3.3/src/cpufreqd_acpi_battery.c
cpufreqd-2.3.3.new/src/cpufreqd_acpi_battery.c
--- cpufreqd-2.3.3/src/cpufreqd_acpi_battery.c 2008-08-23 05:52:47.0
+0200
+++ cpufreqd-2.3.3.new/src/cpufreqd_acpi_battery.c 2008-12-23
19:39:18.850501003 +0100
@@ -325,7 +325,6 @@
/* if check_timeout is expired */
if (check_timeout = 0) {
- check_timeout = acpi_config.battery_update_interval;
if (read_battery(info[i]) == 0)
n_read++;
else
@@ -365,6 +364,11 @@
#endif
} /* end info loop */
+ /* check_timeout is global for all batteries, so update it after all
batteries got updated */
+ if (check_timeout = 0) {
+ check_timeout = acpi_config.battery_update_interval;
+ }
+
/* calculates medium battery life between all batteries */
if (total_capacity 0)
avg_battery_level = 100 * (total_remaining /
(double)total_capacity);
signature.asc
Description: This is a digitally signed message part.
Bug#515777: can spawn-fcgi.lighttpd be split to a separate package.
Hi, spawn-fcgi is now available as a separate package from http://redmine.lighttpd.net/projects/spawn-fcgi/news spawn-fcgi will be removed from the upstream lighttpd sources soon (see http://www.lighttpd.net/2009/2/16/1-4-21-yes-we-can-do-another-release) Greetings, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#527020: Problem still occurs, but cannot swap gamin for fam as it would make many packages unusable
Hi, See: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=438345 This is not a lighttpd problem - either rebuild lighty against libgamin or just ignore the warning (I think it was agreed that the warning is a false positiv). On 07/03/2010 11:28 AM, Andreas Neudecker wrote: Package: lighttpd Version: 1.4.26-3 Severity: normal As of 2010-07-03 this problem still exists in testing. I cannot use the workaround of replacing gamin by fam because I would have to remove several packages that depend on gamin. Regards Andreas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521235: [pkg-lighttpd] Bug#521235: Adding modules to server.modules not idempotent
On 07/09/2010 12:00 PM, Olaf van der Spek wrote: On Sat, Jun 26, 2010 at 7:14 PM, Josh Triplettj...@joshtriplett.org wrote: Rough recipe to reproduce: A full and minimal lighttpd.conf would be nice. Although I'm quite sure upstream will say won'tfix. :( Olaf Hi! Olaf is quite right here: as the order of the modules is important, adding modules can not be idempotent, and we therefore will not change it. Stefan (upstream dev) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521235: [pkg-lighttpd] Bug#521235: Adding modules to server.modules not idempotent
On 08/05/2010 11:26 PM, Olaf van der Spek wrote: 2010/8/5 Stefan Bühlerstbueh...@lighttpd.net: Olaf is quite right here: as the order of the modules is important, adding modules can not be idempotent, and we therefore will not change it. What happens when a module is added for the second time? I don't understand why it can't be idempotent. Olaf You think that a module-load-list (a, a, b) should be the same as (a, b) - i.e. removing duplicates But there is no good way to decide what to do with (a, b, a), as (a, b) and (b, a) are really different (order matters); and therefore we cannot make module loading idempotent. And i don't recommend loading modules in vhost configs; you really should know what modules are loaded from a look at your main config file. It is not uncommon that people with debian configs ask in #lighttpd for support and don't even know whether they use cgi or fastcgi (or think they know and are wrong)... Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521235: [pkg-lighttpd] Bug#521235: Adding modules to server.modules not idempotent
On 08/06/2010 12:04 AM, Olaf van der Spek wrote: 2010/8/6 Stefan Bühlerstbueh...@lighttpd.net: You think that a module-load-list (a, a, b) should be the same as (a, b) - i.e. removing duplicates But there is no good way to decide what to do with (a, b, a), as (a, b) and (b, a) are really different (order matters); and therefore we cannot make module loading idempotent. What about not adding a module that's in the list already? Olaf That would be deciding (a, b, a) should be (a, b). You write your replies so fast that i somehow doubt you even thought about it. If you still don't get it, ask me in irc instead of chatting here, thx. PS: Small example: server.modules += ( mod_proxy ) server.modules += ( mod_auth, mod_proxy ) - you really want mod_auth to be loaded before mod_proxy, but your algorithm would load mod_proxy before mod_auth. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#521235: [pkg-lighttpd] Bug#521235: Adding modules to server.modules not idempotent
Ok, irc makes it easier to discuss things :) We still will not make Adding modules to server.modules idempotent, but i think we fixed the core problem. The fix is to insert small check to disable loading a module twice, so you get a clean error message when you try. See rev 2751: * http://cgit.lighttpd.net/lighttpd/lighttpd-1.x/commit/?h=lighttpd-1.4.xid=614bb7538dc9bbccf4299386f8847be018f7d63d * or http://redmine.lighttpd.net/projects/lighttpd/repository/revisions/2751 Thx to Olaf for pointing that out! Good night :) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543764: Default klipperrc gets installed into the wrong directory (/etc/kde3/ instead of /etc/kde4/)
Package: klipper Version: 4:4.3.0-3 Severity: important $ dpkg -L klipper [..] /etc/kde3/klipperrc But strace shows: $ strace -e trace=open,stat klipper --nofork [..] stat(/etc/kde4/klipperrc, 0x7fff132bbd20) = -1 ENOENT (No such file or directory) [..] (And it doesn't look for the one in /etc/kde3) Workaround: copy the file either to /etc/kde4/ or ~/.kde/share/config -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#537788: [php-maint] Bug#537788: php5 + suhosin with suhosin.session.encrypt = On segfaults
seems to be gone with latest updates (5.2.10.dfsg.1-2.1), suhosin.session.encrypt can be turned on again -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554590: [Fwd: [pkg-lighttpd] Bug#554590: lighttpd_1.4.24-1(ia64/unstable): FTBFS: test failures]
See http://sourceware.org/bugzilla/show_bug.cgi?id=10162 - i think the second patch was the result of the above backtrace :) So eglibc (2.10.1-7) unstable; urgency=low probably fixed this: * patches/ia64/submitted-memchr.diff: fix memchr() when data is shorter than software pipeline. - and i verified it is the right patch. Btw, I guess you could close #534488 as invalid or whatever... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#554401: fglrx doesn't build with linux 2.6.32-rcX
Package: fglrx-driver
Version: 1:9-10-1
Hi,
fglrx doesn't build with linux 2.6.32-rcX.
#include linux/signal.h
in common/lib/modules/fglrx/build_mod/kcl_io.c fixes this - this shouldn't
hurt any older version.
I also recommend fixing some warnings, see attached patch.
commit 47332e3b1052595fc2acd0d0c1628644b0bc4837
Author: Stefan sou...@stbuehler.de
Date: Wed Nov 4 09:52:15 2009 +
debian 1:9-10-1.1
diff --git a/debian/changelog b/debian/changelog
index 77980b9..b9f1fe9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+fglrx-driver (1:9-10-1.1) unstable; urgency=low
+
+ * Non-maintainer upload.
+ * Fix compiling with 2.6.32-rc5
+ * Fix some warnings
+
+ -- Stefan Bühler sou...@stbuehler.de Wed, 04 Nov 2009 09:51:21 +
+
fglrx-driver (1:9-10-1) unstable; urgency=low
* New upstream release.
diff --git a/debian/patches/00list b/debian/patches/00list
index 9eb41a7..d0f559d 100644
--- a/debian/patches/00list
+++ b/debian/patches/00list
@@ -1,2 +1,4 @@
01-CONFIG_X86_XEN.dpatch
03-authatieventsd.sh.dpatch
+05-fix_missing_signal_include.patch
+06-fix-warnings.patch
diff --git a/debian/patches/05-fix_missing_signal_include.patch b/debian/patches/05-fix_missing_signal_include.patch
new file mode 100644
index 000..fefb83a
--- /dev/null
+++ b/debian/patches/05-fix_missing_signal_include.patch
@@ -0,0 +1,19 @@
+#!/bin/sh /usr/share/dpatch/dpatch-run
+## 05-fix_missing_signal_include.patch
+##
+## DP: Make fglrx compile with linux-2.6.32-rc5
+
+...@dpatch@
+
+diff --git a/common/lib/modules/fglrx/build_mod/kcl_io.c b/common/lib/modules/fglrx/build_mod/kcl_io.c
+index a592569..a4b4478 100755
+--- a/common/lib/modules/fglrx/build_mod/kcl_io.c
b/common/lib/modules/fglrx/build_mod/kcl_io.c
+@@ -39,6 +39,7 @@
+ #include linux/version.h
+ #include linux/autoconf.h
+ #include linux/poll.h
++#include linux/signal.h
+ #include asm/io.h
+
+ #include kcl_config.h
diff --git a/debian/patches/06-fix-warnings.patch b/debian/patches/06-fix-warnings.patch
new file mode 100644
index 000..8ef8953
--- /dev/null
+++ b/debian/patches/06-fix-warnings.patch
@@ -0,0 +1,35 @@
+#!/bin/sh /usr/share/dpatch/dpatch-run
+## 06-fix-warnings.patch
+##
+## DP: Fix some warnings
+
+...@dpatch@
+
+diff --git a/common/lib/modules/fglrx/build_mod/drm_proc.h b/common/lib/modules/fglrx/build_mod/drm_proc.h
+index dc6e1bb..b2ce017 100755
+--- a/common/lib/modules/fglrx/build_mod/drm_proc.h
b/common/lib/modules/fglrx/build_mod/drm_proc.h
+@@ -496,7 +496,7 @@ static int DRM(_vma_info)(char *buf, char **start, off_t offset, int request,
+
+ DRM_PROC_PRINT(vma use count: %d, high_memory = %p, 0x%08lx\n,
+ atomic_read(dev-vma_count),
+- high_memory, virt_to_phys(high_memory));
++ high_memory, (long unsigned int) virt_to_phys(high_memory));
+ for (pt = dev-vmalist; pt; pt = pt-next) {
+ if (!(vma = pt-vma)) continue;
+ DRM_PROC_PRINT(\n%5d 0x%08lx-0x%08lx %c%c%c%c%c%c 0x%08lx,
+diff --git a/common/lib/modules/fglrx/build_mod/firegl_public.c b/common/lib/modules/fglrx/build_mod/firegl_public.c
+index f74b2bd..cc7ae05 100755
+--- a/common/lib/modules/fglrx/build_mod/firegl_public.c
b/common/lib/modules/fglrx/build_mod/firegl_public.c
+@@ -1565,9 +1565,9 @@ void ATI_API_CALL KCL_UnmapVirtualToPhysical(KCL_PCI_DevHandle pdev, unsigned lo
+ */
+ unsigned long ATI_API_CALL KCL_MapPageToPfn(KCL_PCI_DevHandle pdev, void* page)
+ {
+-dma_addr_t bus_addr;
+ unsigned long page_index;
+ #ifdef FIREGL_DMA_REMAPPING
++dma_addr_t bus_addr;
+ bus_addr = pci_map_page ((struct pci_dev*)pdev, (struct page*)page, 0, PAGE_SIZE, PCI_DMA_BIDIRECTIONAL);
+ page_index = (bus_addr PAGE_SHIFT);
+ #else
Bug#551760: Acknowledgement (apt: Something wicked happened resolving)
Hi! @David: Small question - did you even try to reproduce it? Just do it :) I have the same problem. debootstrap, squeeze or sid; mounting some things (bind dev, some tmp filesystems, mkdir + bind /lib/init/rw/resolconf..., mount proc, mount sys, all done in a CLONE_NEWNS container to keep things clean) ping works, libnss-mdns is not installed. apt-get update (or aptitude update) doesn't work: Something wicked happened resolving 'ftp.us.debian.org:http' (-5) -5 is EAI_NODATA afaik Now i wondered why it works on my main system and couldn't find anything useful (apart from the problem that gdb didn't find the libc debug lib i installed as it did in my main system) - so i just copied /etc to the chroot, and it worked. Some straces and tries later i found the fix: just add mdns in nsswitch.conf (see below for diff). As noted above: there is no libnss-mdns installed, so i don't think it should fix problems... --- /etc/nsswitch.conf 2006-08-28 16:33:19.0 + +++ /etc.works/nsswitch.conf2009-08-11 11:56:51.0 + @@ -8,7 +8,7 @@ group: compat shadow: compat -hosts: files dns +hosts: files mdns_minimal dns mdns networks: files protocols: db files -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551760: Acknowledgement (apt: Something wicked happened resolving)
Stefan Bühler Stefan Bühler light...@stbuehler.de wrote: Hi! Some straces and tries later i found the fix: just add mdns in nsswitch.conf (see below for diff). As noted above: there is no libnss-mdns installed, so i don't think it should fix problems... Sry, i have been wrong about that. libnss-mdns was installed, just the configure wasn't successful (missing avahi) - without libnss-mdns it doesn't work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551760: Acknowledgement (apt: Something wicked happened resolving)
Hi, $ touch /etc/hosts or removing files from the hosts: line fixed the issue too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#551760: Acknowledgement (apt: Something wicked happened resolving)
Vladimir Stavrinov Vladimir Stavrinov v...@inist.ru wrote: On Wed, Oct 21, 2009 at 01:23:18AM +0200, Stefan B??hler wrote: $ touch /etc/hosts Yes, moving /etc/hosts anywhere cause resolver don't work. This problem appear on the systems with libc6 version 2.10.1-1, but not with 2.9-26. I have this problem with libc 2.9-25 and 2.10.1-1. I guess the real bug is in libc, but perhaps debootstrap could be modified to touch /etc/hosts (and fill it perhaps with some sane defaults?) Btw: Using hints.ai_flags = (AI_ADDRCONFIG); fixes the problem as long as you don't have any ipv6 address. Asking for AF_INET fixes it too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545586: imagemagick update breaks librmagick-ruby
Yes, just rebuilding the ruby library package fixed the problem for me (tried with the testing source). Thx for your work! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534488: lighttpd: Lighttpd fails to start
Hi, I think you forgot to look in your error.log: ERROR: unexpected value for key: fix-root-scriptname true (enable|disable) Disabling the server.errorlog may be helpful if you run it in foreground mode. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543480: lighttpd: FastCGI socket handling prevents php configuration changes
Hi, you are right: removing the sockets would result in lighty spawning new backends. But the problem is that php doesn't die, and if you just remove the sockets, you will just create more hanging processes. If you (or someone else who has the problem, that stopping lighty doesn't kill the spawned backends) can find out why that really could help. I always recommend spawning FastCGI backends with spawn-fcgi from supervise (daemontools) or runit; that way you can restart your applications independently. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#471325: lighttpd: Fails to start when there are dupblicate configuration variables
Hi, I disagree: setting the same option twice in one block is a fatal error. Changing the default in the source isn't a good idea either (in this case), as the perl script detects when it is safe to enable ipv6. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#483061: lighttpd doesn't like relative docroot
Hi, try: server.document-root = var.CWD + /www -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#546256: lighttpd: wrong implementation of 206 status code
Hi, I couldn't reproduce this with curl and lighttpd 1.4.23 - could you give an example? Something like the output of $ curl -r 0-1,3-4 -v http://localhost/test.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#482601: lighttpd: Fails to start at all if a FastCGI responder fails
Hi, if you don't want lighttpd to depend on your fastcgi applications, you should spawn them with supervise(daemontools)/runit + spawn-fcgi (and remove bin- path from the lighty config). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627053: approx update re-adds entry to inetd
Package: approx Version: 4.5-1+squeeze1 Severity: critical Hi, upgrading approx added the line 80 stream tcp nowait approx /usr/sbin/approx /usr/sbin/approx again to my /etc/inetd.conf, although i changed the line so it would only listen to only one ip (apache is used on the others). This breaks the unrelated web server software on the system (when the services are started in a way that allows inetd to listen before the other web servers), so i think critical is the correct severity level. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#627053: approx update re-adds entry to inetd
Hi, On 05/17/2011 02:17 PM, Eric Cooper wrote: upgrading approx added the line 80 stream tcp nowait approx /usr/sbin/approx /usr/sbin/approx again to my /etc/inetd.conf, although i changed the line so it would only listen to only one ip (apache is used on the others). Please send me the exact inetd.conf line you were using before the upgrade. well, it obviously was a different ip, but apart from that it looks like this: 192.168.0.1:80 stream tcp nowait approx /usr/sbin/approx /usr/sbin/approx -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#628934: highlight --force doesn't work
Package: highlight Version: 3.4-2+b1 Hi, highlight doesn't work with unknown languages anymore, although according to the man page --force should work. $ highlight --force config.yaml highlight: Lua error ( cannot open /usr/share/highlight/langDefs/yaml.lang: No such file or directory ) in yaml.lang -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#622733: lighttpd: binNMU for openssl 1.0.0 broke SSL support
Hi, http://redmine.lighttpd.net/issues/2306 was a duplicate of http://redmine.lighttpd.net/issues/2269, which is now the correct upstream bug. I found and fixed the problem in commit 2788: http://cgit.lighttpd.net/lighttpd/lighttpd-1.x/commit/?h=lighttpd-1.4.xid=328043caf395e40c8f544162de8965853bb0393a The problem was that we export our own md5 functions, and the symbol names conflict with those from ssl/crypt. Don't ask me why it didn't trigger when i compiled lighttpd with -O0 instead of -O2, but prefixing our functions with li_ fixed it. On 04/14/2011 01:52 PM, Arno Töll wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 tags: 622733 +upstream forwarded: 622733 http://redmine.lighttpd.net/issues/2306 owner: 622733 ! thanks It looks like lighttpd is not really compatible with new openssl. Agreed, can confirm this for the Lighttpd package as well as for upstream's trunk. The issue is tracked upstream as http://redmine.lighttpd.net/issues/2306, but might correlate with http://redmine.lighttpd.net/issues/2255 and http://redmine.lighttpd.net/issues/2246 I will keep track. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#624426: mumble-django postinst chown ignores dpkg-statoverride
Package: mumble-django Version: 2.4-3 Hi, I think running mumble-django as www-data is stupid and wrong; so I chose to spawn it with runit/spawn-fcgi as a different user: exec /usr/bin/spawn-fcgi -s /var/run/lighttpd2/mumble-django.sock -n -u mumble-server -U www-data -- /usr/share/mumble-django/mumble-django.fastcgi Unfortunately your postinst script overwrites the db permissions at every update despite my dpkg-statoverride entries: # dpkg-statoverride --list '/var/lib/mumble-django*' mumble-server mumble-server 751 /var/lib/mumble-django mumble-server mumble-server 640 /var/lib/mumble-django/mumble-django.db3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607297: cvs: violates FHS
NO I DO NOT WANT TO SETUP CVS SERVER REPOSITORIES! I just wanted to able to import cvs repos into git... That is really stupid. just split the package into client and server packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612735: imvirt misses pciutils dependency
Hi again, On 02/10/2011 12:45 PM, Thomas Liske wrote: Re, On 02/10/2011 12:21 PM, Stefan Bühler wrote: On 02/10/2011 12:16 PM, Thomas Liske wrote: Hi, IMHO imvirt should not depend on pciutils (I would prefer a Suggests or Recommends) as this might be useless for some virtualization containers. I am not sure what the goal of the project is; but if you already know which container you are on (and therefore don't install some packages needed for some detections), the detection is not that useful. imvirt is to be used on (large scale) setups with (Debian) hosts running on virtual and physical machines. With apt-dater + imvirt you are able to filter the hosts by virtualization containers and do special actions on them. Other software might use it to behave different depending on the container. Well, so i think the point of imvirt is, that it produces the expected results (detecting the correct container) in every container in every valid setup - oh sry, for xen detection you need to install 1 (or 10) other packages breaks this idea, and makes the package useless imho (as i already mentioned: if i have to know the container in order to install the correct dependencies, i don't need detection). There are also some metaphysic aspects as in Stanislaw Lem's short story Professor Corcorana’s Boxes, The Matrix and others - it tells you if you should get a red pill ;-) hehe :D - stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637444: experimental gkrellm broken by openssl split
Package: gnutls26 Version: 2.12.7-4 Manual breaks are the wrong way imho - they only protect known dependencies. Imho the gnutls library itself needs a so bump - you should never change the interface provided by a library packages, and this includes reomving libs. Yes, this means that more packages will need a binNMU. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637444: experimental gkrellm broken by openssl split
On 08/12/2011 03:15 PM, Andreas Metzler wrote: On 2011-08-11 Stefan Bühlerlight...@stbuehler.de wrote: Package: gnutls26 Version: 2.12.7-4 Manual breaks are the wrong way imho - they only protect known dependencies. We do know the packages in Debian that break. I have checked. That didn't work well, did it? gkrellm in experimental is broken now. Looking at the changelog you already had fun adding new Breaks... And i might add that it is a really closed view of the world. There are more repositories for debian packages than the official ones; nobody asks you to support them ofc, but breaking the interface of a library packages is just wrong. Imho the gnutls library itself needs a so bump - you should never change the interface provided by a library packages, and this includes reomving libs. The main gnutls API did not break. The fact thhat I ahve shipped two librariers in a single package does nor change this. Ok, the main gnutls library doesn't need a so bump, but you need a new package name. sorry for the wrong wording. There is also a question of scale. 4 packages in Debian use the openssl wrapper, 200 use gnutls proper. ametzler@argenau:~$ grep-available -FDepends -sPackage \ libgnutls26 \ | wc 202 4044355 Well, shit happens. But the reason still stands: a library *package* provides an interface, which must be binary compatible with updates. That is the point of dependencies after all. On top of that there is no reason for upstream to change the man gnults soname. It did not break. There is already another new gnutls stable release (3.0.0), it does break the API/ABI and includes a soname bump. Please also note that I have asked on Debian release ages ago whether handling the transition the way I did was ok, or whether they had better ideas. I found now the mail with your question, but there was no answer... For reference: http://lists.debian.org/debian-release/2011/03/msg00405.html I see 3 possibilities: * Rename libgnutls26 (I often saw people append c2 when sobump wasn't an option) * Provide a backported openssl wrapper in libgnutls26 * Move to the new upstream release (with sobump) asap, and hope that the broken libgnutls26 doesn't hit testing. ciao stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636339: Missing directory structure in /var/run
Package: initscripts Version: 2.88dsf-13.11 User: rle...@debian.org Usertags: run-transition Hi! Let me put this first: I think using a tmpfs for /var/run is a good idea. But I think you have to be a little bit more careful. The FHS states, that Files under this directory must be cleared (removed or truncated as appropriate) at the beginning of the boot process. And debian has always interpreted Files to mean not a directory: (from /lib/init/bootclean.sh) find . ! -xtype d ! -name utmp ! -name innd.pid -delete And so I have been using custom sub directories like /var/run/lighttpd where I put FastCGI socket files. I use 0750 www-data:root on it, so only www-data processes can see the sockets, and I would like to keep it that way. I do *not* want to put those sockets directly in /var/run, as there is no reason for others to even *see* those sockets (file permissions on the socket would still prevent unauthorized connections). I don't use init scripts, and even if i did, the runit FastCGI services might still get started before my init script. So I need a simple way to have a persistent directory tree under /var/run (I guess we can agree that writing new rcS.d scripts isn't an option). A second note: You really should think about backporting. Especially server packages are a valid target for backporting, and those often use /var/run. So i really suggest not to use /run in any source package for debian until all supported debian dists (including ubuntu) support /run, so we can still backport them. (core packages like udev can use /run ofc, backporting them is probably hell anyway :D) Btw: https://build.opensuse.org/ provides backport overlays with current debhelper releases for ubuntu, so backporting is really not that hard. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#637091: Stall while Connecting in Psi-plus and Kopete with jabberd2
Package: kopete Version: 4:4.6.5-2 Hi, kopete doesn't connect to my jabberd2 server, it hangs in the Connecting state. It claims to send some data in the xml console, but this data never reaches the network, and neither does new data i enter in the box. It works with ekg2. For more details, see the upstream bug report for iris: https://github.com/psi-im/iris/issues/4 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642563: wget needs many memory for recursive https downloads
Same here. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-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/dash Versions of packages wget depends on: ii dpkg 1.16.0.3 ii install-info 4.13a.dfsg.1-8 ii libc6 2.13-21 ii libgcrypt111.5.0-3 ii libgnutls262.12.10-2 ii libgpg-error0 1.10-1 ii libidn11 1.22-3 ii zlib1g 1:1.2.3.4.dfsg-3 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#636339: Missing directory structure in /var/run
Hi Michael, On 09/28/2011 10:22 PM, Michael Biebl wrote: Hi Stefan, a mechanism like tmpfiles.d [2] as provided by systemd would be the solution for this and we should consider making that generally usable (i.e. without a dependency on systemd). This way your package can drop a simple file in /usr/lib/tmpfiles.d or you as administrator can create a file in /etc/tmpfiles.d In your case this file would be as simple as ,--- |d /var/run/lighttpd 0750 www-data root - `--- yes, this sounds like the right solution to me if it would be provided outside from systemd, perhaps in a base package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#644227: lighttpd create-mime.assign.pl ignores ~/.mime.types
On 10/04/2011 09:29 AM, Magnus Olsson wrote: Lighttpd gets its MIME configuration from output of /usr/share/lighttpd/create-mime.assign.pl. This script only reads MIME types from /etc/mime.types. However, the mime-support package also keeps per-user MIME-types in ~/.mime.types. These are ignored in the Lighttpd configuration, even if kept in www-data home-dir. The only way to add new per-user MIME types that are also picked up by Lighttpd is through /etc/mime.types, which is not recommended. Files in /etc are there to be changed. To avoid update conflicts, the mime-support package should be fixed to either allow additional config files in /etc (like /etc/mime.types.d) or to put the current data in /usr/share, and only have custom types in /etc/mime.types. I propose that create-mime.assign.pl also reads .mime.types in the home-dir of lighttpd user (lighttpd.conf::server.username) Reading from any user home dir is certainly not an option. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#642604: lighttpd always binds to IPv6 on TCP port 80
On 10/04/2011 01:34 PM, Olaf van der Spek wrote: On Tue, Oct 4, 2011 at 1:08 PM, Adam Nielsena.niel...@shikadi.net wrote: but at least in this case the files will both be small enough that it shouldn't really be a problem in practice. Shouldn't? Really? Those qualifications indicate potential problems. Splitting lighttpd.conf makes things harder for the majority of users. For some, it might make things a little bit easier. The only conclusion I can draw is that it should not be split. I disagree. The proposed settings in platform.conf should only be changed by the package maintainers or very experienced users who know that they'll have to change many other things like logrotate, init scripts and so on, so it is ok to put them into a separate file. Oh, and btw: the config is already splitted anyway, so why do you care about another extra file? Otoh it is true that probably not all platforms would provide a similar config, so i'm not sure how useful this is for puppet users. perhaps it would be better to extract those settings from the current config (lighttpd -p -f /etc/lighttpd/lighttpd.conf | grep ... new-puppet-plaform.conf) in a puppet run. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673030: Bug 673030 still a problem?
Hi! On 06/28/2012 06:14 AM, Scott Kitterman wrote: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673030 You reported this bug at a time when Qt had been updated in Unstable to 4.8, but Sip and PyQt hadn't been updated to match. They have been now, so I expect this problem has resolved itself. Is this still and issue for you? Yes, it is working now. So this was actually a bug in the dependencies - perhaps qt was missing a so bump? While the bug looks fixed now (it doesn't crash anymore), i'm not convinced the underlying issue (that i could install incompatible versions of qt+pyqt/sip) is fixed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#679854: [lighttpd] Please assume /var/log/ can be volatile
Hi! On 07/02/2012 07:20 AM, Roman Mamedov wrote: Package: lighttpd Version: 1.4.31-1 Severity: wishlist Hello, On various embedded systems running from a flash disk with limited number of overwrite cycles it might be desirabe to mount /var/log as tmpfs, especially if long-term storage of logs is not required (but logs are still useful for immediate debugging). Currently lighttpd properly assumes that /var/run can be volatile and does this in /etc/init.d/lighttpd: Same as with /var/run/lighttpd, i think it is stupid if every init script tries to solve this itself. (See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=636339) With /var/log/lighttpd this probably isn't a big problem, as only lighttpd is using it if it is a tmpfs directory, but for /var/run/lighttpd other processes (externally spawned fastcgi) will need the directory too, and the init script is the wrong place creating it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#675801: BaseTsd.h not found - case sensitive problems
Package: gcc-mingw-w64-i686
Version: 4.6.3-5+6
$ printf '#include BaseTsd.h\nint main() { return 0; }\n' |
i686-w64-mingw32-gcc -o /dev/stdout -E -
# 1 stdin
# 1 built-in
# 1 command-line
# 1 stdin
stdin:1:21: fatal error: BaseTsd.h: No such file or directory
compilation terminated.
Same problem with x86_64-w64-mingw32-gcc; basetsd.h works, but according to
my windows box BaseTsd.h is the correct name.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673522: unshare NEWNET + using sockets from before: unregister_netdevice: waiting for lo to become free. Usage count = 2
Package: linux-image-3.2.0-2-amd64
Version: 3.2.16-1
Hi,
CLONE_NEWNET is still buggy (i found random reports with the same error message
from 2010).
uname: Linux * 3.2.0-2-amd64 #1 SMP Mon Apr 30 05:20:23 UTC 2012 x86_64
GNU/Linux
See the attached example.
I don't think it matters much how the socket is used: just create the socket
before the unshare and use it somehow - listen() after unshare() triggered it
too.
The kernel starts spamming the message after the program is terminated.
Also the port is not reachable from the outside - although i admit i couldn't
find docs mentioning this is supported, but it really should be.
(Given that struct net is part of struct sock(common) this shouldn't be hard)
I could reproduce it in virtualbox with rescue mode from
http://cdimage.debian.org/cdimage/wheezy_di_alpha1/amd64/iso-cd/debian-wheezy-DI-a1-amd64-netinst.iso
- when i started it a second time the process would even hang for some time
(not killable).
logs look like this:
[ 796.444219] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 806.684213] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 816.924212] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 827.164217] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 837.408237] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 847.648216] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 857.888219] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 868.128224] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 878.368221] unregister_netdevice: waiting for lo to become free. Usage count
= 2
[ 888.608215] unregister_netdevice: waiting for lo to become free. Usage count
= 2
#define _GNU_SOURCE
#include sched.h
#include stdio.h
#include stdlib.h
#include strings.h
#include sys/socket.h
#include sys/types.h
#include netinet/in.h
#include netinet/ip.h
int main() {
int listenfd, acceptfd, connectfd;
struct sockaddr_in addr;
socklen_t addrlen = sizeof(addr);
puts(newnet + listen/connect test);
if (-1 == (listenfd = socket(AF_INET, SOCK_STREAM, 0))) { perror(socket failed); abort(); }
if (0 != listen(listenfd, 1)) { perror(listen failed); abort(); }
if (0 != unshare(CLONE_NEWNET)) { perror(unshare failed); abort(); }
if (0 != getsockname(listenfd, (struct sockaddr*) addr, addrlen)) { perror(getsockname failed); }
if (-1 == (connectfd = socket(AF_INET, SOCK_STREAM, 0))) { perror(socket failed); abort(); }
if (0 == connect(connectfd, (struct sockaddr*) addr, addrlen)) {
puts(successful connect - something is wrong here);
} else {
perror(connect failed as expected);
}
close(connectfd);
printf(listening on 0.0.0.0:%i\n, (int) addr.sin_port);
if (-1 == (acceptfd = accept(listenfd, NULL, NULL))) { perror(accept failed); abort(); }
{
char buf[1024];
int len = read(acceptfd, buf, sizeof(buf)-1);
if (len 0) { perror(read failed); abort(); }
buf[len] = 0;
printf(received: '%s'\n, buf);
write(acceptfd, buf, len);
close(acceptfd);
}
puts(done.);
}
Bug#671740: pam_userdb only supports basic crypt with 2 character salt
Package: libpam-modules
Version: 1.1.3-7
pam_userdb should at least support the platform crypt() algorithms;
ideally it should support the same set as pam_unix.
Patch for the first part is attached (works for me with cups on kfreebsd).
It would also be nice to have a tool to generate the hashes
(i wrote my own mkcrypt now...).
--- pam-1.1.3.orig/modules/pam_userdb/pam_userdb.c 2010-05-27 14:49:23.0 +0200
+++ pam-1.1.3/modules/pam_userdb/pam_userdb.c 2012-05-06 13:28:35.0 +0200
@@ -214,17 +214,11 @@
/* crypt(3) password storage */
char *cryptpw;
- char salt[2];
- if (data.dsize != 13) {
- compare = -2;
- } else if (ctrl PAM_ICASE_ARG) {
+ if (ctrl PAM_ICASE_ARG) {
compare = -2;
} else {
- salt[0] = *data.dptr;
- salt[1] = *(data.dptr + 1);
-
- cryptpw = crypt (pass, salt);
+ cryptpw = crypt (pass, data.dptr);
if (cryptpw) {
compare = strncasecmp (data.dptr, cryptpw, data.dsize);
Bug#644912: ipv6 link-local doesn't work as lookup doesn't set scope id
Package: libnss-mdns Tags: ipv6 Version: 0.10-3.2 Hi, libnss-mdns doesn't set the scope-id for link-local addresses, so something like $ ping6 example.local gives connect: Invalid argument while $ getent host example.local returns a valid link-local IPv6 address (fe80::...) and $ ping6 fe80::...%eth0 works fine. I sent this nearly 2 years ago upstream per mail, but never got a response, and i couldn't find an upstream bug tracker. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#692317: dh-autoreconf_clean deletes unrelated files (due to spaces?)
Hi, I think you're right - the spaces in the filenames lead to problems: dh_autoreconf_clean uses the perl split function to split the lines into checksum and filename: * a comment says the delimiter is comma, which is wrong: there are two spaces between checksum and filename * split splits by default at /\s+/ - and returns as many components it finds Fix it by replacing *both* split calls with: my ($checksum, $filename) = split(/\s+/, $_, 2); It uses the same delimiter, but only splits at the first one (returning at most two parts). (Also you probably should fix the comment) @Paul: I couldn't completely check whether my fix works, because I didn't want to install the dependencies. Also shallow git clone doesn't work, as it is probably stored as one index file which gets downloaded completely. regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#683619: NBD lockup with segfaulting qemu-nbd
Package: linux-image-3.2.0-3-amd64 Version: 3.2.21-3 Hi, i tried to get https://github.com/asb/spindle running, but in ./wheezy-stage0 mkfs hangs forever. kill -9 doesn't work on mkfs and qemu-nbd, and i can't attach with strace (at least i can kill strace). I guess qemu-nbd shouldn't segfault in the first place, but the kernel should handle this better. qemu-nbd -d (disconnect) doesn't work (and can't be killed either). USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND root 5206 0.0 0.0 129644 2384 ?Dsl 10:29 0:00 qemu-nbd --nocache -c /dev/nbd0 /.../spindle/work/wheezy_apt_cache.qed root 9504 0.0 0.1 96460 6524 pts/4D+ 10:35 0:00 qemu-nbd -d /dev/nbd0 [ 4353.088802] nbd0: unknown partition table [ 4358.345650] qemu-nbd[5206]: segfault at 0 ip 7fd160ea20b8 sp 7fd160e32cc0 error 4 in qemu-nbd[7fd160e55000+6d000] [ 4358.345694] nbd (pid 5209: qemu-nbd) got signal 9 [ 4560.732316] INFO: task qemu-nbd:5206 blocked for more than 120 seconds. [ 4560.732321] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 4560.732324] qemu-nbdD 88009c63f8d0 0 5206 1 0x [ 4560.732330] 88009c63f8d0 0082 88009c63f918 88011aee87b0 [ 4560.732336] 00013740 8800b6df9fd8 8800b6df9fd8 88009c63f8d0 [ 4560.732341] 88011fd137b0 88011fd13740 8801164fc830 7fff [ 4560.732347] Call Trace: [ 4560.732356] [81349d2e] ? schedule_timeout+0x2c/0xdb [ 4560.732362] [8103f47f] ? try_to_wake_up+0x187/0x197 [ 4560.732366] [81349974] ? wait_for_common+0xa0/0x119 [ 4560.732370] [8103f48f] ? try_to_wake_up+0x197/0x197 [ 4560.732375] [810ff18c] ? do_coredump+0x2b5/0xab9 [ 4560.732380] [8107072d] ? arch_local_irq_save+0x11/0x17 [ 4560.732384] [8134abd4] ? _raw_spin_lock_irqsave+0x9/0x25 [ 4560.732388] [8103f47f] ? try_to_wake_up+0x187/0x197 [ 4560.732393] [81053d3b] ? __dequeue_signal+0xca/0xf4 [ 4560.732397] [81053bd8] ? recalc_sigpending+0x23/0x3c [ 4560.732402] [81055baf] ? get_signal_to_deliver+0x464/0x48f [ 4560.732407] [81343a19] ? force_sig_info_fault+0x5b/0x63 [ 4560.732413] [8100de33] ? do_signal+0x38/0x610 [ 4560.732417] [8103f48f] ? try_to_wake_up+0x197/0x197 [ 4560.732422] [810fa727] ? fget_light+0x5f/0x73 [ 4560.732427] [8100e441] ? do_notify_resume+0x25/0x68 [ 4560.732431] [8134afbc] ? retint_signal+0x48/0x8c [ 4560.732435] INFO: task qemu-nbd:5207 blocked for more than 120 seconds. [ 4560.732438] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 4560.732441] qemu-nbdD 88011aee87b0 0 5207 1 0x [ 4560.732445] 88011aee87b0 0082 8801164fc140 [ 4560.732451] 00013740 8800d81fdfd8 8800d81fdfd8 88011aee87b0 [ 4560.732456] 88011aee87b0 8800d825f080 88011aee87b0 88011aee87b0 [ 4560.732461] Call Trace: [ 4560.732466] [8104986f] ? exit_mm+0x97/0x122 [ 4560.732471] [81049b40] ? do_exit+0x246/0x6fc [ 4560.732475] [8104a276] ? do_group_exit+0x74/0x9e [ 4560.732479] [81055bb8] ? get_signal_to_deliver+0x46d/0x48f [ 4560.732484] [8100de33] ? do_signal+0x38/0x610 [ 4560.732489] [81037ec0] ? set_next_entity+0x32/0x55 [ 4560.732493] [8100d025] ? paravirt_write_msr+0xb/0xe [ 4560.732497] [8100d6f1] ? __switch_to+0x181/0x258 [ 4560.732503] [8106f2f9] ? sys_futex+0x138/0x147 [ 4560.732507] [8100e441] ? do_notify_resume+0x25/0x68 [ 4560.732512] [8134fe60] ? int_signal+0x12/0x17 [ 4560.732515] INFO: task qemu-nbd:5208 blocked for more than 120 seconds. [ 4560.732518] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 4560.732521] qemu-nbdD 8801164fc140 0 5208 1 0x [ 4560.732526] 8801164fc140 0082 8801164fc830 [ 4560.732531] 00013740 8800d4235fd8 8800d4235fd8 8801164fc140 [ 4560.732536] 8801164fc140 8800d825f080 8801164fc140 8801164fc140 [ 4560.732542] Call Trace: [ 4560.732546] [8104986f] ? exit_mm+0x97/0x122 [ 4560.732550] [81049b40] ? do_exit+0x246/0x6fc [ 4560.732555] [8104a276] ? do_group_exit+0x74/0x9e [ 4560.732559] [81055bb8] ? get_signal_to_deliver+0x46d/0x48f [ 4560.732564] [8100de33] ? do_signal+0x38/0x610 [ 4560.732569] [8106f2f9] ? sys_futex+0x138/0x147 [ 4560.732573] [8100e441] ? do_notify_resume+0x25/0x68 [ 4560.732577] [8134fe60] ? int_signal+0x12/0x17 [ 4560.732581] INFO: task qemu-nbd:5209 blocked for more than 120 seconds. [ 4560.732583] echo 0 /proc/sys/kernel/hung_task_timeout_secs disables this message. [ 4560.732586] qemu-nbdD 88011fd13740 0 5209
Bug#613116: libev-dev: c++ compilation problem
Hi, looks like it got fixed: http://cgit.lighttpd.net/libev.git/commit/ev++.h?id=0c56dcc65f038fe37c790397251f1317aed7539c Don't ask me how to look that up in the upstream cvs :P And ofc no commit message, as usual. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684902: libev_4.11.orig.tar.gz has different size than upstream libev-4.11.tar.gz
Package: libev Version: 1:4.11-1 And as there is no difference i see no reason why you would repackage it... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#684902: libev_4.11.orig.tar.gz has different size than upstream libev-4.11.tar.gz
On 08/14/2012 05:23 PM, Jérémy Lal wrote: On 14/08/2012 16:15, Stefan Bühler wrote: Package: libev Version: 1:4.11-1 And as there is no difference i see no reason why you would repackage it... Maybe git-buildpackage (i.e. pristine-tar) is responsible of that ? Jérémy. git import-orig --pristine-tar ../libev-4.11.tar.gz pristine-tar checkout libev_4.11.orig.tar.gz worked for me. perhaps you forgot the --pristine-tar option? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#663678: icinga-idoutils fails to start if socket file exists
Package: icinga-idoutils Version: 1.6.1-2 Severity: serious Reproduce: # /etc/init.d/ido2db stop # touch /var/lib/icinga/ido.sock # /etc/init.d/ido2db start Could not bind socket: Address already in use (or just powercycle your box...) You should unlink the old socket file before you try to bind; if you want you can check whether the file is an active socket by connecting to it. (An ugly workaround would be to just delete the file in the init script if no ido2db process is running) I think this is a serious bug, as the service really should come back after a box crashed. Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#641684: Quote character not escaped correctly for Postgresql
severity 641684 grave thanks This bug makes the package unusable unless the mentioned workarounds are applied, as it doesn't work with the default postgres server on wheezy (9.1 right now). Even with the workaround applied the log gets spammed: 2012-03-13 10:33:51 UTC WARNING: nonstandard use of \' in a string literal at character 100 2012-03-13 10:33:51 UTC HINT: Use '' to write quotes in strings, or use the escape string syntax (E'...'). The upstream bug https://dev.icinga.org/issues/1974 looks fixed now. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660806: libdispatch0 uses SSE2 instructions
Package: libdispatch0 Severity: serious libdispatch0 uses SSE2 instructions (MFENCE) which are not available on a Pentium 3. According to http://www.debian.org/releases/stable/i386/ch02s01.html.en Pentium 3 has to be supported; so at least the user should get more than a Illegal instruction error message. Both stable and testing are affected (tested with forked-daapd from testing). gdb with version from stable: Program received signal SIGILL, Illegal instruction. 0xb6d4ef9c in dispatch_once_f () from /usr/lib/libdispatch.so.0 (gdb) bt #0 0xb6d4ef9c in dispatch_once_f () from /usr/lib/libdispatch.so.0 #1 0xb6d5021f in _dispatch_continuation_alloc_from_heap () from /usr/lib/libdispatch.so.0 #2 0xb6d4f621 in ?? () from /usr/lib/libdispatch.so.0 #3 0xb6d4f5fa in dispatch_async_f () from /usr/lib/libdispatch.so.0 #4 0xb6d4f57c in dispatch_async () from /usr/lib/libdispatch.so.0 #5 0x0804faaa in ?? () #6 0xb6bf0e46 in __libc_start_main () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #7 0x0804f0a1 in ?? () (gdb) disassemble Dump of assembler code for function dispatch_once_f: [...] 0xb6d4ef9c dispatch_once_f+76:mfence [...] End of assembler dump. gdb with version from testing: Program received signal SIGILL, Illegal instruction. 0xb6d50ed1 in dispatch_once_f () from /usr/lib/libdispatch.so.0 (gdb) bt #0 0xb6d50ed1 in dispatch_once_f () from /usr/lib/libdispatch.so.0 #1 0xb6d51858 in ?? () from /usr/lib/libdispatch.so.0 #2 0xb6d51809 in dispatch_async_f () from /usr/lib/libdispatch.so.0 #3 0xb6d51767 in dispatch_async () from /usr/lib/libdispatch.so.0 #4 0x0804faaa in ?? () #5 0xb6bf2e46 in __libc_start_main () from /lib/i386-linux-gnu/i686/cmov/libc.so.6 #6 0x0804f0a1 in ?? () (gdb) disassemble Dump of assembler code for function dispatch_once_f: [...] 0xb6d50ed1 dispatch_once_f+49:mfence [...] End of assembler dump. # cat /proc/cpuinfo processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 7 model name : Pentium III (Katmai) stepping: 2 cpu MHz : 451.094 cache size : 512 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pse36 mmx fxsr sse up bogomips: 902.18 clflush size: 32 cache_alignment : 32 address sizes : 36 bits physical, 32 bits virtual power management: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi Michael, i have a small question: is systemd still needed for /etc/tmpfiles.d/lighttpd.conf ? If yes i think it should *not* be used, as it only works if you are using systemd, which is a wrong dependency here - it must work with all init systems (see #636339). The /lib/systemd/system/lighttpd.service looks simple enough that i might include it upstream (if you don't see any problem with that). Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi Michael, On 12/17/2011 01:12 PM, Michael Stapelberg wrote: Hi Stefan, Excerpts from Stefan Bühler's message of 2011-12-17 11:59:13 +: I’m not sure why providing this file would add a dependency on systemd: • If the user uses sysvinit, the init-script will create the folder. • If the user uses systemd, its tmpfiles.d-mechanism will create the folder. So, this seems like a completely different problem to me. Could you elaborate? And if a different sysvinit script, that uses the same directory for temporary sockets for example like php-fpm, runs before the lighttpd one, the directory is missing, and it will fail. Of course you could add more dependencies and so on, but this is just the wrong way to ensure a directory exists. IMO, if a script / program relies on some directory being there, it has to create it. Or, if it should be created by some other program earlier in the boot sequence, the script / program clearly should have a dependency on the other program. Why do you think this is the wrong way? :) If i (as user) configure php-fpm to use that directory (by setting the socket paths), i need an easy way to make sure it exists. same problem if i'd be using /var/run/php-fpm/..., but it makes sense to put all sockets that are going to be used by lighttpd in /var/run/lighttpd/, and seeing that /var/run/lighttpd/ already exists, why would I ever think using that directory might be a problem? And there is no need to run lighttpd - perhaps sometimes you only want to run the backend (parallel start for example), so a runtime dependency is wrong too. And there should be only one place that creates the directory, and it should be easily configurable (+1 for /etc/tmpfiles.d/) (Imho the core system should manage this automatically for all directories that are installed from packages in /var/run/ to ensure old packages keep working; configuring it with dpkg-statoverride as always). Don't get me wrong: I actually like the tmpfiles.d thing. I just think it needs a more generic handling than systemd, iow all init systems must create those directories before doing anything else (well, after mounting /run ofc). Right, I basically agree, but I don’t see why that prevents you from adding the file *without* touching the existing init structure? I mean, the existing init-script is either working or broken, but adding the tmpfiles.d/lighttpd.conf will not change that. However, when adding lighttpd.service, we must also add tmpfiles.d/lighttpd.conf, otherwise we introduced a regression. hm, right. the debian init script creates that directory (and overwrites permissions, very bad style). It still is just an ugly workaround, and i'd like to see a proper fix for it, not more workarounds. Now i have two questions for the systemd service itself :) a) ExecStartPre - is that useful? lighttpd -t only checks the basic syntax, not whether the config options actually exist or whether they have the right structure (strings, ints, bools, lists of ...) and so on. IMO, more checks are always useful. The systemd service file only reflects the current behavior of the init script, which does not check for the existence of /etc/lighttpd/lighttpd.conf either. If you want to check that, use the following line in the [Unit] section: ConditionPathExists=/etc/lighttpd/lighttpd.conf Hm. I think is isn't worth it to check for the syntax. You don't gain much from it, but you might end up paying too much for it (running all the include_shell things and so on). I guess ExecStartPre is always called before starting the service, right? b) SIGHUP only reopens the log files, it does not reload the config. Is this the right thing for ExecReload? Hm, to quote systemctl(1): Asks all units listed on the command line to reload their configuration. Note that this will reload the service-specific configuration, not the unit configuration file of systemd. If you want systemd to reload the configuration file of a unit use the daemon-reload command. In other words: for the example case of Apache, this will reload Apache's httpd.conf in the web server, not the apache.service systemd unit file. So, providing SIGHUP as reload-action is a misnomer, since it doesn’t actually reload the service-specific configuration. However (!), since the command '/etc/init.d/lighttpd reload' will effectively invoke 'systemctl reload lighttpd.service' when using systemd, we should probably keep it to stay backwards-compatible. I could imagine scripts using /etc/init.d/lighttpd reload after rotating the logfiles…? (The cleaner way would be to use systemctl kill --signal=SIGHUP lighttpd.service in those scripts, but I think staying backwards-compatible is more important right now.) Actually, the init script was changed, and reload does a restart now. reopen-logs is used for sending HUP. regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of
Bug#652442: lighttpd: please include systemd service file
Hi Michael, On 12/17/2011 12:27 PM, Michael Stapelberg wrote: Hi Stefan, Thanks for your quick reply. Excerpts from Stefan Bühler's message of 2011-12-17 11:18:14 +: is systemd still needed for /etc/tmpfiles.d/lighttpd.conf ? If yes i think it should *not* be used, as it only works if you are using systemd, which is a wrong dependency here - it must work with all init systems (see #636339). I’m not sure why providing this file would add a dependency on systemd: • If the user uses sysvinit, the init-script will create the folder. • If the user uses systemd, its tmpfiles.d-mechanism will create the folder. So, this seems like a completely different problem to me. Could you elaborate? And if a different sysvinit script, that uses the same directory for temporary sockets for example like php-fpm, runs before the lighttpd one, the directory is missing, and it will fail. Of course you could add more dependencies and so on, but this is just the wrong way to ensure a directory exists. And as php-fpm wouldn't default to that path, but a user might want to use that path for additional security (so users can't list all sockets), the distribution provided files won't have a dependency, and the user probably won't get it right. Don't get me wrong: I actually like the tmpfiles.d thing. I just think it needs a more generic handling than systemd, iow all init systems must create those directories before doing anything else (well, after mounting /run ofc). The /lib/systemd/system/lighttpd.service looks simple enough that i might include it upstream (if you don't see any problem with that). Cool, feel free to do that. I didn’t send an email with an upstream inclusion request since it seems like lighttpd doesn’t ship an init-file either, but providing that file is definitely a good thing for other distributions. I think we actually ship some init scripts, but they depend on the distribution you are using. The systemd service looks simple enough that it should work on all dists. Now i have two questions for the systemd service itself :) a) ExecStartPre - is that useful? lighttpd -t only checks the basic syntax, not whether the config options actually exist or whether they have the right structure (strings, ints, bools, lists of ...) and so on. b) SIGHUP only reopens the log files, it does not reload the config. Is this the right thing for ExecReload? Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi, i committed the systemd/lighttpd.service file in r2818. I won't add the tmpfiles config upstream, as i think this should be handled by the distributions. Regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#652442: lighttpd: please include systemd service file
Hi Michael, On 12/18/2011 04:29 PM, Michael Stapelberg wrote: Excerpts from Stefan Bühler's message of 2011-12-18 15:19:14 +: I won't add the tmpfiles config upstream, as i think this should be handled by the distributions. So, every distribution now has to ship an identical tmpfiles.d/lighttpd.conf and be aware that it is missing? I don’t get the rationale behind this decision. Every distribution which picks up the lighttpd.service *needs* a file like this, since systemd expects /run on tmpfs. There is no need for a (/var)/run/lighttpd/ directory - the pid file is placed directly in (/var)/run, and the sockets are placed wherever the user wants them to be. The upstream config examples don't contain any reference to (/var)/run/lighttpd/, so i see no reason to add a tmpfile here (neither are our init script examples creating that directory). As soon as there is a sane tmpfiles.d approach, we can discuss actually using it in our config examples. (afaik the debian configs contain a /var/run/lighttpd/ reference only in mod_webdav.conf, which could be modified to use /var/run easily) regards, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#668617: PXE Boot kfreebsd-9 broken
Package: debian-installer Hi, The grub.cfg for kfreebsd-9 is broken: (http://d-i.debian.org/daily-images/kfreebsd-i386/daily/netboot-9/debian-installer/kfreebsd-i386/grub.cfg) It uses $prefix/kfreebsd.gz as kernel, but the kernel is named kfreebsd-9.gz (Perhaps other kfreebsd-9 images have the same problem) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666948: tangerine doesn't work on Debian/kfreebsd
Package: tangerine
Version: 0.3.4-3
Hi,
tangerine doesn't run as the inotify lib isn't available (i can't
even build it on testing).
The easiest way is to build a stub lib which returns -1 in the init
function (no other functions need apparently).
The attached patch can probably be done in a better way, but it is
at least easy to understand :)
tangerine-properties doesn't work out of the box either, but this
is probably a bug in libglade2.0-cil, as it doesn't depend on
libglade2-0 on kfreebsd. (aptitude install libglade2-0 fixes it)
# mono --debug /usr/lib/tangerine/tangerine-properties.exe
Unhandled Exception: System.DllNotFoundException: libglade-2.0.so.0
at (wrapper managed-to-native) Glade.XML:glade_xml_new_from_buffer
(byte[],int,intptr,intptr)
at Glade.XML..ctor (System.Reflection.Assembly assembly, System.String
resource_name, System.String root, System.String domain) [0x0] in filename
unknown:0
at Glade.XML..ctor (System.String resource_name, System.String root)
[0x0] in filename unknown:0
at Tangerine.PropertiesWindow..ctor () [0x00040] in
/root/src/tangerine-0.3.4/TangerineProperties/src/PropertiesWindow.cs:103
at Tangerine.EntryPoint.Main () [0xf] in
/root/src/tangerine-0.3.4/TangerineProperties/src/PropertiesWindow.cs:31
[ERROR] FATAL UNHANDLED EXCEPTION: System.DllNotFoundException:
libglade-2.0.so.0
at (wrapper managed-to-native) Glade.XML:glade_xml_new_from_buffer
(byte[],int,intptr,intptr)
at Glade.XML..ctor (System.Reflection.Assembly assembly, System.String
resource_name, System.String root, System.String domain) [0x0] in filename
unknown:0
at Glade.XML..ctor (System.String resource_name, System.String root)
[0x0] in filename unknown:0
at Tangerine.PropertiesWindow..ctor () [0x00040] in
/root/src/tangerine-0.3.4/TangerineProperties/src/PropertiesWindow.cs:103
at Tangerine.EntryPoint.Main () [0xf] in
/root/src/tangerine-0.3.4/TangerineProperties/src/PropertiesWindow.cs:31
Description: Build stub lib if inotify isn't available
Index: tangerine-0.3.4/libtangglue/Makefile.am
===
--- tangerine-0.3.4.orig/libtangglue/Makefile.am 2012-04-02 22:02:48.0 +0200
+++ tangerine-0.3.4/libtangglue/Makefile.am 2012-04-02 22:03:49.0 +0200
@@ -1,10 +1,12 @@
-if HAVE_INOTIFY
-
INCLUDES = -I$(top_srcdir)
AM_CFLAGS = -DG_LOG_DOMAIN=\libtangglue\ \
$(LIBTANGGLUE_CFLAGS)
+if !HAVE_INOTIFY
+AM_CFLAGS += -DINOTIFY_STUB=1
+endif
+
gluelibdir = $(pkglibdir)
gluelib_LTLIBRARIES = libtangglue.la
@@ -18,5 +20,3 @@
maintainer-clean-local:
rm -f Makefile.in
-
-endif
\ No newline at end of file
Index: tangerine-0.3.4/libtangglue/src/inotify-glue.c
===
--- tangerine-0.3.4.orig/libtangglue/src/inotify-glue.c 2012-04-02 22:02:48.0 +0200
+++ tangerine-0.3.4/libtangglue/src/inotify-glue.c 2012-04-02 22:02:48.0 +0200
@@ -27,6 +27,8 @@
* DEALINGS IN THE SOFTWARE.
*/
+#ifndef INOTIFY_STUB
+
#include stdio.h
#include stdlib.h
#include fcntl.h
@@ -217,3 +219,13 @@
*buffer_out = buffer;
}
+
+#else
+
+int
+inotify_glue_init (void)
+{
+ return -1;
+}
+
+#endif
Bug#666949: amarok doesn't work with tangerine
Package: tangerine
Version: 0.3.4-3
Hi again,
this is probably a bug in amarok...
amarok doesn't send a session id for the sound files (and doesn't
support login with password ofc); so as a workaround one can allow
requests without session id if there is no session limit and no
authentication required.
--- a/daap-sharp/src/Server.cs
+++ b/daap-sharp/src/Server.cs
@@ -667,8 +667,10 @@
if (!sessions.ContainsKey (session) path != /server-info path != /content-codes
path != /login) {
-ws.WriteResponse (client, HttpStatusCode.Forbidden, invalid session id);
-return true;
+if (serverInfo.AuthenticationMethod != AuthenticationMethod.None || maxUsers 0) {
+ws.WriteResponse (client, HttpStatusCode.Forbidden, invalid session id);
+return true;
+}
}
if (session != 0) {
Bug#670412: geli init script fails if /etc/default/geli is unconfigured
Package: geom Version: 9.0+ds1-3 The geli init script fails if no geli devices are configured in /etc/fstab and /etc/default/geli. This prevented an upgrade of geom and freebsd-geom: [...] Setting up geom (9.0+ds1-3) ... Starting GELI subsystem...UNCONFIGURED. See /etc/default/geli ... failed! invoke-rc.d: initscript geli, action start failed. dpkg: error processing geom (--configure): subprocess installed post-installation script returned error exit status 1 configured to not write apport reports dpkg: dependency problems prevent configuration of freebsd-geom: freebsd-geom depends on geom; however: Package geom is not configured yet. dpkg: error processing freebsd-geom (--configure): dependency problems - leaving unconfigured [...] As geom contains more than just geli it is imho wrong to print an error (warning is fine ofc), but it certainly is wrong to fail the init script. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696752: segfault in ruby-taglib2, need FTBFS fix
Package: ruby-taglib2 Version: 0.1.3-1 Severity: important Environment: kFreeBSD (9.0.2-amd64) file_alloc sets data-closed=0; but doesn't set data-file=NULL. This means that free_tgFileData (the ruby data destructor) can fail, if init failed (which would set data-file in case of success). version 0.1.5-1 fixes it by setting data-closed (in _alloc and _init), although it still doesn't clear data-file in _alloc (not required, but should be done anyway imho). I triggered the segfault by running https://github.com/stbuehler/media-player-indexer (the update script) on about 6000 files; not all were media files (.m3u files for example). The backtrace didn't contain anything useful apart from what i described above - data-closed was 0, and data-file was an invalid C++ object (the virtual-table pointer was 0). Other issues: * fix the clean rules. debian/clean doesn't delete directories, use override_dh_clean: dh_clean; rm -rf tests/tmp instead. * somehow the write for f.save gets delayed partially (ktrace). calling f.save twice in tests/file.rb fixes the checks, don't ask me why (sleep doesn't work, so not a timing issue). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673030: plasma-desktop segfault (in python-kde/pythin-sip)
Package: plasma-desktop Version: 4:4.7.4-2+b1 Versions of: python-sip: 4.13.2-1 python-kde4: 4:4.7.4-2+b1 python-qt4: 4.9.1-3 Moving /usr/lib/python2.7/dist-packages/sip.so to /usr/lib/python2.7/dist-packages/sip.so.bak fixed it. Application: Plasma Desktop Shell (plasma-desktop), signal: Segmentation fault Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [KCrash Handler] #6 0x7f4b2f6ca388 in ?? () from /usr/lib/python2.7/dist-packages/sip.so #7 0x7f4b2f6ca698 in ?? () from /usr/lib/python2.7/dist-packages/sip.so #8 0x7f4b2e1d52bc in initkdecore () from /usr/lib/python2.7/dist-packages/PyKDE4/kdecore.so #9 0x7f4b3061cbd5 in _PyImport_LoadDynamicModule () from /usr/lib/libpython2.7.so.1.0 #10 0x7f4b306c1fac in ?? () from /usr/lib/libpython2.7.so.1.0 #11 0x7f4b306963d2 in ?? () from /usr/lib/libpython2.7.so.1.0 #12 0x7f4b306c2604 in ?? () from /usr/lib/libpython2.7.so.1.0 #13 0x7f4b306bc07a in PyImport_ImportModuleLevel () from /usr/lib/libpython2.7.so.1.0 #14 0x7f4b305b3ebf in ?? () from /usr/lib/libpython2.7.so.1.0 #15 0x7f4b306a9773 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0 #16 0x7f4b306aa2db in ?? () from /usr/lib/libpython2.7.so.1.0 #17 0x7f4b3063ab1e in PyObject_CallFunction () from /usr/lib/libpython2.7.so.1.0 #18 0x7f4b3061d30d in PyImport_Import () from /usr/lib/libpython2.7.so.1.0 #19 0x7f4b3061e6bc in PyImport_ImportModule () from /usr/lib/libpython2.7.so.1.0 #20 0x7f4b2f6c0e42 in ?? () from /usr/lib/python2.7/dist-packages/sip.so #21 0x7f4b2e969107 in initplasma () from /usr/lib/python2.7/dist-packages/PyKDE4/plasma.so #22 0x7f4b3061cbd5 in _PyImport_LoadDynamicModule () from /usr/lib/libpython2.7.so.1.0 #23 0x7f4b306c1fac in ?? () from /usr/lib/libpython2.7.so.1.0 #24 0x7f4b306963d2 in ?? () from /usr/lib/libpython2.7.so.1.0 #25 0x7f4b306c2604 in ?? () from /usr/lib/libpython2.7.so.1.0 #26 0x7f4b306bc07a in PyImport_ImportModuleLevel () from /usr/lib/libpython2.7.so.1.0 #27 0x7f4b305b3ebf in ?? () from /usr/lib/libpython2.7.so.1.0 #28 0x7f4b306a9773 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0 #29 0x7f4b306aa0c7 in PyEval_CallObjectWithKeywords () from /usr/lib/libpython2.7.so.1.0 #30 0x7f4b305ffc62 in PyEval_EvalFrameEx () from /usr/lib/libpython2.7.so.1.0 #31 0x7f4b305b88b5 in PyEval_EvalCodeEx () from /usr/lib/libpython2.7.so.1.0 #32 0x7f4b305b8be2 in PyEval_EvalCode () from /usr/lib/libpython2.7.so.1.0 #33 0x7f4b305ba282 in PyImport_ExecCodeModuleEx () from /usr/lib/libpython2.7.so.1.0 #34 0x7f4b306c184e in ?? () from /usr/lib/libpython2.7.so.1.0 #35 0x7f4b306c1fac in ?? () from /usr/lib/libpython2.7.so.1.0 #36 0x7f4b306963d2 in ?? () from /usr/lib/libpython2.7.so.1.0 #37 0x7f4b306c25bf in ?? () from /usr/lib/libpython2.7.so.1.0 #38 0x7f4b306bc07a in PyImport_ImportModuleLevel () from /usr/lib/libpython2.7.so.1.0 #39 0x7f4b305b3ebf in ?? () from /usr/lib/libpython2.7.so.1.0 #40 0x7f4b306a9773 in PyObject_Call () from /usr/lib/libpython2.7.so.1.0 #41 0x7f4b306aa2db in ?? () from /usr/lib/libpython2.7.so.1.0 #42 0x7f4b3063ab1e in PyObject_CallFunction () from /usr/lib/libpython2.7.so.1.0 #43 0x7f4b3061d30d in PyImport_Import () from /usr/lib/libpython2.7.so.1.0 #44 0x7f4b3061e6bc in PyImport_ImportModule () from /usr/lib/libpython2.7.so.1.0 #45 0x7f4b30a95387 in ?? () from /usr/lib/kde4/kpythonpluginfactory.so #46 0x7f4b30a9633d in ?? () from /usr/lib/kde4/kpythonpluginfactory.so #47 0x7f4b4bf661ea in createPlasma::AppletScript (keyword=..., parent=0x16fd880, this=0x16027d0, args=..., parentWidget=0x0) at ../../kdecore/util/kpluginfactory.h:531 #48 createInstancePlasma::AppletScript (error=0x7fffa0166120, args=..., parent=0x16fd880, parentWidget=0x0, this=0x16fbb20) at ../../kdecore/services/kservice.h:553 #49 createInstancePlasma::AppletScript (error=0x7fffa0166120, args=..., parent=0x16fd880, this=0x16fbb20) at ../../kdecore/services/kservice.h:530 #50 Plasma::loadEngine (language=..., type=Plasma::AppletComponent, parent=0x16fd880) at ../../plasma/scripting/scriptengine.cpp:175 #51 0x7f4b4bf6710e in Plasma::loadScriptEngine (language=..., applet=0x16fd880) at ../../plasma/scripting/scriptengine.cpp:205 #52 0x7f4b4beaa581 in Plasma::AppletPrivate::init (this=0x15ea800, packagePath=...) at ../../plasma/applet.cpp:2782 #53 0x7f4b4beab0f3 in Plasma::Applet::Applet (this=0x16fd880, parentObject=0x0, args=...) at ../../plasma/applet.cpp:193 #54 0x7f4b4bef66f3 in Plasma::PluginLoader::loadApplet (this=optimized out, name=..., appletId=optimized out, args=...) at ../../plasma/pluginloader.cpp:134 #55 0x7f4b4bec1b10 in Plasma::ContainmentPrivate::addApplet (this=0x156e550, name=..., args=..., appletGeometry=..., id=133, delayInit=true) at ../../plasma/containment.cpp:2218 #56 0x7f4b4becb894 in
