Bug#622134: marked as done (transition: openssl 1.0.0)

2012-04-03 Thread Debian Bug Tracking System
Your message dated Tue, 03 Apr 2012 23:06:35 +0100
with message-id 1333490795.8980.12.ca...@jacala.jungle.funky-badger.org
and subject line Re: Bug#622134: transition: openssl 1.0.0
has caused the Debian Bug report #622134,
regarding transition: openssl 1.0.0
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
622134: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622134
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This is to track the transition of openssl 1.0.0.  Most of the
problems are related to dropping SSLv2 support.


Kurt



---End Message---
---BeginMessage---
On Sun, 2012-04-01 at 22:02 +0100, Adam D. Barratt wrote:
 On Thu, 2011-11-17 at 22:10 +0100, Kurt Roeckx wrote:
  Ace now seems to be the only one left in testing.
 
 It still is, but I think we're really close to getting rid of it now.  
 
 The most recent version of ace built successfully on all architectures,
 and I binNMUed the packages still depending on the older libraries
 (diagnostics/armel and ivman/{amd64,armel}) earlier today.  The old
 libraries have now been decrufted, so after the next dinstall we should
 just be waiting for ace to be old enough to enter testing; I'll try and
 remember to do a test run tomorrow to confirm that.

I aged ace a little and openssl098 was removed from testing in tonight's
britney run; I'm therefore closing this bug.

Regards,

Adam


---End Message---


Bug#622134: transition: openssl 1.0.0

2012-04-01 Thread Adam D. Barratt
On Thu, 2011-11-17 at 22:10 +0100, Kurt Roeckx wrote:
 On Tue, Nov 08, 2011 at 11:56:40PM +0100, Julien Cristau wrote:
  On Mon, Oct 17, 2011 at 22:08:57 +0200, Kurt Roeckx wrote:
  
   So I currently see those in testing:
   - ace: There have been a number of gcc-4.6 updates, I gave
 it back to see if the ICE has been fixed or not.
  
  Still does.  Apparently using gcc-4.4 would work around it, there's a
  patch to do that in #644826.  NMU candidate?
 
 Ace now seems to be the only one left in testing.

It still is, but I think we're really close to getting rid of it now.  

The most recent version of ace built successfully on all architectures,
and I binNMUed the packages still depending on the older libraries
(diagnostics/armel and ivman/{amd64,armel}) earlier today.  The old
libraries have now been decrufted, so after the next dinstall we should
just be waiting for ace to be old enough to enter testing; I'll try and
remember to do a test run tomorrow to confirm that.

Regards,

Adam




-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/114164.5757.34.ca...@jacala.jungle.funky-badger.org



Bug#622134: transition: openssl 1.0.0

2011-11-08 Thread Julien Cristau
On Mon, Oct 17, 2011 at 22:08:57 +0200, Kurt Roeckx wrote:

 So I currently see those in testing:
 - ace: There have been a number of gcc-4.6 updates, I gave
   it back to see if the ICE has been fixed or not.

Still does.  Apparently using gcc-4.4 would work around it, there's a
patch to do that in #644826.  NMU candidate?

 - beid: Still has RC bugs

Removing.

 - ipsec-tools: fixed in unstable, almost ready to migrate?

Fixed.

 - pantomime1.2: fixed in unstable, but stuck in the gnustep
   transition.

Still is.

 - transgui: Still has RC bug.
 
Fixed in sid, should migrate next week.

There's also a new one (hydra/amd64), I'll binNMU.

Cheersm
Julien



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/2008225640.gs3...@radis.liafa.jussieu.fr



Bug#622134: transition: openssl 1.0.0

2011-10-19 Thread peter green

- ace: There have been a number of gcc-4.6 updates, I gave
 it back to see if the ICE has been fixed or not.


The build that resulted from the most recent give-back 
failed but it did so in a VERY strange manner.


It claimed to install libzzlib-dev and zlib1g-dev yet it 
failed to link against the libraries they contain and 
during cleanup it didn't clean up anything claiming they

were not installed! So I think something weird happened
on the buildd and it is nessacery to repeat the give-back.






--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e9e8fb7.7010...@p10link.net



Bug#622134: transition: openssl 1.0.0

2011-10-17 Thread Matthew Grant
Hi Julien

This should be fixed for ipsec-tools and racoon as of 0.8.0-9 on sid.
Checked on sid amd64 via apt-cache depends.

Building again on kfreebsd-i386 and kfreebsd-amd64 via buildd. Closed
the 2 bugs that kept kfreebsd.

Lets see if this package makes it to testing.

Cheers,

Matthew

On Thu, 2011-10-06 at 20:46 +0200, Julien Cristau wrote:
 On Sun, Apr 10, 2011 at 16:02:14 +0200, Kurt Roeckx wrote:
 
  Package: release.debian.org
  Severity: normal
  User: release.debian@packages.debian.org
  Usertags: transition
  
  This is to track the transition of openssl 1.0.0.  Most of the
  problems are related to dropping SSLv2 support.
  
 openssl098 is still kept in testing by:
 - ace (ICE on armel)
 - beid (RC-buggy, candidate for removal)
 - ipsec-tools (#619687 #643570, has reverse dependencies)
 - isakmpd (#622051, candidate for removal)
 - isdnutils (#618228, has reverse dependencies)
 - pantomime1.2 (part of the gnustep transition)
 - transgui (#632532, candidate for removal)
 
 A fix for the ones with reverse dependencies would be nice...
 
 Cheers,
 Julien
 
 
 



signature.asc
Description: This is a digitally signed message part


Bug#622134: transition: openssl 1.0.0

2011-10-17 Thread Kurt Roeckx
On Thu, Oct 06, 2011 at 08:46:22PM +0200, Julien Cristau wrote:
 On Sun, Apr 10, 2011 at 16:02:14 +0200, Kurt Roeckx wrote:
 
  Package: release.debian.org
  Severity: normal
  User: release.debian@packages.debian.org
  Usertags: transition
  
  This is to track the transition of openssl 1.0.0.  Most of the
  problems are related to dropping SSLv2 support.
  
 openssl098 is still kept in testing by:
 - ace (ICE on armel)
 - beid (RC-buggy, candidate for removal)
 - ipsec-tools (#619687 #643570, has reverse dependencies)
 - isakmpd (#622051, candidate for removal)
 - isdnutils (#618228, has reverse dependencies)
 - pantomime1.2 (part of the gnustep transition)
 - transgui (#632532, candidate for removal)

So I currently see those in testing:
- ace: There have been a number of gcc-4.6 updates, I gave
  it back to see if the ICE has been fixed or not.
- beid: Still has RC bugs
- ipsec-tools: fixed in unstable, almost ready to migrate?
- pantomime1.2: fixed in unstable, but stuck in the gnustep
  transition.
- transgui: Still has RC bug.


Kurt




-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111017200857.ga23...@roeckx.be



Bug#622134: transition: openssl 1.0.0

2011-10-10 Thread Julien Cristau
On Sat, Oct  8, 2011 at 22:23:46 +0200, Andreas Noteng wrote:

 On Thu, 2011-10-06 at 20:46 +0200, Julien Cristau wrote:
  - transgui (#632532, candidate for removal)
 
 I'm sorry, but rebuilding transgui with the current fpc creates a bug
 which makes it almost useless, at least on amd64. I've sent one more
 mail to upstream, but it looks like this one might have to go.

OK. :/

 If it comes down to removing the package, would I as the maintainer have
 to do something? How are removals handled?
 
For removals from testing you don't need to do anything, no.

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111010182057.gd12...@radis.liafa.jussieu.fr



Bug#622134: transition: openssl 1.0.0

2011-10-10 Thread Julien Cristau
On Sat, Oct  8, 2011 at 02:46:34 +0100, peter green wrote:

 openssl098 is still kept in testing by:
 - ace (ICE on armel)
 Taking a look at this one

Thanks.  IIRC it was similar to the one affecting shibboleth-sp2, which
had to revert to using gcc-4.4 instead of 4.6.

 - beid (RC-buggy, candidate for removal)
 - ipsec-tools (#619687 #643570, has reverse dependencies)
 - isakmpd (#622051, candidate for removal)
 This bug has had a patch for several months, but the maintainer
 hasn't responded to said patch (either postively or negatively) and
 there hasn't been a maintainer upload in over a year. Maybe someone
 should NMU or even orphan the package.

Added a removal hint.

 - isdnutils (#618228, has reverse dependencies)
 Maintainer has uploaded fix (as already discussed here), waiting for it to 
 age and migrate to testing.

Should be good to go tomorrow night.

 - pantomime1.2 (part of the gnustep transition)
 - transgui (#632532, candidate for removal)
 Apparently waiting for upstream to fix some issues when built with the latest 
 fpc.
 
Right.

Thanks,
Julien



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111010183125.ge12...@radis.liafa.jussieu.fr



Bug#622134: transition: openssl 1.0.0

2011-10-08 Thread Otavio Salvador
Hi Rene,

On Fri, Oct 7, 2011 at 10:10, Rene Engelhard r...@debian.org wrote:
...
 That was all what was to prove. No one denied that sid might have
 picked up 1.0.0, but testing definitely isn't (and this isdnutils
 keeps openssl 0.9.8 in testing as the idnutils *there* *does* depend
 on 0.9.8)

It seems that fixing the RC bug, in the isdnutils case, was the
missing thing and now seems OK. So now it turns into the normal
transition window as this blocker has been fixed.

Have I missed anything?

-- 
Otavio Salvador                             O.S. Systems
E-mail: ota...@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cap9odkqkroufsysov40pc+vzr4kbzsvy2rwp61tq5sc+gkv...@mail.gmail.com



Bug#622134: transition: openssl 1.0.0

2011-10-08 Thread Andreas Noteng
On Thu, 2011-10-06 at 20:46 +0200, Julien Cristau wrote:
 - transgui (#632532, candidate for removal)

I'm sorry, but rebuilding transgui with the current fpc creates a bug
which makes it almost useless, at least on amd64. I've sent one more
mail to upstream, but it looks like this one might have to go.
If it comes down to removing the package, would I as the maintainer have
to do something? How are removals handled?

Regards
Andreas Noteng


signature.asc
Description: This is a digitally signed message part


Bug#622134: transition: openssl 1.0.0

2011-10-07 Thread Rolf Leggewie


  
  
On 07.10.2011 02:46, Julien Cristau wrote:
openssl098 is still kept in testing by:
  [...]
- isdnutils (#618228, has reverse dependencies)



Julien,

thank you for the heads up. I maintain (to the best of my limited
abilities) the isdnutils package in Debian. I believe isdnutils is
a false positive in your list. All packages in testing depend on
1.0.0 of the openssl packages. The arches where isdnutils-derived
packages still depend on 0.9.8 either have outdated isdnutils and/or
openssl packages. There's nothing inherently in isdnutils that
should block the transition so there is nothing I can do, I
believe. FWIW, there's also no blocker bug against isdnutils among
the list in the BTS.

FYI, RC bug 618228 which you list above has also finally been fixed
this morning. I had been waiting for a sponsor for about 2 months
or so on that one. Otavio was kind enough to help me out and upload
my fix quickly after I asked him for support.

Regards

Rolf
  




-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e8eaeb7.5040...@rolf.leggewie.biz



Bug#622134: transition: openssl 1.0.0

2011-10-07 Thread Adam D. Barratt

On Fri, 07 Oct 2011 15:48:07 +0800, Rolf Leggewie wrote:

 I believe isdnutils is a
false positive in your list. All packages in testing depend on 1.0.0
of the openssl packages. The arches where isdnutils-derived packages
still depend on 0.9.8 either have outdated isdnutils and/or openssl
packages.


I'm afraid that you're mistaken:

adsb@franck:~$ grep-dctrl -S isdnutils -s Package,Depends (zcat 
ftp/dists/testing/main/binary-amd64/Packages.gz) | grep ssl
Depends: isdnutils-base (= 1:3.9.20060704+dfsg.2-8), debconf (= 1.2.9) 
| debconf-2.0, ppp, libc6 (= 2.7), libpcap0.8 (= 0.9.8), libssl0.9.8 
(= 0.9.8m-1)


*No* isdnutils packages in testing depend on openssl 1.0.0.

Regards,

Adam



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2f5d731a40fae82ded07c48694d23...@adsl.funky-badger.org



Bug#622134: transition: openssl 1.0.0

2011-10-07 Thread Rolf Leggewie
Adam,

thank you for your comment.

FWIW, http://packages.debian.org/sid/ipppd lists libssl0.9.8 for alpha,
armhf, hppa, m68k, sh4 and libssl1.0.0 for the rest.  I checked the
other binary packages as well.

I can only repeat that there is nothing inherently in isdnutils to force
dependency on libssl0.9.8.  Grep through the source and packaging
information if you don't believe me.

To me it seems as if the packages that still depend on the old libssl
are simply outdated and were built at a time when 0.9.8 was the default.
Maybe you want to rebuild the packages?  I don't think there's anything
I can do.

Regards

Rolf



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e8ec399.6000...@rolf.leggewie.biz



Bug#622134: transition: openssl 1.0.0

2011-10-07 Thread Rene Engelhard
On Fri, Oct 07, 2011 at 05:17:13PM +0800, Rolf Leggewie wrote:
 FWIW, http://packages.debian.org/sid/ipppd lists libssl0.9.8 for alpha,
 armhf, hppa, m68k, sh4 and libssl1.0.0 for the rest.  I checked the
 other binary packages as well.

Totally irrelevant.

sid != testing.

http://packages.debian.org/wheezy/ipppd;:

[...]
#

dep: libssl0.9.8 (= 0.9.8m-1)
SSL shared libraries 

[...]

Surprise!

 I can only repeat that there is nothing inherently in isdnutils to force
 dependency on libssl0.9.8.  Grep through the source and packaging
 information if you don't believe me.

See above. Maybe you should look at the right packages and ACK that
Adam meant *testing*.

 To me it seems as if the packages that still depend on the old libssl
 are simply outdated and were built at a time when 0.9.8 was the default.

Yes, and?

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111007114831.gc1...@rene-engelhard.de



Bug#622134: transition: openssl 1.0.0

2011-10-07 Thread Rolf Leggewie
I'm not in a mood for this kind of discussion. I can only reiterate
that there is nothing I can do.  Packages built after openssl 1.0.0 had
become the standard are fine and I have no control over older binary
packages that are already released.

 I can only repeat that there is nothing inherently in isdnutils to force
 dependency on libssl0.9.8.  Grep through the source and packaging
 information if you don't believe me.
 
 See above. Maybe you should look at the right packages and ACK that
 Adam meant *testing*.

There's nothing in isdnutils packaging or source in testing that would
force a dependency on a specific version, either.  Look at the
testing-to-unstable debdiff or the testing source if you think I'm
wrong.  The only significant difference is the time the packages were
built.  If packages are stuck at older binaries built pre-openssl1.0.0
for certain arches that is nothing I have control over, either.

You guys keep barking up the wrong tree.  Send a patch against isdnutils
if you disagree and can prove your point.

If there is indeed something I can do to help fix the situation I'm more
than willing to do that.  But I think there simply isn't.



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e8ef867.5000...@rolf.leggewie.biz



Bug#622134: transition: openssl 1.0.0

2011-10-07 Thread Rene Engelhard
On Fri, Oct 07, 2011 at 09:02:31PM +0800, Rolf Leggewie wrote:
 I'm not in a mood for this kind of discussion. I can only reiterate
 that there is nothing I can do.  Packages built after openssl 1.0.0 had
 become the standard are fine and I have no control over older binary

Yes.

 packages that are already released.

True.

  I can only repeat that there is nothing inherently in isdnutils to force
  dependency on libssl0.9.8.  Grep through the source and packaging
  information if you don't believe me.
  
  See above. Maybe you should look at the right packages and ACK that
  Adam meant *testing*.
 
 There's nothing in isdnutils packaging or source in testing that would
 force a dependency on a specific version, either.  Look at the

And?

 testing-to-unstable debdiff or the testing source if you think I'm
 wrong.  The only significant difference is the time the packages were
 built.  If packages are stuck at older binaries built pre-openssl1.0.0
 for certain arches that is nothing I have control over, either.
 
 You guys keep barking up the wrong tree.  Send a patch against isdnutils
 if you disagree and can prove your point.

You said in  4e8eaeb7.5040...@rolf.leggewie.biz:

All packages in testing depend on 1.0.0 of 
 the openssl packages.  The arches where isdnutils-derived packages still 
 depend on 0.9.8 either have outdated isdnutils and/or openssl packages.

*packages in testing. Proven wrong.

That was all what was to prove. No one denied that sid might have
picked up 1.0.0, but testing definitely isn't (and this isdnutils
keeps openssl 0.9.8 in testing as the idnutils *there* *does* depend
on 0.9.8)

Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70



--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111007131028.gd1...@rene-engelhard.de



Bug#622134: transition: openssl 1.0.0

2011-10-07 Thread peter green

openssl098 is still kept in testing by:
- ace (ICE on armel)

Taking a look at this one

- beid (RC-buggy, candidate for removal)
- ipsec-tools (#619687 #643570, has reverse dependencies)
- isakmpd (#622051, candidate for removal)
This bug has had a patch for several months, but the maintainer hasn't responded to said patch (either postively or negatively) 
and there hasn't been a maintainer upload in over a year. Maybe someone should NMU or even orphan the package.

- isdnutils (#618228, has reverse dependencies)

Maintainer has uploaded fix (as already discussed here), waiting for it to age 
and migrate to testing.

- pantomime1.2 (part of the gnustep transition)
- transgui (#632532, candidate for removal)

Apparently waiting for upstream to fix some issues when built with the latest 
fpc.





--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4e8fab7a.1020...@p10link.net



Bug#622134: transition: openssl 1.0.0

2011-10-06 Thread Julien Cristau
On Sun, Apr 10, 2011 at 16:02:14 +0200, Kurt Roeckx wrote:

 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: transition
 
 This is to track the transition of openssl 1.0.0.  Most of the
 problems are related to dropping SSLv2 support.
 
openssl098 is still kept in testing by:
- ace (ICE on armel)
- beid (RC-buggy, candidate for removal)
- ipsec-tools (#619687 #643570, has reverse dependencies)
- isakmpd (#622051, candidate for removal)
- isdnutils (#618228, has reverse dependencies)
- pantomime1.2 (part of the gnustep transition)
- transgui (#632532, candidate for removal)

A fix for the ones with reverse dependencies would be nice...

Cheers,
Julien



-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20111006184622.gn2...@radis.liafa.jussieu.fr



Bug#622134: transition: openssl 1.0.0

2011-04-10 Thread Kurt Roeckx
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

This is to track the transition of openssl 1.0.0.  Most of the
problems are related to dropping SSLv2 support.


Kurt




-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110410140214.ga22...@roeckx.be



Processed: Track openssl 1.0.0 related bugs

2011-04-10 Thread Debian Bug Tracking System
Processing commands for cont...@bugs.debian.org:

 block 622134 by 620777
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was not blocked by any bugs.
Added blocking bug(s) of 622134: 620777
 block 622134 by 620893
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 620777
Added blocking bug(s) of 622134: 620893
 block 622134 by 620998
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 620893 620777
Added blocking bug(s) of 622134: 620998
 block 622134 by 621395
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 620893 620998 620777
Added blocking bug(s) of 622134: 621395
 block 622134 by 621402
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 621395 620893 620998 620777
Added blocking bug(s) of 622134: 621402
 block 622134 by 621509
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 621395 620893 621402 620998 620777
Added blocking bug(s) of 622134: 621509
 block 622134 by 622074
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 621395 620893 621509 620998 621402 620777
Added blocking bug(s) of 622134: 622074
 block 622134 by 622068
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 621395 620893 622074 621509 621402 620998 620777
Added blocking bug(s) of 622134: 622068
 block 622134 by 622027
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 620998 621402 620777 621395 622074 621509
Added blocking bug(s) of 622134: 622027
 block 622134 by 622076
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 621402 620998 620777 621395 621509 622074 622027
Added blocking bug(s) of 622134: 622076
 block 622134 by 622072
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 620998 621402 620777 621395 622074 621509 622076 
622027
Added blocking bug(s) of 622134: 622072
 block 622134 by 622065
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 621402 620998 620777 622072 621395 621509 622074 
622027 622076
Added blocking bug(s) of 622134: 622065
 block 622134 by 622025
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 620998 621402 620777 622072 621395 622074 621509 
622076 622027 622065
Added blocking bug(s) of 622134: 622025
 block 622134 by 622012
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622025 621402 620998 620777 622072 621395 621509 
622074 622027 622076 622065
Added blocking bug(s) of 622134: 622012
 block 622134 by 622070
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622025 620998 621402 620777 622072 621395 622012 
622074 621509 622076 622027 622065
Added blocking bug(s) of 622134: 622070
 block 622134 by 622069
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622025 621402 620998 620777 622072 621395 622070 
622012 621509 622074 622027 622076 622065
Added blocking bug(s) of 622134: 622069
 block 622134 by 622049
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622025 620998 621402 621509 622076 622027 622065 
620777 622072 621395 622069 622070 622012 622074
Added blocking bug(s) of 622134: 622049
 block 622134 by 622008
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622025 621402 620998 622049 621509 622027 622076 
622065 620777 622072 622069 621395 622012 622070 622074
Added blocking bug(s) of 622134: 622008
 block 622134 by 622014
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622008 622025 620998 621402 622049 621509 622076 
622027 622065 620777 622072 621395 622069 622070 622012 622074
Added blocking bug(s) of 622134: 622014
 block 622134 by 622016
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622008 622025 621402 620998 622049 621509 622027 
622076 622065 622014 620777 622072 622069 621395 622012 622070 622074
Added blocking bug(s) of 622134: 622016
 block 622134 by 622054
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622008 622025 620998 621402 622049 622016 621509 
622076 622027 622065 622014 620777 622072 621395 622069 622070 622012 622074
Added blocking bug(s) of 622134: 622054
 block 622134 by 622034
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622008 622025 621402 620998 622049 621509 622016 
622027 622076 622065 622014 620777 622072 622069 621395 622012 622070 622074 
622054
Added blocking bug(s) of 622134: 622034
 block 622134 by 621994
Bug #622134 [release.debian.org] transition: openssl 1.0.0
Was blocked by: 622068 620893 622008 622034 622025 620998 621402 622049 622016 
621509 622076 622027 622065 622014 620777 622072 621395 622069 622070 622012 
622074

Re: Openssl 1.0.0

2011-04-06 Thread Kurt Roeckx
On Wed, Apr 06, 2011 at 12:45:03AM +0200, Julien Cristau wrote:
 On Sun, Feb 13, 2011 at 00:27:51 +0100, Kurt Roeckx wrote:
 
  Hi,
  
  I would like to upload version 1.0.0(d) to unstable soon.  It
  changes soname, but as far as I know the API is still compatible
  with the old one, and you should be able to rebuild everything
  against the new version.
  
 So this is started now.  Most packages should be fine because we keep
 libssl0.9.8 around for a while.  However, the udeb needed for openssh is
 going away, which means we'd need to migrate openssl, openssl098 and
 openssh together to testing.  That might not work out because of
 #612607, which Colin says nobody knows how to fix yet.
 
 I can see two ways out.  One is ignoring the bug and getting the new
 openssh in testing anyway.  The other is to force libcrypto0.9.8-udeb to
 stay in testing for now.  Please pick one (or an alternative I'm not
 thinking of). :)

Or re-introduce libcrypto0.9.8-udeb as part of the openssl098
source package.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110406071054.ga20...@roeckx.be



Re: Openssl 1.0.0

2011-04-05 Thread Julien Cristau
On Sun, Feb 13, 2011 at 00:27:51 +0100, Kurt Roeckx wrote:

 Hi,
 
 I would like to upload version 1.0.0(d) to unstable soon.  It
 changes soname, but as far as I know the API is still compatible
 with the old one, and you should be able to rebuild everything
 against the new version.
 
So this is started now.  Most packages should be fine because we keep
libssl0.9.8 around for a while.  However, the udeb needed for openssh is
going away, which means we'd need to migrate openssl, openssl098 and
openssh together to testing.  That might not work out because of
#612607, which Colin says nobody knows how to fix yet.

I can see two ways out.  One is ignoring the bug and getting the new
openssh in testing anyway.  The other is to force libcrypto0.9.8-udeb to
stay in testing for now.  Please pick one (or an alternative I'm not
thinking of). :)

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110405224503.gb3...@radis.liafa.jussieu.fr



Re: Openssl 1.0.0

2011-04-04 Thread Kurt Roeckx
On Mon, Apr 04, 2011 at 01:42:20PM +0900, Nobuhiro Iwamatsu wrote:
 Hi,
 
 I confirm that some packages still use SSLv2[1][2].
 I suggest that we do binNMU about openssl 1.0.

I'm sure we'll do binNMUs soon.  But I think the release
team might want to wait until 1.0.0 has reached testing.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110404164619.ga31...@roeckx.be



Re: Openssl 1.0.0

2011-04-03 Thread Nobuhiro Iwamatsu
Hi,

2011/3/9 Kurt Roeckx k...@roeckx.be:
 On Tue, Mar 08, 2011 at 11:11:15PM +0100, Jakub Wilk wrote:
 * Kurt Roeckx k...@roeckx.be, 2011-02-13, 00:27:
 I would like to upload version 1.0.0(d) to unstable soon. It
 changes soname, but as far as I know the API is still compatible
 with the old one, and you should be able to rebuild everything
 against the new version.

 Support for SSLv2 has been disabled in openssl 1.0.0c-2. We have a
 few dozens of packages in the archive that are not prepared for
 this: when rebuilt, they will either FTBFS or, worse, produce shared
 libraries with missing symbols.

 We really should stop using SSLv2.  It was either making the
 functions related to ssl 2 do nothing, and potentionally silently
 breaking the applications, or just removing the related function
 from the API and trying to make sure they fail on build and
 hopefully catch most of the problems like that.

 I think I'll also change some of the header files so that no v2
 related things are defined or declared, since the define for it
 doesn't seem to be used correctly everywhere.


I confirm that some packages still use SSLv2[1][2].
I suggest that we do binNMU about openssl 1.0.

[1]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620776
[2]: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620777

Best regards,
  Nobuhirio
-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/banlktikuoo2-u8axkc3nn4zkjoj0xpy...@mail.gmail.com



Re: Openssl 1.0.0

2011-03-18 Thread Kurt Roeckx
Hi,

I'm still waiting for a reply to my questions.  If I don't hear
from you I will upload it to unstable a week from now.


Kurt


On Sun, Mar 06, 2011 at 03:07:47PM +0100, Kurt Roeckx wrote:
 Hi,
 
 I'm still waiting for a reply.
 
 
 Kurt
 
 On Sun, Feb 13, 2011 at 12:27:51AM +0100, Kurt Roeckx wrote:
  Hi,
  
  I would like to upload version 1.0.0(d) to unstable soon.  It
  changes soname, but as far as I know the API is still compatible
  with the old one, and you should be able to rebuild everything
  against the new version.
  
  I wonder if I need to upload an openssl098 source package at
  the same time to provide the current soname.  I would really
  like to avoid having the old soname in wheezy, so I would like
  to get rid of it as soon as possible and don't plan to keep
  a -dev package for it in any case.
  
  Please let me know what I should do, and when you think it's
  a good time to do that.
  
  
  Kurt
  
  
  -- 
  To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
  with a subject of unsubscribe. Trouble? Contact 
  listmas...@lists.debian.org
  Archive: http://lists.debian.org/20110212232751.gb9...@roeckx.be
  
 
 
 -- 
 To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 Archive: http://lists.debian.org/20110306140747.ga17...@roeckx.be
 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110318202211.ga2...@roeckx.be



Re: Openssl 1.0.0

2011-03-18 Thread Julien Cristau
On Sun, Feb 13, 2011 at 00:27:51 +0100, Kurt Roeckx wrote:

 Hi,
 
 I would like to upload version 1.0.0(d) to unstable soon.  It
 changes soname, but as far as I know the API is still compatible
 with the old one, and you should be able to rebuild everything
 against the new version.
 
 I wonder if I need to upload an openssl098 source package at
 the same time to provide the current soname.  I would really
 like to avoid having the old soname in wheezy, so I would like
 to get rid of it as soon as possible and don't plan to keep
 a -dev package for it in any case.
 
We should keep both SONAMES in sid and wheezy for now, IMO.  So I think
that means first upload openssl 1.0.0 as a new source package without
the -dev (this can probably happen now).  Then when that's in testing
and you get an ack, switch the -dev from 0.9.8 to 1.0.0.

 Please let me know what I should do, and when you think it's
 a good time to do that.
 
We'll let you know.  Thanks for your patience.

Cheers,
Julien


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110318203023.gs12...@radis.liafa.jussieu.fr



Re: Openssl 1.0.0

2011-03-18 Thread Kurt Roeckx
On Fri, Mar 18, 2011 at 09:30:23PM +0100, Julien Cristau wrote:
 We should keep both SONAMES in sid and wheezy for now, IMO.  So I think
 that means first upload openssl 1.0.0 as a new source package without
 the -dev (this can probably happen now).  Then when that's in testing
 and you get an ack, switch the -dev from 0.9.8 to 1.0.0.

If all you want to do is to have both libssl0.9.8 and libssl1.0.0
both in testing at the same time, I don't see why you want to do
it like that.  I could just upload a openssl098 source package
just containing libssl0.9.8(-dbg), and have the openssl source
package provide libssl1.0.0 and libssl-dev.  It shouldn't take
that long for the openssl098 pacakge to migrate to testing.

I could also upload an openssl098 source package that provides
the libssl0.9.8(-dbg) and libssl-dev binary package.  And I would
upload an openssl source package that provides libssl1.0.0(-dbg),
openssl, and libcrypto1.0.0-udeb, so without -dev package.  And
once openssl098 is migrated to testing I could change the -dev
package.  But it seems to be more work, and I don't see the what
that would gain us.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110318223217.ga3...@roeckx.be



Re: Openssl 1.0.0

2011-03-08 Thread Kurt Roeckx
On Tue, Mar 08, 2011 at 11:11:15PM +0100, Jakub Wilk wrote:
 * Kurt Roeckx k...@roeckx.be, 2011-02-13, 00:27:
 I would like to upload version 1.0.0(d) to unstable soon. It
 changes soname, but as far as I know the API is still compatible
 with the old one, and you should be able to rebuild everything
 against the new version.
 
 Support for SSLv2 has been disabled in openssl 1.0.0c-2. We have a
 few dozens of packages in the archive that are not prepared for
 this: when rebuilt, they will either FTBFS or, worse, produce shared
 libraries with missing symbols.

We really should stop using SSLv2.  It was either making the
functions related to ssl 2 do nothing, and potentionally silently
breaking the applications, or just removing the related function
from the API and trying to make sure they fail on build and
hopefully catch most of the problems like that.

I think I'll also change some of the header files so that no v2
related things are defined or declared, since the define for it
doesn't seem to be used correctly everywhere.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110308232928.ga13...@roeckx.be



Re: Openssl 1.0.0

2011-03-08 Thread Jakub Wilk

* Kurt Roeckx k...@roeckx.be, 2011-02-13, 00:27:
I would like to upload version 1.0.0(d) to unstable soon. It changes 
soname, but as far as I know the API is still compatible with the old 
one, and you should be able to rebuild everything against the new 
version.


Support for SSLv2 has been disabled in openssl 1.0.0c-2. We have a few 
dozens of packages in the archive that are not prepared for this: when 
rebuilt, they will either FTBFS or, worse, produce shared libraries with 
missing symbols.


--
Jakub Wilk


--
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110308221115.ga8...@jwilk.net



Openssl 1.0.0

2011-02-12 Thread Kurt Roeckx
Hi,

I would like to upload version 1.0.0(d) to unstable soon.  It
changes soname, but as far as I know the API is still compatible
with the old one, and you should be able to rebuild everything
against the new version.

I wonder if I need to upload an openssl098 source package at
the same time to provide the current soname.  I would really
like to avoid having the old soname in wheezy, so I would like
to get rid of it as soon as possible and don't plan to keep
a -dev package for it in any case.

Please let me know what I should do, and when you think it's
a good time to do that.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110212232751.gb9...@roeckx.be