Bug#675434: nmu: libnet-ssleay-perl_1.48-1
Hi Cyril Thanks for your reply! (adding debian-perl list to the recipients, to have more comments if needed) On Fri, Jun 01, 2012 at 11:07:44AM +0200, Cyril Brulebois wrote: Salvatore Bonaccorso car...@debian.org (01/06/2012): It was reported [1], that libnet-ssleay-perl does not report the correct constant value for SSL_OP_NO_TLSv1_1. There was the following change in openssl 1.0.1b-1: openssl (1.0.1b-1) unstable; urgency=high . * New upstream version - Remaps SSL_OP_NO_TLSv1_1, so applications linked to 1.0.0 can talk to servers supporting TLS 1.1 but not TLS 1.2 - Drop rc4_hmac_md5.patch, applied upstream Does it mean we're going to hit the same kind of issues next time there's a similar change in openssl? Yes I think so if openssl would have again such a change, we will have similar issue again. If openssl changes constant values as for 1.0.1b, then libnet-ssleay-perl would need a rebuild against this updated openssl version. However ... In changes of openssl I read this: cut-cut-cut-cut-cut-cut- *) OpenSSL 1.0.0 sets SSL_OP_ALL to 0x8FFFL and OpenSSL 1.0.1 and 1.0.1a set SSL_OP_NO_TLSv1_1 to 0x0400L which would unfortunately mean any application compiled against OpenSSL 1.0.0 headers setting SSL_OP_ALL would also set SSL_OP_NO_TLSv1_1, unintentionally disablng TLS 1.1 also. Fix this by changing the value of SSL_OP_NO_TLSv1_1 to 0x1000L Any application which was previously compiled against OpenSSL 1.0.1 or 1.0.1a headers and which cares about SSL_OP_NO_TLSv1_1 will need to be recompiled as a result. Letting be results in inability to disable specifically TLS 1.1 and in client context, in unlike event, limit maximum offered version to TLS 1.0 [see below]. [Steve Henson] *) In order to ensure interoperabilty SSL_OP_NO_protocolX does not disable just protocol X, but all protocols above X *if* there are protocols *below* X still enabled. In more practical terms it means that if application wants to disable TLS1.0 in favor of TLS1.1 and above, it's not sufficient to pass SSL_OP_NO_TLSv1, one has to pass SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2. This applies to client side. [Andy Polyakov] cut-cut-cut-cut-cut-cut- So this might not affect only libnet-ssleay-perl? At least if one uses SSL_OP_NO_TLSv1_1. Regards, Salvatore signature.asc Description: Digital signature
versioned symbols
Julien, The patch was not as bad as I thought. 00022340 gDF .text 01b5 libmysqlclient_18 my_connect http://anonscm.debian.org/viewvc/pkg-mysql/mysql-5.5/branches/unstable/debian/patches/versioned_symbols.patch?view=markup http://anonscm.debian.org/viewvc/pkg-mysql/mysql-5.5/branches/unstable/debian/rules?r1=2127r2=2131 http://anonscm.debian.org/viewvc/pkg-mysql/mysql-5.5/branches/unstable/debian/changelog?r1=2128r2=2131 But I still need to port this into what we have for wheezy/testing/sid and it looks like I need some more tweaks for #672359 and possibly a Break against amarok ( 2.5.0-2). -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4fc9d6fa.3020...@periapt.co.uk
bts.turmzimmer.net not updating
It seems that http://bts.turmzimmer.net service Unofficial RC-Bugs Count isn't updated since last year. It has some features that official pages lack. But it should be fixed or links to it removed. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602103603.GA11039@lisko
Re: versioned symbols
On Sat, Jun 2, 2012 at 10:03:54 +0100, Nicholas Bamber wrote: Julien, The patch was not as bad as I thought. 00022340 gDF .text01b5 libmysqlclient_18 my_connect http://anonscm.debian.org/viewvc/pkg-mysql/mysql-5.5/branches/unstable/debian/patches/versioned_symbols.patch?view=markup http://anonscm.debian.org/viewvc/pkg-mysql/mysql-5.5/branches/unstable/debian/rules?r1=2127r2=2131 http://anonscm.debian.org/viewvc/pkg-mysql/mysql-5.5/branches/unstable/debian/changelog?r1=2128r2=2131 But I still need to port this into what we have for wheezy/testing/sid and it looks like I need some more tweaks for #672359 and possibly a Break against amarok ( 2.5.0-2). Sounds good, thanks! Cheers, Julien -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602112239.gn31...@radis.cristau.org
Re: bts.turmzimmer.net not updating
On Sat, Jun 2, 2012 at 13:36:03 +0300, Touko Korpela wrote: It seems that http://bts.turmzimmer.net service Unofficial RC-Bugs Count isn't updated since last year. It has some features that official pages lack. But it should be fixed or links to it removed. I don't know what links to it, but it's been broken for a *long* time, and isn't coming back afaik. Cheers, Julien -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602120152.go31...@radis.cristau.org
Bug#675594: pu: package lockfile-progs/0.1.15
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: pu Hi, I have backported the fix for #626752[1], which currently makes the --use-pid feature useless in stable. The fix has already been deployed in sid (version 0.1.16). Please see attached debdiff. ~Niels [1] lockfile-progs: lockfile-create --use-pid uses wrong pid diff -Nru lockfile-progs-0.1.15/debian/changelog lockfile-progs-0.1.15+squeeze1/debian/changelog --- lockfile-progs-0.1.15/debian/changelog 2010-06-13 09:21:29.0 +0200 +++ lockfile-progs-0.1.15+squeeze1/debian/changelog 2012-06-02 13:17:42.0 +0200 @@ -1,3 +1,20 @@ +lockfile-progs (0.1.15+squeeze1) stable; urgency=low + + [ Niels Thykier ] + * Non-maintainer upload. + * Backport fix for #626752 + + [ Rob Browning ] + * Use L_PID rather than L_PPID when appropriate. In cases where +lockfile_create() and lockfile_check() were being called with L_PID, +use L_PPID to capture the parent's PID. Capturing the PID of the +lockfile-create or lockfile-check process made no sense. Thanks to +Zrin Žiborski zrin+launch...@ziborski.net for the report, Larry +Diegel for the patch, and Sebastian Siewior sebast...@breakpoint.cc +for the suggestion to update the documentation. (Closes: #626752) + + -- Niels Thykier ni...@thykier.net Sat, 02 Jun 2012 13:07:35 +0200 + lockfile-progs (0.1.15) unstable; urgency=low * Add missing debhelper Build-Depends. diff -Nru lockfile-progs-0.1.15/lockfile-progs.1 lockfile-progs-0.1.15+squeeze1/lockfile-progs.1 --- lockfile-progs-0.1.15/lockfile-progs.1 2010-06-12 19:02:33.0 +0200 +++ lockfile-progs-0.1.15+squeeze1/lockfile-progs.1 2012-06-02 13:07:13.0 +0200 @@ -81,11 +81,12 @@ .PP .\ --use-pid \fB\-p\fR, \fB\-\-use\-pid\fR .RS 4 -Write the current process id (PID) to the lockfile whenever a lockfile +Write the parent process id (PPID) to the lockfile whenever a lockfile is created, and use that pid when checking a lock's validity. See the \fBlockfile_create\fR(3) manpage for more information. This option -applies to \fBlockfile\-create\fR, \fBlockfile\-remove\fR, -\fBlockfile-touch\fR, and \fBlockfile-check\fR. +applies to \fBlockfile\-create\fR and \fBlockfile-check\fR. NOTE: +this option will not work correctly between machines sharing a +filesystem. .RE .PP .\ --oneshot \fB\-o\fR, \fB\-\-oneshot\fR diff -Nru lockfile-progs-0.1.15/lockfile-progs.c lockfile-progs-0.1.15+squeeze1/lockfile-progs.c --- lockfile-progs-0.1.15/lockfile-progs.c 2010-06-09 07:27:30.0 +0200 +++ lockfile-progs-0.1.15+squeeze1/lockfile-progs.c 2012-06-02 13:07:13.0 +0200 @@ -328,7 +328,7 @@ static int cmd_lock(const char *lockfilename, int retry_count) { - int rc = lockfile_create(lockfilename, retry_count, (use_pid ? L_PID : 0)); + int rc = lockfile_create(lockfilename, retry_count, (use_pid ? L_PPID : 0)); const char *rc_str = get_status_code_string(rc); if(rc != L_SUCCESS) @@ -363,7 +363,7 @@ static int cmd_check(const char *lockfilename) { - int rc = lockfile_check(lockfilename, (use_pid ? L_PID : 0)); + int rc = lockfile_check(lockfilename, (use_pid ? L_PPID : 0)); return rc; } diff -Nru lockfile-progs-0.1.15/Makefile lockfile-progs-0.1.15+squeeze1/Makefile --- lockfile-progs-0.1.15/Makefile 2009-06-21 19:01:51.0 +0200 +++ lockfile-progs-0.1.15+squeeze1/Makefile 2012-06-02 13:07:13.0 +0200 @@ -46,7 +46,7 @@ bin/lockfile-create --use-pid --lock-name check/file.lock bin/lockfile-touch --oneshot --lock-name check/file.lock # PID shouldn't be the same, so this should fail. - ! bin/lockfile-check --use-pid --lock-name check/file.lock + bin/lockfile-check --use-pid --lock-name check/file.lock bin/lockfile-remove --lock-name check/file.lock ! test -e check/file.lock
Re: bts.turmzimmer.net not updating
On Sat, Jun 02, 2012 at 02:01:52PM +0200, Julien Cristau wrote: On Sat, Jun 2, 2012 at 13:36:03 +0300, Touko Korpela wrote: It seems that http://bts.turmzimmer.net service Unofficial RC-Bugs Count isn't updated since last year. It has some features that official pages lack. But it should be fixed or links to it removed. I don't know what links to it, but it's been broken for a *long* time, and isn't coming back afaik. At least http://release.debian.org/ links to it. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602121318.GA8363@tiikeri.vuoristo.local
Bug#675434: nmu: libnet-ssleay-perl_1.48-1
On Fri, Jun 01, 2012 at 11:07:44AM +0200, Cyril Brulebois wrote: Salvatore Bonaccorso car...@debian.org (01/06/2012): It was reported [1], that libnet-ssleay-perl does not report the correct constant value for SSL_OP_NO_TLSv1_1. There was the following change in openssl 1.0.1b-1: openssl (1.0.1b-1) unstable; urgency=high . * New upstream version - Remaps SSL_OP_NO_TLSv1_1, so applications linked to 1.0.0 can talk to servers supporting TLS 1.1 but not TLS 1.2 - Drop rc4_hmac_md5.patch, applied upstream Does it mean we're going to hit the same kind of issues next time there's a similar change in openssl? This change was made to make sure applications build against 1.0.0 can talk to a server that does TLS 1.1 but not TLS 1.2, as the changelog says. This is not something I like to change again, since it will cause problems. Everything build against 1.0.1 or 1.0.1a that cares about SSL_OP_NO_TLSv1_1 should be rebuild against 1.0.1b or later. If using the defines from the the 1.0.1 and 1.0.1a version, but using 1.0.1b or laster the SSL_OP_NO_TLSv1_1 will not have any effect. Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602122135.ga9...@roeckx.be
Request removal for gnunet-fuse
Hello, I'm requesting removal for package gnunet-fuse. It's orphaned, outdated and doesn't work anymore with gnunet 0.9.2. Also, there is a FTBFS bug (http://bugs.debian.org/674342). It doesn't make sense to keep it in testing. I've got in touch with upstream. They are going to re-work gnunet-fuse, but no at this moment. The next question is, whether we want to keep it in unstable as well? -- Pozdrawiam / Kind regards, Artur Rona
Processed: reassign 640818 to src:pike7.8, forcibly merging 651317 640818
Processing commands for cont...@bugs.debian.org: reassign 640818 src:pike7.8 Bug #640818 [pike7.8] pike7.8 ftbfs with -O2 on i386 Bug reassigned from package 'pike7.8' to 'src:pike7.8'. No longer marked as found in versions pike7.8/7.8.352-dfsg-4. Ignoring request to alter fixed versions of bug #640818 to the same values previously set forcemerge 651317 640818 Bug #651317 [src:pike7.8] pike7.8: FTBFS on i386: Segmentation fault Bug #640818 [src:pike7.8] pike7.8 ftbfs with -O2 on i386 Severity set to 'serious' from 'important' 671115 was blocked by: 674328 673528 667428 673263 650058 660686 674122 649955 651110 674309 672714 650060 666331 672619 672950 673264 672716 651317 673262 674210 672765 661422 673260 673183 673161 649638 668232 673153 672824 672621 672816 672207 672588 671115 was blocking: 672928 Added blocking bug(s) of 671115: 640818 Marked as found in versions pike7.8/7.8.352-dfsg-4. Merged 640818 651317 thanks Stopping processing here. Please contact me if you need assistance. -- 640818: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=640818 651317: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651317 671115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=671115 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/handler.s.c.13386411988544.transcr...@bugs.debian.org
Bug#675359: marked as done (nmu: ibus-chewing_1.3.10+clean-3)
Your message dated Sat, 02 Jun 2012 19:40:53 +0800 with message-id 87pq9ix7p6@isil.kanru.info and subject line Fixed in ibus-chewing/1.3.10+clean-3+b1 has caused the Debian Bug report #675359, regarding nmu: ibus-chewing_1.3.10+clean-3 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 ow...@bugs.debian.org immediately.) -- 675359: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675359 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu ibus-chewing_1.3.10+clean-3 . i386 . -m Rebuild against new libchewing3-dev (Closes: #671118) -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash ---End Message--- ---BeginMessage--- I've uploaded ibus-chewing:i386/1.3.10+clean-3+b1 to unstable. -- Kanru pgpTm4oXQLvHH.pgp Description: PGP signature ---End Message---
Re: bts.turmzimmer.net not updating
* Touko Korpela (touko.korp...@iki.fi) [120602 12:46]: It seems that http://bts.turmzimmer.net service Unofficial RC-Bugs Count isn't updated since last year. It has some features that official pages lack. But it should be fixed or links to it removed. it's basically dead. I added an appropriate error page now. Andi -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602141704.gm13...@mails.so.argh.org
exim4 and the mysqlclient transition
Hello, the PTS tells me that exim4 is involved in the mysqlclient transition. However afaict mysql-5.5 (libmysqlclient18, libmysqlclient-dev) has propagated (or been forced) to testing. Therefore an exim upload should not worsen the situation as it can be built against the newer version. Is this correct or should I refrain from uploading exim 4.80 to unstable? thanks, cu andreas -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/eamp99-me6@argenau.downhill.at.eu.org
Re: Request removal for gnunet-fuse
On Sat, Jun 02, 2012 at 02:23:31PM +0200, Artur Rona wrote: I'm requesting removal for package gnunet-fuse. It's orphaned, outdated and doesn't work anymore with gnunet 0.9.2. Also, there is a FTBFS bug (http://bugs.debian.org/674342). It doesn't make sense to keep it in testing. I've got in touch with upstream. They are going to re-work gnunet-fuse, but no at this moment. The next question is, whether we want to keep it in unstable as well? Please use reportbug to file a bug against release.debian.org (testing) or ftp.debian.org (unstable). -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602154645.gj7...@lupin.home.powdarrmonkey.net
Transition of rpm package
Hello, I've noticed that new revision of rpm source package has been uploaded this week and introduced new binary packages names. However, maintainer of rpm didn't let us know about that fact. The list of changed SONAME: librpm2 - librpm3 librpmio2 - librpmio3 librpmbuild2 - librpmbuild3 librpmsign0 - librpmsign1 List of reverse depends: * ceve [amd64 armel hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 powerpc sparc] * dose-distcheck [amd64 armel hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 sparc] * dose-extra [amd64 armel hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 sparc] * edos-distcheck [amd64 armel hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 powerpc sparc] * fossology-agents [amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc] * fossology-agents-single [amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc] * libdose2-ocaml * libdose3-ocaml [amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 s390x sparc] * librpm-dev [armel] * librpm2 * librpmbuild2 * librpmsign0 * pkglab [amd64 armel hurd-i386 i386 kfreebsd-amd64 kfreebsd-i386 powerpc sparc] * python-rpm [armel] * rpm [armel] * rpm2cpio [armel] * rpm2html -- Pozdrawiam / Kind regards, Artur Rona
Bug#664681: transition: KDE's 4.8 release of platform, applications and workspace
Hello, On šeštadienis 24 Kovas 2012 23:45:02 Sune Vuorela wrote: On Saturday 24 March 2012 22:10:07 you wrote: On Mon, Mar 19, 2012 at 22:07:22 +0100, Sune Vuorela wrote: a couple of months ago, KDE released the januar feature release Should we do the qt multiarch change before this? We can do the qt multiarch change first. we also can do it after. I would personally like to see the Qt multiarch change done, because it also brings in qt4.8 With qt4-x11 multiarch done [1] and KDE Plasma Workspaces ready in experimental [2], when could we expect a transition slot? [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653903 [ bug not closed though ] [2] http://pkg-kde.alioth.debian.org/redir/kde-sc-buildd-experimental?compact=1 -- Modestas Vainius mo...@debian.org signature.asc Description: This is a digitally signed message part.
Bug#653903: qt4-x11 multiarch NMUs
Hi, Alle venerdì 18 maggio 2012, Pino Toscano ha scritto: The other issue I'm aware of is the qt 4.8 breakage in the plugin loading system on 64 bits big endian architectures (so s390x and ppc64); this prevents kde4libs (and thus kde-runtime and pykde4 as said to be rebuilt in this bug) to compile, and could affect compilation (either because of broken multiarch paths in kdelibs5-dev, or because of crashes in helper applications that load plugins used during build) of other sources. A fixed qt4-x11 has been uploaded few hours ago and compiled fine on s390x; a few KDE sources among the failing ones have been given back (building fine) already, the only missing bits I can see are - kde-runtime (so we end the exiv2 transition for real) - kmymoney - kraft so could you (r-t or CCed s390x buildd admins) please binNMU kde-runtime for the exiv2 transition and give the other two back? Cyril, I remember you did a couple of days ago a list of the s390 - s390x differences; after updating it and considering the packages above, which other Qt/KDE sources are left? Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Re: Request removal for gnunet-fuse
Hi Artur, cc:ing the gnunet maintainer as he told me he was thinking of adoptiong these packages... (he's also aware of the upstream situation..) On Samstag, 2. Juni 2012, Artur Rona wrote: I'm requesting removal for package gnunet-fuse. It's orphaned, outdated and doesn't work anymore with gnunet 0.9.2. Also, there is a FTBFS bug (http://bugs.debian.org/674342). It doesn't make sense to keep it in testing. I've got in touch with upstream. They are going to re-work gnunet-fuse, but no at this moment. The next question is, whether we want to keep it in unstable as well? cheers, Holger -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201206022321.31802.hol...@layer-acht.org
Re: bts.turmzimmer.net not updating
Touko Korpela touko.korp...@iki.fi (02/06/2012): At least http://release.debian.org/ links to it. Commented out from index.html for now, thanks. Mraw, KiBi. signature.asc Description: Digital signature
Re: exim4 and the mysqlclient transition
Andreas Metzler ametz...@downhill.at.eu.org (02/06/2012): the PTS tells me that exim4 is involved in the mysqlclient transition. However afaict mysql-5.5 (libmysqlclient18, libmysqlclient-dev) has propagated (or been forced) to testing. Therefore an exim upload should not worsen the situation as it can be built against the newer version. Is this correct or should I refrain from uploading exim 4.80 to unstable? It's probably OK to upload. I'll deal with consequences if there's anything going wrong. Please upload, and thanks for checking with us. Mraw, KiBi. signature.asc Description: Digital signature
Bug#675434: marked as done (nmu: libnet-ssleay-perl_1.48-1)
Your message dated Sun, 3 Jun 2012 01:34:05 +0200 with message-id 20120602233405.ge27...@mraw.org and subject line Re: Bug#675434: nmu: libnet-ssleay-perl_1.48-1 has caused the Debian Bug report #675434, regarding nmu: libnet-ssleay-perl_1.48-1 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 ow...@bugs.debian.org immediately.) -- 675434: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=675434 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Release Team It was reported [1], that libnet-ssleay-perl does not report the correct constant value for SSL_OP_NO_TLSv1_1. There was the following change in openssl 1.0.1b-1: openssl (1.0.1b-1) unstable; urgency=high . * New upstream version - Remaps SSL_OP_NO_TLSv1_1, so applications linked to 1.0.0 can talk to servers supporting TLS 1.1 but not TLS 1.2 - Drop rc4_hmac_md5.patch, applied upstream [1]: http://bugs.debian.org/675424 After rebuilding libnet-ssleay-perl the problem is fixed. Would it be possible to schedule binnmu's for libnet-ssleay-perl? nmu libnet-ssleay-perl_1.48-1 . ALL . -m Rebuild for remap change for SSL_OP_NO_TLSv1_1 in openssl 1.0.1b-1 Many thanks in advance, Regards, Salvatore - -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/8 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJPyGbdAAoJEHidbwV/2GP+E7AQAImjQRluw+gtTh1tnPCBejVA v9nC959uKoXnRA+D7JlQnMCXQex8jJ/iNhqlJ14N4yMHFgOWa0H3BSHriPd2bDRO xzp60RgWXwKjbrX4Yv+z5fB3PRVPR6R0CFizC1vh+VKxrwkoZ2e9gpXDVArAQGrf ds2UylMBIuVIFhL51Y5kWhdBNePILgRpb1huyvG/+5x1qRvoFGbP+LKCZoSwVsGE jcDf7twMhL2nyPx0QkTmOsKJGIsqd6DpiGfu2grrQBUdXXDUM/89LWS2rKKKESNt HuYWazKeRXX1GIB3TojbHWkl63HXvVtbiFvA+my0T35Tez4Vgd1yckFCBxSOU8ov cnP7MiUaO+kVy2FUYWs0gjeS7cQwisZeEQgUnEdbDh/pSev3cU4efnmQ7FCK3dtw lbbEAhTUdY+r5aLtQNwNCh2QfW9U/Y+MRz1/looqeqMa6l+zgKLEHX4vvW2HZRBZ tmF3D5F+S1JppUmjv8vW7qb/nty6h2/eEpbu69ULZC0oAd86n+nmQe8IrxAAUO1z SF/hbJJIoztVwvn/3KnUlboyRvIugUeAuswADyK5HkfUmi/HPH5yy8JruQwzYS/Y wNS5Wu6kimNfwr0Cn1AgsJLiRLxsjdgIehZUcHyNCjtWDN+/2H77sShxQzzWqLgW C7SC2g9/fTTx8VP2D6Mn =j4Dy -END PGP SIGNATURE- ---End Message--- ---BeginMessage--- Hi, Kurt Roeckx k...@roeckx.be (02/06/2012): This change was made to make sure applications build against 1.0.0 can talk to a server that does TLS 1.1 but not TLS 1.2, as the changelog says. This is not something I like to change again, since it will cause problems. Everything build against 1.0.1 or 1.0.1a that cares about SSL_OP_NO_TLSv1_1 should be rebuild against 1.0.1b or later. If using the defines from the the 1.0.1 and 1.0.1a version, but using 1.0.1b or laster the SSL_OP_NO_TLSv1_1 will not have any effect. do we have better ways to detect that than maintainers noticing and pinging us? :/ Salvatore: done, thanks. Mraw, KiBi. signature.asc Description: Digital signature ---End Message---
Bug#675434: nmu: libnet-ssleay-perl_1.48-1
On Sun, Jun 03, 2012 at 01:34:05AM +0200, Cyril Brulebois wrote: Hi, Kurt Roeckx k...@roeckx.be (02/06/2012): This change was made to make sure applications build against 1.0.0 can talk to a server that does TLS 1.1 but not TLS 1.2, as the changelog says. This is not something I like to change again, since it will cause problems. Everything build against 1.0.1 or 1.0.1a that cares about SSL_OP_NO_TLSv1_1 should be rebuild against 1.0.1b or later. If using the defines from the the 1.0.1 and 1.0.1a version, but using 1.0.1b or laster the SSL_OP_NO_TLSv1_1 will not have any effect. do we have better ways to detect that than maintainers noticing and pinging us? :/ Scanning all reverse dependencies for that string? Kurt -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120602234438.ga4...@roeckx.be
Bug#675740: unblock: ffgtk/None
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: freeze-exception Please unblock package ffgtk I've been trying for a while to find a sponsor for ffgtk. The mentor who said they would do it informed me yesterday that it likely won't happen in time for the freeze. D'uh. Please grant a freeze exception or better yet, sponsor it ;-) http://bugs.debian.org/602723 (ITP) http://mentors.debian.net/debian/pool/main/f/ffgtk/ffgtk_0.8.1-1.dsc http://qa.debian.org/developer.php?login=f...@rolf.leggewie.biz unblock ffgtk/None -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120603025814.23611.59394.report...@www.google-analytics.com