Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-30 Thread Steve Langasek
On Wed, Aug 23, 2006 at 10:40:18PM +0100, James Westby wrote:
   We ant to request removal ASAP, however, there are 4 packages with
   binary dependencies, and so require a binNMU. Two of these require a
   sourceful upload however as they are not binNMU safe.

  Which ones aren't binNMU-safe?

 uim-applet-gnome (#383040) and ggz-kde-games (no report as I have found
 it just now) I think, as they both use ${source-Version} to depend on
 their data.

 The binNMU safe ones are evolution-exchange and ggz-kde-client. I am
 unsure of how to proceed, as Andreas Metzler has been handling it up to
 now. Shall I email -release with a binNMU request for these two?

So conveniently, all of these packages have now had maintainer uploads in
the past few days, leaving only a handful of reverse-dependencies on
libgnutls11 on individual architectures (principally on m68k and arm, which
are the archs having trouble keeping up).

I would say it's time to file a bug against ftp.d.o to request libgnutls11's
removal.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature


Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-24 Thread Steve Langasek
On Wed, Aug 23, 2006 at 10:40:18PM +0100, James Westby wrote:
 On (23/08/06 14:31), Steve Langasek wrote:
   We ant to request removal ASAP, however, there are 4 packages with
   binary dependencies, and so require a binNMU. Two of these require a
   sourceful upload however as they are not binNMU safe.

  Which ones aren't binNMU-safe?

 uim-applet-gnome (#383040) and ggz-kde-games (no report as I have found
 it just now) I think, as they both use ${source-Version} to depend on
 their data.

 The binNMU safe ones are evolution-exchange and ggz-kde-client. I am
 unsure of how to proceed, as Andreas Metzler has been handling it up to
 now. Shall I email -release with a binNMU request for these two?

 Also I am have only checked i386 for binary dependencies, is there a way
 to ensure the same for all arches?

FWIW, this omits ggz-client-libs, which had the dependency on most archs but
not on i386.  So ggz-kde-client probably can't be binNMUed until
ggz-client-libs is fixed first; since not all archs need binNMUs for
ggz-client-libs, that makes it inconvenient to do this with dep-waits, so
I'll probably wait a couple of days instead febofer trying to queue it.

And I think evolution-exchange was just NMUed, so no need for a binNMU there
either.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-23 Thread Bastian Blank
Package: libtasn1-3-bin
Version: 0.3.5-2
Severity: serious

libtasn1-3-bin is important and conflicts against the important package
libtasn1-2-bin.

Bastian

-- 
The joys of love made her human and the agonies of love destroyed her.
-- Spock, Requiem for Methuselah, stardate 5842.8


signature.asc
Description: Digital signature


Bug#384324: [Pkg-gnutls-maint] Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-23 Thread James Westby
On (23/08/06 16:11), Bastian Blank wrote:
 Package: libtasn1-3-bin
 Version: 0.3.5-2
 Severity: serious
 
 libtasn1-3-bin is important and conflicts against the important package
 libtasn1-2-bin.
 

Apologies for this,

libtasn1 is currently undergoing a transition, with libtasn1-2 to be
removed ASAP, it is currently blocked by gnutls11 remaining, and there
is only one reverse dep of this left. There is an RC bug (#383040) filed, but 
with no maintainer comment yet. 

Can I ask how this should have been handled, as the two packages provide
the same files, but a security bug prompted an API change, hence the new
package?

Is it satisfactory for this bug to wait and be resolved by the removal
of -2?

James

-- 
  James Westby   --GPG Key ID: B577FE13-- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#384324: [Pkg-gnutls-maint] Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-23 Thread Bastian Blank
On Wed, Aug 23, 2006 at 04:05:49PM +0100, James Westby wrote:
 Can I ask how this should have been handled, as the two packages provide
 the same files, but a security bug prompted an API change, hence the new
 package?

Why is this package important at all? It barely fullfills the
conditions.

 Is it satisfactory for this bug to wait and be resolved by the removal
 of -2?

If you are going to request removal now, it is okay. The problem that
debootstrap only supports that as it simply discards it and cdebootstrap
choke on it.

Bastian

-- 
No one wants war.
-- Kirk, Errand of Mercy, stardate 3201.7


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#384324: [Pkg-gnutls-maint] Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-23 Thread James Westby
On (23/08/06 18:58), Bastian Blank wrote:
 On Wed, Aug 23, 2006 at 04:05:49PM +0100, James Westby wrote:
  Can I ask how this should have been handled, as the two packages provide
  the same files, but a security bug prompted an API change, hence the new
  package?
 
 Why is this package important at all? It barely fullfills the
 conditions.

I'm not sure it should be. The source package is Priority: Important,
and there is no Priority: for the binary package. Maybe we should change
this on the next upload.

 
  Is it satisfactory for this bug to wait and be resolved by the removal
  of -2?
 
 If you are going to request removal now, it is okay. The problem that
 debootstrap only supports that as it simply discards it and cdebootstrap
 choke on it.

We ant to request removal ASAP, however, there are 4 packages with
binary dependencies, and so require a binNMU. Two of these require a
sourceful upload however as they are not binNMU safe.

Andreas has been pushing this transition along, but he is away until the
end of the month, and so it has stalled a little. 

James


-- 
  James Westby   --GPG Key ID: B577FE13-- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#384324: [Pkg-gnutls-maint] Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-23 Thread Steve Langasek
reassign 384324 ftp.debian.org
severity 384324 important
retitle 384324 please lower the override priority for libtasn1-3-bin and 
libtasn1-2-bin
thanks

On Wed, Aug 23, 2006 at 06:07:23PM +0100, James Westby wrote:
 On (23/08/06 18:58), Bastian Blank wrote:
  On Wed, Aug 23, 2006 at 04:05:49PM +0100, James Westby wrote:
   Can I ask how this should have been handled, as the two packages provide
   the same files, but a security bug prompted an API change, hence the new
   package?

  Why is this package important at all? It barely fullfills the
  conditions.

 I'm not sure it should be. The source package is Priority: Important,
 and there is no Priority: for the binary package. Maybe we should change
 this on the next upload.

Yes, please do so, but more importantly the override needs to be changed in
the archive; let's reassign this bug to ftp.debian.org.

   Is it satisfactory for this bug to wait and be resolved by the removal
   of -2?

  If you are going to request removal now, it is okay. The problem that
  debootstrap only supports that as it simply discards it and cdebootstrap
  choke on it.

 We ant to request removal ASAP, however, there are 4 packages with
 binary dependencies, and so require a binNMU. Two of these require a
 sourceful upload however as they are not binNMU safe.

Which ones aren't binNMU-safe?

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]



Bug#384324: libtasn1-3-bin - important, conflicts against important package

2006-08-23 Thread James Westby
On (23/08/06 14:31), Steve Langasek wrote:
 reassign 384324 ftp.debian.org
 severity 384324 important
 retitle 384324 please lower the override priority for libtasn1-3-bin and 
 libtasn1-2-bin
 thanks
 
 On Wed, Aug 23, 2006 at 06:07:23PM +0100, James Westby wrote:
  I'm not sure it should be. The source package is Priority: Important,
  and there is no Priority: for the binary package. Maybe we should change
  this on the next upload.
 
 Yes, please do so, but more importantly the override needs to be changed in
 the archive; let's reassign this bug to ftp.debian.org.


Yes, of course. Thanks. I shall make the change in SVN to match.

  We ant to request removal ASAP, however, there are 4 packages with
  binary dependencies, and so require a binNMU. Two of these require a
  sourceful upload however as they are not binNMU safe.
 
 Which ones aren't binNMU-safe?
 

uim-applet-gnome (#383040) and ggz-kde-games (no report as I have found
it just now) I think, as they both use ${source-Version} to depend on
their data.

The binNMU safe ones are evolution-exchange and ggz-kde-client. I am
unsure of how to proceed, as Andreas Metzler has been handling it up to
now. Shall I email -release with a binNMU request for these two?

Also I am have only checked i386 for binary dependencies, is there a way
to ensure the same for all arches?

Thanks,

James

-- 
  James Westby   --GPG Key ID: B577FE13-- http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!|7U.L#9E)Tu)T0AM - secp256r1/nistp256



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]