On Thu, Aug 23, 2018 at 09:07:31AM +0200, Paul Gevers wrote: > Source: openssl > Version: 1.1.1~~pre9-1 > Severity: serious > User: debian...@lists.debian.org > Usertags: breaks > Control: affects -1 src:ganeti src:libnet-ssleay-perl src:ruby-openssl > Control: affects -1 src:m2crypto src:python2.7 src:python3.6 > Control: affects -1 src:python3.7 src:stunnel4 isync > Control: block -1 by 900161 906981 906955
> We file this bug to: > 1) allow reverse dependencies some time (we let you judge how long is > reasonable for the serious severity) to adapt to the new situation > 2) enable the openssl package to collect information which packages it > breaks and which version of those package fix the issue. With that > information the openssl package can add versioned Breaks As a status update, I count just six packages left in testing that are marked as blockers for this bug. (I could be wrong of course; double checking welcome.) - src:foolscap #898800: foolscap: FTBFS against openssl 1.1.1 - src:kdeconnect #907339: qtbase-opensource-src breaks kdeconnect autopkgtest possibly due to new openssl - src:m2crypto #897658: m2crypto: FTBFS against openssl 1.1.1 - src:python-boto #909545: SSL CERTIFICATE_VERIFY_FAILED when using gs (Google Cloud Storage) backend - src:kimap #907427: (kimap) openssl 1.1.1 breaks ssl tests - src:ruby-eventmachine #900160: ruby-eventmachine: FTBFS against openssl 1.1.1 Is it still useful to block openssl 1.1.1 testing migration with this bug? My personal concern is that the openssl testing/unstable situation has been the only blocker for a Perl 5.28 transition for quite some time now, and the buster transition deadline (2019-01-12) is less than three months away. -- Niko Tyni nt...@debian.org