Hi,
> ... on second thought ... and since nothing in Debian (except gnutls*) is
> using libopencdk ...
.. and on third thought ... since libtool obsoletes the need of foo-dev to
depend on bar-dev ... we can actually forget about the interim opencdk8.11
package.
In other words, even though libope
Hi, Kenshi Muto wrote:
> OK, I and Sebastien took worst method. X-(
> I didn't want to change libcupsys2 name, but we did...
The libcupsys2 renaming could have been avoided...
oh well, you always know better *afterwards*.
> Must I revert the package name to libcupsys2? Or provide new package,
>
On Sun, Jul 25, 2004 at 07:08:24AM +0900, Kenshi Muto wrote:
> At Sat, 24 Jul 2004 19:23:32 +0200,
> Andreas Metzler wrote:
> > * contrary to the last transition (libcupsys2 -> libcupsys-2gnutls10)
> > different versions of gnutls and gcrypt can co-exist in the archive.
> > Of course the last tr
Hi,
At Sat, 24 Jul 2004 19:23:32 +0200,
Andreas Metzler wrote:
> * contrary to the last transition (libcupsys2 -> libcupsys-2gnutls10)
> different versions of gnutls and gcrypt can co-exist in the archive.
>
> Of course the last transition was as bad as possible, so "smoother" is
> not necessar
Hi, Matthias Urlichs wrote:
> I could create a opencdk8.11 package, but that'd need different library
> versioning tags, which would be incompatible with Upstream and presumably
> cause problems with non-Debian binaries. I can do that if there's a
> consensus that this is not going to be much of a
Hi, Steve Langasek wrote:
> I would recommend re-uploading gnutls11 and gcrypt11 to unstable
> immediately; I don't see any reason why the addition of new library
> packages needs to be staged in experimental, this would be more of an
> issue for packages *depending* on such libraries.
Unfortunat
On Sat, Jul 24, 2004 at 05:35:59PM +0200, Matthias Urlichs wrote:
> * gnutls10 and gcrypt7 are *seriously* out-of-date Upstream;
> * Upstream urges us to not distribute them in Sarge (cf. bug #258975):
> >> FWIW, I want to restate that I consider it a *very bad idea* to go
> >> with libgcrypt7
Hi, Andreas Metzler wrote:
> Of course the last transition was as bad as possible, so "smoother" is
> not necessarily "smooth enough".
I define "smooth enough" as "nothing breaks" (which isn't broken already).
(The d-i people will probably have some remarks about this assertion...)
> I am not su
Hi, J.H.M. Dassen Ray wrote:
> On Sat, Jul 24, 2004 at 17:35:59 +0200, Matthias Urlichs wrote:
>> * the API changes are minor and only require recompilation;
>
> "only [...] recompilation". Please provide details on the number of packages
> this affects. The last gnutls change affected 400+ packa
On 2004-07-24 "J.H.M. Dassen (Ray)" <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 24, 2004 at 17:35:59 +0200, Matthias Urlichs wrote:
> > * the API changes are minor and only require recompilation;
> "only [...] recompilation". Please provide details on the number of
> packages this affects. The last g
On Sat, Jul 24, 2004 at 17:35:59 +0200, Matthias Urlichs wrote:
> * the API changes are minor and only require recompilation;
"only [...] recompilation". Please provide details on the number of packages
this affects. The last gnutls change affected 400+ packages (KDE, GNOME,
cups, ...) and tooks m
Hi,
given that
* gnutls10 and gcrypt7 are *seriously* out-of-date Upstream;
* Upstream urges us to not distribute them in Sarge (cf. bug #258975):
>> FWIW, I want to restate that I consider it a *very bad idea* to go
>> with libgcrypt7 for the Sarge release. We did not declared that
>> rel
On Fri, Jul 23, 2004 at 08:47:39PM -0400, Jay Berkenbilt wrote:
> > However, it's best to give maintainers of these packages *immediate*
> > notice of the coming transition, so they can prepare for it even before
> > libtiff4 is in the archive. . . .
> Should I send individual mail to each m
13 matches
Mail list logo
