Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-31 21:40:25 [+0200], To Emilio Pozuelo Monfort wrote:
> On 2018-07-28 10:11:47 [+0200], Emilio Pozuelo Monfort wrote:
> > We never break packages in testing (unless it's a critical situation, and 
> > this
> > obviously isn't). Also the cruft package in unstable doesn't hurt much, so 
> > it
> > can be left around for a while longer. What we want to do here is to get 
> > rid of
> > the old library in testing in order to finish the transition there: the 
> > only two
> > options for that are to remove scilab or to fix it. Given it's a key 
> > package and
> > probably has rdeps that'd mean the latter.
> 
> Okay. scilab received an upload an built properly. This was the only
> keypackage. We have four packages left, none of them is in testing. Can
> we close this transition now? :)

While four are still left (only) in unstable, one of them is fixed in
experimental.

> > Cheers,
> > Emilio

Sebastian

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-28 10:11:47 [+0200], Emilio Pozuelo Monfort wrote:
> We never break packages in testing (unless it's a critical situation, and this
> obviously isn't). Also the cruft package in unstable doesn't hurt much, so it
> can be left around for a while longer. What we want to do here is to get rid 
> of
> the old library in testing in order to finish the transition there: the only 
> two
> options for that are to remove scilab or to fix it. Given it's a key package 
> and
> probably has rdeps that'd mean the latter.

Okay. scilab received an upload an built properly. This was the only
keypackage. We have four packages left, none of them is in testing. Can
we close this transition now? :)

> Cheers,
> Emilio

Sebastian

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 25/07/18 22:01, Sebastian Andrzej Siewior wrote:
> On 2018-07-25 10:47:50 [+0200], Emilio Pozuelo Monfort wrote:
>>> Any suggestions from the D-Science folks?
>>
>> Maybe send this to the scilab bug rather than the curl transition one?
> 
> I Cced the scilab folks. I was more interrested in the release team's
> opinion if it is worth fixing those and get it built in order to
> complete the curl transition or if it does not make sense (to fix only
> one of those RC bugs) and breaking the package (i.e. removing libcurl3
> from unstable) would be an option.

We never break packages in testing (unless it's a critical situation, and this
obviously isn't). Also the cruft package in unstable doesn't hurt much, so it
can be left around for a while longer. What we want to do here is to get rid of
the old library in testing in order to finish the transition there: the only two
options for that are to remove scilab or to fix it. Given it's a key package and
probably has rdeps that'd mean the latter.

Cheers,
Emilio

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-25 10:47:50 [+0200], Emilio Pozuelo Monfort wrote:
> > Any suggestions from the D-Science folks?
> 
> Maybe send this to the scilab bug rather than the curl transition one?

I Cced the scilab folks. I was more interrested in the release team's
opinion if it is worth fixing those and get it built in order to
complete the curl transition or if it does not make sense (to fix only
one of those RC bugs) and breaking the package (i.e. removing libcurl3
from unstable) would be an option.

> btw that failure may be due to the ongoing gfortran transition, and it may 
> just
> need to wait for the binNMUs to happen (which are ongoing).

Ah thanks, that is good to know.

> Cheers,
> Emilio

Sebastian

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 21/07/18 23:51, Sebastian Andrzej Siewior wrote:
> On 2018-07-19 00:39:27 [+0200], To Emilio Pozuelo Monfort wrote:
>> - scilab
>>   rebuilt everywhere except for i386. Plus
>>   #891351 [G|  |  ] [scilab] scilab segfaults at startup
>>   #875790 [S|⛺+|  ] [src:scilab] scilab: depends on openjdk-8
>>   #884033 [S|  |☣] [scilab] scilab segfaults building 
>> scilab-{ann,celestlab,plotlib}
>>   #902826 [S|  |  ] [src:scilab] scilab: FTBFS on i386 - seg. fault during 
>> build
>>
>>   Building currently without all (#902826).  Assuming it works, would it
>>   make sense to NMU+2d it? We would get rid of one RC bug for curl but…
> 
> This one got worse since gcc-8 is the default[0], this is amd64:
> 
> |/bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
> -fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/twodq.lo 
> src/fortran/twodq.f
> | /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
> -fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/dqagse.lo 
> src/fortran/dqagse.f
> | libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
> -I../../modules/core/includes/ -g -O2 -c src/fortran/xerrwv.f  -fPIC -o 
> src/fortran/.libs/xerrwv.o
> | /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
> -fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/greatr.lo 
> src/fortran/greatr.f
> | libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
> -I../../modules/core/includes/ -g -O2 -c src/fortran/twodq.f  -fPIC -o 
> src/fortran/.libs/twodq.o
> | libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
> -I../../modules/core/includes/ -g -O2 -c src/fortran/dqagse.f  -fPIC -o 
> src/fortran/.libs/dqagse.o
> | libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
> -I../../modules/core/includes/ -g -O2 -c src/fortran/greatr.f  -fPIC -o 
> src/fortran/.libs/greatr.o
> | /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
> -fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/hpdel.lo 
> src/fortran/hpdel.f
> | src/fortran/twodq.f:373:17:
> |
> |call tridv(node,node1,node2,0.5d0,1)
> |  1
> | Error: Actual argument contains too few elements for dummy argument 'node' 
> (9/10) at (1)
> | make[3]: *** [Makefile:1444: src/fortran/twodq.lo] Error 1
> 
> I am not fluent in fortran so I can't tell if this is a temporary glitch
> or a new permant FTBFS.
> Any suggestions from the D-Science folks?

Maybe send this to the scilab bug rather than the curl transition one?

btw that failure may be due to the ongoing gfortran transition, and it may just
need to wait for the binNMUs to happen (which are ongoing).

Cheers,
Emilio

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-07-19 00:39:27 [+0200], To Emilio Pozuelo Monfort wrote:
> - scilab
>   rebuilt everywhere except for i386. Plus
>   #891351 [G|  |  ] [scilab] scilab segfaults at startup
>   #875790 [S|⛺+|  ] [src:scilab] scilab: depends on openjdk-8
>   #884033 [S|  |☣] [scilab] scilab segfaults building 
> scilab-{ann,celestlab,plotlib}
>   #902826 [S|  |  ] [src:scilab] scilab: FTBFS on i386 - seg. fault during 
> build
> 
>   Building currently without all (#902826).  Assuming it works, would it
>   make sense to NMU+2d it? We would get rid of one RC bug for curl but…

This one got worse since gcc-8 is the default[0], this is amd64:

|/bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/twodq.lo 
src/fortran/twodq.f
| /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/dqagse.lo 
src/fortran/dqagse.f
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/xerrwv.f  -fPIC -o 
src/fortran/.libs/xerrwv.o
| /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/greatr.lo 
src/fortran/greatr.f
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/twodq.f  -fPIC -o 
src/fortran/.libs/twodq.o
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/dqagse.f  -fPIC -o 
src/fortran/.libs/dqagse.o
| libtool: compile:  gfortran -DNDEBUG -m64 -fPIC 
-I../../modules/core/includes/ -g -O2 -c src/fortran/greatr.f  -fPIC -o 
src/fortran/.libs/greatr.o
| /bin/bash ../../libtool  --tag=F77   --mode=compile gfortran -DNDEBUG -m64 
-fPIC -I../../modules/core/includes/ -g -O2 -c -o src/fortran/hpdel.lo 
src/fortran/hpdel.f
| src/fortran/twodq.f:373:17:
|
|call tridv(node,node1,node2,0.5d0,1)
|  1
| Error: Actual argument contains too few elements for dummy argument 'node' 
(9/10) at (1)
| make[3]: *** [Makefile:1444: src/fortran/twodq.lo] Error 1

I am not fluent in fortran so I can't tell if this is a temporary glitch
or a new permant FTBFS.
Any suggestions from the D-Science folks?

[0] I *think* it is gcc-8 because I built it recently and it built on
amd64 but today it doesn't anymore.

Sebastian

Bug#891872: transition: curl

[Sebastian Andrzej Siewior]

On 2018-05-28 17:43:15 [+0200], Emilio Pozuelo Monfort wrote:
> Let's go with this. I'll schedule the binNMUs soon.

atm we have:

- netsurf (sid only)
  #867694 [G|  |  ] [netsurf-fb] netsurf-fb: Completely unusable due to missing 
dependencies, symlinks and documentation
  #859230 [S|  |  ] [netsurf] netsurf: Please migrate to openssl1.1 in Buster
  #869600 [S|⛺|  ] [src:netsurf] netsurf FTBFS: error: conflicting types for 
'svgtiny_color_lookup' 

  NMU+2d to fix #859230 + #869600. #867694 is still there but…
  
- frobtads (sid only)
  #836934 [S|+|  ] [src:frobtads] frobtads: FTBFS with GCC 6: error: exception 
cleanup for this placement new selects non-placement operator delete
  #871215 [S|+|  ] [src:frobtads] frobtads: FTBFS with GCC-7: error: ISO C++ 
forbids comparison between pointer and integer

  There are patches attached. Maybe NMU?

- gambas3 (sid only)
  #867306 [S|  |  ] [src:gambas3] gambas3: spurious libqtwebkit-dev build 
dependency
  #899515 [S|  |  ] [src:gambas3] gambas3: Invalid maintainer address 
pkg-gambas-de...@lists.alioth.debian.org
  #900998 [S|u|  ] [src:gambas3] gambas3: FTBFS w/SDL2 2.0.7+: 
MIX_INIT_FLUIDSYNTH undeclared
  #867930 [S|  |↝] [src:gambas3] gambas3: Build-Depends on deprecated 
libgnome-keyring-dev

  Hmm. So based on https://hg.libsdl.org/SDL_mixer/rev/92882ef2ab81 it
  seems that MIX_INIT_FLUIDSYNTH -> MIX_INIT_MID would make it build
  again. And Upstream did almost the same thing:
  
https://gitlab.com/gambas/gambas/commit/caf54c5b75d62d3136f12a6e5657df4e2ec555ba
  
  Not sure about the other bugs. Worth fixing that one?

- scilab
  rebuilt everywhere except for i386. Plus
  #891351 [G|  |  ] [scilab] scilab segfaults at startup
  #875790 [S|⛺+|  ] [src:scilab] scilab: depends on openjdk-8
  #884033 [S|  |☣] [scilab] scilab segfaults building 
scilab-{ann,celestlab,plotlib}
  #902826 [S|  |  ] [src:scilab] scilab: FTBFS on i386 - seg. fault during build

  Building currently without all (#902826).  Assuming it works, would it
  make sense to NMU+2d it? We would get rid of one RC bug for curl but…

- xmltooling (sid only)
  #859831 [S|  |♔☣] [xmltooling] xmltooling: Please migrate to openssl1.1 in 
Buster
  Can't be built at the moment. We are waiting for new upstream version.

- freeipa (sid only)
  hardcoded "libcurl3 (>= 7.22.0)" in freeipa-client. There is
  #901430 conflict: freeipa depends upon libcurl3 and (curl --> libcurl4)
  Dropping the build-depend on libcurl3, NMU 4d.
  Maybe I should rise that to 'serious'?

- kcov (sid only)
  #780620 [S|+|  ] [src:kcov] control file not policy compliant and build 
failures almost everywhere
  #790912 [S|⛺|  ] [kcov] FTBFS: ld: CMakeFiles/kcov.dir/capabilities.cc.o .. 
recompile with -fPIC
  #839374 [S|  |  ] [src:kcov] kcov: FTBFS: ld: final link failed: 
Nonrepresentable section on output
  #880344 [S|  |  ] [src:kcov] kcov: FTBFS: Test failures

  Ehm, yes. 

- openalpr (sid only)
  #896793 [S|⛺|  ] [src:openalpr] openalpr: missing build dependency on 
python3-distutils
  Adding B-D, NMU+2d

> Cheers,
> Emilio

Sebastian

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

Control: tags -1 confirmed

On 28/05/18 15:59, Alessandro Ghedini wrote:
> On Mon, May 28, 2018 at 01:09:14PM +0200, Emilio Pozuelo Monfort wrote:
>> Control: tags -1 - confirmed
>>
>> On 23/05/18 13:07, Emilio Pozuelo Monfort wrote:
>>> On 23/04/18 20:38, Emilio Pozuelo Monfort wrote:
 On 01/03/18 22:31, Alessandro Ghedini wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hello,
>
> I'd like to request a transition for curl in order to unblock the 
> migration
> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl 
> ABI
> exposes a structure inherited from libssl itself, which was changed in 
> the 1.1
> update (see #844018 for more information).

 I was looking at this in order to ack it. However I've noticed that 
 libcurl4
 conflicts against libcurl3. Why is that? That's going to make the 
 transition
 hard, can it be removed?

 Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
 conflict.
 I just found the rationale for this in
 https://salsa.debian.org/debian/curl/merge_requests/2. That means this 
 will have
 to wait until there are no conflicting ongoing transitions. I will ack 
 this when
 that time comes.
>>>
>>> Please go ahead now.
>>>
>>> Since all packages need to migrate at the same time, some NMUs may be 
>>> needed to
>>> fix potential FTBFS in rdeps. I will notify this bug when the binNMUs are 
>>> done
>>> and we have a list of failing packages.
>>
>> I've acked the R transition, so let's wait for that now.
> 
> Ugh, sorry for the big delay. curl 7.60.0-2 just got accepted (it was stuck in
> NEW due to the fact I had to upload a new version to sid last week to fix
> security issues so the experimental upload got removed, and I didn't make it 
> in
> time to clear 7.60.0 with the migration changes through experimental).
> 
> This is totally my fault, I should have notified you about that when I did the
> upload. I hope this doesn;t cause you too much of a pain. Is there anything I
> can do to fix this?

No problem, I didn't notice that it was back in NEW, otherwise I would have
asked for fast processing.

Thankfully we didn't end up with both this and the R transition starting at the
same time, which would have caused me quite some headaches.

Let's go with this. I'll schedule the binNMUs soon.

Cheers,
Emilio

Bug#891872: transition: curl

[Alessandro Ghedini]

On Mon, May 28, 2018 at 01:09:14PM +0200, Emilio Pozuelo Monfort wrote:
> Control: tags -1 - confirmed
> 
> On 23/05/18 13:07, Emilio Pozuelo Monfort wrote:
> > On 23/04/18 20:38, Emilio Pozuelo Monfort wrote:
> >> On 01/03/18 22:31, Alessandro Ghedini wrote:
> >>> Package: release.debian.org
> >>> Severity: normal
> >>> User: release.debian@packages.debian.org
> >>> Usertags: transition
> >>>
> >>> Hello,
> >>>
> >>> I'd like to request a transition for curl in order to unblock the 
> >>> migration
> >>> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl 
> >>> ABI
> >>> exposes a structure inherited from libssl itself, which was changed in 
> >>> the 1.1
> >>> update (see #844018 for more information).
> >>
> >> I was looking at this in order to ack it. However I've noticed that 
> >> libcurl4
> >> conflicts against libcurl3. Why is that? That's going to make the 
> >> transition
> >> hard, can it be removed?
> >>
> >> Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
> >> conflict.
> >> I just found the rationale for this in
> >> https://salsa.debian.org/debian/curl/merge_requests/2. That means this 
> >> will have
> >> to wait until there are no conflicting ongoing transitions. I will ack 
> >> this when
> >> that time comes.
> > 
> > Please go ahead now.
> > 
> > Since all packages need to migrate at the same time, some NMUs may be 
> > needed to
> > fix potential FTBFS in rdeps. I will notify this bug when the binNMUs are 
> > done
> > and we have a list of failing packages.
> 
> I've acked the R transition, so let's wait for that now.

Ugh, sorry for the big delay. curl 7.60.0-2 just got accepted (it was stuck in
NEW due to the fact I had to upload a new version to sid last week to fix
security issues so the experimental upload got removed, and I didn't make it in
time to clear 7.60.0 with the migration changes through experimental).

This is totally my fault, I should have notified you about that when I did the
upload. I hope this doesn;t cause you too much of a pain. Is there anything I
can do to fix this?

Cheers


signature.asc
Description: PGP signature

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

Control: tags -1 - confirmed

On 23/05/18 13:07, Emilio Pozuelo Monfort wrote:
> On 23/04/18 20:38, Emilio Pozuelo Monfort wrote:
>> On 01/03/18 22:31, Alessandro Ghedini wrote:
>>> Package: release.debian.org
>>> Severity: normal
>>> User: release.debian@packages.debian.org
>>> Usertags: transition
>>>
>>> Hello,
>>>
>>> I'd like to request a transition for curl in order to unblock the migration
>>> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl 
>>> ABI
>>> exposes a structure inherited from libssl itself, which was changed in the 
>>> 1.1
>>> update (see #844018 for more information).
>>
>> I was looking at this in order to ack it. However I've noticed that libcurl4
>> conflicts against libcurl3. Why is that? That's going to make the transition
>> hard, can it be removed?
>>
>> Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
>> conflict.
>> I just found the rationale for this in
>> https://salsa.debian.org/debian/curl/merge_requests/2. That means this will 
>> have
>> to wait until there are no conflicting ongoing transitions. I will ack this 
>> when
>> that time comes.
> 
> Please go ahead now.
> 
> Since all packages need to migrate at the same time, some NMUs may be needed 
> to
> fix potential FTBFS in rdeps. I will notify this bug when the binNMUs are done
> and we have a list of failing packages.

I've acked the R transition, so let's wait for that now.

Emilio

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 23/04/18 20:38, Emilio Pozuelo Monfort wrote:
> On 01/03/18 22:31, Alessandro Ghedini wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: transition
>>
>> Hello,
>>
>> I'd like to request a transition for curl in order to unblock the migration
>> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl ABI
>> exposes a structure inherited from libssl itself, which was changed in the 
>> 1.1
>> update (see #844018 for more information).
> 
> I was looking at this in order to ack it. However I've noticed that libcurl4
> conflicts against libcurl3. Why is that? That's going to make the transition
> hard, can it be removed?
> 
> Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
> conflict.
> I just found the rationale for this in
> https://salsa.debian.org/debian/curl/merge_requests/2. That means this will 
> have
> to wait until there are no conflicting ongoing transitions. I will ack this 
> when
> that time comes.

Please go ahead now.

Since all packages need to migrate at the same time, some NMUs may be needed to
fix potential FTBFS in rdeps. I will notify this bug when the binNMUs are done
and we have a list of failing packages.

Cheers,
Emilio

Bug#859841: Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 18/05/18 09:24, Jan Niehusmann wrote:
> Hi Emilio,
> 
> On Mon, Apr 23, 2018 at 08:38:30PM +0200, Emilio Pozuelo Monfort wrote:
>> Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
>> conflict.
>> I just found the rationale for this in
>> https://salsa.debian.org/debian/curl/merge_requests/2. That means this will 
>> have
>> to wait until there are no conflicting ongoing transitions. I will ack this 
>> when
>> that time comes.
> 
> What's the best way to stay up to date regarding this transition? Is it
> being discussed on some mailing list / IRC channel? Or shall I just
> monitor the ticket on the BTS at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891872 ?

The latter.

At the moment I'm waiting for the icu transition to move on. Once that happens,
I'll see if we can get this started.

Emilio

Bug#859841: Bug#891872: transition: curl

[Jan Niehusmann]

Hi Emilio,

On Mon, Apr 23, 2018 at 08:38:30PM +0200, Emilio Pozuelo Monfort wrote:
> Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the 
> conflict.
> I just found the rationale for this in
> https://salsa.debian.org/debian/curl/merge_requests/2. That means this will 
> have
> to wait until there are no conflicting ongoing transitions. I will ack this 
> when
> that time comes.

What's the best way to stay up to date regarding this transition? Is it
being discussed on some mailing list / IRC channel? Or shall I just
monitor the ticket on the BTS at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891872 ?

Jan

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 01/03/18 22:31, Alessandro Ghedini wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I'd like to request a transition for curl in order to unblock the migration
> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl ABI
> exposes a structure inherited from libssl itself, which was changed in the 1.1
> update (see #844018 for more information).

I was looking at this in order to ack it. However I've noticed that libcurl4
conflicts against libcurl3. Why is that? That's going to make the transition
hard, can it be removed?

Hmm, I just realised libcurl3 ships libcurl.so.4, so that explains the conflict.
I just found the rationale for this in
https://salsa.debian.org/debian/curl/merge_requests/2. That means this will have
to wait until there are no conflicting ongoing transitions. I will ack this when
that time comes.

Cheers,
Emilio

Bug#891872: transition: curl

[Dimitri John Ledkov]

On Fri, 2 Mar 2018 10:04:44 +0100 Emilio Pozuelo Monfort 
wrote:
> On 01/03/18 22:31, Alessandro Ghedini wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> >
> > Hello,
> >
> > I'd like to request a transition for curl in order to unblock the
migration
> > to OpenSSL 1.1 (#871056).
>
> Good!
>
> > This is necessary due to the fact that the curl ABI
> > exposes a structure inherited from libssl itself, which was changed in
the 1.1
> > update (see #844018 for more information).
> >
> > It is for the most part a clean ABI bump, however a few packages that
build
> > depend on both libcurl and libssl will need source uploads so they can
also
> > migrate to OpenSSL 1.1. The following packages were identified as part
of the
> > discussion in #858398:
> >
> > * hhvm: #858927 (sid-only)
> > * lastpass-cli: #858991
> > * libapache2-mod-auth-cas: 858992
> > * netsurf: #859230
> > * xmltooling: #859831
> > * zurl: #859841
>
> xmltooling / Shibboleth / xml-security-c don't seem ready yet. Apparently
there
> are patches upstream but there have been no new releases and they are not
easy
> to backport. I suppose at some point we'll need to stop blocking on them.
They
> can be fixed later and re-enter testing when that happens, there's still
plenty
> of time before the freeze.

Indeed xmltooling requires both openssl based curl, and openssl-1.0. In
Ubuntu, we did not manage to resolve it, hence I have uploaded "curl3"[0]
package into ubuntu that provides libcurl-openssl1.0-dev, which builds curl
against openssl1.0 and provides a library that xmltooling can link against.

This was done out of time constraints due to imminent Ubuntu release.
Ideally xmltooling should be ported to openssl-1.1 as a long term
maintainable solution.

Regards,

Dimitri.

[0] https://launchpad.net/ubuntu/+source/curl3/7.58.0-2ubuntu2

Bug#891872: transition: curl

[Jan Niehusmann]

Hi,

On Fri, Mar 02, 2018 at 10:04:44AM +0100, Emilio Pozuelo Monfort wrote:
> Also zurl seems to need Qt with openssl 1.1, which is only in experimental 
> atm.
> That shouldn't be a blocker for this though (we can temporarily kick it from
> testing if necessary). But let's wait a bit and see.

I don't think that's necessary, as there is no direct interaction
between both instances of openssl through zurl.

The only code I found which uses both QSsl and OpenSSL is in
src/websocket.cpp:

#ifdef HAVE_OPENSSL
QSslCertificate cert = sock->peerCertificate();
QByteArray der = cert.toDer();
const unsigned char *p = (const unsigned char 
*)der.data();
X509 *opensslCert = d2i_X509(NULL, , 
der.size());
if(opensslCert)
{

if(verifyhost(connectHost.toUtf8().data(), opensslCert) == CURLE_OK)
hostMismatchOk = true;

X509_free(opensslCert);
}
#endif

It loads a certificate from QSsl, converts it to a DER formatted char
array, and builds an OpenSSL X509 struct from that. Looks like a rather
stable interface to me.

I uploaded a version of zurl built against openssl 1.1 to experimental
an hour ago: https://tracker.debian.org/news/937630

If somebody cares, another pair of eyes looking through the zurl source
code would be appreciated, of course.

Jan

Bug#891872: transition: curl

[Emilio Pozuelo Monfort]

On 01/03/18 22:31, Alessandro Ghedini wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I'd like to request a transition for curl in order to unblock the migration
> to OpenSSL 1.1 (#871056).

Good!

> This is necessary due to the fact that the curl ABI
> exposes a structure inherited from libssl itself, which was changed in the 1.1
> update (see #844018 for more information).
> 
> It is for the most part a clean ABI bump, however a few packages that build
> depend on both libcurl and libssl will need source uploads so they can also
> migrate to OpenSSL 1.1. The following packages were identified as part of the
> discussion in #858398:
> 
> * hhvm: #858927 (sid-only)
> * lastpass-cli: #858991 
> * libapache2-mod-auth-cas: 858992
> * netsurf: #859230
> * xmltooling: #859831
> * zurl: #859841

xmltooling / Shibboleth / xml-security-c don't seem ready yet. Apparently there
are patches upstream but there have been no new releases and they are not easy
to backport. I suppose at some point we'll need to stop blocking on them. They
can be fixed later and re-enter testing when that happens, there's still plenty
of time before the freeze.

Also zurl seems to need Qt with openssl 1.1, which is only in experimental atm.
That shouldn't be a blocker for this though (we can temporarily kick it from
testing if necessary). But let's wait a bit and see.

> The updated curl package (7.58.0-3) has been uploaded and accepted in
> experimental. The full changeset (from Steve Langasek) can be found at:
> https://salsa.debian.org/debian/curl/merge_requests/3/diffs
> 
> The auto-generated tracker (which looks correct) is:
> https://release.debian.org/transitions/html/auto-curl.html

It doesn't. There are false positives due to e.g. libcurl3-gnutls and
libcurl4-gnutls-dev matching is_good / is_bad respectively. I'll see if I can
come up with a better regexp later today.

Cheers,
Emilio

Bug#891872: transition: curl

[Alessandro Ghedini]

On Thu, Mar 01, 2018 at 09:31:20PM +, Alessandro Ghedini wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Hello,
> 
> I'd like to request a transition for curl in order to unblock the migration
> to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl ABI
> exposes a structure inherited from libssl itself, which was changed in the 1.1
> update (see #844018 for more information).
> 
> It is for the most part a clean ABI bump, however a few packages that build
> depend on both libcurl and libssl will need source uploads so they can also
> migrate to OpenSSL 1.1. The following packages were identified as part of the
> discussion in #858398:
> 
> * hhvm: #858927 (sid-only)
> * lastpass-cli: #858991 
> * libapache2-mod-auth-cas: 858992
> * netsurf: #859230
> * xmltooling: #859831
> * zurl: #859841

To be clear, these are the packages that are affected by the ABI change, they
don't just build depend on both libcurl and libssl.

Cheers


signature.asc
Description: PGP signature

Bug#891872: transition: curl

[Alessandro Ghedini]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hello,

I'd like to request a transition for curl in order to unblock the migration
to OpenSSL 1.1 (#871056). This is necessary due to the fact that the curl ABI
exposes a structure inherited from libssl itself, which was changed in the 1.1
update (see #844018 for more information).

It is for the most part a clean ABI bump, however a few packages that build
depend on both libcurl and libssl will need source uploads so they can also
migrate to OpenSSL 1.1. The following packages were identified as part of the
discussion in #858398:

* hhvm: #858927 (sid-only)
* lastpass-cli: #858991 
* libapache2-mod-auth-cas: 858992
* netsurf: #859230
* xmltooling: #859831
* zurl: #859841

The updated curl package (7.58.0-3) has been uploaded and accepted in
experimental. The full changeset (from Steve Langasek) can be found at:
https://salsa.debian.org/debian/curl/merge_requests/3/diffs

The auto-generated tracker (which looks correct) is:
https://release.debian.org/transitions/html/auto-curl.html

Let me know if you need more information.

Thanks

-- System Information:
Debian Release: buster/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.15.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)


signature.asc
Description: PGP signature