Your message dated Wed, 20 Mar 2013 11:49:18 +0000
with message-id <[email protected]>
and subject line Re: Bug#703499: unblock: soprano/2.7.6+dfsg.1-2wheezy1
has caused the Debian Bug report #703499,
regarding unblock: soprano/2.7.6+dfsg.1-2wheezy1
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
703499: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=703499
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: release.debian.org
Severity: normal
User: [email protected]
Usertags: unblock
Please unblock package soprano
I just uploaded version 2.7.6+dfsg.1-2wheezy1 which solves a bug where
virtuoso's postinst fails because of soprano. We (José Manuel and
myself) made the upload through tpu because the fixed version in
unstable depends on librdf0 >= 1.0.16 (for !hppa) which is not available
in testing. The upload in tpu add the exact same patch as the fixed
package in unstable and has thus been throughly tested.
Below is the full explaination of the bug as found in the patch:
Soprano launches a Virtuoso server using an unix socket (/tmp/virt_XXXX
where XXXX is the tcp port specified in the configuration file). It tries
first with the /tmp/virt_1111 port if it's availaible, and if it's not, keeps
trying with above ports one by one until it finds an usuable /tmp/virt_XXXX.
Starting with 1111 is a very unfortunate choice, because if you start other
virtuoso server configured to use the same port (note that 1111 is the
default), then it would fail to start. It should fail and return, but currently
it hangs.
When installing virtuoso-opensource-6.1, the postinst script will try to start
Virtuoso using the default 1111 port in order to change the admin password. So
the problem is the following: since the unix socket /tmp/virt_1111 is (probably)
already being used by the Virtuoso instance started by Soprano, the Virtuoso
instance started by the postinst script would hang (as explained in the
paragraph above), breaking the installation.
Attached is the debdiff of the change.
Best regards,
Thomas Preud'homme
unblock soprano/2.7.6+dfsg.1-2wheezy1
-- System Information:
Debian Release: 7.0
APT prefers unstable
APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 'testing'),
(500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diff -Nru soprano-2.7.6+dfsg.1/debian/changelog soprano-2.7.6+dfsg.1/debian/changelog
--- soprano-2.7.6+dfsg.1/debian/changelog 2012-11-27 22:34:30.000000000 +0100
+++ soprano-2.7.6+dfsg.1/debian/changelog 2013-03-01 16:57:01.000000000 +0100
@@ -1,3 +1,12 @@
+soprano (2.7.6+dfsg.1-2wheezy1) testing-proposed-updates; urgency=low
+
+ * Team upload.
+ * Upload to testing-proposed-updates.
+ * Add dont_use_virtuoso_default_port.diff, prevents hangs when installing or
+ running virtuoso as a standalone server.
+
+ -- José Manuel Santamaría Lema <[email protected]> Fri, 01 Mar 2013 16:56:04 +0100
+
soprano (2.7.6+dfsg.1-2) unstable; urgency=low
* Team upload.
diff -Nru soprano-2.7.6+dfsg.1/debian/patches/dont_use_virtuoso_default_port.diff soprano-2.7.6+dfsg.1/debian/patches/dont_use_virtuoso_default_port.diff
--- soprano-2.7.6+dfsg.1/debian/patches/dont_use_virtuoso_default_port.diff 1970-01-01 01:00:00.000000000 +0100
+++ soprano-2.7.6+dfsg.1/debian/patches/dont_use_virtuoso_default_port.diff 2013-03-01 16:55:13.000000000 +0100
@@ -0,0 +1,33 @@
+Author: José Manuel Santamaría Lema <[email protected]>
+Forwarded: https://projects.kde.org/projects/kdesupport/soprano/repository/revisions/3482b5fe
+Description: If possible, don't use the default virtuso port (1111)
+ Soprano launches a Virtuoso server using an unix socket (/tmp/virt_XXXX where
+ XXXX is the tcp port specified in the configuration file). It tries first with
+ the /tmp/virt_1111 port if it's availaible, and if it's not, keeps trying with
+ above ports one by one until it finds an usuable /tmp/virt_XXXX. Starting with
+ 1111 is a very unfortunate choice, because if you start other virtuoso server
+ configured to use the same port (note that 1111 is the default), then it would
+ fail to start. It should fail and return, but currently it hangs.
+ .
+ When installing virtuoso-opensource-6.1, the postinst script will try to start
+ Virtuoso using the default 1111 port in order to change the admin password. So
+ the problem is the following: since the unix socket /tmp/virt_1111 is
+ (probably) already being used by the Virtuoso instance started by Soprano, the
+ Virtuoso instance started by the postinst script would hang (as explained in
+ the paragraph above), breaking the installation.
+--- a/backends/virtuoso/virtuosocontroller.cpp
++++ b/backends/virtuoso/virtuosocontroller.cpp
+@@ -56,11 +56,11 @@ namespace {
+ // }
+ #ifdef Q_OS_WIN
+ static QMutex portNumberMutex;
+- static quint16 p = 1111;
++ static quint16 p = 1113;
+ QMutexLocker l(&portNumberMutex);
+ return p++;
+ #else
+- int p = 1111;
++ int p = 1113;
+ while ( QFile::exists( QString( "/tmp/virt_%1" ).arg( p ) ) ) {
+ ++p;
+ }
diff -Nru soprano-2.7.6+dfsg.1/debian/patches/series soprano-2.7.6+dfsg.1/debian/patches/series
--- soprano-2.7.6+dfsg.1/debian/patches/series 2012-11-25 15:06:51.000000000 +0100
+++ soprano-2.7.6+dfsg.1/debian/patches/series 2013-03-01 16:55:13.000000000 +0100
@@ -2,3 +2,4 @@
disable_usr_lib_install_rpath.diff
doxyfile_generate_tagfile.diff
redland_raptor2_support.h
+dont_use_virtuoso_default_port.diff
--- End Message ---
--- Begin Message ---
On 20.03.2013 11:02, Thomas Preud'homme wrote:
Please unblock package soprano
Already done in #701981; one bug will do... :P
I did mention it in the first bug, but for reference "this will need a
tpu" does not mean "please go ahead and upload to tpu". :-| The version
number should also preferably have been 2.7.6+dfsg.1-2+deb7u1; even when
using suite names the "+" should be included to ensure that the
resulting binary packages sort above any existing binNMUs.
Regards,
Adam
--- End Message ---
