Hi,
On Sun, Jul 25, 2004 at 09:48:21AM +0200, Matthias Urlichs wrote:
> Hi, Andreas Metzler wrote:
>
> > Bad news for you. :-( This change in the new gnutls10
> > | * Use hevea, not latex2html.
> > makes it FTBFS on hppa, m68k, mips, mipsel, s390 because hevea is
> > uninstallable in these archi
Hi,
On Wed, Jul 28, 2004 at 02:13:02AM +0200, Matthias Urlichs wrote:
>
>
> Andreas Metzler wrote:
> > GnuTLS currently uses cdbs, which makes it difficult (or impossible?)
> > to make use of Build-Depends-Indep.
>
> I have decided to move the documentation to contrib.
>
> The LaTeX code conta
Andreas Metzler wrote:
> GnuTLS currently uses cdbs, which makes it difficult (or impossible?)
> to make use of Build-Depends-Indep.
I have decided to move the documentation to contrib.
The LaTeX code contains latex2html-specific macros which are nontrivial to
modify. The attempt at Hevea-izati
On 2004-07-25 Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Jul 25, 2004 at 09:48:21AM +0200, Matthias Urlichs wrote:
[hevea]
> > Any other latex >= HTML converters which don't require an in-depth latex
> > knowledge to adapt to? (I had help with hevea...)
> Is there any chance this could be
On Sun, Jul 25, 2004 at 09:48:21AM +0200, Matthias Urlichs wrote:
> Hi, Andreas Metzler wrote:
> > Bad news for you. :-( This change in the new gnutls10
> > | * Use hevea, not latex2html.
> > makes it FTBFS on hppa, m68k, mips, mipsel, s390 because hevea is
> > uninstallable in these architecture
Hi, Andreas Metzler wrote:
> Bad news for you. :-( This change in the new gnutls10
> | * Use hevea, not latex2html.
> makes it FTBFS on hppa, m68k, mips, mipsel, s390 because hevea is
> uninstallable in these architectures, as ocaml does not build on these
> anymore.
Yowch.
Any other latex >= H
On 2004-07-24 Matthias Urlichs <[EMAIL PROTECTED]> wrote:
> I will upload a gnutls10 which builds against the new version
> later today.
[...]
Bad news for you. :-( This change in the new gnutls10
| * Use hevea, not latex2html.
makes it FTBFS on hppa, m68k, mips, mipsel, s390 because hevea is
uni
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
19 matches
Mail list logo
