Bug#827061: transition: openssl
On 2017-02-22 00:46:56 [+0100], Emilio Pozuelo Monfort wrote: > Thanks. Investigating the rest would be good. I guess most of those are just > for So I made a list by the time I received that email I just managed to work through it. I check most of them manually but by the end of it I hacked something that checked if any of the libssl1.0.2 symbols were used. Anyway. Most of them do not use libssl at all. A few use for a testsuite or load it at runtime. As next course of action I would make sure that each libssl1.0-dev package has a bug to move it back to libssl-dev for Buster. Is anything that blocks this bug from getting closed? My protocol: 389-ds-base-1.3.5.15 Seems not to use it, had it from netsmp alljoyn-gateway-1504-15.04~git20160606 seems not to use it. alljoyn-services-1504-15.04 seems not to use it. alljoyn-thin-client-1509-15.09a testsuite only probably alljoyn-thin-client-1604-16.0 testsuite only probably autofs-5.1.2 used once, probably no longer, as part of SASL bro-aux-0.38 seem to check for it but not use it cacti-spine-0.8.8h recommends openssl, probably for netsnmp reasons, does not user it. carbon-c-relay-2.5 used libssl-dev for crypto but not is selfcontained. citus-6.0.1.PGDG recommends using openssl-devel but does not use opessl connectome-workbench-1.2.3+git3-g7b83782 Recommends it, but it seems not using it. cryfs-0.9.6 Depends on it, could use it but does not. donkey-1.0.1 alt dep drumgizmo-0.9.11 testsuite only edbrowse-3.6.1 no longer using fis-gtm-6.3-000A got disabled, fixed for 1.1, not enabled. #856984 opened freebsd-utils-10.3~svn296373 #835806, not building at all gfarm2fs-1.2.9.9 no libssl usage (openssl but no dep) gnome-commander-1.4.8 seems not to use it gnutls28-3.5.8 testsuite guymager-0.8.3 depends on libssl for crypto reasons but use internal havp-0.92a does not need it hplip-3.16.11+repack0 looks like it does not use it httraqt-1.4.8 does not need it, just a frontend for httrack isc-dhcp-4.3.5: does not use it isdnutils-3.25+dfsg1: does not user it iva-1.0.8+ds: seems not to use it lcmaps-plugins-jobrep-1.5.3 header exports only, no libs functions. lgogdownloader-3.1 uses libcurl4-gnutls-dev, openssl crypto locks are nops with 1.1 libapache-mod-log-sql-1.100 depends on it, seems not to use it libasr-1.0.2 includes the header but does not make any use of it. libdap-3.18.2 seems not to need it, moved to libcurl4-gnutls-dev libfprint-0.6.0 does not use it, switched to nss libgwenhywfar-4.15.3 libssl not found due multiarch lib layout. libpam-ufpidentity-1.0 seems not to use it libsecp256k1-0.1~20161228 testsuite linux-grsec-4.9.10 does not look used. lnav-0.8.1 does not need it mcabber-1.0.4 does not use it mitmproxy-0.18.2 uses only openssl, not libssl-dev mysql++-3.2.2+pristine seems not to use it mysql-connector-c++_1.1.7 seems not to use it. openclonk-7.0 seems not to use it. openntpd seems not use it. Check for arc4random (libbsd) and has builtin sha support orafce-3.3.1 seems not to use it percona-xtrabackup-2.2.3 not in testing phantomjs-2.1.1+dfsg seems not to use it. pldebugger-9.5.0-10-gd663a19 seems not to use it profanity-0.5.0 seems not to use it. pychef-0.2.3 does not user it. pygresql-5.0.3 seems not to use it pyopenssl_16.2.0-1 does not need it. qpid-cpp-0.16 seems not to need it quassel-0.12.4 maybe not, uses to check if QT supports ssl quota-4.03 seems not to use it racket-6.7 loaded at runtime rhash-1.3.3 optional via dlopen and does not look for 1.0.2 or 1.1. signond-8.59 seems not to use it subcommander-2.0.0~b5p2 does not really use it, but prints openssl's version number telepathy-rakia-0.8.0 seems not to use it unar-1.10.1 is not using it. user-mode-linux-4.9-1um: needs it during compile only vdr-plugin-live-0.3.0+git20160123 seems not to need it vsearch-2.3.4 does not use it. websocketpp-0.7.0 ships header files wget-1.19.1 only udeb wimlib-1.11.0 could use crypto but does not wine-1.8.6 seems not to use it. wine-development-2.0 seems not to use it > Thanks, > Emilio Sebastian
Bug#827061: transition: openssl
On 2017-02-22 00:46:56 [+0100], Emilio Pozuelo Monfort wrote: > > There are 78 packages in the unkown state. The first few I looked could > > actually have their libssl-dev dependency dropped. khtml is the first > > one which looked wrong. I will open a bug about that later. I didn't get > > any further yet. > > Thanks. Investigating the rest would be good. I guess most of those are just > for > build-depends, but if there are any with bad depends (e.g. some -dev package > unnecessarily depending on libssl*-dev) it'd be good to fix that for stretch, > because of the conflicting libssl dev packages. We shouldn't have any of those FTBFS in archive so I guess you mean something outside of the archive. Anyway, if I find something I will act. > Sounds like things are under control now. The concern of -dev packages not > being > co-installable is a valid one, but I guess we'll have to live with that. Both openssl versions provide .pc files. So we could keep 1.1 as-is and force the libssl1.0-dev users to use what the .pc file(s) says which would include a different lib to link (say -lssl-1.0) and a different spot for the header files. We have 148 1.0 packages and 437 using 1.1 right now. That means we would have to touch 148 packages for that (and most packages I touched did not use the .pc file). I'm not sure it is worth it. Also having them not co-installable minimizes the risk that someone tries to pass openssl's struct from one package to the other. > Thanks, > Emilio Sebastian
Bug#827061: transition: openssl
On 22/02/17 00:28, Sebastian Andrzej Siewior wrote: > On 2017-01-28 19:37:09 [+0100], Julien Cristau wrote: >> At this point, it seems clear to me that we're getting nowhere fast. >> With the freeze looming in a few days, this is growing to be a very big >> risk for the stretch release. > > Where do we stand on the openssl transition from the perspective of > people who think it is not done yet? > > The transition tracker for 1.0 shows three packages red. They depend on > "libssl-dev | libssl1.0-dev" and it builds against 1.1. Do want them to > decide properly? I think that's alright. > The transition tracker for 1.1 shows 11 packages. Except for pyrit all > are out of testing and have more than just one RC bug which is not > relevant to the transition. And pyrit just didn't make it on i386. Hopefully it gets fixed, but otherwise it's not a key package so it will eventually get dropped from testing. > There are 78 packages in the unkown state. The first few I looked could > actually have their libssl-dev dependency dropped. khtml is the first > one which looked wrong. I will open a bug about that later. I didn't get > any further yet. Thanks. Investigating the rest would be good. I guess most of those are just for build-depends, but if there are any with bad depends (e.g. some -dev package unnecessarily depending on libssl*-dev) it'd be good to fix that for stretch, because of the conflicting libssl dev packages. Sounds like things are under control now. The concern of -dev packages not being co-installable is a valid one, but I guess we'll have to live with that. Thanks, Emilio
Bug#827061: transition: openssl
On 2017-01-28 19:37:09 [+0100], Julien Cristau wrote: > At this point, it seems clear to me that we're getting nowhere fast. > With the freeze looming in a few days, this is growing to be a very big > risk for the stretch release. Where do we stand on the openssl transition from the perspective of people who think it is not done yet? The transition tracker for 1.0 shows three packages red. They depend on "libssl-dev | libssl1.0-dev" and it builds against 1.1. Do want them to decide properly? The transition tracker for 1.1 shows 11 packages. Except for pyrit all are out of testing and have more than just one RC bug which is not relevant to the transition. And pyrit just didn't make it on i386. There are 78 packages in the unkown state. The first few I looked could actually have their libssl-dev dependency dropped. khtml is the first one which looked wrong. I will open a bug about that later. I didn't get any further yet. > Cheers, > Julien Sebastian
Bug#827061: transition: openssl
JFTR cyrus-sasl2 should not fail with openssl 1.0, so I'll fix that quickly if needed. O. -- Ondřej Surý Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server Knot Resolver (https://www.knot-resolver.cz/) – secure, privacy-aware, fast DNS(SEC) resolver Vše pro chleba (https://vseprochleba.cz) – Mouky ze mlýna a potřeby pro pečení chleba všeho druhu On Fri, Feb 3, 2017, at 13:45, Sebastian Andrzej Siewior wrote: > On 2017-02-01 22:18:07 [+0100], Sebastian Andrzej Siewior wrote: > > Currently I am rebuilding testing with the same set of package against > > libssl-dev provided by libssl1.0-dev. After that I retry the failed > > packages above where I am not sure why they failed (mostly I suspect the > > parallel) case. > > Do you want a complete testing rebuild or another set of packages? > > it is at [0] and a retry of all failed with -j1 at [1]. I had just a > quick look: > - perl fails in the test suite but that ist "okay". It builds against > 1.0 but it B-D are built against 1.1 and perl exposes the openssl ABI > as-is. So rebuilding it in the right order should avoid it. > > - a few packages like cfengine3, ldns, freelan, duo-unix, dogecoin, > dsniff and cyrus-sasl2 seem like they compile with 1.1 but do not > compile against 1.0 since they expect 1.1 functions to be around. > There may be more, I had a quick look. The build succeeded with 1.1 > earlier. > > - some of globus-* and lcmaps-* packages fail and I am not sure if they > can't deal with 1.0 anymore or if it is similar to perl where > everything has to be moved to 1.0 in the right order. > > [0] > https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0/ > [1] > https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0-retry/ > > > > Cheers, > > > Julien > > Sebastian
Bug#827061: transition: openssl
On 2017-02-01 22:18:07 [+0100], Sebastian Andrzej Siewior wrote: > Currently I am rebuilding testing with the same set of package against > libssl-dev provided by libssl1.0-dev. After that I retry the failed > packages above where I am not sure why they failed (mostly I suspect the > parallel) case. > Do you want a complete testing rebuild or another set of packages? it is at [0] and a retry of all failed with -j1 at [1]. I had just a quick look: - perl fails in the test suite but that ist "okay". It builds against 1.0 but it B-D are built against 1.1 and perl exposes the openssl ABI as-is. So rebuilding it in the right order should avoid it. - a few packages like cfengine3, ldns, freelan, duo-unix, dogecoin, dsniff and cyrus-sasl2 seem like they compile with 1.1 but do not compile against 1.0 since they expect 1.1 functions to be around. There may be more, I had a quick look. The build succeeded with 1.1 earlier. - some of globus-* and lcmaps-* packages fail and I am not sure if they can't deal with 1.0 anymore or if it is similar to perl where everything has to be moved to 1.0 in the right order. [0] https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0/ [1] https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-against-openssl1.0-retry/ > > Cheers, > > Julien Sebastian
Bug#827061: transition: openssl
On Thu, Feb 02, 2017 at 09:49:15PM +0100, Sebastian Andrzej Siewior wrote: > what is wrong with passing -j16 to sbuild? Other packages, that do not > support parallel building, don't do it. yeah, exactly. -- cheers, Holger signature.asc Description: Digital signature
Bug#827061: transition: openssl
On 2017-02-02 22:26:35 [+0200], Adrian Bunk wrote: > The kannel package does not claim to support parallel building. > > If you attempt parallel building on that, > then any build failures are your fault. what is wrong with passing -j16 to sbuild? Other packages, that do not support parallel building, don't do it. > cu > Adrian Sebastian
Bug#827061: transition: openssl
On Thu, Feb 02, 2017 at 09:09:56PM +0100, Sebastian Andrzej Siewior wrote: >... > > You can go to http://reproducible.debian.net/$srcpkgname and see for > > yourself > > whether they build fine in our environment. If they do, you can rule out > > "parallel" as causing this… > > I see. I looked at kannel. The -j1 version: >... > That "flow object not accepted by port" seems not to be the issue but > the fact, that wtls.tmp is reused and probably removed too early. The kannel package does not claim to support parallel building. If you attempt parallel building on that, then any build failures are your fault. > Sebastian cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#827061: transition: openssl
On 2017-02-02 16:54:08 [+], Holger Levsen wrote: > > I'm surprised to see that many packages failing to build in parallel, as we're > building everything in parallel and I dont remember such failures recentl.y So retried them with -j1 [0] and: - passed: boxbackup 0.11.1~r2837-4 erlang 19.2.1+dfsg-1 gridsite 2.3.2-3 kannel-sqlbox 0.7.2-4 kannel 1.4.4-4 mailsync 5.2.2-3.1 netkit-telnet-ssl 0.17.41+0.2-2 nmh 1.6-16 postfix 3.1.4-3 pure-ftpd 1.0.43-3 qtwebsockets-opensource-src 5.7.1~20161021-4 r-cran-rsclient 0.7-3-2 rserve 1.7-3-3 vde2 2.3.2+r586-2.1 - still failing: mongodb 3.2.11-2 nova 14.0.0-3 openvswitch 2.6.2~pre+git20161223-3 pyrit 0.4.0-7 python-asyncssh 1.8.1-2 ruby2.3 2.3.3-1 and the failing ones do not look obvious. [0] https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing-retry/ > You can go to http://reproducible.debian.net/$srcpkgname and see for yourself > whether they build fine in our environment. If they do, you can rule out > "parallel" as causing this… I see. I looked at kannel. The -j1 version: |sed "s/#FIGTYPE#/.png/;s/#VERSION#/1.4.4/;s/#DATE#/2016-12-03/;s/#DRAFTS#/IGNORE/" doc/wtls/wtls.xml > doc/wtls/wtls.tmp |openjade -V nochunks -t sgml -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/html/docbook.dsl /usr/share/xml/declaration/xml.dcl doc/wtls/wtls.tmp > doc/wtls/wtls.html |rm -f doc/wtls/wtls.tmp … |sed "s/#FIGTYPE#/.ps/;s/#VERSION#/1.4.4/;s/#DATE#/2016-12-03/;s/#DRAFTS#/IGNORE/" doc/wtls/wtls.xml > doc/wtls/wtls.tmp |cd `dirname doc/wtls/wtls.xml` && openjade -o `basename doc/wtls/wtls`.rtf -t rtf -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/print/docbook.dsl /usr/share/xml/declaration/xml.dcl `basename doc/wtls/wtls`.tmp |rm -f doc/wtls/wtls.tmp and the -j16: |sed "s/#FIGTYPE#/.png/;s/#VERSION#/1.4.4/;s/#DATE#/2016-12-03/;s/#DRAFTS#/IGNORE/" doc/wtls/wtls.xml > doc/wtls/wtls.tmp |openjade -o doc/wtls/wtls.tex -t tex -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/print/docbook.dsl /usr/share/xml/declaration/xml.dcl doc/wtls/wtls.tmp |openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbttlpg.dsl:2722:6:E: flow object not accepted by port; only display flow objects accepted |openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbttlpg.dsl:2722:6:E: flow object not accepted by port; only display flow objects accepted |openjade:/usr/share/sgml/docbook/stylesheet/dsssl/modular/print/dbttlpg.dsl:2722:6:E: flow object not accepted by port; only display flow objects accepted |rm -f doc/wtls/wtls.tmp |openjade -o doc/alligata/alligata.tex -t tex -d /usr/share/sgml/docbook/stylesheet/dsssl/modular/print/docbook.dsl /usr/share/xml/declaration/xml.dcl doc/alligata/alligata.tmp |rm -f doc/wtls/wtls.tmp … |ranlib libwmlscript.a |openjade:E: cannot find "doc/wtls/wtls.tmp"; tried "doc/wtls/wtls.tmp", "/usr/local/share/sgml/doc/wtls/wtls.tmp", "/usr/share/sgml/doc/wtls/wtls.tmp" |openjade:/usr/share/xml/declaration/xml.dcl:190:1:E: end of document in prolog |rm -f doc/wtls/wtls.tmp That "flow object not accepted by port" seems not to be the issue but the fact, that wtls.tmp is reused and probably removed too early. > -- > cheers, > Holger Sebastian
Bug#827061: transition: openssl
On Wed, Feb 01, 2017 at 10:18:07PM +0100, Sebastian Andrzej Siewior wrote: > - boxbackup_0.11.1~r2837-4 > parallel issue? > - erlang 1:19.2.1+dfsg-1 > parallel issue? > - kannel 1.4.4-4 > parallel issue? > - kannel-sqlbox 0.7.2-4 > parallel issue? > - mailsync 5.2.2-3.1 > parallel? > - netkit-telnet-ssl 0.17.41+0.2-2 > parallel? > - postfix 3.1.4-3 > parallel? > - pure-ftpd 1.0.43-3 > parallel? > - pyrit 0.4.0-7 > parallel? testsuite > - r-cran-rsclient 0.7-3-2 > parallel? > - rserve 1.7-3-3 > parallel? > - krat 1:2.2cvs20100105-true-dfsg-6.1 > parallel? I'm surprised to see that many packages failing to build in parallel, as we're building everything in parallel and I dont remember such failures recentl.y You can go to http://reproducible.debian.net/$srcpkgname and see for yourself whether they build fine in our environment. If they do, you can rule out "parallel" as causing this… -- cheers, Holger signature.asc Description: Digital signature
Bug#827061: transition: openssl
On 2017-01-28 19:37:09 [+0100], Julien Cristau wrote: > At this point, it seems clear to me that we're getting nowhere fast. > With the freeze looming in a few days, this is growing to be a very big > risk for the stretch release. I rebuild testing, with the subset of: grep-dctrl -FDepends libssl1.0.2 Packages -sSource -n | awk '{print $1}' > List grep-dctrl -FDepends libssl1.1 Packages -sSource -n | awk '{print $1}' >> List grep-dctrl -FDepends openssl Packages -sSource -n | awk '{print $1}' >> List grep-dctrl -FBuild-Depends,Build-Depends-Indep -w libssl-dev -o -w openssl Sources -sPackage -n >> List grep-dctrl -FBuild-Depends,Build-Depends-Indep -w libssl1.0-dev Sources -sPackage -n >> List as of today. The result is at [0]. Let me go over results of the failed packages: - bind9 1:9.10.3.dfsg.P4-10.1 1.1 issue, unstable has 1:9.10.3.dfsg.P4-11 with libssl1.0-dev - boxbackup_0.11.1~r2837-4 parallel issue? - clamav 0.99.2+dfsg-5 #852894, curl related - erlang 1:19.2.1+dfsg-1 parallel issue? - gridsite 2.3.2-2 /usr/bin/ld: cannot find -lgridsite unstable has newer version - gvpe 2.25-3 missing zlib-dev, #850983, unstable has fixed version - httest 2.4.8-1.1 1.1 issue, unstable has 2.4.18-1.1 with libssl1.0-dev - kamailio 4.4.4-1 missing dependcy, #852905, unstable has fixed version - kannel 1.4.4-4 parallel issue? - kannel-sqlbox 0.7.2-4 parallel issue? - lcmaps-plugins-verify-proxy 1.5.4-2 1.1 issue, unstable has fixed version - lcmaps-plugins-voms 1.6.2-2 1.1 issue, unstable has fixed version - m2crypto 0.24.0-1 1.1 issue, no fix yet (#827068) - mailsync 5.2.2-3.1 parallel? - mongodb 1:3.2.11-2 testsuite killed - netkit-telnet-ssl 0.17.41+0.2-2 parallel? - nmh 1.6-16 most of testsuite fails? - nova 2:14.0.0-3 testsuite fails? - ntp 1:4.2.8p9+dfsg-2 not openssl related, fixed in unstable, #851803 - openvswitch 2.6.2~pre+git20161223-3 testsuite failure, probably due to br0 on the test box. - php7.0 7.0.14-2 curl check, unstable has the fixed version - postfix 3.1.4-3 parallel? - pure-ftpd 1.0.43-3 parallel? - pyrit 0.4.0-7 parallel? testsuite - python-asyncssh testsuite, X? - qtwebsockets-opensource-src 5.7.1~20161021-4 testsuite failed - r-cran-rsclient 0.7-3-2 parallel? - rserve 1.7-3-3 parallel? - ruby2.3 2.3.3-1 parallel?, testsuite failure, maybe harmless - sbsigntool 0.6-3.1 linker failre, unstable has fixed, #842446 - swi-prolog 7.2.3+dfsg-5 fails the testsuite, #852892 - sx 2.0+ds-3 fails the testsuite, #852888 - krat 1:2.2cvs20100105-true-dfsg-6.1 parallel? - tpm-tools 1.3.8-2 1.1 related, looks like two RC bugs related - vde2 2.3.2+r586-2.1 parallal? - wpa 2.5-2+v2.4-3 1.1 related, unstable should be fixed. Currently I am rebuilding testing with the same set of package against libssl-dev provided by libssl1.0-dev. After that I retry the failed packages above where I am not sure why they failed (mostly I suspect the parallel) case. Do you want a complete testing rebuild or another set of packages? [0] https://breakpoint.cc/openssl-rebuild/2017-02-01-rebuild-testing/ > Cheers, > Julien Sebastian
Bug#827061: transition: openssl
On Sat, Jan 28, 2017 at 07:37:09PM +0100, Julien Cristau wrote: > On Sat, Jun 11, 2016 at 20:59:53 +0200, Kurt Roeckx wrote: > > > OpenSSL will soon release a new upstream version with a new > > soname. This new version will break various packages, see: > > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > > > I'm currently not sure when the release will be ready. I would > > like to start this transition as soon as possible, but probably > > after it's actually released. I don't expect this to take long. > > > At this point, it seems clear to me that we're getting nowhere fast. > With the freeze looming in a few days, this is growing to be a very big > risk for the stretch release. Why? The last time I saw it status it was down to something like five packages in question. What new RC bugs related to the transition? Cheers, Moritz
Bug#827061: transition: openssl
On Sat, Jun 11, 2016 at 20:59:53 +0200, Kurt Roeckx wrote: > OpenSSL will soon release a new upstream version with a new > soname. This new version will break various packages, see: > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > I'm currently not sure when the release will be ready. I would > like to start this transition as soon as possible, but probably > after it's actually released. I don't expect this to take long. > At this point, it seems clear to me that we're getting nowhere fast. With the freeze looming in a few days, this is growing to be a very big risk for the stretch release. I believe we should cut our losses, go back to shipping libssl-dev as 1.0.2 for stretch, and rebuild the world. I think this is 1) less work than actually getting ourselves out of the current mess, and 2) likely to get us to a better state for stretch users, who won't have to deal with half the archive's -dev package indirectly conflicting with the other half. I'm willing to prepare a new openssl1.0 package to take over libssl-dev and openssl binaries. Cheers, Julien signature.asc Description: PGP signature
Bug#827061: transition: openssl: Unrelated updates to rdep packages?
On 10/12/16 14:08, Christian Seiler wrote: > Hi, > > On 10/26/2016 10:55 AM, Emilio Pozuelo Monfort wrote: >> Control: tags -1 confirmed > > I have a quick question now that the transition is ongoing: is it OK > for me to upload a new version of open-isns (B-D: libssl-dev) that's > unrelated to this transition? (New upstream version, some debconf > translations; all severity <= normal.) Both OpenSSL 1.1 and 1.0 have > migrated to testing a while back, and open-isns compiles with either > one of those (though it hasn't been binNMU'd yet), so I don't think > this will cause any problems - but the text in the package tracker > says I should wait with unrelated uploads until the transition is > completed, so I thought I'd ask first. Yes, that is fine. We should probably update the transition trackers so they aren't exported and the PTS doesn't show that warning (export = false in the .ben files). Cheers, Emilio
Bug#827061: transition: openssl: Unrelated updates to rdep packages?
Hi, On 10/26/2016 10:55 AM, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed I have a quick question now that the transition is ongoing: is it OK for me to upload a new version of open-isns (B-D: libssl-dev) that's unrelated to this transition? (New upstream version, some debconf translations; all severity <= normal.) Both OpenSSL 1.1 and 1.0 have migrated to testing a while back, and open-isns compiles with either one of those (though it hasn't been binNMU'd yet), so I don't think this will cause any problems - but the text in the package tracker says I should wait with unrelated uploads until the transition is completed, so I thought I'd ask first. Thanks! Regards, Christian
Bug#827061: transition: openssl
On Thu, Dec 01, 2016 at 09:15:44PM +0100, Sebastian Andrzej Siewior wrote: > On 2016-12-01 00:52:59 [+0200], Adrian Bunk wrote: > > Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev" > > give a reasonably small superset of all packages that need a binNMU? > > Do you mean something like > is_affected = .depends ~ /libssl1\.0\.2/ & ! .build-depends ~ > /libssl1.0-dev/; > > which results in [0] ? This gives you all packages with a B-D libssl-dev > and D libssl1.0.2 like [1] but also lists package which do not depend on > libssl-dev. >... Yes, that's what I had in mind. Note that this is a superset of all packages requiring binNMUs, and it is not expected to become all-green in stretch. > Sebastian cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#827061: transition: openssl
On 2016-12-01 00:52:59 [+0200], Adrian Bunk wrote: > Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev" > give a reasonably small superset of all packages that need a binNMU? Do you mean something like is_affected = .depends ~ /libssl1\.0\.2/ & ! .build-depends ~ /libssl1.0-dev/; which results in [0] ? This gives you all packages with a B-D libssl-dev and D libssl1.0.2 like [1] but also lists package which do not depend on libssl-dev. Otherwise please give a ben config and will add it. [0] https://breakpoint.cc/openssl-trans/html/openssl_need_upload.html [1] https://breakpoint.cc/openssl-trans/html/openssl.html > cu > Adrian Sebastian
Bug#827061: transition: openssl
On Wed, Nov 30, 2016 at 07:43:36PM +0100, Sebastian Andrzej Siewior wrote: > On 2016-11-05 21:59:27 [+0100], Sebastian Andrzej Siewior wrote: > > I've been playing with ben. I tried a few things and this is the best I > > was able to achieve [0]: > > > > title = "openssl 1.0"; > > is_affected = .build-depends ~ /libssl1.0-dev/; > > is_good = .depends ~ /libssl1.0.2/; > > is_bad = .depends ~ /libssl1.1/; > > > > And > > > > title = "openssl 1.1"; > > is_affected = .build-depends ~ /libssl-dev/; > > is_good = .depends ~ /libssl1\.1/; > > is_bad = .depends ~ /libssl1\.0\.2/; > > This does not cover packages which link against 1.0.2 but do not depend > on libssl-dev (but inherit their dependencies). > So it is up to you what you setup but something should be done because > the auto tracker is gone. Wouldn't "depends on libssl1.0.2 and does not build-depend on libssl1.0-dev" give a reasonably small superset of all packages that need a binNMU? > Sebastian cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#827061: transition: openssl
On 2016-11-05 21:59:27 [+0100], Sebastian Andrzej Siewior wrote: > I've been playing with ben. I tried a few things and this is the best I > was able to achieve [0]: > > title = "openssl 1.0"; > is_affected = .build-depends ~ /libssl1.0-dev/; > is_good = .depends ~ /libssl1.0.2/; > is_bad = .depends ~ /libssl1.1/; > > And > > title = "openssl 1.1"; > is_affected = .build-depends ~ /libssl-dev/; > is_good = .depends ~ /libssl1\.1/; > is_bad = .depends ~ /libssl1\.0\.2/; This does not cover packages which link against 1.0.2 but do not depend on libssl-dev (but inherit their dependencies). So it is up to you what you setup but something should be done because the auto tracker is gone. Sebastian
Bug#827061: transition: openssl - will both 1.0.x and 1.1.x be in Stretch?
Hi, I'm maintaining two packages affected by this transition. So far, I've just been monitoring the situation, as I share many of the concerns that have been raised on -devel. Is it an acceptable solution to instead build-depend on libbsl1.0-dev, downgrade the severity of the FTBFS with 1.1.0 bug to important, and unblock the transition by it? Many thanks and regards Afif -- Afif Elghraoui | عفيف الغراوي http://afif.ghraoui.name
Bug#827061: transition: openssl
On 2016-10-26 10:55:19 [+0200], Emilio Pozuelo Monfort wrote: > So let's do this. Let's try to get it finished and only ship openssl 1.1. We > still have three months until the full freeze, and depending on how many > packages (and which ones, for risk management etc) are left to be fixed after > that, I may be happy to grant exceptions. But worst case we just ship both. I've been playing with ben. I tried a few things and this is the best I was able to achieve [0]: title = "openssl 1.0"; is_affected = .build-depends ~ /libssl1.0-dev/; is_good = .depends ~ /libssl1.0.2/; is_bad = .depends ~ /libssl1.1/; And title = "openssl 1.1"; is_affected = .build-depends ~ /libssl-dev/; is_good = .depends ~ /libssl1\.1/; is_bad = .depends ~ /libssl1\.0\.2/; The first one will keep a list of all packages that want to stay with 1.0.2. The bad state of the second tracker should keep track of everything that needs action. You might also want to add [1] if you think it is usefull here. I noticed that people close the bug referenced in [1] and stay with 1.0.2. Shouldn't they just unblock this transition bug and downgrade severity to important? [0] it seems ben can't match something like ".build-depends ~ /libssl-dev/ & .depends ~ /libssl1.0.2/" but this would allow to keep everything in one page. [1] https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans;users=pkg-openssl-devel-requ...@lists.alioth.debian.org > Cheers, > Emilio Sebastian
Bug#827061: transition: openssl
On Sun, Oct 30, 2016 at 10:18:32PM +0200, Adrian Bunk wrote: > > If everything that is important in 1.1.0 should be used by all > users of OpenSSL in stretch, then the best solution for stretch > is to ship only 1.0.2 and add all desired features there. And I guess you're going to add all those features, and support them? Kurt
Bug#827061: transition: openssl
Disclaimer: I am not a member of the release team, and I am only speaking for myself. On Sat, Oct 29, 2016 at 02:28:12AM +0200, Kurt Roeckx wrote: >... > I think the most important new security feature in the 1.1.0 > version is the extended master secret support. There are also a > bunch of others like the chacha20-poly1305 and x25519, but they're > less important. All TLS using applications really should start > ussing the EMS, not just a few that want to switch to 1.1. This implies that OpenSSL 1.0.2 in stretch has to support EMS. Reality is that a significant part of the archive will likely use 1.0.2 in stretch, and planning should not be based on the unlikely case that everything compiles and works smoothly with 1.1.0 The soft freeze is only 2 months away, and therefore a complete transition to 1.1.0 in stretch would imply that libssl1.0.2 must be removed from testing in November if it should not delay the whole release - I'd expect there will be plenty of runtime bugs in both OpenSSL itself and the 1.1.0 support of various users that will require debugging and fixing, and runtime testing of everything has to start ASAP. If everything that is important in 1.1.0 should be used by all users of OpenSSL in stretch, then the best solution for stretch is to ship only 1.0.2 and add all desired features there. 1.0.2 is also LTS, and has upstream security support for an additional 16 months after upstream support for 1.1.0 has ended. I am aware that this is not a nice solution, but since there does not seem to be a realistic 1.1.0-only solution without impact on the release schedule it might be the best among the available options. > Kurt cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#827061: transition: openssl
On Wed, Oct 26, 2016 at 10:55:19AM +0200, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 25/10/16 20:09, Moritz Muehlenhoff wrote: > > On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: > >> On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > >>> > >>> I'm sorry but I'm going to have to nack this for Stretch, as much as I > >>> like to > >>> approve transitions and get new stuff in. I have looked at the opened > >>> bugs and > >>> I'm afraid this still is too disruptive. I have noticed that you have > >>> forwarded > >>> some of them and sent patches, and I appreciate that. We can do this > >>> early in > >>> the Buster cycle, so let's look at the status of this and prepare for the > >>> transition when Stretch gets released. > >> > >> Is having 2 version of OpenSSL in Stretch an option? > > > > We've discussed this within the security team and we'd be fine with > > a one-time exception to have two openssl releases in stretch; the API > > changes are clearly too invasive to cover the entire Debian archive, > > but 1.1 also carries sufficiently important new features (like support > > for chacha20/poly1305) to warrant the extra complexity. > > > > (It's the release team's call of course). > > 19:46 < nthykier> pochu: seen jmm_ reply to the libssl thread? > 19:46 < jcristau> adsb: yay for binary debdiffs in q-v! thanks a bunch. > 19:46 < pochu> yep > 19:47 < pochu> nthykier: so my concern was there was a big risk that we > wouldn't finish the transition intime, delaying the release. but if the > security > team is fine with (potentially, as I'll try not to) shipping both, then we > should be fine, and I think I'll ack it > 19:48 < pochu> of course we'll still try to get rid of the old one > 19:48 < nthykier> ack, I think that just made me pro on doing that as well > 19:48 < pochu> cool, good to see we're on the same page > > So let's do this. Let's try to get it finished and only ship openssl 1.1. We > still have three months until the full freeze, and depending on how many > packages (and which ones, for risk management etc) are left to be fixed after > that, I may be happy to grant exceptions. But worst case we just ship both. > > But please, wait a little bit so that we can sort out the PIE fallout. You can > start preparing the updates and upload to experimental to clear NEW if you > want. > We'll let you know once it's ok to upload to sid. So it has been suggested that we keep the libssl-dev package at the 1.0.2 package and create a new -dev package for the 1.1 version. We could then lower the severity of the bugs to important again, and only the packages wanting to make use of 1.1 could switch then. I think the most important new security feature in the 1.1.0 version is the extended master secret support. There are also a bunch of others like the chacha20-poly1305 and x25519, but they're less important. All TLS using applications really should start ussing the EMS, not just a few that want to switch to 1.1. Kurt
Bug#827061: transition: openssl
On Tue, Oct 25, 2016 at 08:09:06PM +0200, Moritz Muehlenhoff wrote: > On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: > > On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > > > > > > I'm sorry but I'm going to have to nack this for Stretch, as much as I > > > like to > > > approve transitions and get new stuff in. I have looked at the opened > > > bugs and > > > I'm afraid this still is too disruptive. I have noticed that you have > > > forwarded > > > some of them and sent patches, and I appreciate that. We can do this > > > early in > > > the Buster cycle, so let's look at the status of this and prepare for the > > > transition when Stretch gets released. > > > > Is having 2 version of OpenSSL in Stretch an option? > > We've discussed this within the security team and we'd be fine with > a one-time exception to have two openssl releases in stretch; the API > changes are clearly too invasive to cover the entire Debian archive, > but 1.1 also carries sufficiently important new features (like support > for chacha20/poly1305) to warrant the extra complexity. What are actually the exact technical benefits of 1.1 that are relevant for the software in stretch? Which new features are desirable for all OpenSSL-using software, and for which new features is it a good option that only software using these features opts in to using 1.1? The only way to make chacha20/poly1305 available for all OpenSSL-using code in stretch would be to patch 1.0.2. Patches are available and LibreSSL ships this since the original release in July 2014, so that should be doable. Improvements to the defaults like #728504 (disable RC4 by default) can be backported to 1.0.2 even more easily. And these are things that really should be done in any case, unless stretch ships without 1.0.2 What is the situation regarding other important 1.1 features? > (It's the release team's call of course). > > Cheers, > Moritz cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed
Bug#827061: transition: openssl
On Wed, Oct 26, 2016 at 10:55:19 +0200, Emilio Pozuelo Monfort wrote: > So let's do this. Let's try to get it finished and only ship openssl 1.1. We > still have three months until the full freeze Hi, packages that currently FTBFS will be removed from testing in 2 weeks. The freeze deadline for re-entry is January 5th. With the migration delay the fixed package should be uploaded until the end of December, where may people will be on holiday I guess (both Debian and Upstream developers). So I think it's desirable for many maintainers to have a fixed package in Sid before Christmas or they will have to ask for a freeze exception. I'd be glad if this is announced more prominent, e.g on the debian-devel-announce mailing list. Regards, Tino
Bug#827061: transition: openssl
On 2016-10-26 21:31:26 [+0200], Kurt Roeckx wrote: > > Is this situation > > supported or should we expect things to break? This can easily happen if an > > app > > links against a library libA which uses openssl 1.0, and against libB which > > uses > > openssl 1.1. > > When linking you actually get a warning. > > As far as I know, it should only break when they use dlopen(). > They most likely won't be using dlvsym() in that case and then it > can pick any version. It could of course also break if they do > very weird things. One of the weird things would be probably if libA allocate a SSL pointer and passes it to libB. > Kurt Sebastian
Bug#827061: transition: openssl
On Wed, Oct 26, 2016 at 08:53:56PM +0200, Emilio Pozuelo Monfort wrote: > > Adrian Bunk asked whether mixing both OpenSSL versions into the same address > space works fine. Is OpenSSL using symbol versioning? Yes, and all symbols have a different version name in 1.0.2 and 1.1.0. (What is actually the important thing.) > Is this situation > supported or should we expect things to break? This can easily happen if an > app > links against a library libA which uses openssl 1.0, and against libB which > uses > openssl 1.1. When linking you actually get a warning. As far as I know, it should only break when they use dlopen(). They most likely won't be using dlvsym() in that case and then it can pick any version. It could of course also break if they do very weird things. But I guess we'll have to see if something breaks or not. Kurt
Bug#827061: transition: openssl
On 26/10/16 10:55, Emilio Pozuelo Monfort wrote: > Control: tags -1 confirmed > > On 25/10/16 20:09, Moritz Muehlenhoff wrote: >> On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: >>> On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: I'm sorry but I'm going to have to nack this for Stretch, as much as I like to approve transitions and get new stuff in. I have looked at the opened bugs and I'm afraid this still is too disruptive. I have noticed that you have forwarded some of them and sent patches, and I appreciate that. We can do this early in the Buster cycle, so let's look at the status of this and prepare for the transition when Stretch gets released. >>> >>> Is having 2 version of OpenSSL in Stretch an option? >> >> We've discussed this within the security team and we'd be fine with >> a one-time exception to have two openssl releases in stretch; the API >> changes are clearly too invasive to cover the entire Debian archive, >> but 1.1 also carries sufficiently important new features (like support >> for chacha20/poly1305) to warrant the extra complexity. >> >> (It's the release team's call of course). > > 19:46 < nthykier> pochu: seen jmm_ reply to the libssl thread? > 19:46 < jcristau> adsb: yay for binary debdiffs in q-v! thanks a bunch. > 19:46 < pochu> yep > 19:47 < pochu> nthykier: so my concern was there was a big risk that we > wouldn't finish the transition intime, delaying the release. but if the > security > team is fine with (potentially, as I'll try not to) shipping both, then we > should be fine, and I think I'll ack it > 19:48 < pochu> of course we'll still try to get rid of the old one > 19:48 < nthykier> ack, I think that just made me pro on doing that as well > 19:48 < pochu> cool, good to see we're on the same page > > So let's do this. Let's try to get it finished and only ship openssl 1.1. We > still have three months until the full freeze, and depending on how many > packages (and which ones, for risk management etc) are left to be fixed after > that, I may be happy to grant exceptions. But worst case we just ship both. > > But please, wait a little bit so that we can sort out the PIE fallout. You can > start preparing the updates and upload to experimental to clear NEW if you > want. > We'll let you know once it's ok to upload to sid. > > BTW I noticed Fedora has started this transition as well, so they may have > some > patches that we are missing in the BTS. > > Also, please bump all the bugs to serious. Adrian Bunk asked whether mixing both OpenSSL versions into the same address space works fine. Is OpenSSL using symbol versioning? Is this situation supported or should we expect things to break? This can easily happen if an app links against a library libA which uses openssl 1.0, and against libB which uses openssl 1.1. Cheers, Emilio
Bug#827061: transition: openssl
Control: tags -1 confirmed On 25/10/16 20:09, Moritz Muehlenhoff wrote: > On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: >> On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: >>> >>> I'm sorry but I'm going to have to nack this for Stretch, as much as I like >>> to >>> approve transitions and get new stuff in. I have looked at the opened bugs >>> and >>> I'm afraid this still is too disruptive. I have noticed that you have >>> forwarded >>> some of them and sent patches, and I appreciate that. We can do this early >>> in >>> the Buster cycle, so let's look at the status of this and prepare for the >>> transition when Stretch gets released. >> >> Is having 2 version of OpenSSL in Stretch an option? > > We've discussed this within the security team and we'd be fine with > a one-time exception to have two openssl releases in stretch; the API > changes are clearly too invasive to cover the entire Debian archive, > but 1.1 also carries sufficiently important new features (like support > for chacha20/poly1305) to warrant the extra complexity. > > (It's the release team's call of course). 19:46 < nthykier> pochu: seen jmm_ reply to the libssl thread? 19:46 < jcristau> adsb: yay for binary debdiffs in q-v! thanks a bunch. 19:46 < pochu> yep 19:47 < pochu> nthykier: so my concern was there was a big risk that we wouldn't finish the transition intime, delaying the release. but if the security team is fine with (potentially, as I'll try not to) shipping both, then we should be fine, and I think I'll ack it 19:48 < pochu> of course we'll still try to get rid of the old one 19:48 < nthykier> ack, I think that just made me pro on doing that as well 19:48 < pochu> cool, good to see we're on the same page So let's do this. Let's try to get it finished and only ship openssl 1.1. We still have three months until the full freeze, and depending on how many packages (and which ones, for risk management etc) are left to be fixed after that, I may be happy to grant exceptions. But worst case we just ship both. But please, wait a little bit so that we can sort out the PIE fallout. You can start preparing the updates and upload to experimental to clear NEW if you want. We'll let you know once it's ok to upload to sid. BTW I noticed Fedora has started this transition as well, so they may have some patches that we are missing in the BTS. Also, please bump all the bugs to serious. Cheers, Emilio
Bug#827061: transition: openssl
On Wed, Oct 19, 2016 at 10:44:08PM +0200, Kurt Roeckx wrote: > On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > > > > I'm sorry but I'm going to have to nack this for Stretch, as much as I like > > to > > approve transitions and get new stuff in. I have looked at the opened bugs > > and > > I'm afraid this still is too disruptive. I have noticed that you have > > forwarded > > some of them and sent patches, and I appreciate that. We can do this early > > in > > the Buster cycle, so let's look at the status of this and prepare for the > > transition when Stretch gets released. > > Is having 2 version of OpenSSL in Stretch an option? We've discussed this within the security team and we'd be fine with a one-time exception to have two openssl releases in stretch; the API changes are clearly too invasive to cover the entire Debian archive, but 1.1 also carries sufficiently important new features (like support for chacha20/poly1305) to warrant the extra complexity. (It's the release team's call of course). Cheers, Moritz
Bug#827061: transition: openssl
On Mon, Oct 17, 2016 at 08:52:31PM +0200, Emilio Pozuelo Monfort wrote: > > I'm sorry but I'm going to have to nack this for Stretch, as much as I like to > approve transitions and get new stuff in. I have looked at the opened bugs and > I'm afraid this still is too disruptive. I have noticed that you have > forwarded > some of them and sent patches, and I appreciate that. We can do this early in > the Buster cycle, so let's look at the status of this and prepare for the > transition when Stretch gets released. Is having 2 version of OpenSSL in Stretch an option? I could upload an openssl102 source package that provides an libssl1.0.2-dev package, so that packages that aren't ready to move to the 1.1.0 version can build-depend on that instead. Kurt
Bug#827061: transition: openssl
Hi Kurt, On 12/10/16 22:47, Kurt Roeckx wrote: > On Sun, Sep 18, 2016 at 09:33:43PM +0200, Kurt Roeckx wrote: >> On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote: >>> On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote: On 11/06/16 20:59, Kurt Roeckx wrote: > OpenSSL will soon release a new upstream version with a new > soname. This new version will break various packages, see: > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > I'm currently not sure when the release will be ready. I would > like to start this transition as soon as possible, but probably > after it's actually released. I don't expect this to take long. 405 packages failed to build during your test rebuild AFAICS. That's going to take some time to sort out... > If I'm ready to upload it to unstable, can I start this > transition? Are there things you want me to do? Please upload to experimental first and let us know when that's happened. >>> >>> It's in experimental already. The test suite only fails >>> on hurd, for some reason it's not finding the engine. I still >>> need to look at that. >>> We will also need bugs filed, with severity important for now. >>> >>> Sure, I'll start on that if I find the time. >>> Also it may be useful if you can get us the intersection between the packages that failed to build and the key packages[1] (see "Final list of 3302 key source packages" in that file). >>> >>> That actually seem to be 3247 source package. Anyway, the list is >>> below. >> >> So OpenSSL 1.1.0 was released about 3 weeks ago. Since then we've >> been working on the key packages, to get them to build with >> OpenSSL 1.1.0. You can see that status of that at: >> https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org >> >> Most of the packages are really trivial to fix, but some do >> require that you fix the same issues in many different places and >> it can take some time to fix it. >> >> I would like to motivate more people to work on this by either >> marking those bugs as RC, or uploading it to unstable. > > Ping. I'm sorry but I'm going to have to nack this for Stretch, as much as I like to approve transitions and get new stuff in. I have looked at the opened bugs and I'm afraid this still is too disruptive. I have noticed that you have forwarded some of them and sent patches, and I appreciate that. We can do this early in the Buster cycle, so let's look at the status of this and prepare for the transition when Stretch gets released. Cheers, Emilio
Bug#827061: transition: openssl
On Sun, Sep 18, 2016 at 09:33:43PM +0200, Kurt Roeckx wrote: > On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote: > > On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote: > > > On 11/06/16 20:59, Kurt Roeckx wrote: > > > > OpenSSL will soon release a new upstream version with a new > > > > soname. This new version will break various packages, see: > > > > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > > > > > > > I'm currently not sure when the release will be ready. I would > > > > like to start this transition as soon as possible, but probably > > > > after it's actually released. I don't expect this to take long. > > > > > > 405 packages failed to build during your test rebuild AFAICS. That's > > > going to > > > take some time to sort out... > > > > > > > If I'm ready to upload it to unstable, can I start this > > > > transition? Are there things you want me to do? > > > > > > Please upload to experimental first and let us know when that's happened. > > > > It's in experimental already. The test suite only fails > > on hurd, for some reason it's not finding the engine. I still > > need to look at that. > > > > > We will also need bugs filed, with severity important for now. > > > > Sure, I'll start on that if I find the time. > > > > > Also it may be useful if you can get us the intersection between the > > > packages > > > that failed to build and the key packages[1] (see "Final list of 3302 key > > > source > > > packages" in that file). > > > > That actually seem to be 3247 source package. Anyway, the list is > > below. > > So OpenSSL 1.1.0 was released about 3 weeks ago. Since then we've > been working on the key packages, to get them to build with > OpenSSL 1.1.0. You can see that status of that at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org > > Most of the packages are really trivial to fix, but some do > require that you fix the same issues in many different places and > it can take some time to fix it. > > I would like to motivate more people to work on this by either > marking those bugs as RC, or uploading it to unstable. Ping. Kurt
Bug#827061: transition: openssl
On 2016-09-18 21:33:43 [+0200], Kurt Roeckx wrote: > > So OpenSSL 1.1.0 was released about 3 weeks ago. Since then we've now a month and a few days now. > been working on the key packages, to get them to build with > OpenSSL 1.1.0. You can see that status of that at: > https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org 22 are tagged patch. > Most of the packages are really trivial to fix, but some do > require that you fix the same issues in many different places and > it can take some time to fix it. yup. > I would like to motivate more people to work on this by either > marking those bugs as RC, or uploading it to unstable. besides the above status for the key packages there is also https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans;users=pkg-openssl-devel-requ...@lists.alioth.debian.org which covers all of them. > Kurt Sebastian
Bug#827061: transition: openssl
On Sat, Jun 11, 2016 at 09:42:59PM +0200, Kurt Roeckx wrote: > On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote: > > On 11/06/16 20:59, Kurt Roeckx wrote: > > > OpenSSL will soon release a new upstream version with a new > > > soname. This new version will break various packages, see: > > > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > > > > > I'm currently not sure when the release will be ready. I would > > > like to start this transition as soon as possible, but probably > > > after it's actually released. I don't expect this to take long. > > > > 405 packages failed to build during your test rebuild AFAICS. That's going > > to > > take some time to sort out... > > > > > If I'm ready to upload it to unstable, can I start this > > > transition? Are there things you want me to do? > > > > Please upload to experimental first and let us know when that's happened. > > It's in experimental already. The test suite only fails > on hurd, for some reason it's not finding the engine. I still > need to look at that. > > > We will also need bugs filed, with severity important for now. > > Sure, I'll start on that if I find the time. > > > Also it may be useful if you can get us the intersection between the > > packages > > that failed to build and the key packages[1] (see "Final list of 3302 key > > source > > packages" in that file). > > That actually seem to be 3247 source package. Anyway, the list is > below. So OpenSSL 1.1.0 was released about 3 weeks ago. Since then we've been working on the key packages, to get them to build with OpenSSL 1.1.0. You can see that status of that at: https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=openssl-1.1-trans-keypkg;users=pkg-openssl-devel-requ...@lists.alioth.debian.org Most of the packages are really trivial to fix, but some do require that you fix the same issues in many different places and it can take some time to fix it. I would like to motivate more people to work on this by either marking those bugs as RC, or uploading it to unstable. Kurt
Bug#827061: transition: openssl
Re: Kurt Roeckx 2016-09-16 <20160916054549.2wjl4xzb2eyg6...@roeckx.be> > > do you expect the transition to be done for stretch? > > I really would like to have it in stretch. I don't want to have > the same situtation like we had with 1.0.2 that didn't make it it > to jessie. Nod, thanks for confirming. > > I'm asking because the PostgreSQL people want to know if they need to > > add support for OpenSSL 1.1 in the older release branches (9.2 .. > > 9.4), or if patching 9.5 .. 10 is enough for now. > > I guess they want to provide binaries for all their releases on > apt.postgresql.org? That's exactly the reason, yes. (And "they" is me ;) Christoph signature.asc Description: PGP signature
Bug#827061: transition: openssl
On Thu, Sep 15, 2016 at 11:44:42PM +0200, Christoph Berg wrote: > Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be> > > > > If I'm ready to upload it to unstable, can I start this > > > > transition? Are there things you want me to do? > > > > > > Please upload to experimental first and let us know when that's happened. > > > > It's in experimental already. The test suite only fails > > on hurd, for some reason it's not finding the engine. I still > > need to look at that. > > Hi, > > do you expect the transition to be done for stretch? I really would like to have it in stretch. I don't want to have the same situtation like we had with 1.0.2 that didn't make it it to jessie. > I'm asking because the PostgreSQL people want to know if they need to > add support for OpenSSL 1.1 in the older release branches (9.2 .. > 9.4), or if patching 9.5 .. 10 is enough for now. I guess they want to provide binaries for all their releases on apt.postgresql.org? > (Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems > unlikely, but just to confirm?) This is not my plan. Kurt
Bug#827061: transition: openssl
Re: Kurt Roeckx 2016-06-11 <20160611194259.ga6...@roeckx.be> > > > If I'm ready to upload it to unstable, can I start this > > > transition? Are there things you want me to do? > > > > Please upload to experimental first and let us know when that's happened. > > It's in experimental already. The test suite only fails > on hurd, for some reason it's not finding the engine. I still > need to look at that. Hi, do you expect the transition to be done for stretch? I'm asking because the PostgreSQL people want to know if they need to add support for OpenSSL 1.1 in the older release branches (9.2 .. 9.4), or if patching 9.5 .. 10 is enough for now. (Alternatively, would stretch have OpenSSL 1.0 next to 1.1? This seems unlikely, but just to confirm?) Thanks, Christoph signature.asc Description: PGP signature
Bug#827061: transition: openssl
On Sat, Jun 11, 2016 at 09:31:17PM +0200, Emilio Pozuelo Monfort wrote: > On 11/06/16 20:59, Kurt Roeckx wrote: > > OpenSSL will soon release a new upstream version with a new > > soname. This new version will break various packages, see: > > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > > > I'm currently not sure when the release will be ready. I would > > like to start this transition as soon as possible, but probably > > after it's actually released. I don't expect this to take long. > > 405 packages failed to build during your test rebuild AFAICS. That's going to > take some time to sort out... > > > If I'm ready to upload it to unstable, can I start this > > transition? Are there things you want me to do? > > Please upload to experimental first and let us know when that's happened. It's in experimental already. The test suite only fails on hurd, for some reason it's not finding the engine. I still need to look at that. > We will also need bugs filed, with severity important for now. Sure, I'll start on that if I find the time. > Also it may be useful if you can get us the intersection between the packages > that failed to build and the key packages[1] (see "Final list of 3302 key > source > packages" in that file). That actually seem to be 3247 source package. Anyway, the list is below. Kurt bind9 clamav curl cyrus-sasl2 freebsd-utils freerdp gsoap gst-plugins-bad1.0 kde4libs kdelibs4support kopete krb5 libcrypt-openssl-rsa-perl libevent libexosip2 libmicrohttpd libmsn libnet-ssleay-perl libssh links2 m2crypto mariadb-client-lgpl neon27 net-snmp nghttp2 nginx nmap nodejs ntp openhpi openipmi opensc openssh openvpn opusfile php5 pkcs11-helper postfix postgresql-9.5 pulseaudio pypy python-cryptography qca2 qt4-x11 qtbase-opensource-src rdesktop ruby2.3 sendmail serf socat spamassassin spdylay spice spice-gtk stunnel4 tcpdump transmission unbound uw-imap vde2 virtualbox virtuoso-opensource wget wpa xmlsec1 xmms2
Bug#827061: transition: openssl
On 11/06/16 20:59, Kurt Roeckx wrote: > OpenSSL will soon release a new upstream version with a new > soname. This new version will break various packages, see: > https://lists.debian.org/debian-devel/2016/06/msg00205.html > > I'm currently not sure when the release will be ready. I would > like to start this transition as soon as possible, but probably > after it's actually released. I don't expect this to take long. 405 packages failed to build during your test rebuild AFAICS. That's going to take some time to sort out... > If I'm ready to upload it to unstable, can I start this > transition? Are there things you want me to do? Please upload to experimental first and let us know when that's happened. We will also need bugs filed, with severity important for now. Also it may be useful if you can get us the intersection between the packages that failed to build and the key packages[1] (see "Final list of 3302 key source packages" in that file). Cheers, Emilio [1] https://udd.debian.org/cgi-bin/key_packages.cgi
Bug#827061: transition: openssl
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, OpenSSL will soon release a new upstream version with a new soname. This new version will break various packages, see: https://lists.debian.org/debian-devel/2016/06/msg00205.html I'm currently not sure when the release will be ready. I would like to start this transition as soon as possible, but probably after it's actually released. I don't expect this to take long. If I'm ready to upload it to unstable, can I start this transition? Are there things you want me to do? Kurt