Bug#713675: tokyotyrant: FTBFS: ld: ttserver.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
Hi, Adding gcs which has promised to take over this package. Thanks! David Suárez (david.sephi...@gmail.com) wrote: Source: tokyotyrant Version: 1.1.40-4.1 Severity: serious Tags: jessie sid User: debian...@lists.debian.org Usertags: qa-ftbfs-20130620 qa-ftbfs Justification: FTBFS on amd64 Hi, During a rebuild of all packages in sid, your package failed to build on amd64. Maybe you need to add explicitly the offending lib to LD flags. Relevant part: gcc -g -O2 -std=c99 -Wall -fPIC -pedantic -fsigned-char -g -O2 -pipe -o ttserver ttserver.o scrext.o -L. -L/usr/lib -L/usr/local/lib -L/usr/include/lua5.1 -L/usr/local/include/lua5.1 -L/usr/include/lua -L/usr/local/include/lua -ltokyotyrant -llua5.1 -ltokyocabinet -lrt -lpthread -lm -lc -llua5.1 -ltokyocabinet /usr/bin/ld: ttserver.o: undefined reference to symbol 'dlclose@@GLIBC_2.2.5' /lib/x86_64-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status The full build log is available from: http://aws-logs.debian.net/ftbfs-logs/2013/06/20/tokyotyrant_1.1.40-4.1_unstable.log A list of current common problems and possible solutions is available at http://wiki.debian.org/qa.debian.org/FTBFS . You're welcome to contribute! About the archive rebuild: The rebuild was done on EC2 VM instances from Amazon Web Services, using a clean, minimal and up-to-date chroot. Every failed build was retried once to eliminate random failures. signature.asc Description: Digital signature
Bug#709226: Experimental version leaks memory in reset
Package: python-pycurl Version: 7.19.0-6 The user-agent string allocated in reset() will not be freed. This was introduced in 20_remove_string_options.patch Attached is a small patch that fixes this issue. 50_dont_leak_user_agent.patch Description: Binary data
Bug#690851: Code review
Mike Gabriel (mike.gabr...@das-netzwerkteam.de) wrote: I currently have not time to fix that patch. I still recommend switching to gevent 1.0~b1, though I am aware of the release team not accepting new upstream releases in packages at this state of the freeze. I don't think that would be the most awesome idea. There's quite a few bugs that are present in beta1 and some API incompatible changes. signature.asc Description: Digital signature
Bug#694750: python-gevent: python -m gevent.monkey --thread script.py Can't work
control: tags -1 +upstream +confirmed leiqin (leiqin2...@gmail.com) wrote: when I delete the word 'not' in line 228, and run the command age. everything is OK now. I think this is a bug and may be need to be fixed. Good catch. The given documentation for monkey also doesn't really reflect how the command works. I'll forward it upstream. Thanks! signature.asc Description: Digital signature
Bug#694750: python-gevent: python -m gevent.monkey --thread script.py Can't work
I submitted[1] your patch together with some additional fixes to make the --module work as documented. [1] https://github.com/SiteSupport/gevent/pull/214 Since this is a minor bug, it'll be fixed in the next 1.0 version in unstable or experimental. Thanks again! signature.asc Description: Digital signature
Bug#650293: segfault while running it with eventlet
Stefano Rivera (stefa...@debian.org) wrote: No idea which revision fixes the problem, however it *is* fixed in 0.3.3, released upstream. (as a zip file only, which is why DEHS hasn't seen it) I've updated the package to include 0.3.3. Upload pending. Thanks! signature.asc Description: Digital signature
Bug#640787: Please upload python-gevent to squeeze-backports
Chris Lamb (la...@debian.org) wrote: Would you be prepared to maintain a sqeeze backport of gevent? I'd be very interested in having that. Alternatively , if you don't have the time / motivation / whatever, I am happy to upload it there myself, with your blessing. Sure, that'd be really nice! You have my blessing. :) Just tell me if you need my help in anyway. I'm not a Debian Developer or Maintainer yet, I guess it'd be easier if you did it for now. Thank you! signature.asc Description: Digital signature
Bug#592876: python-migrate: postgres has been renamed to postgresql
Package: python-migrate
Version: 0.6-3
Severity: important
Tags: upstream
In Lenny, the schema for postgres was postgres://... and files in the db
respository was called xxx_postgres_upgrade.sql and so forth.
But in Squeeze, SQLAlchemy have renamed the dialect to postgresql. The
dialects.postgres.py works fine, but the upgrade scripts does not seem
to work.
It seems like the engine's name is postgresql, where the self.sql in
migrate.versioning.version still is called postgres.
Traceback (most recent call last):
File /usr/bin/migrate, line 6, in module
sys.exit(main())
File /usr/lib/pymodules/python2.6/migrate/versioning/shell.py, line 205, in
main
ret = command_func(**kwargs)
File /usr/lib/pymodules/python2.6/migrate/versioning/api.py, line 185, in
upgrade
return _migrate(url, repository, version, upgrade=True, err=err, **opts)
File string, line 2, in _migrate
File /usr/lib/pymodules/python2.6/migrate/versioning/util/__init__.py, line
161, in with_engine
return f(*a, **kw)
File /usr/lib/pymodules/python2.6/migrate/versioning/api.py, line 343, in
_migrate
changeset = schema.changeset(version)
File /usr/lib/pymodules/python2.6/migrate/versioning/schema.py, line 74, in
changeset
changeset = self.repository.changeset(database, start_ver, version)
File /usr/lib/pymodules/python2.6/migrate/versioning/repository.py, line
213, in changeset
changes = [self.version(v).script(database, op) for v in versions]
File /usr/lib/pymodules/python2.6/migrate/versioning/version.py, line 175,
in script
There is no script for %d version % self.version
AssertionError: There is no script for 1 version
self.sql = {'default': {'upgrade': ...},
'postgres': {'downgrade': ...}}
Renaming the files to xxx_postgres works, but to maintain compatibility
with lenny I used xxx_default.
It would be quite trivial to add a mapping from postgres to postgresql
for these filenames.
Regards,
Örjan
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (600, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#588628: python-gevent: FTBFS with sphinx 1.0 and docutils 0.7: KeyError: 'modname'
tags 588628 + pending thanks Jakub Wilk (jw...@debian.org) wrote: When rebuilt with python-sphinx 1.0~b1-1 and python-docutils 0.7-1 (both available in experimental), python-gevent failed to build. Here are the relevant parts of the build log: […] | sphinx-build -b html -d _build/doctrees . _build/html | Making output directory... [...] File ./mysphinxext.py, line 21, in missing_reference modname = node['modname'] File /usr/lib/pymodules/python2.6/docutils/nodes.py, line 534, in __getitem__ return self.attributes[key] KeyError: 'modname' Thanks for the report. In sphinx 1.0, attributes have been renamed. modname is now called py:module and classname is py:class. Regards, Örjan signature.asc Description: Digital signature
Bug#586419: tokyotyrant: daemon dies after receiving SIGABRT after random time of operating
severity 586419 important thanks bugrepor...@one-2-one.pl (bugrepor...@one-2-one.pl) wrote: Currently I also started session as you described and it is working fine for about 5 minutes now. It would be very helpful if you're able to tell exactly what's triggering this behaviour. :) Than I'll try to search application that normally runs there, what is exactly the 'misc' command performed. Seems that this 'misc' command is problem here. You used the misc command in your lua extension. I'm lowering the severity of this bug since it seems to be a special case and probably related to the lua code. The application code has been previously used on another installation of TT - in some other server environment and it used to work fine there. How are you communicating with tyrant? Regards, Örjan signature.asc Description: Digital signature
Bug#586419: tokyotyrant: daemon dies after receiving SIGABRT after random time of operating
o2o bug reporter (bugrepor...@one-2-one.pl) wrote: The problem is that after quite random time of operation (at least 30 minutes, usually few hours)- while daemon is not under heavy load (I would even say while it is almost not used) - it crashes, leaving it's PID file. Without using 'gdb' it was impossible for me to get any clue why it bahaves so. Daemon process has just been dissappearing at a time. Hello, That sounds indeed like a bug, but I'm unable to reproduce this problem. I started a server like this: $ ttserver -port 1999 -ext expire.lua -extpc expire 1.0 -ld test.tct#idx=key:lex#idx=x:dec#idx=val:lex#dfunit=8 And then I inserted some keys: $ for i in `seq 1 60`; do tcrmgr put -port 1999 -sep '|' localhost $i x|$((`date +%s`+i)); done And to verify the keys, I did this: $ tcrmgr list -pv -port 1999 -sep '|' localhost I also tried sending HUP to it: $ kill -HUP `pgrep -f 'ttserver -port 1999'` Can you always reproduce this when SIGHUP is sent to the process? Or is it completely random? Regards, Örjan signature.asc Description: Digital signature
Bug#584775: git-buildpackage: git-clone does not work with trailing slashes
Package: git-buildpackage
Version: 0.4.67
Severity: normal
Tags: lenny
If you choose to gbp-clone a repo with trailing slashes, you will get
this error:
$ gbp-clone ../path/repo.git/
Initialized empty Git repository in /path/to/repo/.git/
../path/repo.git/
Traceback (most recent call last):
File /usr/bin/gbp-clone, line 105, in module
sys.exit(main(sys.argv))
File /usr/bin/gbp-clone, line 73, in main
os.chdir(clone)
OSError: [Errno 2] No such file or directory: ''
But it works without trailing slashes. I'm not sure if a rstrip('/') would work
in all cases, but I think it would.
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (600, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages git-buildpackage depends on:
ii devscripts2.10.64scripts to make the life of a Debi
ii git [git-core]1:1.7.1-1 fast, scalable, distributed revisi
ii git-core 1:1.7.1-1 fast, scalable, distributed revisi
ii python2.5.4-9An interactive high-level object-o
ii python-dateutil 1.4.1-3powerful extensions to the standar
ii python-support1.0.8 automated rebuilding support for P
Versions of packages git-buildpackage recommends:
ii pristine-tar 1.03 regenerate pristine tarballs
Versions of packages git-buildpackage suggests:
ii git-load-dirs 1.1.8 Import upstream archives into git
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583947: python-setproctitle: Does not work on kfreebsd
Package: python-setproctitle Version: 1.0-1 Severity: important Tags: sid The test suite fails on kfreebsd[1]. For other BSD-systems, this package is currently able to be build in two ways: 1. PS_USE_SETPROCTITLE -- uses the setproctitle function in BSD. This is not the case for Debian since that function does not exist. 2. PS_USE_PS_STRING -- this is how the current Debian package uses it. There's also PS_USE_CHANGE_ARGV and PS_USE_CLOBBER_ARGV, but I don't think these are useful. It looks like PS_STRINGS doesn't have any effect on kfreebsd. [1] https://buildd.debian.org/build.cgi?pkg=python-setproctitle -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#583506: ITP: python-setproctitle -- A setproctitle implementation for Python
Package: wnpp Severity: wishlist Owner: Örjan Persson ora...@fobie.net * Package name: python-setproctitle Version : 1.0 Upstream Author : Daniele Varrazzo daniele.varra...@gmail.com * URL : http://code.google.com/p/py-setproctitle/ * License : BSD Programming Lang: Python Description : A setproctitle implementation for Python The library allows a process to change its title (as displayed by system tools such as ps and top). Changing the title is mostly useful in multi-process systems, for example when a master process is forked: changing the children's title allows to identify the task each process is busy with. The technique is used by PostgreSQL and the OpenSSH Server for example. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#581355: qemu-kvm: Fails to start with Cannot boot from non-existent NIC error
Package: qemu-kvm
Version: 0.12.3+dfsg-4
Severity: important
Tags: squeeze sid
After upgrading kvm and using the version in lenny-backports, KVM fails
to start and giving a Cannot boot from non-existent NIC error.
I found this problem reported here[1] and after applying upstream
commits 4e9e9d6e0a68f1691bcdcc80601a9a1bc2954736 ...
4e9e9d6e0a68f1691bcdcc80601a9a1bc2954736 the problem went away.
[1] http://lists.gnu.org/archive/html/qemu-devel/2010-04/msg00378.html
I'm attaching a working patch. Feel free to do whatever with it. As
mentioned in qemu-devel, it's only the patch #2 which fixes the problem.
-- System Information:
Debian Release: squeeze/sid
APT prefers stable
APT policy: (990, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff --git a/debian/changelog b/debian/changelog
index ee44c7a..ddb6ebe 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+qemu-kvm (0.12.3+dfsg-4~bpo50+2.1) unstable; urgency=low
+
+ * added patch from upstream, 4e9e9d6e0a68f1691bcdcc80601a9a1bc2954736,
+07_remove_nicinfo_bootable_field.patch
+ * added patch from upstream, da1fcfda59a6bcbdf58d49243fbced455f2bf78a,
+08_remove_broken_set_boot_mask.patch, fixes an issue with PXE booting
+and more where kvm would say Cannot boot from non-existent NIC
+ * added patch from upstream, c2564608a149555d748390e446990324802586e7,
+09_remove_unused_boot_devices_bitmap_variable.patch
+
+ -- Örjan Persson or...@spotify.com Tue, 11 May 2010 15:45:19 +0200
+
qemu-kvm (0.12.3+dfsg-4~bpo50+2) lenny-backports; urgency=low
* Re-add 99_lenny_bpo_ksm.patch: define MADV_MERGEABLE to enable KSM
diff --git a/debian/patches/07_remove_nicinfo_bootable_field.patch b/debian/patches/07_remove_nicinfo_bootable_field.patch
new file mode 100644
index 000..0233abb
--- /dev/null
+++ b/debian/patches/07_remove_nicinfo_bootable_field.patch
@@ -0,0 +1,24 @@
+Index: qemu-kvm-0.12.3+dfsg/net.c
+===
+--- qemu-kvm-0.12.3+dfsg.orig/net.c 2010-05-11 15:32:51.0 +0200
qemu-kvm-0.12.3+dfsg/net.c 2010-05-11 15:33:06.0 +0200
+@@ -1196,7 +1196,6 @@
+
+ for (i = 0; i nb_nics; i++) {
+ if (net_boot_mask (1 i)) {
+-nd_table[i].bootable = 1;
+ net_boot_mask = ~(1 i);
+ }
+ }
+Index: qemu-kvm-0.12.3+dfsg/net.h
+===
+--- qemu-kvm-0.12.3+dfsg.orig/net.h 2010-05-11 15:32:58.0 +0200
qemu-kvm-0.12.3+dfsg/net.h 2010-05-11 15:33:06.0 +0200
+@@ -132,7 +132,6 @@
+ VLANState *vlan;
+ VLANClientState *netdev;
+ int used;
+-int bootable;
+ int nvectors;
+ };
+
diff --git a/debian/patches/08_remove_broken_set_boot_mask.patch b/debian/patches/08_remove_broken_set_boot_mask.patch
new file mode 100644
index 000..b7231bf
--- /dev/null
+++ b/debian/patches/08_remove_broken_set_boot_mask.patch
@@ -0,0 +1,65 @@
+Index: qemu-kvm-0.12.3+dfsg/net.c
+===
+--- qemu-kvm-0.12.3+dfsg.orig/net.c 2010-05-11 15:33:55.0 +0200
qemu-kvm-0.12.3+dfsg/net.c 2010-05-11 15:34:15.0 +0200
+@@ -1187,25 +1187,6 @@
+ qemu_del_vlan_client(vc);
+ }
+
+-void net_set_boot_mask(int net_boot_mask)
+-{
+-int i;
+-
+-/* Only the first four NICs may be bootable */
+-net_boot_mask = net_boot_mask 0xF;
+-
+-for (i = 0; i nb_nics; i++) {
+-if (net_boot_mask (1 i)) {
+-net_boot_mask = ~(1 i);
+-}
+-}
+-
+-if (net_boot_mask) {
+-fprintf(stderr, Cannot boot from non-existent NIC\n);
+-exit(1);
+-}
+-}
+-
+ void do_info_network(Monitor *mon)
+ {
+ VLANState *vlan;
+Index: qemu-kvm-0.12.3+dfsg/net.h
+===
+--- qemu-kvm-0.12.3+dfsg.orig/net.h 2010-05-11 15:34:00.0 +0200
qemu-kvm-0.12.3+dfsg/net.h 2010-05-11 15:34:15.0 +0200
+@@ -162,7 +162,6 @@
+ int net_init_clients(void);
+ void net_check_clients(void);
+ void net_cleanup(void);
+-void net_set_boot_mask(int boot_mask);
+ void net_host_device_add(Monitor *mon, const QDict *qdict);
+ void net_host_device_remove(Monitor *mon, const QDict *qdict);
+
+Index: qemu-kvm-0.12.3+dfsg/vl.c
+===
+--- qemu-kvm-0.12.3+dfsg.orig/vl.c 2010-05-11 15:34:06.0 +0200
qemu-kvm-0.12.3+dfsg/vl.c 2010-05-11 15:35:20.0 +0200
+@@ -4919,7 +4919,7 @@
+ const char *gdbstub_dev = NULL;
+ uint32_t boot_devices_bitmap = 0;
+ int i;
+-int snapshot, linux_boot, net_boot;
++int snapshot, linux_boot;
+ const char *initrd_filename;
+ const char *kernel_filename, *kernel_cmdline;
+ char boot_devices[33] = cad; /* default
Bug#581356: qemu-kvm: PXE boot fails with e1000
Package: qemu-kvm Version: 0.12.3+dfsg-4 Severity: wishlist Tags: squeeze sid After applying the patch I described in the previous report[1], I had a problem PXE booting with e1000. This has been fixed in etherboot[2]. But since qemu-kvm depends on etherboot at build time, this problem could follow into squeeze. etherboot 5.4.4-5 fixes this problem but has currently not entered unstable. [1] http://bugs.debian.org/581355 [2] http://bugs.debian.org/569581 I wasn't sure if this bug should be filed with higher severity or if it's bogus. If you don't agree with me please close this bug report or bump the severity. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (990, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.30-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#576437: ITP: python-gevent -- a coroutine-based Python networking library
Package: wnpp Severity: wishlist Owner: Örjan Persson ora...@fobie.net * Package name: python-gevent Version : 0.12.2 Upstream Author : Denis Bilenko denis.bile...@gmail.com * URL : http://www.gevent.org/ * License : MIT Programming Lang: C, Python Description : a coroutine-based Python networking library gevent is a coroutine-based Python networking library that uses greenlet to provide a high-level synchronous API on top of libevent event loop. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (600, 'stable'), (200, 'testing'), (100, 'unstable') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566573: [Bug#566573: tokyotyrant: bad error handling]
Hi Mikio, I'm the Debian maintainer of Tokyo Tyrant. I received a bug report about error handling. Is this something you think is reasonable to be improved in the upstream version of Tyrant? Regards, Örjan - Forwarded message from Sebastian Harl tok...@debian.org - Date: Sat, 23 Jan 2010 23:34:50 +0100 From: Sebastian Harl tok...@debian.org Reply-To: Sebastian Harl tok...@debian.org, 566...@bugs.debian.org To: Debian Bug Tracking System sub...@bugs.debian.org Subject: Bug#566573: tokyotyrant: bad error handling User-Agent: Mutt/1.5.18 (2008-05-17) Package: tokyotyrant Version: 0.9.19-2 Severity: normal Hi, some (most? all?) public functions in tokyotyrant verify their arguments by (ab)using assert(). Thus, any user program passing an invalid argument will abort. That's not a nice thing to do. Also, please note that tokyotyrant is currently built using -DNDEBUG, i.e., assert() will be a no-op. Thus, an invalid argument will probably cause a segfault in most cases, providing no useful information to the user about what might be the source of the problem. I know that it will be quite some work to fix this properly, because upstream seems to rely on that and does not do any/much error checking. So, if upstream does not agree with my POV, feel free to mark this bug 'wontfix'. Cheers, Sebastian -- Sebastian tokkee Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/ Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin - End forwarded message - signature.asc Description: Digital signature
Bug#566246: tokyotyrant: unclear package description
Michael Prokop (m...@debian.org) wrote: What's a package of network interface? Good question. I'll update the descriptions. :) signature.asc Description: Digital signature
Bug#563921: ITP: tokyotyrant -- Tokyo Tyrant is a package of network interface to the DBM called Tokyo Cabinet
Package: wnpp Severity: wishlist Owner: Örjan Persson ora...@fobie.net * Package name: tokyotyrant Version : 1.1.39 Upstream Author : Mikio Hirabayashi hira...@gmail.com * URL : http://1978th.net/tokyotyrant/ * License : LGPL Programming Lang: C Description : Tokyo Tyrant is a package of network interface to the DBM called Tokyo Cabinet Tokyo Tyrant is provided for concurrent and remote connections to Tokyo Cabinet. It is composed of the server process managing a database and its access library for client applications. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (600, 'stable'), (200, 'testing') Architecture: amd64 (x86_64) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#322033: Apache -t reports false warnings about VirtualHosts
Ah, you are absolutly correct. Why would I? :) Changing it works of course much better. Thanks! On 10/16/06, Josip Rodin [EMAIL PROTECTED] wrote: On Tue, Aug 09, 2005 at 11:00:17AM +0200, Örjan Persson wrote: I've isolated the problem. My virtualhosts looked like this: IfDefine SSL VirtualHost xxx.xxx.xxx.xxx:443 [...] /VirtualHost /IfDefine Removing the IfDefine or adding them around the NameVirtualHost's directive solves the problem. Why would you want to have NameVirtualHost settings for :443 not enclosed in the same SSL conditionals? Wasn't this a simple semantic problem with your own configuration? -- 2. That which causes joy or happiness.
Bug#322033: Apache -t reports false warnings about VirtualHosts
I've isolated the problem. My virtualhosts looked like this: IfDefine SSL VirtualHost xxx.xxx.xxx.xxx:443 [...] /VirtualHost /IfDefine Removing the IfDefine or adding them around the NameVirtualHost's directive solves the problem.
