Bug#856114: wolfssl: CVE-2017-6076
I'm conferencing today and then vacationing Monday, but I should be able to get to it Tuesday. Excerpts from Salvatore Bonaccorso's message of 2017-03-03 21:30:02 +0100: > Hi, > > On Mon, Feb 27, 2017 at 05:42:33PM -0800, Felix Lechner wrote: > > Hi Salvatore, > > > > A version fixing the vulnerability is available on Mentors > > <https://mentors.debian.net/package/wolfssl>. Please feel free to upload it. > > > > With a new soname version, this upload will go through NEW. Also I am not > > sure the library will make it into stretch. Currently, no packages depend > > on it. > > > > In the past, I cooperated with Clint Byrum as a sponsor and copied him on > > this message. Perhaps he would prefer to upload? Thank you! > > Clint, can you please take care of the sponsoring? I'm quite > overwhelmed with other tasks, and it is not possible for me helping > reviewing+sponsoring new upstream version packages ATM for me. > > @Felix, have the other part still pending on my todo list. > > Regards, > Salvatore
Bug#811428: [debian-mysql] Bug#811428: Bug#811428: mysql-5.5: Multiple security fixes from the January 2016 CPU
Is anyone working on the build/test/upload of the final binaries? Excerpts from Norvald H. Ryeng's message of 2016-01-19 13:02:57 -0800: > The Critical Patch Update is out: > http://www.oracle.com/technetwork/topics/security/cpujan2016-2367955.html > > The following vulnerabilities are fixed by upgrading from MySQL 5.5.46 to > 5.5.47: > > CVE-2016-0505 > CVE-2016-0546 > CVE-2016-0597 > CVE-2016-0598 > CVE-2016-0600 > CVE-2016-0606 > CVE-2016-0608 > CVE-2016-0609 > CVE-2016-0596 > CVE-2016-0616 > > Regards, > > Norvald H. Ryeng >
Bug#793314: Let's just drop handlersocket
Excerpts from Esa Peuha's message of 2016-01-01 03:32:45 -0800: > On Wed, 30 Dec 2015, Clint Byrum wrote: > > > I orphaned it a long time ago, and nobody has stepped up to maintain, so > > I suggest just dropping it rather than chasing this RC. > > The people who have the power to completely remove packages from > Debian are unlikely to notice this here, so please file a proper > removal request, i.e. file a bug for the pseudo-package > ftp.debian.org with subject "RM: handlersocket -- ROM; reasons>" and details of the reasons in the body. (I would do so > myself, but removal requests are expected to be filed by either > maintainer(s) of a package or the QA team, and I'm neither.) Nor am I the maintainer, as I orphaned the package, and the QA team has taken ownership. I'm just recording my recommendation that it should be removed.
Bug#793314: Let's just drop handlersocket
It is an interesting piece of technology, but IMO it is more trouble than it is worth, and most of the use cases for it are handled well by the Memcache protocol addition in MySQL 5.6: http://dev.mysql.com/doc/refman/5.6/en/innodb-memcached.html I orphaned it a long time ago, and nobody has stepped up to maintain, so I suggest just dropping it rather than chasing this RC.
Bug#809011: closing 809011
close 809011 thanks The recent upload of 1.3.0-1 should address this.
Bug#775630: closing 775630
close 775630 thanks See http://lists.alioth.debian.org/pipermail/pkg-mysql-maint/2015-March/007624.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#765663: [debian-mysql] Bug#765663: mysql-5.5: Multiple security fixes from October 2014 CPU
Sorry Salvatore, I think at least a couple of us have been preoccupied with the OpenStack summit in Paris the last few weeks. I'll try to make some time to update unstable ASAP. Excerpts from Salvatore Bonaccorso's message of 2014-11-05 22:19:12 +0100: > On Fri, Oct 17, 2014 at 09:40:13AM +0200, Salvatore Bonaccorso wrote: > > Source: mysql-5.5 > > Version: 5.5.23-2 > > Severity: grave > > Tags: security upstream fixed-upstream > > > > Hi > > > > Please see: > > > > http://www.oracle.com/technetwork/topics/security/cpuoct2014-1972960.html#AppendixMSQL > > *ping*? > > Regards, > Salvatore > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763378: [Pkg-monitoring-maintainers] Bug#763378: syslog-nagios-bridge is not installable
I've uploaded 0.9.1 to unstable. Excerpts from Daniel Pocock's message of 2014-09-29 21:59:33 +0200: > > On 29/09/14 21:22, Aurelien Jarno wrote: > > Package: syslog-nagios-bridge > > Version: 1.0.1-4 > > Severity: grave > > Justification: renders package unusable > > > > Latest upload of syslog-nagios-bridge bumped the dependency on pynag to > > 0.9.1: > > > > | syslog-nagios-bridge (1.0.1-4) unstable; urgency=low > > | > > | * Update pynag dependency to 0.9.1 or greater, fixing file_time bug. > > | > > | -- Daniel Pocock Sun, 03 Aug 2014 18:34:51 +0200 > > > > This makes syslog-nagios-bridge uninstallable as this version is not > > available in debian (not even in experimental). > > I pinged the maintainers a couple of times to upload the new pynag but > they haven't uploaded it yet. > > This also blocks the next ganglia-nagios-bridge version. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763378: [Pkg-monitoring-maintainers] Bug#763378: syslog-nagios-bridge is not installable
BTW, the last time Palli was seen on IRC was April 17. 07:49 ... join!#debian-python -> palli(~pa...@212-30-216-15.static.simnet.is) Excerpts from Daniel Pocock's message of 2014-11-03 23:41:48 +0100: > > Palli's email address is bouncing: > >- The following addresses had permanent fatal errors - > > (reason: 550 5.1.1 : Recipient address > rejected: zimbra.okhysing.is) > >- Transcript of session follows - > ... while talking to zimbra.okhysing.is.: > > >>> DATA > > <<< 550 5.1.1 : Recipient address rejected: > zimbra.okhysing.is > 550 5.1.1 ... User unknown > <<< 554 5.5.1 Error: no valid recipients > > On 03/11/14 14:35, Daniel Pocock wrote: > > Hi Clint, Palli, > > > > Can you please let me know about the pynag 0.9.1 release? I notice you > > still haven't uploaded it to Debian and this makes syslog-nagios-bridge > > unusable, it is an RC bug. > > > > Regards, > > > > Daniel > > > > On 29/09/14 12:59, Daniel Pocock wrote: > >> On 29/09/14 21:22, Aurelien Jarno wrote: > >>> Package: syslog-nagios-bridge > >>> Version: 1.0.1-4 > >>> Severity: grave > >>> Justification: renders package unusable > >>> > >>> Latest upload of syslog-nagios-bridge bumped the dependency on pynag to > >>> 0.9.1: > >>> > >>> | syslog-nagios-bridge (1.0.1-4) unstable; urgency=low > >>> | > >>> | * Update pynag dependency to 0.9.1 or greater, fixing file_time bug. > >>> | > >>> | -- Daniel Pocock Sun, 03 Aug 2014 18:34:51 +0200 > >>> > >>> This makes syslog-nagios-bridge uninstallable as this version is not > >>> available in debian (not even in experimental). > >> I pinged the maintainers a couple of times to upload the new pynag but > >> they haven't uploaded it yet. > >> > >> This also blocks the next ganglia-nagios-bridge version. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#763378: [Pkg-monitoring-maintainers] Bug#763378: syslog-nagios-bridge is not installable
Apologies, I may have missed emails in the past. I will take a look at getting the latest pynag uploaded. Excerpts from Daniel Pocock's message of 2014-09-29 21:59:33 +0200: > > On 29/09/14 21:22, Aurelien Jarno wrote: > > Package: syslog-nagios-bridge > > Version: 1.0.1-4 > > Severity: grave > > Justification: renders package unusable > > > > Latest upload of syslog-nagios-bridge bumped the dependency on pynag to > > 0.9.1: > > > > | syslog-nagios-bridge (1.0.1-4) unstable; urgency=low > > | > > | * Update pynag dependency to 0.9.1 or greater, fixing file_time bug. > > | > > | -- Daniel Pocock Sun, 03 Aug 2014 18:34:51 +0200 > > > > This makes syslog-nagios-bridge uninstallable as this version is not > > available in debian (not even in experimental). > > I pinged the maintainers a couple of times to upload the new pynag but > they haven't uploaded it yet. > > This also blocks the next ganglia-nagios-bridge version. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730544: closing 730544
close 730544 2.1.6-2 thanks -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#713580: handlersocket: diff for NMU version 1.1.0-7-g1044a28-1.1
Excerpts from gregor herrmann's message of 2013-08-22 08:13:29 -0700: > tags 713580 + patch > tags 713580 + pending > thanks > > Dear maintainer, > > I've prepared an NMU for handlersocket (versioned as 1.1.0-7-g1044a28-1.1) and > uploaded it to DELAYED/2. Please feel free to tell me if I > should delay it longer. Thanks so much for addressing this gregor, no further delay is needed. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#707280: [debian-mysql] Bug#707280: mysql-5.5: gcc-4.4 is targeted for removal in unstable
On 2013-05-08 10:47, Matthias Klose wrote: Package: mysql-5.5 Version: 5.5.31+dfsg-1 Severity: serious Tags: jessie sid User: debian-...@lists.debian.org Usertags: gcc-4.4-removal Jessie will ship without gcc-4.4. please use the default versions of the compiler packages to build this package and prepare the package to build using GCC 4.8. If the package cannot be built anymore, please file a removal request or stop building the parts or architectures built using gcc-4.4. The plan is to disable the inline assembler on i386 and remove the dependency. This should be done in the next upload. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699886: [debian-mysql] Bug#699886: TLS timing attack in yaSSL (Lucky 13)
I will be at the openstack summit all this week, and thus pressed for time. An NMU for this bug would be most welcome, thanks!! Sent from my iPhone On Apr 14, 2013, at 6:25, Michael Stapelberg wrote: > Hi Clint, > > Clint Byrum writes: >> Thanks Michael! I suspect that we will see 2.2.2d in one of the >> upcoming releases from Oracle. While I would prefer to ship wheezy >> with no known security bugs, I don't have much time to build and test >> a new package. If someone else wants to do that I will gladly sponsor >> it. > I just built MySQL with (an updated version of) my patch and it passes > all the build-time tests. Furthermore, I configured SSL and connected > using mysql(1) — SSL still works :-). > > Should I NMU this package or do you want to upload it yourself? The > debdiff and latest version of my patch is attached. > > -- > Best regards, > Michael > > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#699886: [debian-mysql] Bug#699886: TLS timing attack in yaSSL (Lucky 13)
Thanks Michael! I suspect that we will see 2.2.2d in one of the upcoming releases from Oracle. While I would prefer to ship wheezy with no known security bugs, I don't have much time to build and test a new package. If someone else wants to do that I will gladly sponsor it. -Original Message- From: Michael Stapelberg To: Thijs Kinkhorst , 699...@bugs.debian.org, cont...@bugs.debian.org Sent: Wed, 27 Mar 2013 3:09 Subject: [debian-mysql] Bug#699886: TLS timing attack in yaSSL (Lucky 13) Control: tags -1 +patch Hi Thijs, Thijs Kinkhorst writes: > Nadhem Alfardan and Kenny Paterson have discovered a weakness in the handling > of CBC ciphersuites in SSL, TLS and DTLS. Their attack exploits timing > differences arising during MAC processing. Details of this attack can be > found at: http://www.isg.rhul.ac.uk/tls/ > > The issue has been fixed in upstream yaSSL 2.5.0: > http://www.yassl.com/yaSSL/Docs-cyassl-changelog.html Currently, MySQL uses yaSSL 2.2.2. yaSSL has released version 2.2.2d which addresses this problem. I downloaded yassl-2.2.2.zip from http://fossies.org/unix/privat/yassl-2.2.2.zip and yassl-2.2.2d.zip from http://yassl.com/yaSSL/download I then created a git repo in 2.2.2 and copied over the files from 2.2.2d. The following files differ: $ git status | grep 'modified' | grep -v '\.in$' | grep -v '\(INSTALL\|README\|aclocal.m4\|config.guess\|config.sub\|configure\|depcomp\|install-sh\|ltmain.sh\|missing\|mkinstalldirs\)' # modified: include/openssl/ssl.h # modified: include/yassl_error.hpp # modified: include/yassl_types.hpp # modified: src/handshake.cpp # modified: src/yassl_error.cpp # modified: src/yassl_imp.cpp # modified: taocrypt/include/asn.hpp # modified: taocrypt/include/sha.hpp # modified: taocrypt/src/asn.cpp I then created a patch and modified it so that it (somewhat) applies to the MySQL source: git diff include/openssl/ssl.h include/yassl_error.hpp include/yassl_types.hpp src/handshake.cpp src/yassl_error.cpp src/yassl_imp.cpp taocrypt/include/asn.hpp taocrypt/include/sha.hpp taocrypt/src/asn.cpp > yassl.patch sed -i 's,\([iw]\)/,\1/extra/yassl/,g' yassl.patch dos2unix yassl.patch Then, I used quilt to get the patch in shape: cd /tmp/mysql-5.5-5.5.30+dfsg export QUILT_PATCHES=debian/patches quilt import ../yassl-2.2.2/yassl.patch quilt push -f # apply 4 hunks of the patch manually quilt refresh I attached the result to this email, hopefully that helps. Note that I didn’t compile and test MySQL. -- Best regards, Michael
Bug#698068: MySQL 5.5.30 does not fix CVE-2012-4414, what to do next?
Please refer to [1] as the rest of this message assumes the reader has read the log thus far. I have just now comitted MariaDB's test for CVE-2012-4414 to the SVN repo where we maintain mysql-5.5 unstable packaging. The package fails to build right now because this test fails. Lifting the test out of the commit is easy. To lift the fix out, is much more complicated. I know it can be done, because Percona did it in their branch. But I do not have the time to commit to such a delicate operation. So, we are left with some options: 1) Un-block unstable's 5.5.29 and let it proceed into testing, which will fix several other CVE's. This will introduce CVE-2012-4414. Its a lower priority fix, so this seems like a valid option if we are pressed for time. 2) Somebody step up and give us a patch for 5.5.30 which fixes CVE-2012-4414. There's probably a commit in percona's tree somewhere that can solve the issue with perhaps some fuzz to resolve. 3) Wait until 5.5.31 comes out, and pray that Oracle have actually fixed this security vulnerability. They've been releasing patch versions on a 2-3 month pace, so we should be able to expect 5.5.31 by late April at the latest. Its actually a good sign that the changelog for 5.5.31 [2] has nothing in it. The security fixes are never enumerated there due to Oracle's non-disclosure policy. We will end up shipping 5.5.31 in the security pocket anyway. This is as much "FYI" as "halp!" for the release team. Any advice is appreciated. Thank you [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=698068 [2] http://dev.mysql.com/doc/relnotes/mysql/5.5/en/news-5-5-31.html -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698068: mysql-server-5.5: Serious regression in replication caused by fix for CVE-2012-4414
I will try and upload 5.5.30 packages soon. No point in shipping old stuff in the release when more changes are bound to drop in security updates anyway. So we should downgrade this bug after that upload. On Feb 28, 2013, at 12:29, "Adam D. Barratt" wrote: > On Sun, 2013-02-03 at 22:53 +0100, Moritz Mühlenhoff wrote: >> On Sat, Jan 26, 2013 at 11:26:27AM +, Adam D. Barratt wrote: >>> On Sun, 2013-01-13 at 11:53 -0800, Clint Byrum wrote: >>>> According to this blog post by Stewart Smith: >>>> >>>> http://www.mysqlperformanceblog.com/2013/01/13/cve-2012-4414-in-mysql-5-5-29-and-percona-server-5-5-29/ >>>> >>>> It looks like 5.5.29 has a serious problem with replication. >>> >>> Is there any news on a fix for that? It unfortunately means the other RC >>> fixes from 5.5.29 are stuck in unstable. :-( >> >> Personally I don't think a bug in some replication scenarios is more >> severe than migrating the security fixes... >> >> But I leave that to the MySQL maintainers. > > MySQL maintainers - ping? > > Regards, > > Adam > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698068: mysql-server-5.5: Serious regression in replication caused by fix for CVE-2012-4414
Package: mysql-server-5.5 Version: 5.5.29+dfsg-1 Severity: grave Tags: upstream Justification: causes non-serious data loss According to this blog post by Stewart Smith: http://www.mysqlperformanceblog.com/2013/01/13/cve-2012-4414-in-mysql-5-5-29-and-percona-server-5-5-29/ It looks like 5.5.29 has a serious problem with replication. -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-19-generic (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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#695001: I believe these are addressed upstream with 5.2.29
I have verified at least CVE-2012-5612 is fixed in 5.5.29. Will upload the new upstream version to unstable soon after some testing. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694748: php5-ps segmentation fault on ps_setfont (64bit)
Package: php5-ps
Version: 1.3.6-7
Severity: grave
Tags: patch upstream
Justification: renders package unusable
Forwarding Ubuntu bug report:
http://pad.lv/1024207
This was seen on Ubuntu and FreeBSD systems. Upstream has not acknowledged
the bug (perhaps dead upstream?)
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-18-generic (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
--- a/ps.c 2007-11-27 03:40:14.0 -0600
+++ b/ps.c 2012-07-13 01:35:16.815241282 -0500
@@ -518,7 +518,8 @@
{
zval *zps;
char *text;
- int text_len, len;
+ int text_len;
+long len;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rsl", &zps, &text, &text_len, &len)) {
@@ -527,7 +528,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- PS_show2(ps, text, len);
+ PS_show2(ps, text, (int)len);
RETURN_TRUE;
}
@@ -561,7 +562,8 @@
{
zval *zps;
char *text;
- int text_len, len;
+ int text_len;
+long len;
double x, y;
PSDoc *ps;
@@ -571,7 +573,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- PS_show_xy2(ps, text, len, (float) x, (float) y);
+ PS_show_xy2(ps, text, (int)len, (float) x, (float) y);
RETURN_TRUE;
}
@@ -611,7 +613,7 @@
PHP_FUNCTION(ps_setfont) {
zval *zps;
double fontsize;
- int font;
+ long font;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rld", &zps, &font, &fontsize)) {
@@ -620,7 +622,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- PS_setfont(ps, font, (float) fontsize);
+ PS_setfont(ps, (int)font, (float) fontsize);
RETURN_TRUE;
}
@@ -691,7 +693,7 @@
PHP_FUNCTION(ps_setoverprintmode)
{
zval *zps;
- int mode;
+ long mode;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rl", &zps, &mode)) {
@@ -700,7 +702,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- PS_setoverprintmode(ps, mode);
+ PS_setoverprintmode(ps, (int)mode);
RETURN_TRUE;
}
@@ -944,7 +946,7 @@
PHP_FUNCTION(ps_setlinejoin)
{
zval *zps;
- int value;
+ long value;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rl", &zps, &value)) {
@@ -953,7 +955,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- PS_setlinejoin(ps, value);
+ PS_setlinejoin(ps, (int)value);
RETURN_TRUE;
}
@@ -964,7 +966,7 @@
PHP_FUNCTION(ps_setlinecap)
{
zval *zps;
- int value;
+ long value;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rl", &zps, &value)) {
@@ -973,7 +975,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- PS_setlinecap(ps, value);
+ PS_setlinecap(ps, (int)value);
RETURN_TRUE;
}
@@ -1091,7 +1093,7 @@
char *text;
int text_len;
double width, size = 0.0;
- int font = 0;
+ long font = 0;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rs|ld", &zps, &text, &text_len, &font, &size)) {
@@ -1100,7 +1102,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- width = (double) PS_stringwidth2(ps, text, text_len, font, (float)size);
+ width = (double) PS_stringwidth2(ps, text, text_len, (int)font, (float)size);
RETURN_DOUBLE((double) width);
}
@@ -1114,7 +1116,7 @@
char *text;
int text_len;
double width, size = 0.0;
- int font = 0;
+ long font = 0;
float dimension[3];
PSDoc *ps;
@@ -1124,7 +1126,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
- width = (double) PS_string_geometry(ps, text, text_len, font, (float) size, dimension);
+ width = (double) PS_string_geometry(ps, text, text_len, (int)font, (float) size, dimension);
array_init(return_value);
add_assoc_double(return_value, "width", (double) dimension[0]);
@@ -1279,7 +1281,7 @@
zval *zps;
char *text;
int text_len;
- int parentid = 0, open = 0, id;
+ long parentid = 0, open = 0, id;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rs|ll", &zps, &text, &text_len, &parentid, &open)) {
@@ -1289,7 +1291,7 @@
PSDOC_FROM_ZVAL(ps, &zps);
/* will never return 0 */
- id = PS_add_bookmark(ps, text, parentid, open);
+ id = PS_add_bookmark(ps, text, (int)parentid, (int)open);
RETURN_LONG(id);
}
@@ -1302,7 +1304,7 @@
zval *zps;
char *type, *filename, *image, *stringparam = NULL;
int type_len, filename_len, stringparam_len;
- int imageid, intparam = 0;
+ long imageid, intparam = 0;
PSDoc *ps;
if (FAILURE == zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, "rss|sl", &zps, &type, &type_len, &filename, &filename_len, &stringparam, &stringparam_len, &intparam)) {
@@ -1317,7 +1319,7 @@
image = filename;
#endif
- imageid = PS_open_image_file(ps, type, image, stringparam, intparam);
+ imageid = PS_open_image_file(ps, type, image, stringparam, (int)intparam);
if (imageid == 0) {
RETURN_FALSE;
@@ -1399,7 +1401,7 @@
PHP_FUNCTION(ps_close_image)
{
zval *zps;
- int imageid;
+ long imageid;
PSDo
Bug#692871: mysql-server-5.5: Regression in privileges of mysql debian-sys-maint user
Package: mysql-server-5.5 Version: 5.5.28+dfsg-1 Severity: serious Justification: important This bug was originally reported in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1062716 Basically, the debian-sys-maint user, which is inserted via raw INSERT, is missing a new privilege for 5.5. This causes problems for those who rely on the user to be able to create users and do other things. This may have also been the issue with warnings we've seen about schema differences. -- System Information: Debian Release: wheezy/sid APT prefers quantal-updates APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 'quantal') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5.0-17-generic (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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#684831: (no subject)
Looking into this FTBFS, it looks like this is an apt resolver bug. If I build w/ sbuild --build-dep-resolver=aptitude , libphonon-dev installs just fine and the package builds. I'm not sure what the correct course of action is though, as I'd like to close this RC bug if we can. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685728: Packages pending
Will upload soon, but at the moment they FTBFS because of issues with argparse. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685728: juju: Communication with store.juju.ubuntu.com is not authenticated
Package: juju
Version: 0.5.1+bzr563-0juju2~quantal1
Severity: grave
Tags: security patch upstream
Justification: user security hole
This problem with juju has been fixed in upstream trunk and so can be
considered "disclosed".
When using juju with the built in "charm store" at store.juju.ubuntu.com,
the SSL certificate is not verified. This could lead to a man in the
middle attack where an attacker could have trojaned "charms" installed
instead of the official charms.
-- System Information:
Debian Release: wheezy/sid
APT prefers quantal-updates
APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500,
'quantal'), (400, 'precise-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5.0-10-generic (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 juju depends on:
ii openssh-client 1:6.0p1-2ubuntu1
ii python 2.7.3-0ubuntu5
ii python-oauth1.0.1-3build1
ii python-twisted 12.0.0-1ubuntu1
ii python-txaws0.2.3-1ubuntu1
ii python-txzookeeper 0.9.5-1
ii python-yaml 3.10-4
ii python2.7 2.7.3-0ubuntu4
ii tmux1.6-2
Versions of packages juju recommends:
ii byobu 5.21-0ubuntu1
ii python-pydot 1.0.2-1
Versions of packages juju suggests:
ii apt-cacher-ng 0.7.7-1ubuntu1
ii libvirt-bin0.9.13-0ubuntu7
ii lxc0.8.0~rc1-4ubuntu24
ii zookeeper 3.3.6+dfsg-0ubuntu1
-- no debconf information
Origin: http://bazaar.launchpad.net/~juju/juju/trunk/revision/565
Bug: http://pad.lv/992447
=== modified file 'juju/charm/repository.py'
--- a/juju/charm/repository.py 2012-05-03 18:42:09 +
+++ b/juju/charm/repository.py 2012-08-23 23:57:09 +
@@ -3,11 +3,13 @@
import os
import tempfile
import urllib
+import urlparse
import yaml
from twisted.internet.defer import fail, inlineCallbacks, returnValue, succeed
from twisted.web.client import downloadPage, getPage
from twisted.web.error import Error
+from txaws.client.ssl import VerifyingContextFactory
from juju.charm.provider import get_charm_from_path
from juju.charm.url import CharmURL
@@ -126,7 +128,8 @@
url = "%s/charm-info?charms=%s" % (
self.url_base, urllib.quote(charm_id))
try:
-all_info = json.loads((yield getPage(url)))
+host = urlparse.urlparse(url).hostname
+all_info = json.loads((yield getPage(url, contextFactory=VerifyingContextFactory(host
charm_info = all_info[charm_id]
for warning in charm_info.get("warnings", []):
log.warning("%s: %s", charm_id, warning)
@@ -147,8 +150,9 @@
delete=False)
f.close()
downloading_path = f.name
+host = urlparse.urlparse(url).hostname
try:
-yield downloadPage(url, downloading_path)
+yield downloadPage(url, downloading_path, contextFactory=VerifyingContextFactory(host))
except Error:
raise CharmNotFound(self.url_base, charm_url)
os.rename(downloading_path, cache_path)
=== modified file 'juju/charm/tests/test_repository.py'
--- a/juju/charm/tests/test_repository.py 2012-07-01 22:20:22 +
+++ b/juju/charm/tests/test_repository.py 2012-08-06 20:06:37 +
@@ -5,6 +5,8 @@
from twisted.internet.defer import fail, inlineCallbacks, succeed
from twisted.web.error import Error
+from txaws.client.ssl import VerifyingContextFactory
+
from juju.charm.directory import CharmDirectory
from juju.charm.errors import CharmNotFound, CharmURLError, RepositoryNotFound
@@ -16,7 +18,7 @@
from juju.lib import under
from juju.charm import tests
-from juju.lib.mocker import ANY
+from juju.lib.mocker import ANY, MATCH
from juju.lib.testing import TestCase
@@ -280,15 +282,19 @@
return json.dumps({url_str: info})
def mock_charm_info(self, url, result):
-self.getPage(url)
+def match_context(value):
+return isinstance(value, VerifyingContextFactory)
+self.getPage(url, contextFactory=MATCH(match_context))
self.mocker.result(result)
def mock_download(self, url, error=None):
-self.downloadPage(url, ANY)
+def match_context(value):
+return isinstance(value, VerifyingContextFactory)
+self.downloadPage(url, ANY, contextFactory=MATCH(match_context))
if error:
return self.mocker.result(fail(error))
-def download(_, path):
+def download(_, path, contextFactory):
self.assertTrue(path.startswith(self.download_path))
with open(path, "wb") as f:
f.write(self.bundle_data)
=== modified file 'juju/control/tests/test_upgrade_charm.py'
--- a/juju/control/tests/test_upgrade_charm.py 2012-05-04 22:43:40 +
+++ b/juju/control/tests/test_upgrade_charm.py 2012-08-06 19:29:30 +
@@ -12,6 +12,7 @@
from juju
Bug#674267: [debian-mysql] facing upto #674267
Excerpts from Matthias Klose's message of 2012-06-20 02:46:19 -0700: > On 19.06.2012 17:54, Nicholas Bamber wrote: > > 1.) compile against gcc-4.5 and g++-4.5 > > 2.) set the magic TAOCRYPT_DISABLE_X86ASM thingy causing SSL connections > > on those platforms to be slower. > > 3.) compile against gcc-4.4 and g++-4.4 > > > > > > Matthias, > > Any opinion on which short term hack we should adopt? Would you like to > > ahve a look at the code which is causing us issues? > > this is inline assembler, I won't look at it. So best disable it if nobody > wants to maintain it (and the code has comments like "won't work with compiler > xy at opt level z"). If you still want to look at it, find out which function > with the inline assembler causes the unexpected behaviour (modify the code to > build just half of the functions with asm statements, then bisect until you > get > down to one function). > > As a side note, why isn't the package built using the system openssl? It looks > like everybody except Debian/Ubuntu does do this. > Its been explained to me like this: * libmysqlclient is GPL, with an exception given to things that are not GPL to link to it: http://www.mysql.com/about/legal/licensing/foss-exception/ * OpenSSL is given an exception, despite being GPL incompatible * However, now anything that links to *libmysqlclient* must also explicitly give OpenSSL an exception since they are effectively transitively accepting the OpenSSL license, which is not compatible. With almost 150 reverse depends on libmysqlclient, it would be a lot of work to make sure all of those projects gave OpenSSL an exception. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675304: [debian-mysql] reassigning
Excerpts from Nicholas Bamber's message of 2012-06-01 02:17:01 -0700: > reassign 675304 amarok > thanks > > I am much clearer about this now. This bug is clearly a duplicate of > #672207. > > That said I think we could have instead of changing > > " language= /usr/share/mysql/english" > > to > > "lc-messages-dir = /usr/share/mysql" > > changed it to > > " > loose-lc-messages-dir = /usr/share/mysql/ > # This option is deprecated and will be removed in a later version > language= /usr/share/mysql/english > " > I'm not sure how this is going to work. loose-lc-messages-dir is still going to be unrecognized by any 5.1 based mysqld. Unless this is some undocumented field that I am not aware of. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675304: [debian-mysql] Bug#675304: amarok
Excerpts from Nicholas Bamber's message of 2012-05-31 14:05:36 -0700: > Modestas, > I would be very grateful if you could advise us on this bug: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675304 > > I presume what has happpened is that the user is on testing and did an > apt-get upgrade. Because of the current state of affairs his mysql got > upgraded and not his amarok. > > I don't quite see why that should cause his amarok to fail - an > explanation would be appreciated. > > Should we be asking for the amarok 2.5.0-3 to be rushed through to > testing? Should we put a breaks clause to make late mysql incompatible > with early versions of amarok - though I really don't want to do that as > it would be unworkable in the long term. > > Also beyond following the proper transition procedures is there > something we could be doing to avoid these situations? > If I had to guess, I'd say its the new MySQL 5.5 mysql-common's my.cnf directives that the old 5.1 libmysqld embedded in amarok does not understand. A workaround is probably to comment those out of /etc/mysql/my.cnf until the new amarok is available. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674122: [debian-mysql] Fwd: Re: Bug#674122: otrs2: fails to upgrade from squeeze: Can't create table 'otrs2.#sql-1712_71
Excerpts from Patrick Matthäi's message of 2012-05-25 13:13:05 -0700: > Hi Sean, Debian-MySQL team and the rest of the world > > first thanks to the MySQL team and sean for doing a good job with mysql > and dbconfig-common > > But now we have got a critical issue with upgrades from Squeeze to > Wheezy, where I need some help.. > > The situation is: > a) otrs2, like many other packages in Squeeze, are using MyISAM as > storage engine as default > b) With mysql-5.5 the default storage engine has been changed from > MyISAM to InnoDB, which is IMHO (with my administrator hat on) a realy > good decision > c) .. but applications like otrs2 using MyISAM may fail with it :( > > If we would install otrs2 with the current sid development all tables > are created with the InnoDB database engine, it would be successful but > the ticket fulltextsearch would fail > Hi Patrick. This is a bug in otrs2. Any time one uses a storage engine specific feature, like fulltext indexes, one should be explicit when creating tables. There's nothing reasonable to do in the mysql package. otrs2 just needs to evolve and start being explicit about its storage engine for the tables which need FULLTEXT search. It would also be a good idea to consider using something better, like sphinx, as FULLTEXT really does not perform well, and can only operate on the non-transactional non-crash-safe MyISAM. > There are no errors and side effects if a user upgrades his otrs2 > installation from Squeeze to current wheezy/testing (with mysql-5.1), > since CREATE TABLE statements will create MyISAM tables (upstream didn't > "hardcoded" the engine) > > Upgrading from a Squeeze installation to current sid with mysql-5.5 will > create a few new tables, with the InnoDB format and after that setting > some attributes will fail, as reported in #674122 .. > > > So I want to ask if there is some nice and quick workaround for such > issues, I don't think that otrs2 will be the only DBMS application with > 5.1 -> 5.5 upgrade issues. You're right, but there's not much we can or even should do in the MySQL package. I'd rather ship as pure-to-upstream as possible a package, and that means default storage engine is InnoDB. > Patching every upgrade and install script of dbconfig-common to hardcode > MyISAM (in this case) is IMHO a big bunch of work, maybe you have got > better ideas or there is already an implementation (which I do not find) > to solve such problems Whatever code creates fulltext indexes needs to also ensure that the table is MyISAM. 5.5 has been out for a long time, and the change is well documented in the release notes. People just need to fix their applications, even though I understand this is a lot of work. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673162: handlersocket: FTBFS: configure: error: MySQL source version does not match MySQL binary version
Excerpts from gregor herrmann's message of Mon May 21 11:47:48 -0700 2012: > On Wed, 16 May 2012 16:47:25 +0200, Christoph Egger wrote: > > > Your package failed to build on the buildds > > Full build log at > > https://buildd.debian.org/status/fetch.php?pkg=handlersocket&arch=kfreebsd-amd64&ver=1.0.6-80-g88bf1e0-1.1&stamp=1336595525 > > Seems to be caused by build-depending on mysql-source-5.1 and > libmysqlclient-dev (which is 5.5.23-2 now). > [Cf. also #649214 which is also about MySQL versions.] > > Since one binary package is called handlersocket-mysql-5.1, I guess > just changing the build dependency is not really enough. Agreed. I thinK I may recommend that we combine this into the mysql source package actually. With 3.0 format debian source, one can have multiple upstream sources. That will make sure that handlersocket always gets built when mysql does. Anwyay, for now, I will backport the patches that I did for Ubuntu 12.04 into unstable, which moves this to producing a handlersocket-mysql-5.5 instead of 5.1. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660206: [debian-mysql] Bug#660206: Bug#660206: This is a regression
Excerpts from Olaf van der Spek's message of Tue Apr 10 10:23:27 -0700 2012: > On Tue, Apr 10, 2012 at 5:59 PM, micah anderson wrote: > > I agree. However, the reality is that the security upgrade brought in > > unrelated changes to the security upgrade and caused unrelated software > > to break. > > The problem is that Oracle does not release individual security > updates. So Debian can't provide them (easily) either. > Right. We're stuck between a rock and a hard place. If somebody wants to produce a patch that fixes this problem, I'd be happy to help get it out to affected users in a subsequent update. But I don't really have the resources to triage and fix this individual issue, and upstream doesn't seem interested in fixing it, so I don't think there's much we can do. I would encourage you to participate in the discussions that are sure to happen in the coming weeks around whether or not it is still appropriate to ship MySQL to Debian users given these problems, and around alternative databases that will continue to provide full disclosure of security vulnerabilities. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#660206: [debian-mysql] Bug#660206: This is a regression
Excerpts from micah anderson's message of Sun Apr 08 10:13:40 -0700 2012: > severity 660206 serious > thanks > > This is actually a regression, the only way to get things to work again > is to downgrade package like such: > > apt-get install mysql-server-5.1=5.1.49-3 mysql-client-5.1=5.1.49-3 > mysql-common=5.1.49-3 mysql-server-core-5.1=5.1.49-3 > libmysqlclient16=5.1.49-3 > > micah > So, I'm not sure I agree that this is such a serious regression. *lenny* shipped with rails 2.1.0. 1.2.6 was released in 2007, and is not supported in Debian at all. The referenced upstream bug talks about using client versions older than 4.1, which is basically ancient. I'm not disputing that this is a regression introduced by the upstream jump to 5.1.61, but I don't know that its worth downgrading and losing security updates for. Perhaps the client libraries should be updated to something that is still supported by upstream and/or Debian. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#659687: Debian RT - Fix for mysql CVE's needs sponsorship
Hello! I have prepared fixed packages for stable-security and unstable for mysql-5.1. They are available in SVN here (these are tagged and ready to upload): http://anonscm.debian.org/viewvc/pkg-mysql/mysql-5.1/branches/ Or I can upload the raw source packages somewhere if that is preferred. This is a new upstream version so the orig tarball will need to be uploaded (it does not need to be repacked so it can be downloaded using the url in the watch file.) This is my first time updating a package for security issues, so please advise me what I should do next. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631820: gearman-interface: FTBFS: SWIG version >= 1.3.31 is required. You have 2.0.4.
Thanks, I have not been able to spend much time on gearman-interface lately. Thanks for the heads up. Note that the Vcs-Bzr in the package is more or less correct, and you may want to consider tacking my pending changes on top of this as one of them is an RC bug fix. Excerpts from coldtobi's message of Fri Mar 02 16:20:49 -0800 2012: > Package: gearman-interface > Followup-For: Bug #631820 > > Hash: SHA1 > > Hallo, > > Ubuntu has a patch that works around this issue. > > MAINTAINERS: PLEASE NOT THAT I AM INTENDING AN NMU > ### I'm currently preparing an NMU. I will ask debian-mentors to upload this > into a delayed queue. ### > > > > - -- System Information: > Debian Release: wheezy/sid > APT prefers unstable > APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 3.2.0-1-amd64 (SMP w/4 CPU cores) > Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#631820: Fix found, awaiting upstream feedback
The problem here is just that the autoconf ac_pkg_swig.m4 snippet used in the m4 dir of gearman-interface is broken and cannot detect swig versions greater than 1.x. There is an updated macro available in the latest version of autoconf-archive, which I've asked upstream to include (they do not have a public bug tracker setup). Once I hear back from them, I will prepare an upload with the new m4 macro in place. Its staged here lp:~clint-fewbar/gearman-interface/debian-packaging -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: [Python-modules-team] Bug#620469: Bug#620496
Excerpts from Piotr Ożarowski's message of Tue Apr 19 03:27:05 -0700 2011: > FYI: if this package doesn't use setuptools/distribute's > namespace_packages.txt, you can add "--namespace gearman" to > dh_python2's call and let the helper handle namespace issue Hi Piotr. If I understand the suggestion correctly, we can use something in distutils/setuptools to extend the path in this file, without actually having this file in either package? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: Bug#620496
Excerpts from Oxan van Leeuwen's message of Mon Apr 18 11:49:18 -0700 2011: > Hi Clint, > > On 03-04-11 18:53, Clint Byrum wrote: > > I think the way to go is to drop __init__.py from > > python-gearman.libgearman, and make it depend on python-gearman, since > > it is a sub-module of the gearman namespace. > > > > I haven't been able to make gearman.libgearman work properly without > > the __path__ changes, though I'm not entirely sure why as I'm sort of a > > python extension novice. If anyone *can* make that work, then we don't > > even need the change suggested above. > > I did some more testing and gearman.libgearman actually works without the > __path__ changes, when it's installed in one of the standard Debian locations. > During compilation it's not, so it needs the __path__ changes then. > > The problem with implementating that is python-gearman uses dh_python2 while > gearman.libgearman uses python-support, which results in the bytecode files > (.pyc) being installed into different directories. When I converted > gearman.libgearman to dh_python2 both packages work fine. Do you agree with > this > solution? Thats great news, and yes I agree with the solution completely. I had actually already begun porting the package to dh_python2 in the bzr branch: https://code.launchpad.net/~clint-fewbar/gearman-interface/debian-packaging > > I've attached the patch that I used for testing gearman.libgearman using > dh_python. You'll probably need to make some more changes, but maybe you can > use > this. I've added some of your tweaks to the branch. However, its not clear to me the reason for these two additions to debian/rules: rm -rf python3/build/ + rm -rf python3/gearman/_libgearman*so + rm -rf python3/gearman/__pycache__ [ ! -f python/libgearman.c.orig ] || mv -f python/libgearman.c.orig python/libgearman.c I was hoping you could explain those. Once I can explain what that is in debian/changelog, I'll get it uploaded. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#620469: Bug#620496
Excerpts from Oxan van Leeuwen's message of Sun Apr 03 05:43:27 -0700 2011: > # wheezy not affected as this bug blocks python-gearman from migrating > tag 620469 + sid > thanks > > I see three solutions for this problem: > > (A) Add Conflicts against each other. > This prevents users from installing the packages together, which normally > isn't needed as they provide the same functionality. It isn't optimal > however, as in the future it might be possible that there are programs > that > depend on one of these libraries and that need to be co-installable. > > (B) Rename the python module in one of the packages. > This would be the best solution, but it is a backwards-incompatible break > and every reverse-dependency needs to be patched to use the renamed API. > > (C) Drop the __init__.py from one of the packages. > The two modules are actually co-installable and usable, as they don't use > the same namespace: python-gearman.libgearman uses gearman.libgearman, > while python-gearman uses just gearman. The __init__.py from > python-gearman can't be dropped as it imports the primary API into the > gearman namespace. python-gearman.libgearman seems to be functional > without > the __init__.py, but I'm not 100% sure. Also having two packages providing > the same Python package is confusing. > Oxan, thanks for the quick response. I opened this issue upstream: https://github.com/Yelp/python-gearman/issues/#issue/11 I think the way to go is to drop __init__.py from python-gearman.libgearman, and make it depend on python-gearman, since it is a sub-module of the gearman namespace. I haven't been able to make gearman.libgearman work properly without the __path__ changes, though I'm not entirely sure why as I'm sort of a python extension novice. If anyone *can* make that work, then we don't even need the change suggested above. > I think the best we can do at this point is A, given the side-effects of the > other options. I'll implement that in python-gearman (which should be enough) > if nobody objects. Yeah I was thinking of doing the same in the python-gearman.libgearman, but I think since its temporary we can just leave it in python-gearman until the necessary changes can be made for python-gearman.libgearman to depend on python-gearman. With the Conflicts on one side, I think we can close this bug, and open a new wishlist bug to implement the dependency relationship. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#599127: Reported in Ubuntu as well
https://bugs.launchpad.net/debian/+source/libdbi/+bug/673307 There is a fix pending in the merge proposal there. As you'll see, this was also reported and fixed in Fedora. This is a simple fix Thomas, I suggest just tacking '-fno-fast-math' onto the CFLAGS. Since this is marked release critical, and it really does seem very serious, doesn't that mean this must be fixed before squeeze is released? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#602222: Should bacula-sd have an OR in the recommends?
Would it fix the problem if bacula-sd had Recommends: mt-st, bacula-sd-sqlite3 (>= 5.0.2-2) | bacula-sd-tools Similar to the way bacula-server depends on bacula-sd-tools? -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590383: I believe this bug is fixed
I was able to build v1.8.1-1 using pbuilder and the latest updated testing dist. rabbitmq-server-build.log Description: Binary data
Bug#595120: suggstion for resolution to bug#595120 - skip-name-resolve in mysql-server-5.1
Reverse-dns is one of the least reliable forms of host identification one can use. While source IP address isn't much better, it at least requires a full man in the middle or layer-2 compromise. With the default setting in mysql of resolving each and every hostname, one gets a false sense of security. Its quite simple for a dns cache poisoning attack from anywhere to end up allowing somebody to connect from the wrong host. Also, running with skip-name-resolve means one less step to perform while connecting to the server, resulting in lower connection latency. It also means more reliability, as mysql will continue to function even if its DNS resolvers are down. Even if this option is left on, its reasonable to suggest that mysql can be *started* before the local named that it might use is available for resolving names. Any named that does rely on a local mysqld should be configured, by default, to connect to mysql on the localhost/unix socket anyway, so it won't cause any issues to place it after mysqld for startup. Likewise, mysqld will be functional enough to function for any local service that needs it between starting and a local resolver starting. Here is a debdiff which just removes $named from the Should portions. While I do think skip-name-resolve is actually the better default mode, it will likely break peoples systems on upgrade if it is forcibly turned off, and could even open security holes if certain hostnames have been restricted while others, like '%' have more capabilities. That change would need to go into squeeze+1 after some discussion and possibly include adding a debconf warning/question. diff -u mysql-5.1-5.1.49/debian/mysql-server-5.1.mysql.init mysql-5.1-5.1.49/debian/mysql-server-5.1.mysql.init --- mysql-5.1-5.1.49/debian/mysql-server-5.1.mysql.init +++ mysql-5.1-5.1.49/debian/mysql-server-5.1.mysql.init @@ -4,8 +4,8 @@ # Provides: mysql # Required-Start:$remote_fs $syslog # Required-Stop: $remote_fs $syslog -# Should-Start: $network $named $time -# Should-Stop: $network $named $time +# Should-Start: $network $time +# Should-Stop: $network $time # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Start and stop the mysql database server daemon diff -u mysql-5.1-5.1.49/debian/changelog mysql-5.1-5.1.49/debian/changelog --- mysql-5.1-5.1.49/debian/changelog +++ mysql-5.1-5.1.49/debian/changelog @@ -1,3 +1,10 @@ +mysql-5.1 (5.1.49-1.1) unstable; urgency=low + + * debian/mysql-server-5.1.mysql.init: Remove $named from + Should-Start/Should-Stop (closes: #595120) + + -- Clint Byrum Thu, 07 Oct 2010 01:02:49 -0700 + mysql-5.1 (5.1.49-1) unstable; urgency=low * New upstream release. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594607: Status in Ubuntu, and Experimental
I just wanted to share the status in Ubuntu 10.10 here as well. We've left libdbi v0.8.3 in 10.10. The rationale is that all of the affected packages in ubuntu test well, and do not use the enum that was changed between 0.8.2 and 0.8.3. This does mean things compiled by 3rd parties that do use that enum will be broken upon upgrade to Ubuntu 10.10. We've recommended that release managers include this warning in the release notes. A recompile will correct any issues. As far as Debian is concerned, I think we should get the 0.8.4 package here: https://code.launchpad.net/~clint-fewbar/ubuntu/maverick/libdbi/upstream-0.8.4 Into Experimental (cleaned up for Debian of course, there are a few Ubuntu-isms there), which would resolve this bug and allow us to start moving all other packages that build depend on libdbi0-dev to libdbi-dev. I will also begin working with Thomas to move the package vcs into collab-maint. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594607: libdbi upload to SID reverted (was: Freeze exception for libdbi and libdbi-drivers)
You're timing is fine from my point of view Markus, this should be enough time to fix for 10.10. We'll be in beta freeze for 10.10 for another week or so. Upon importing the tarball into the ubuntu package, it builds correctly with libdbi.1.0.0.so. I was also able to build libdbi-drivers, including the testing suite, without errors (nice to have those tests! :) There is some more work to do, namely renaming libdbi0-dev to libdbi-dev (as it should have been originally I think) and renaming libdbi0 to libdbi1. Then we'll need to tweak all of the packages that build-depend on libdbi0-dev to libdbi-dev, and rebuild them. As far as squeeze goes, this probably won't happen. But it should be doable for Ubuntu 10.10. Markus, thanks for pushing this out quickly! On Aug 31, 2010, at 4:46 PM, Markus Hoenicka wrote: > Clint Byrum writes: >> I believe all that is needed is to bump 'LIB_CURRENT' in configure.in from 0 >> -> 1, and autoreconf. > > Hi, > > I hope it's not too late, but I've prepared a 0.8.4 test tarball: > > http://libdbi.sourceforge.net/downloads/libdbi-0.8.4.tar.gz > > This isn't officially released yet, but I could do so in no > time. Please have a look at the tarball and let me know if this > serves your immediate needs. > > I've used the 0.8.3 sources and changed the following things: > > - bumped the package version number to 0.8.4 > > - updated some autotools-related things in configure.in, autogen.sh, > and Makefile.am (recent versions need AC_CONFIG_MACRO_DIR set > properly, otherwise I wouldn't be able to bootstrap the build on my > FreeBSD development box) > > - LIB_CURRENT=1, LIB_REVISION=0, LIB_AGE=0 > > - fixed the --disable-docs behaviour of configure (this had been fixed > long ago in HEAD) > > > regards, > Markus > > > -- > Markus Hoenicka > http://www.mhoenicka.de > AQ score 38 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#594607: libdbi upload to SID reverted (was: Freeze exception for libdbi and libdbi-drivers)
On Aug 28, 2010, at 1:49 AM, Thomas Goirand wrote: > > Now, version 0.8.2 is back to SID. I can't upload a new 0.8.3 to > experimental, because I need you to change your so version number before > I can upload (otherwise, there's collisions). Please let me know when I > can download a new fixed version of the 0.8.x series, and upload it to > experimental (so that Ubuntu gets a chance to have the new package we've > been working on before 10.10 is out in few month, which was the > motivation of Clint Byrum). > Markus, it would be great if an 0.8.4 or 0.8.3.1 release arrived with soname bumped. We could just rebuild all of our rdepends, but then anybody who has depended on libdbi0 will break when the new version arrives. Either way, I'd prefer not to revert to 0.8.2 in Maverick, being in Beta freeze right now. Its much better if we can just upload the new version, and then rebuild all these rdepends: $ apt-cache rdepends libdbi0 libdbi0 Reverse Depends: syslog-ng python-gammu-dbg python-gammu libgsmsd7 libdbd-sqlite3 libdbd-sqlite libdbd-pgsql libdbd-mysql libdbd-freetds libapache2-mod-log-sql-dbi libapache2-mod-log-sql-dbi icinga-idoutils gammu-smsd collectd-core collectd rrdtool rrdcached librrd4 liblua5.1-rrd0 libdbi0-dev I have created a bug report in Ubuntu to link to the Debian report. https://bugs.launchpad.net/debian/+source/libdbi/+bug/625882 I believe all that is needed is to bump 'LIB_CURRENT' in configure.in from 0 -> 1, and autoreconf. Markus, please let me know if we can do anything to assist with this, its fairly urgent, but not something we can really work around with a patch. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#593642: python-gearman.libgearman: gearman.libgearman module missing
Hi Jakub, Indeed, it would seem that the amd64 binary package that ccheney built and uploaded was not built "clean". If the clean step is run before the build step, python/libgearman.py gets created. Since autobuilders don't run clean before build, a missing libgearman.py is the result. To fix this, I changed the rules file to rename the packaged .c files, forcing the build step to recreate the .c and .py files. I've uploaded a new package to mentors.debian.net, its here: http://mentors.debian.net/debian/pool/main/g/gearman-interface/ I believe this should correct the problem. I will request sponsorship for it soon, or if you can review and upload it, that would be great. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#571220: upstream not going to fix deprecation errors
According to this upstream bug https://sourceforge.net/tracker/?func=detail&aid=2954087&group_id=37132&atid=418980 phppgadmin 4.x isn't supposed to work on php 5.3. I'd suggest patching Misc.php as Alan suggests. That is what I've done as well to make phppgadmin work, and it doesn't change the actual functionality at all. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
