Bug#688791: unblock: elfutils/0.153-2

[Kurt Roeckx]

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

Hi,

I would like to move the elfutils version 0.153-2 to testing.
Note that the version 0.152-1 is currently in testing, so this
is a new upstream version.

The version in testing has an RC bug (#684825).  I could
fix that instead if you want.  But I got the feeling that
you would be open to move 0.153-2 to testing.

I would really prefer the 0.153-2 to move to testing.

The debdiff between 0.153-1 and 0.153-2 is attached
if that's useful at all.


Kurt

diff -Nru elfutils-0.153/debian/changelog elfutils-0.153/debian/changelog
--- elfutils-0.153/debian/changelog	2012-02-25 01:48:58.0 +0100
+++ elfutils-0.153/debian/changelog	2012-09-18 21:40:06.0 +0200
@@ -1,3 +1,15 @@
+elfutils (0.153-2) unstable; urgency=low
+
+  * Make it actually build properly using build-arch.  (Closes: #684528)
+  * Call rwlock_unlock() before rwlock_fini().  The lock was still held
+causing problems on kfreebsd.  (Closes: #662041)
+  * Don't exclude sh_type = SHT_NUM from stripping, it's set to
+SHT_MIPS_DWARF on mips. (Closes: #662041)
+  * readelf -w didn't show the content of debug sections on mips
+because sh_type was set to SHT_MIPS_DWARF.
+
+ -- Kurt Roeckx k...@roeckx.be  Tue, 18 Sep 2012 21:12:08 +0200
+
 elfutils (0.153-1) unstable; urgency=low
 
   [ Jonathan Nieder jrnie...@gmail.com ]
diff -Nru elfutils-0.153/debian/patches/alldts.patch elfutils-0.153/debian/patches/alldts.patch
--- elfutils-0.153/debian/patches/alldts.patch	2012-02-24 21:21:41.0 +0100
+++ elfutils-0.153/debian/patches/alldts.patch	2012-09-18 21:53:21.0 +0200
@@ -1,5 +1,6 @@
 From: Kurt Roeckx k...@roeckx.be
 Subject: Set up the test environment so that we actually test the new library
+Applied-Upstream: commit:593f2af73d971bdc9dcc06622d529e7848c31f57
 
 --- a/tests/run-alldts.sh.orig	2012-02-24 20:17:17.0 +
 +++ a/tests/run-alldts.sh	2012-02-24 20:17:28.0 +
diff -Nru elfutils-0.153/debian/patches/elf_end_unlock.patch elfutils-0.153/debian/patches/elf_end_unlock.patch
--- elfutils-0.153/debian/patches/elf_end_unlock.patch	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.153/debian/patches/elf_end_unlock.patch	2012-09-18 21:55:20.0 +0200
@@ -0,0 +1,17 @@
+From: Kurt Roeckx k...@roeckx.be
+Subject: Call rwlock_unlock() before rwlock_fini()
+Applied-Upstream: commit:495501611820a9d5c462fda56045c146f7b922d7
+Bug-Debian: http://bugs.debian.org/662041
+
+diff --git a/libelf/elf_end.c b/libelf/elf_end.c
+index 5112eae..6392eaf 100644
+--- a/libelf/elf_end.c
 b/libelf/elf_end.c
+@@ -241,6 +241,7 @@ elf_end (elf)
+ 	munmap (elf-map_address, elf-maximum_size);
+ }
+ 
++  rwlock_unlock (elf-lock);
+   rwlock_fini (elf-lock);
+ 
+   /* Finally the descriptor itself.  */
diff -Nru elfutils-0.153/debian/patches/mips_readelf_w.patch elfutils-0.153/debian/patches/mips_readelf_w.patch
--- elfutils-0.153/debian/patches/mips_readelf_w.patch	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.153/debian/patches/mips_readelf_w.patch	2012-09-18 21:54:18.0 +0200
@@ -0,0 +1,22 @@
+From: Kurt Roeckx k...@roeckx.be
+Subject: Make readelf -w output debug information on mips
+Bug-Debian: http://bugs.debian.org/662041
+Forwarded: not-needed
+
+Upstreams wants a change where this is handled by a hook that needs
+to be filled in by the backend for the arch.
+
+Index: elfutils-0.153/src/readelf.c
+===
+--- elfutils-0.153.orig/src/readelf.c	2012-08-10 22:01:55.0 +0200
 elfutils-0.153/src/readelf.c	2012-09-18 21:46:27.0 +0200
+@@ -7364,7 +7364,8 @@
+   GElf_Shdr shdr_mem;
+   GElf_Shdr *shdr = gelf_getshdr (scn, shdr_mem);
+ 
+-  if (shdr != NULL  shdr-sh_type == SHT_PROGBITS)
++  if (shdr != NULL  (
++	 (shdr-sh_type == SHT_PROGBITS) || (shdr-sh_type == SHT_MIPS_DWARF)))
+ 	{
+ 	  static const struct
+ 	  {
diff -Nru elfutils-0.153/debian/patches/series elfutils-0.153/debian/patches/series
--- elfutils-0.153/debian/patches/series	2012-02-24 23:26:59.0 +0100
+++ elfutils-0.153/debian/patches/series	2012-09-18 21:42:18.0 +0200
@@ -8,3 +8,6 @@
 elf_additions.diff
 alldts.patch
 scanf-format.patch
+elf_end_unlock.patch
+strip_sh_type.patch
+mips_readelf_w.patch
diff -Nru elfutils-0.153/debian/patches/strip_sh_type.patch elfutils-0.153/debian/patches/strip_sh_type.patch
--- elfutils-0.153/debian/patches/strip_sh_type.patch	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.153/debian/patches/strip_sh_type.patch	2012-09-18 21:41:54.0 +0200
@@ -0,0 +1,22 @@
+From: Roland McGrath rol...@hack.frob.com
+Subject: Don't exclude sh_type = SHT_NUM from stripping.
+Origin: upstream, commit:8e8f0be57354d3fa094d0927930dbe1bc1ce8816
+Bug-Debian: http://bugs.debian.org/662041
+
+Needed on mips because sh_type is set to SHT_MIPS_DWARF
+
+index 8b4c0d7..bda192c 100644
+--- a/libelf

Bug#688791: unblock: elfutils/0.153-2

[Kurt Roeckx]

On Sat, Oct 06, 2012 at 05:40:17PM +0200, Kurt Roeckx wrote:
 
 I would really like to know how to proceed with this.

Can someone please comment on this?


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/20121010165314.ga3...@roeckx.be

Bug#688791: unblock: elfutils/0.153-2

[Kurt Roeckx]

So Neil told me on IRC to just fix #684825 via t-p-u using the patch
that's in that bug report.

I looked in to that and found that to due multi-arch changes in
glibc I now run into #691612.

So if I want to fix it via t-p-u I would also need to backport the
multi-arch changes.  The original patch for that is in #657139,
but the patch like it's in that bug report is broken.

Please let me know what I should do.


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/20121027180853.ga32...@roeckx.be

Bug#688791: unblock: elfutils/0.153-2

[Kurt Roeckx]

On Mon, Nov 12, 2012 at 02:15:48PM +, Adam D. Barratt wrote:
 On Sat, 2012-10-27 at 20:08 +0200, Kurt Roeckx wrote:
  So Neil told me on IRC to just fix #684825 via t-p-u using the patch
  that's in that bug report.
  
  I looked in to that and found that to due multi-arch changes in
  glibc I now run into #691612.
  
  So if I want to fix it via t-p-u I would also need to backport the
  multi-arch changes.
 
 Looking at the diff, are there any changes required outside of the
 --libdir setting in debian/rules and the path changes in *.install?

As far as I know the changed for multiarch would require:
- newer debhelper, new compat level
- control file changes
- *.install changes
- the --libdir option to configure

  The original patch for that is in #657139,
  but the patch like it's in that bug report is broken.
 
 That bug is currently assigned to eglibc. What's the status there - does
 unstable's elfutils function correctly wrt multi-arch, or are there
 further changes needed on the libc side?

The bug that's assigned to libc is #632281.  I don't know about
the status there.  If we get a multiarch version of elfutils in
testing, there is no need to change libc (for me).  But I think
it would be good in general that it would look at both the
non-multiarch and multiarch path.

The libc code in testing/unstable will only look at the multi-arch
path.  So the elfutils in testing doesn't work, but the elfutils
in unstable does work.


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/20121112145220.ga25...@roeckx.be

Bug#688791: unblock: elfutils/0.153-2

[Kurt Roeckx]

On Mon, Nov 12, 2012 at 03:52:20PM +0100, Kurt Roeckx wrote:
 On Mon, Nov 12, 2012 at 02:15:48PM +, Adam D. Barratt wrote:
  On Sat, 2012-10-27 at 20:08 +0200, Kurt Roeckx wrote:
   So Neil told me on IRC to just fix #684825 via t-p-u using the patch
   that's in that bug report.
   
   I looked in to that and found that to due multi-arch changes in
   glibc I now run into #691612.
   
   So if I want to fix it via t-p-u I would also need to backport the
   multi-arch changes.
  
  Looking at the diff, are there any changes required outside of the
  --libdir setting in debian/rules and the path changes in *.install?
 
 As far as I know the changed for multiarch would require:
 - newer debhelper, new compat level
 - control file changes
 - *.install changes
 - the --libdir option to configure

So I uploaded a version that doesn't require multiarch to t-p-u.
The debdiff is attached.


Kurt

diff -Nru elfutils-0.152/debian/changelog elfutils-0.152/debian/changelog
--- elfutils-0.152/debian/changelog	2011-02-26 15:09:58.0 +0100
+++ elfutils-0.152/debian/changelog	2012-11-12 21:03:09.0 +0100
@@ -1,3 +1,16 @@
+elfutils (0.152-1+wheezy1) testing-proposed-updates; urgency=low
+
+  [ Sébastien Villemot ]
+  * strict-aliasing.diff: new patch taken from upstream (Closes: #684825).
+Thanks to Mark Wielaard for pointing to the relevant upstream commit.
+
+  [ Kurt Roeckx ]
+  * Use elf_end_unlock.patch from unstable (Closes: #662041)
+  * Use dlopen() with lib instead of $LIB to open the backends.
+(Closes: #691612)
+
+ -- Kurt Roeckx k...@roeckx.be  Mon, 12 Nov 2012 20:22:05 +0100
+
 elfutils (0.152-1) unstable; urgency=low
 
   * New upstream release
diff -Nru elfutils-0.152/debian/patches/backend_dlopen.patch elfutils-0.152/debian/patches/backend_dlopen.patch
--- elfutils-0.152/debian/patches/backend_dlopen.patch	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.152/debian/patches/backend_dlopen.patch	2012-11-12 21:03:23.0 +0100
@@ -0,0 +1,24 @@
+From: Kurt Roeckx k...@roeckx.be
+Subject: Use dlopen() with lib instead of $LIB to open the backends
+Bug-Debian: http://bugs.debian.org/691612
+Forwarded: not-needed
+
+We give dlopen() an absolute path based on $ORIGIN and $LIB.  But $LIB
+is different in case of multiarch.  Just use lib instead.
+
+The other way to solve this is to move the libraries to the multiarch locations
+like done in 0.153-1.
+
+Index: elfutils-0.152/libebl/eblopenbackend.c
+===
+--- elfutils-0.152.orig/libebl/eblopenbackend.c	2012-11-12 20:42:26.0 +0100
 elfutils-0.152/libebl/eblopenbackend.c	2012-11-12 20:51:01.0 +0100
+@@ -334,7 +334,7 @@
+ #ifndef LIBEBL_SUBDIR
+ # define LIBEBL_SUBDIR PACKAGE
+ #endif
+-#define ORIGINDIR $ORIGIN/../$LIB/ LIBEBL_SUBDIR /
++#define ORIGINDIR $ORIGIN/../lib/ LIBEBL_SUBDIR /
+ 
+ 	/* Give it a try.  At least the machine type matches.  First
+try to load the module.  */
diff -Nru elfutils-0.152/debian/patches/elf_end_unlock.patch elfutils-0.152/debian/patches/elf_end_unlock.patch
--- elfutils-0.152/debian/patches/elf_end_unlock.patch	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.152/debian/patches/elf_end_unlock.patch	2012-11-12 20:24:24.0 +0100
@@ -0,0 +1,17 @@
+From: Kurt Roeckx k...@roeckx.be
+Subject: Call rwlock_unlock() before rwlock_fini()
+Applied-Upstream: commit:495501611820a9d5c462fda56045c146f7b922d7
+Bug-Debian: http://bugs.debian.org/662041
+
+diff --git a/libelf/elf_end.c b/libelf/elf_end.c
+index 5112eae..6392eaf 100644
+--- a/libelf/elf_end.c
 b/libelf/elf_end.c
+@@ -241,6 +241,7 @@ elf_end (elf)
+ 	munmap (elf-map_address, elf-maximum_size);
+ }
+ 
++  rwlock_unlock (elf-lock);
+   rwlock_fini (elf-lock);
+ 
+   /* Finally the descriptor itself.  */
diff -Nru elfutils-0.152/debian/patches/series elfutils-0.152/debian/patches/series
--- elfutils-0.152/debian/patches/series	2011-02-26 15:11:22.0 +0100
+++ elfutils-0.152/debian/patches/series	2012-11-12 20:30:48.0 +0100
@@ -7,3 +7,6 @@
 do-autoreconf.diff
 testsuite-ignore-elflint.diff
 elf_additions.diff
+strict-aliasing.diff
+elf_end_unlock.patch
+backend_dlopen.patch
diff -Nru elfutils-0.152/debian/patches/strict-aliasing.diff elfutils-0.152/debian/patches/strict-aliasing.diff
--- elfutils-0.152/debian/patches/strict-aliasing.diff	1970-01-01 01:00:00.0 +0100
+++ elfutils-0.152/debian/patches/strict-aliasing.diff	2012-10-27 17:15:08.0 +0200
@@ -0,0 +1,69 @@
+Description: Fix strict aliasing issues in MD5 and SHA1 code
+Origin: upstream, http://git.fedorahosted.org/cgit/elfutils.git/commit/?id=32899ac4f69d4ca4856d5282464c1f9cee928c8a
+Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=684825
+Last-Update: 2012-09-08
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/lib/md5.c
 b/lib/md5.c
+@@ -82,6 +82,16 @@
+   return resbuf;
+ }
+ 
++static void
++le64_copy (char *dest

Bug#683317: unblock: openssl/1.0.1c-4

[Kurt Roeckx]

On Mon, Jul 30, 2012 at 08:46:13PM +0200, Kurt Roeckx wrote:
 Package: release.debian.org
 Severity: normal
 User: release.debian@packages.debian.org
 Usertags: unblock
 
 Please unblock openssl/1.0.1c-4

Here is the debdiff between the versions:

diff -Nru openssl-1.0.1c/debian/changelog openssl-1.0.1c/debian/changelog
--- openssl-1.0.1c/debian/changelog 2012-06-06 18:30:06.0 +0200
+++ openssl-1.0.1c/debian/changelog 2012-07-29 14:33:38.0 +0200
@@ -1,3 +1,17 @@
+openssl (1.0.1c-4) unstable; urgency=low
+
+  * Fix the configure rules for alpha (Closes: #672710)
+  * Switch the postinst to sh again, there never was a reason to
+switch it to bash (Closes: #676398)
+  * Fix pic.patch to not use #ifdef in x86cpuid.s, only .S files are
+preprocessed.  We generate the file again for pic anyway.
+(Closes: #677468)
+  * Drop Breaks against openssh as it was only for upgrades
+between versions that were only in testing/unstable.
+(Closes: #668600)
+
+ -- Kurt Roeckx k...@roeckx.be  Tue, 17 Jul 2012 11:49:19 +0200
+
 openssl (1.0.1c-3) unstable; urgency=low
 
   * Disable padlock engine again, causes problems for hosts not supporting it.
diff -Nru openssl-1.0.1c/debian/control openssl-1.0.1c/debian/control
--- openssl-1.0.1c/debian/control   2012-04-27 01:12:34.0 +0200
+++ openssl-1.0.1c/debian/control   2012-07-29 14:33:20.0 +0200
@@ -33,7 +33,6 @@
 Multi-Arch: same
 Pre-Depends: ${misc:Pre-Depends}
 Depends: ${shlibs:Depends}, ${misc:Depends}
-Breaks: openssh-client ( 1:5.9p1-4), openssh-server ( 1:5.9p1-4)
 Description: SSL shared libraries
  libssl and libcrypto shared libraries needed by programs like
  apache-ssl, telnet-ssl and openssh.
diff -Nru openssl-1.0.1c/debian/libssl1.0.0.postinst 
openssl-1.0.1c/debian/libssl1.0.0.postinst
--- openssl-1.0.1c/debian/libssl1.0.0.postinst  2010-12-13 20:29:43.0 
+0100
+++ openssl-1.0.1c/debian/libssl1.0.0.postinst  2012-07-17 11:48:50.0 
+0200
@@ -1,4 +1,4 @@
-#!/bin/bash
+#!/bin/sh
 
 . /usr/share/debconf/confmodule
 
diff -Nru openssl-1.0.1c/debian/patches/debian-targets.patch 
openssl-1.0.1c/debian/patches/debian-targets.patch
--- openssl-1.0.1c/debian/patches/debian-targets.patch  2012-03-19 
19:54:51.0 +0100
+++ openssl-1.0.1c/debian/patches/debian-targets.patch  2012-07-17 
11:45:53.0 +0200
@@ -18,7 +18,7 @@
  tru64-alpha-cc, cc:-std1 -tune host -fast 
-readonly_strings::-pthread:::SIXTY_FOUR_BIT_LONG 
RC4_CHUNK:${alpha_asm}:dlfcn:alpha-osf1-shared::-msym:.so,
  
 +# Debian GNU/* (various architectures)
-+debian-alpha,gcc:-DTERMIO 
$debian_cflag::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 
DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
++debian-alpha,gcc:-DTERMIO 
${debian_cflags}::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 
DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
 +debian-alpha-ev4,gcc:-DTERMIO ${debian_cflags} 
-mcpu=ev4::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 
DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
 +debian-alpha-ev5,gcc:-DTERMIO ${debian_cflags} 
-mcpu=ev5::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_RISC1 
DES_UNROLL:${alpha_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
 +debian-armeb,gcc:-DB_ENDIAN -DTERMIO 
${debian_cflags}::-D_REENTRANT::-ldl:BN_LLONG RC4_CHAR RC4_CHUNK DES_INT 
DES_UNROLL 
BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR),
diff -Nru openssl-1.0.1c/debian/patches/pic.patch 
openssl-1.0.1c/debian/patches/pic.patch
--- openssl-1.0.1c/debian/patches/pic.patch 2012-03-17 18:07:31.0 
+0100
+++ openssl-1.0.1c/debian/patches/pic.patch 2012-07-29 14:15:31.0 
+0200
@@ -1,7 +1,7 @@
-Index: openssl-1.0.1/crypto/des/asm/desboth.pl
+Index: openssl-1.0.1c/crypto/des/asm/desboth.pl
 ===
 openssl-1.0.1.orig/crypto/des/asm/desboth.pl   2001-10-24 
23:20:56.0 +0200
-+++ openssl-1.0.1/crypto/des/asm/desboth.pl2012-03-17 14:03:25.0 
+0100
+--- openssl-1.0.1c.orig/crypto/des/asm/desboth.pl  2001-10-24 
23:20:56.0 +0200
 openssl-1.0.1c/crypto/des/asm/desboth.pl   2012-07-29 14:15:26.0 
+0200
 @@ -16,6 +16,11 @@
  
push(edi);
@@ -39,10 +39,10 @@
  
stack_pop(3);
mov($L,DWP(0,ebx,,0));
-Index: openssl-1.0.1/crypto/perlasm/cbc.pl
+Index: openssl-1.0.1c/crypto/perlasm/cbc.pl
 ===
 openssl-1.0.1.orig/crypto/perlasm/cbc.pl   2011-07-13 08:22:46.0 
+0200
-+++ openssl-1.0.1/crypto/perlasm/cbc.pl2012-03-17 14:03:25.0 
+0100
+--- openssl-1.0.1c.orig/crypto/perlasm/cbc.pl  2011-07-13 08:22:46.0 
+0200
 openssl-1.0.1c/crypto/perlasm/cbc.pl   2012-07-29 14:15

Re: FTFBS in sarge

[Kurt Roeckx]

On Thu, Sep 02, 2004 at 12:39:25AM +0200, Bastian Blank wrote:
 I've done a test build of sarge.  About 250 arch any packages failes to build.

The same test for arch all packages would be nice too.  We've
come across several of those when building the amd64 archive and
most should have bugs filed against them, atleast for the version
in sid.


Kurt

Re: gcc-3.4 emits large amounts of test failures

[Kurt Roeckx]

On Mon, Jan 03, 2005 at 10:57:09AM +0100, Bastian Blank wrote:
 I just read a buildlog for gcc-3.4 and saw large amount of test failures
 but the build themself is marked as successfull. I don't think this is
 the proper use of a testsuite and have to asume that nothing in the
 package may work.

Do you have /dev/pts mounted?  Without it dejagnu does not work
properly and generate lots of errors.

There should be test-summary.gz in /usr/share/doc/gcc-3.4 (or
just test-summary in the build directory) with an overview of
what the status of the tests.

This for instance lists this for C on i386:
=== gcc Summary ===

# of expected passes24999
# of unexpected failures2
# of expected failures  70
# of untested testcases 7
# of unsupported tests  201
/home/packages/gcc/3.4/gcc-3.4-3.4.3/build/gcc/xgcc version 3.4.4
20041218 (prerelease) (Debian 3.4.3-6)


And this for c++:
=== g++ Summary ===

# of expected passes9769
# of unexpected successes   3
# of expected failures  71
# of unsupported tests  43
/home/packages/gcc/3.4/gcc-3.4-3.4.3/build/gcc/testsuite/../g++
version 3.4.4 20041218 (prerelease) (Debian 3.4.3-6)


So for C there are 2 unexpected failures and for C++ there are 3
unexpected successes.  I wouldn't call that many errors.  I could
only hope that it gives as good as results as this on all arches.


Kurt

Re: GNUstep packages

[Kurt Roeckx]

On Wed, Jan 05, 2005 at 06:21:01PM +0100, Eric Heintzmann wrote:
   Hi,
 
 Currently, latest GNUstep packages cannot enter in sarge.
 (soname change and nearly all packages have been renamed)
 
 One package is not a valid candidate : gnustep-antlr (Cannot be built 
 on arm)

There is 1 other package that is required for it to transition.
charmap.app is not yet build on hppa.

Note that this isn't showing up in as out-of-date because it
comes from an other source package.


Kurt

Re: libdb*, mutex and threading

[Kurt Roeckx]

On Sun, Jan 16, 2005 at 01:24:57PM +0100, Andreas Barth wrote:
 This will solve the following bugs:
 db2:
 (not reported) packages compiled on 2.6 have issues on 2.4
 (not reported) Fast mutex support for mips and amd64

mutex/spinlocks also seem to be missing for ia64, powerpc and
arm.

 db3:
 #283520: db3: FTBFS: LD_ASSUME_KERNEL=2.4.24 not supported on amd64
 (not reported) Fast mutex support for mips and amd64

Also missing arm mutexes.

 db4.0:
 #276828: db4.0: FTBFS on amd64: No linuxthreads
 (not reported) Fast mutex support for mips and amd64

Also missing arm mutexes.

 db4.1:
 (not reported) packages compiled on 2.6 have issues on 2.4
 #281059: db4.1: Fast mutex support for mips and amd64.
 
 db4.2:
 #232305: libdb4.2: Hangs on SMP (HyperThreaded P4) system using slapd 2.1.25-1

There doesn't seem to be a fix for this?  Or did I miss
something?

 #248131: amd64 support: Missing mutexes and $LD vs. $LD
 
 
 I also will apply the fix to:
 #266685: libdb3: db3 loops on mutex on hppa

The bug says it was fixed in libdb4, but db2 to db4.3 seem to
have identical code for it.



Kurt

Re: Coordinating upload of teTeX-3.0 to unstable

[Kurt Roeckx]

On Tue, Jul 26, 2005 at 06:49:16PM +0200, Frank Küster wrote:
 Kurt Roeckx [EMAIL PROTECTED] wrote:
 
  I can try to build all those for you if you want, and I'll report
  those where I think that show problems.
 
 That would be great.  I think most of the problems will show up in
 failed builds, some might result in different filelists (pdf file
 generated instead of dvi file, but somehow the build does not fail), a
 small number might result in wrong fonts being used.

I started with everything build depending on tetex-*.  Here is an
overview of packages which might have problems.  Note that I have
no clue what some of those message mean.

Those really failed to build:
- bison-1.35
  dvips bison.dvi -o bison.ps
  This is dvips(k) 5.95a Copyright 2005 Radical Eye Software 
(www.radicaleye.com)
  dvips: ! DVI file can't be opened.
- ctie
  Unmet build dependencies: libkpathsea-dev (= 2.0.2-1)
- doc-debian-es:
  dvips -o debian-faq-es.ps debian-faq-es.dvi
  This is dvips(k) 5.95a Copyright 2005 Radical Eye Software 
(www.radicaleye.com)
  dvips: ! DVI file can't be opened.
- gnuplot:
  dvips: ! DVI file can't be opened.
  (And other warnings.)
- gprolog
  hevea -O -nosymb -s -exec xxdate.exe -fix custom.hva manual.tex -o manual.html
  /usr/bin/hevea: unknown option `-nosymb'.
- iproute:
  error post-processing latex2e.
- laptop-net:
  texi2pdf laptop-net.texi
  make[2]: texi2pdf: Command not found
- make:
  dvips: ! DVI file can't be opened.
- ptex-bin
  syntax error: Last token = 289 (!), error buffer = `_',
last id = `O' (parameterless procedure).
  ./pconvert: conversion of  failed, moving dregs:
  ./pconvert:   mv jbibtex.c jbibtex.h jbibd.h ./failure
- python-crypto:
  pdfTeX error (ext1): \pdfinfo used while \pdfoutput is not set.
- scalable-cyrfonts
  No file fontinst.rc.
  ) (./fnstcorr.tex
  ! Undefined control sequence.
  l.37 \catcode`\_=\underscorecatcode

  ? make[1]: *** [build] Terminated
  make[2]: *** [latex_mtx] Terminated
- userv
  debiandoc2ps: ERROR: output could not be generated properly
- lcdf-typetools
  Unmet build dependencies: libkpathsea-dev (= 2.0.2-4)
- libkpathsea-perl
  Unmet build dependencies: libkpathsea-dev (= 2.0-1)





Those just gave warnings:
- am-utils
  ** Unknown command
  *** Unknown node in menu entry `FSinfo host netif:' (l. 5664)
- blitz++: Doesn't seem to make any documentation at all?
- cameleon  
  Warning: Could not find program file: xxdate.exe
  manual.html:1130: Warning, cannot find anchor: pluginchat
- cfitsio
  ./quick.tex:2: Warning: Cannot open file: html.sty
  ./quick.tex:3: Warning: Command not found: \htmladdtonavigation
  [...]
- dvipdfmx: does not make it's documentation?
- ecartis
  ! pdfTeX warning (ext4): destination with the same identifier (name{page.1}) 
has been already used, duplicate ignored
  to be read again
   \penalty
- ecasound2.2:
  ./eci_doc.latex:15: Warning: File \jobname.htoc not found
- freefem:
  ./freefem.tex:23: Warning: Command not found: \PassOptionsToPackage
  ./freefem.tex:46: Warning: keyval, uknown key: ``gobble''
  ./freefem.tex:46: Warning: keyval, uknown key: ``numbers''
  [...]
- freefem3d:
  Package hyperref Warning: Token not allowed in a PDFDocEncoded string,
  (hyperref)removing `\special' on input line 1.
  [...]
  dvips: Unknown keyword (PUSH) in \special will be ignored
  dvips: Unknown keyword (RED) in \special will be ignored
  dvips: Could not find figure file COLOR; continuing
  [...]
- freetype1: Does not generate documentation?
- gap-ctbllib:
  Lots of messages like:
  Reference `CTblLib' undefined.
- gnucap:
  Warning: Could not find program file: xxdate.exe
  ./gnucap-man.tex:47: Warning: File \jobname.htoc not found


Some have the combination of:
  ** menu entry without previous node: License (l. 98)
  ** node_prev `Top' for `License' not found
  ** `Distrib' doesn't appear in menus
(am-utils, esh, fdutils)

I did not have time to look at all those that appeared to have
been built succesful.



Can't be build currently (C++ transition, xorg-x11, ...)
- acl2
- axiom
- boot-floppies
- cmucl
- crystalspace
- darcs
- drift
- gmsh
- ion2
- kdegraphics
- lhs2tex
- maxima
- papaya
- evince


Have other problems building not related to tetex, and I'll file
bugs about those if they don't exist yet:
- bibtool
- clif
- flite
- gcl
- gclcvs
- jlint
- lilypond
- lyx
- pointless
- pspp
- saoimage
- sbcl
- sbm
- skribe
- transfig
- xconq
- xen
- xfree86
- xorg-x11
- tmview


Should I worry about messages like:
Underfull \hbox (badness 2368)
Overfull \hbox (21.3942pt too wide)
LaTeX Font Warning: Font shape `OMS/cmtt/m/n' undefined
LaTeX Warning: Reference `sec-cblash' on page 7 undefined on input line 452.
** `XXX' doesn't appear in menus:



This was the list of everything directly build depending on it,
and I'll do one with the indirect build dependencies soon.


Kurt


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

Re: Gutenprint testing migration

[Kurt Roeckx]

On Sat, Sep 24, 2005 at 03:17:20PM -0700, Steve Langasek wrote:
 
 One or more of these packages still depends on the removed gimp-print
 package, and is not ready to be updated in testing.

printconf still depends on gimp-print.


Kurt


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

Re: first pass at KDE/JACK hint, openssl disaster, etc.

[Kurt Roeckx]

On Wed, Oct 12, 2005 at 04:38:29AM -0400, Nathanael Nerode wrote:
 DO NOT upload packages built against libssl-dev or libssl0.9.8.
 All packages should be built against libssl0.9.7-dev (libssl0.9.7) at this 
 time.

I intend to drop the libssl0.9.7-dev package in the next upload,
which I hope to do soon.  I don't think it's a good idea to keep
that -dev package around.  Unless the release team ask me to keep
it around, I'll remove it.


Kurt


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

Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired

[Kurt Roeckx]

On Fri, Oct 14, 2005 at 04:38:53PM -0700, Steve Langasek wrote:
 On Sat, Oct 15, 2005 at 12:52:08AM +0200, Christoph Martin wrote:
   Finally, are there any plans to alleviate testing migration issues for 
   packages held up by this, and if so, how?
 
 The way to alleviate testing migration issues is by getting openssl097 and
 openssl updates into testing ASAP.  They will probably have to go into
 testing together, because of the move of the openssl binary from one source
 package to the other, which means openssl needs to be reuploaded with symbol
 versionining support and then both packages need to be allowed to get built
 on all architectures and settled long enough that we can be comfortable
 pushing them into testing.

What I'm wondering about was the need for a Conflict between
libssl0.9.7 and libssl0.9.8.  I think we should do it, but it's
going to make migration to testing alot harder, but hopefully the
last time.


Kurt


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

Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired

[Kurt Roeckx]

On Sat, Oct 15, 2005 at 01:11:17PM +0200, Kurt Roeckx wrote:
 
 What I'm wondering about was the need for a Conflict between
 libssl0.9.7 and libssl0.9.8.  I think we should do it, but it's
 going to make migration to testing alot harder, but hopefully the
 last time.

Having talked to with the release team on IRC, we agreed that we
should not add a Conflict.


Kurt


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

Re: Re: [Pkg-openssl-devel] Statement(s) on libssl situation desired

[Kurt Roeckx]

On Sat, Oct 15, 2005 at 03:39:08PM -0400, Nathanael Nerode wrote:
   Packages built against the unversioned libssl0.9.8 will, when run on a 
 system 
   with versioned libssl0.9.8, either pick up the symbols from libssl0.9.7 
   (wrong) or not find their symbols (segfault).  Accordingly, all packages 
   linked against the current libssl0.9.8 are in trouble and will need 
 rebuilds.  
 
 Correction; I got my versioning rules wrong.  They'll work fine if 
 libssl0.9.7 
 is *not* installed, but will pick up the symbols from it if it is installed.  
 Which is seriously bad.

Please note that libssl0.9.7 and libssl0.9.8 have a different
SONAME.  There can only be a problem when a program (indirectly)
links to both of them.  In that case, there isn't even an option
not to install both of them.

If a program is linked to both of them, and it was not linked to
a lib with versioned symbols, there really isn't much you can
tell about which symbols it's going to pick.


Kurt


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

Re: beta status

[Kurt Roeckx]

On Wed, Nov 02, 2005 at 02:08:07PM -0500, Joey Hess wrote:
 
 amd64 has also not built the most recent version of the debian-installer
 package, and has been marked as building for over a day at
 http://people.debian.org/~igloo/status.php?email=packages=debian-installerarches=
 Additionally, it seems that the last debian-installer build to be built
 and installed into the amd64 archive was rc3, in May. See
 http://amd64.debian.net/debian/dists/sid/main/installer-amd64/ So I'm
 not even sure if version 20051026 will get properly installed even if it
 does get built for amd64.

We had some problems (as noted above), and some others.  The
kernel udebs weren't in moved in testing until yesterday evening.
This doesn't happen automaticly since it's a different source
package for every arch, and we didn't notice they were out of
date yet.

Also, the buildd chroot also didn't have amd64 key in
/etc/apt/trusted.gpg.  Those issues should have been fixed, and
20051026 should get build soon.

We also had a problem with a previous version, 20051009, that it
ended up in reject with some strange error message (instead of in
byhand).  I hope we don't error anymore now.


Kurt


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

gnupg migration to testing

[Kurt Roeckx]

Hi,

gnupg seems to be ready to migrate to testing, but is frozen
because of the udeb.

Can someone push this to testing if it's not causing any problems
for d-i?


Kurt


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

openssl 0.9.8a-3 for testing

[Kurt Roeckx]

Hi,

Would it be possible to allow openssl in testing?  It has a udeb
and is therefor currently frozen.  It fixes a grave bug that many
applications had problems with.

Note that it has an added dependency on zlib1g, and so does the
udeb.  I have no idea if this is a problem for d-i.


Kurt


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

Re: Please hint openssl 0.9.8a-5 to testing.

[Kurt Roeckx]

On Sun, Jan 01, 2006 at 09:15:59PM -0800, Steve Langasek wrote:
 
  It still has an open RC bug, which affects testing too.
 
 Any progress on that RC bug, btw?

Unfortuatly not.


Kurt


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

Re: C++ transitions breaking libaspell

[Kurt Roeckx]

On Mon, Jan 02, 2006 at 04:36:15PM -0500, Brian Nelson wrote:
 Can someone please review http://bugs.debian.org/343060 and tell me what
 to do about it?  Several people are claiming libaspell needs to be
 rebuilt, and in that case it would need a package name change and yet
 another painful library transition.  Obviously I don't want to do this
 unless absolutely necessary.

Since this seems to be a C++ package that only exports a C
interface, a simple rebuild should do.  There is no need to
change the name.


Kurt


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

Re: Build-depends on package not in testing

[Kurt Roeckx]

On Thu, Jan 05, 2006 at 06:05:28PM +0100, Gerrit Pape wrote:
 On Wed, Jan 04, 2006 at 03:36:00AM -0800, Steve Langasek wrote:
  reopen 345868
  thanks
  
  On Wed, Jan 04, 2006 at 10:30:47AM +0100, Gerrit Pape wrote:
   Unfortunately the discussion about the freecdb package didn't attract
   my attention earlier, the release critical bug is resolved as invalid
   now.
  
  And reopened.  You have *not* addressed the issues contributing to this RC
  bug:
  
  - freecdb provides no shared library or static _pic library suitable for
linking into other shared libraries, which is something we generally
expect from library packages
  - the only thing that sucks more than static-only libs for security support
of a library is *bundled* static-only libs
  - the author (and current maintainer) of freecdb says that this cdb
implementation should be considered dead
  
  1) and 2) suck, but it's 3) that makes this a serious bug AFAICT; you can
  address 3) by becoming the new maintainer, of course, but in that case I
  would expect that you would actually, er, *maintain* it, for instance by
  providing a _pic.a library instead of dismissing the bug as a problem in
  vpopmail's packaging.
 
 I'm quite suprised.  This isn't a release critical bug.
 
 The real author (not the current maintainer) doesn't consider this cdb
 implementation (the first and original one) dead AFAICS.  This tiny
 library is excellent software from the public domain, rock-solid and
 bug-free for years.
 
 Nothing forces a maintainer to provide a _pic.a library, original
 upstream says that this is not what the library is intended for.  I
 can't see how you justify severity serious, not through policy AFAIK.
 
 Good maintenance is not always to implement each and every wish people
 express.  If anyone requests a pic library, one can tell them that it's
 not a good idea and what to do instead, if appropriate; that's good
 maintenance.  Nobody's currently requesting it though.

Is there a reason that there shouldn't be a shared library of
freecdb?  Is the API/ABI unstable or something?  I don't see why
you only want a static version of the library.  I don't think
saying that upstream says so is a valid reason, without also
saying what the reason is.  The only reason I saw so far was that
it's very small (#338038), which I don't consider to be a good
reason.

 The issue discussed in the original bug report simply _is_ a problem in
 vpopmail's packaging, check the package if you don't believe.

So vpopmail's packaging isn't good because it tries to create a
shared library that makes use of freecdb?  Please explain me how
this can be considered bad packaging.

You're also saying that it's not supposed to be used in that way.
Why shouldn't some other library try and use your library?  What
should they do instead?


Kurt


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

openssl for testing.

[Kurt Roeckx]

Hi,

I've recently uploaded openssl 0.9.8a-6 which fixes an RC bug
affecting testing (#338006), and I'd like to get that version
into testing.

I forgot to bump the severity to high, and it needs a manual hint
because it has a udeb.


Kurt


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

openssl for testing.

[Kurt Roeckx]

Hi,

Could you please hint the openssl 0.9.8a-7 version into testing?

Note that it has a udeb, so it needs to get approved.


Kurt


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

Re: Moving 32-bit libraries to (/usr)/lib32 on amd64

[Kurt Roeckx]

On Mon, Feb 20, 2006 at 11:10:41AM -0700, Bdale Garbee wrote:
 On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote:
  If there's
  consensus that putting this stuff in /usr/lib32 on amd64 is prettier than
  /emul/ia32-linux, I see no reason not to move forward.
 
 My sense is that the concensus that exists is around FHS compliance.
 While I personally consider /usr/lib32 pretty ugly, I am sensitive to
 the fact that we have always tried to be FHS compliant in Debian.

FHS actually has a libqual in it, where qual can be things
like 32 or 64.

For PPC64, s390x, sparc64 and AMD64 it says that 64 bit libraries
should be put in /lib64 and 32 bit version in /lib.

For IA64, it says 64 bit libraries should be put in /lib, but
doesn't say where 32 bit versions belong.  It says:
IA-64 uses a different scheme, reflecting the deprecation of
32-bit binaries (and hence libraries) on that architecture.

I think 32 bit it makes sense to actually put 32 bit libraries on
ia64 in /lib32 too, instead of the current /emul/ia32-linux/, and
think it would be more inline with the FHS.  Is there a reason
it's using /emul/ia32-linux/ ?

So I would like both ia64 and amd64 to use /lib32.


 Looking over the open bug reports, it's well past time for another
 general update of ia32-libs.  I'll try to make time for it this week.

In the end, I'd like to get rid of ia32-libs, and have it be a
dummy package.  But on the other hand, I don't want to make a
biarch version of things like the X libraries.


PS: Does this really have to be on -release?


Kurt


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

Dropping python2.1/2.2

[Kurt Roeckx]

Hi,

You've filed some bugs requesting to drop support for python
2.1/2.2.  Would it be useful if there were some NMU's done for
this?

Should those bug be marked as release critical instead?


Kurt


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

dash for testing

[Kurt Roeckx]

Hi,

Can dash please be pushed to testing?


Kurt


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

Testing hints for amd64

[Kurt Roeckx]

Hi,

Could the following packages be hinted into testing?  They all
have a udeb, and are currently missing on amd64.

expat
freetype
dash


Kurt


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

Re: Easy removals: G

[Kurt Roeckx]

On Tue, May 09, 2006 at 05:00:06PM -0400, Nathanael Nerode wrote:
 # 350688
 # Yes, really.  GCC 2.95 is now a leaf package.
 remove gcc-2.95/2.95.4.ds15-22

There seem to be 2 packages build depending on gcc-2.95: silo and
kernel-image-2.4.27-m68k


Kurt


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

xfsprogs to testing?

[Kurt Roeckx]

Hi,

Can xfsprogs be pushed to testing?  It has a udeb.


Kurt


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

Re: usbutils to testing?

[Kurt Roeckx]

Hi,

Can usbutils be pushed to testing?  It has a udeb.


Kurt


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

Approve openssl for testing.

[Kurt Roeckx]

Hi,

Could you please hint openssl 0.9.8b-3 in testing?

Note that it contains a udeb, so it's frozen.


Kurt


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

Re: Hint openssl to testing.

[Kurt Roeckx]

On Fri, Sep 29, 2006 at 08:02:16PM -0700, Steve Langasek wrote:
 On Sat, Sep 30, 2006 at 02:46:17AM +0200, Kurt Roeckx wrote:
 
  Could you please hint openssl to testing?  It's frozen because it has
  udebs.
 
 Already done, will go in as soon as it's aged another day.

I see a hint in aba's file which says:
unblock openssl/0.9.8b-3

But it's about version 0.9.8c-2


Kurt


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

Re: Hint openssl to testing.

[Kurt Roeckx]

On Mon, Oct 02, 2006 at 09:46:42AM +0200, Andreas Barth wrote:
 * Kurt Roeckx ([EMAIL PROTECTED]) [061002 08:38]:
  On Fri, Sep 29, 2006 at 08:02:16PM -0700, Steve Langasek wrote:
   On Sat, Sep 30, 2006 at 02:46:17AM +0200, Kurt Roeckx wrote:
   
Could you please hint openssl to testing?  It's frozen because it has
udebs.
   
   Already done, will go in as soon as it's aged another day.
  
  I see a hint in aba's file which says:
  unblock openssl/0.9.8b-3
  
  But it's about version 0.9.8c-2
 
 I moved my finished-marker up. Thanks for noticing.

Could 0.9.8c-3 please be hinted in?

As far as I know, it doesn't contain any RC bug, and I still like to see
those security fixes into testing.


Kurt


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

Re: m68k not a release arch for etch; status in testing, future plans?

[Kurt Roeckx]

On Mon, Oct 16, 2006 at 09:48:32PM +0200, Roman Zippel wrote:
  As a result, the bts is already ignoring m68k in calculating a bug's
  applicability for the testing distribution, at the release team's request.
 
 As someone who has recently looked at and fixed many problems, I must say 
 the release team has done m68k no service by doing this and actually 
 sabotaged m68k in its ability to catch up again.
 Fixes for problems are too often simply stuck in the BTS now, because in 
 many cases maintainer simply don't care about m68k support. I often have 
 to bug people to get them to release a fixed package.

I suggest you read section 5.10 of the developers reference, and do
porter/non-maintainer source uploads if you think it's holding up things
and the maintainer isn't very responsive.


Kurt


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

openssl CMS support

[Kurt Roeckx]

Hi,

Someone has requested CMS to be enabled in openssl, and I'm not
sure you find such a change acceptable at this time in the release
process.
See http://en.wikipedia.org/wiki/Cryptographic_Message_Syntax

The only change in the source package this requires is
a configure option.  As far as I can see this just enables a
whole bunch of new functions and adds an application to work
with CMS documents.  So it's atleast going to require an shlib
bump.

It seems that outlook 2010 is using this and this option needs to
be turned on read such documents.


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/20101112192258.ga10...@roeckx.be

openssl rfc5746 / renegotiation support

[Kurt Roeckx]

Hi,

I would like to add rfc5746 support to openssl in stable, so that
CVE-2009-3555 can be fixed.  But adding that support means that
the old renegotiation doesn't work anymore unless you set an
option.  This has the potentional to break both client and server
applications making use of openssl.  See the SSL_CTX_set_options
manpage for the behaviour and the options you can set.

There are atleast 2 packages that have an issue with this that I'm
currently aware of:
- apache2: It would need an option an admin can turn on to allow
  insecure renegotiation.
- tor: It should always disable the new renegotiation.  Running it
  as a server doesn't work.  Newer versions than in stable, like
  the version in volatile, do work properly with any version of
  openssl.  The maintainer and upstream favour dropping the
  version currently in stable.

Other packages still need to be checked.

I think at this point we're not going to be able to check the
various packages that might be affected by this before the next
point release.  So I wonder when the next point release is
going to happen, or that we should try and update this via the
security archive.


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/20101116204806.ga14...@roeckx.be

Unblock openssl 0.9.8o-3

[Kurt Roeckx]

Hi,

Could openssl 0.9.8o-3 please be unblocked?  It contains a
security fix.


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/20101117172722.ga24...@roeckx.be

Re: HPPA and Squeeze

[Kurt Roeckx]

On Fri, Jun 19, 2009 at 05:43:24PM +0200, Philipp Kern wrote:
 On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
  Here is a list of packages that failed to build because of instability
  on the buildds today:
  package | buildd   | error
  qgit| penalosa | make: *** [install] Segmentation fault
  acpica-unix | peri | make: *** [install] Segmentation fault
 
 I had those random segfaults in make on paer too, until we switched to the
 UP kernel, at least from what I saw.

Did something change to peri?  I'm currently only seeing them on
penalosa.

Failed logs the past few days:
Jun 22 | wesnoth| penalosa | quilt segfaults
Jun 22 | gitg   | penalosa | quilt segfaults
Jun 23 | zita-convolver | penalosa | quilt segfaults
Jun 25 | autodocksuite  | penalosa | make segfaults
Jun 26 | mpd| penalosa | find segfaults?
Jun 30 | scorched3d | penalosa | make segfaults
Jun 30 | libtext-bibtex-perl| penalosa | make segfaults
Jun 30 | gnome-chemistry-utils  | penalosa | libtool segfaults
Jul 01 | openmsx-catapult   | penalosa | make segfaults
Jul 01 | prima  | penalosa | make segfaults
Jul 01 | fvwm   | penalosa | gcc says as had a segfault
Jul 01 | cherokee   | penalosa | quilt segfaults
Jul 03 | vflib3 | penalosa | make segfaults
Jul 03 | rpy2   | penalosa | make segfaults
Jul 03 | debian-installer-utils | penalosa | make segfaults

On other that looks weird is, all also on penalosa:
- scid, seems to have been stuck in a cp.
- postgresql-8.3, not sure what the error is
- building gnome-system-monitor, openssh-client failed to install
  in it's postinst script calling update-alternatives

And then there is glob2 that fails with:
/usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot reach 
f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections
/usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot handle 
R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

On Fri, Jul 03, 2009 at 09:28:00PM +0200, Philipp Kern wrote:
 On Fri, Jul 03, 2009 at 08:57:56PM +0200, Kurt Roeckx wrote:
  Did something change to peri?  I'm currently only seeing them on
  penalosa.
 
 UP kernel, maybe?

Both peri and penalosa run 2.6.29-2-parisc64-smp and from what I
can tell run on identical hardware.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

On Sat, Jul 04, 2009 at 11:03:01PM +0200, Kurt Roeckx wrote:
 On Sat, Jul 04, 2009 at 03:52:16PM -0400, John David Anglin wrote:
   And then there is glob2 that fails with:
   /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot 
   reach f9bf_memcpy@@GLIBC_2.2+0, recompile with -ffunction-sections
   /usr/bin/ld: libgag/src/libgag.a(FileManager.o)(.text+0x2fc8): cannot 
   handle R_PARISC_PCREL17F for memcpy@@GLIBC_2.2
   /usr/bin/ld: final link failed: Bad value
   collect2: ld returned 1 exit status
  
  I couldn't duplicate the problem with binutils 2.19.1-1 and gcc-4.3
  4.3.3-10, or with my own binutils build on two different systems.
  
  The above shouldn't happen as the text size of FileManager.o is well below
  the size where a 17-bit branch can't reach the stub table.  Possibly, the
  stub table is full.  On the otherhand, the f9bf_memcpy@@GLIBC_2.2+0
  string looks garbled.  So, this may be another form of the SMP memory
  corruption that causes the segvs, particularly if it isn't reproducible
  on the build system.
 
 It actually already failed twice on the same system with the same
 error.  I've just let it retry again, we'll see if it fails again.

And it failed again with the same error, on peri now.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Progress on OCaml 3.11.1 transition...

[Kurt Roeckx]

On Wed, Jul 08, 2009 at 08:08:25PM +0200, Stéphane Glondu wrote:
 nmu 1 gmetadom_0.2.6-3 . alpha amd64 armel hppa i386 ia64 mips mipsel
 powerpc s390 sparc . -m 'Recompile with OCaml 3.11.1'
 nmu otags_3.09.3-3 . alpha . -m 'Recompile with OCaml 3.11.1'
 gb pagodacf_0.10-2+b1 . mips

done


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Please binNMU pidgin against libsilc-dev (= 1.1.9-1)

[Kurt Roeckx]

On Sat, Jul 11, 2009 at 01:46:24PM +0200, Cyril Brulebois wrote:
 Luk Claes l...@debian.org (11/07/2009):
  Jérémy Bobbio wrote:
   Hi mighty members of the release team,
   
   Could you please schedule a binNMU of pidgin against
   libsilc-dev (= 1.1.9-1) in order to update its binary deps?
  
  Can you please give a bit more context as it doesn't seem obvious why
  this would be needed?
 
 From silc-toolkit_1.1.9-1/changelog:
 |* libsilc and libsilcclient are now shipped in two different binary 
 packages
 |  in order to respect their SONAMEs.  The -dev package depends on both 
 and
 |  has been renamed to libsilc-dev.
 
 libpurple0 (from src:pidgin) depends on one of them. I guess a rebuild
 would update that dependency; given that silc_client_* symbols come from
 the libsilcclient-1.1.3 binary, a dependency against that one is going
 to be added.
 
 FWIW, silc-toolkit is uploaded, but not installed, on amd64. Cc'ing
 amd64 buildd admins for that matter.

I gave back silc-toolkit.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Timeouts

[Kurt Roeckx]

On Tue, Mar 09, 2010 at 10:50:31AM -0700, dann frazier wrote:
 On Mon, Mar 08, 2010 at 11:02:19PM +0100, Marc 'HE' Brockschmidt wrote:
  Joachim Breitner nome...@debian.org writes:
   speaking of which: 
   https://buildd.debian.org/fetch.cgi?pkg=agdaarch=hppaver=2.2.6-3stamp=1267580450file=logas=raw
   says 
  
   Building Agda-2.2.6...
   [  1 of 191] Compiling Agda.Auto.NarrowingSearch ( 
   src/full/Agda/Auto/NarrowingSearch.hs, 
   dist-ghc6/build/Agda/Auto/NarrowingSearch.o )
   E: Caught signal 'Terminated': terminating immediately
   make: *** [build-ghc6-stamp] Terminated
   Build killed with signal TERM after 1 minutes of inactivity
  
   Isn?t this time limit a bit too low?
  
  Seems so, no idea what the reason for that was. penalosa has been
  reconfigured to a normal timeout in the meantime. Given back on hppa,
  now.
 
 Which explains why peri hasn't done anything useful for about 17 hours
 :) 
 
 I'm quite sure it is not going to make any progress:
   https://buildd.debian.org/build.cgi?pkg=agda;ver=2.2.6-3;arch=hppa
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572300
 
 I'm still fairly new to working w/ sbuild. Other than my
 1-minute-timeout trick, is there a way to kill a build and stop it
 from retrying later?

sbuild-abort should 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/20100309182129.ga7...@roeckx.be

Re: [volatile] Updated clamav-related packages available for testing

[Kurt Roeckx]

On Wed, Apr 14, 2010 at 10:35:41PM +0100, Adam D. Barratt wrote:
 
 The clamav project have announced that they will be publishing a
 specially formed virus signature which disables older versions of the
 software, including the version in lenny.  If you have not yet migrated
 to using the volatile packages, now would be a good time to do so. :-)

What does this mean exactly?  Will it now tell that everything is
not a virus, even for things that it used to be able to detect?

What about providing a working version in stable-security and/or
proposed-updates before that happens?


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/20100415185846.ga32...@roeckx.be

Re: [volatile] Updated clamav-related packages available fortesting

[Kurt Roeckx]

On Thu, Apr 15, 2010 at 12:52:47PM -0700, Jason Self wrote:
 Kurt Roeckx k...@roeckx.be wrote ..
  
  What does this mean exactly?
 
 It means that versions older than 0.95 will be remotely disabled by the 
 ClamAV 
 folks once your copy of ClamAV gets the CVD update that includes what I like 
 to 
 call the special self-destruct code. :)
 
 It means that you need to be running least version 0.95 of ClamAV, and 
 preferably always the latest  greatest version, to be protected. Outdated 
 anti-
 virus software is not effective.

I forgot about DSA 1906 in october which basicly already announced
it.


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/20100415201641.ga...@roeckx.be

openssl 0.9.8g-15+lenny7

[Kurt Roeckx]

Hi,

I'll be uploading a new version of openssl to proposed-updates
soon.  This fixes a security issue.  Could you please review
and approve this?

The diff is attached.


Kurt

diff -u openssl-0.9.8g/debian/changelog openssl-0.9.8g/debian/changelog
--- openssl-0.9.8g/debian/changelog
+++ openssl-0.9.8g/debian/changelog
@@ -1,3 +1,10 @@
+openssl (0.9.8g-15+lenny7) stable-security; urgency=low
+
+  * Check return type of bn_wexpand().  Fixes CVE-2009-3245 
+(Closes: #575433)
+
+ -- Kurt Roeckx k...@roeckx.be  Mon, 07 Jun 2010 20:30:01 +0200
+
 openssl (0.9.8g-15+lenny6) stable-security; urgency=low
 
   * Clean up zlib state so that it will be reinitialized on next use and
only in patch2:
unchanged:
--- openssl-0.9.8g.orig/engines/e_ubsec.c
+++ openssl-0.9.8g/engines/e_ubsec.c
@@ -934,7 +934,7 @@
 priv_key = BN_new();
 if (priv_key == NULL) goto err;
 priv_key_len = BN_num_bits(dh-p);
-bn_wexpand(priv_key, dh-p-top);
+if(bn_wexpand(priv_key, dh-p-top) == NULL) goto err;
 do
 if (!BN_rand_range(priv_key, dh-p)) goto err;
 while (BN_is_zero(priv_key));
@@ -949,7 +949,7 @@
 {
 pub_key = BN_new();
 pub_key_len = BN_num_bits(dh-p);
-bn_wexpand(pub_key, dh-p-top);
+if(bn_wexpand(pub_key, dh-p-top) == NULL) goto err;
 if(pub_key == NULL) goto err;
 }
 else
only in patch2:
unchanged:
--- openssl-0.9.8g.orig/crypto/ec/ec2_smpl.c
+++ openssl-0.9.8g/crypto/ec/ec2_smpl.c
@@ -174,8 +174,10 @@
 	dest-poly[2] = src-poly[2];
 	dest-poly[3] = src-poly[3];
 	dest-poly[4] = src-poly[4];
-	bn_wexpand(dest-a, (int)(dest-poly[0] + BN_BITS2 - 1) / BN_BITS2);
-	bn_wexpand(dest-b, (int)(dest-poly[0] + BN_BITS2 - 1) / BN_BITS2);
+	if(bn_wexpand(dest-a, (int)(dest-poly[0] + BN_BITS2 - 1) / BN_BITS2) == NULL)
+		return 0;
+	if(bn_wexpand(dest-b, (int)(dest-poly[0] + BN_BITS2 - 1) / BN_BITS2) == NULL)
+		return 0;
 	for (i = dest-a.top; i  dest-a.dmax; i++) dest-a.d[i] = 0;
 	for (i = dest-b.top; i  dest-b.dmax; i++) dest-b.d[i] = 0;
 	return 1;
@@ -199,12 +201,12 @@
 
 	/* group-a */
 	if (!BN_GF2m_mod_arr(group-a, a, group-poly)) goto err;
-	bn_wexpand(group-a, (int)(group-poly[0] + BN_BITS2 - 1) / BN_BITS2);
+	if(bn_wexpand(group-a, (int)(group-poly[0] + BN_BITS2 - 1) / BN_BITS2) == NULL) goto err;
 	for (i = group-a.top; i  group-a.dmax; i++) group-a.d[i] = 0;
 	
 	/* group-b */
 	if (!BN_GF2m_mod_arr(group-b, b, group-poly)) goto err;
-	bn_wexpand(group-b, (int)(group-poly[0] + BN_BITS2 - 1) / BN_BITS2);
+	if(bn_wexpand(group-b, (int)(group-poly[0] + BN_BITS2 - 1) / BN_BITS2) == NULL) goto err;
 	for (i = group-b.top; i  group-b.dmax; i++) group-b.d[i] = 0;
 		
 	ret = 1;
only in patch2:
unchanged:
--- openssl-0.9.8g.orig/crypto/bn/bn_div.c
+++ openssl-0.9.8g/crypto/bn/bn_div.c
@@ -102,7 +102,7 @@
 	/* The next 2 are needed so we can do a dv-d[0]|=1 later
 	 * since BN_lshift1 will only work once there is a value :-) */
 	BN_zero(dv);
-	bn_wexpand(dv,1);
+	if(bn_wexpand(dv,1) == NULL) goto end;
 	dv-top=1;
 
 	if (!BN_lshift(D,D,nm-nd)) goto end;
only in patch2:
unchanged:
--- openssl-0.9.8g.orig/crypto/bn/bn_mul.c
+++ openssl-0.9.8g/crypto/bn/bn_mul.c
@@ -1025,15 +1025,15 @@
 			t = BN_CTX_get(ctx);
 			if (al  j || bl  j)
 {
-bn_wexpand(t,k*4);
-bn_wexpand(rr,k*4);
+if (bn_wexpand(t,k*4) == NULL) goto err;
+if (bn_wexpand(rr,k*4) == NULL) goto err;
 bn_mul_part_recursive(rr-d,a-d,b-d,
 	j,al-j,bl-j,t-d);
 }
 			else	/* al = j || bl = j */
 {
-bn_wexpand(t,k*2);
-bn_wexpand(rr,k*2);
+if (bn_wexpand(t,k*2) == NULL) goto err;
+if (bn_wexpand(rr,k*2) == NULL) goto err;
 bn_mul_recursive(rr-d,a-d,b-d,
 	j,al-j,bl-j,t-d);
 }
only in patch2:
unchanged:
--- openssl-0.9.8g.orig/crypto/bn/bn_gf2m.c
+++ openssl-0.9.8g/crypto/bn/bn_gf2m.c
@@ -294,7 +294,8 @@
 	if (a-top  b-top) { at = b; bt = a; }
 	else { at = a; bt = b; }
 
-	bn_wexpand(r, at-top);
+	if(bn_wexpand(r, at-top) == NULL)
+		return 0;
 
 	for (i = 0; i  bt-top; i++)
 		{

libtool 2.2.10

[Kurt Roeckx]

Hi,

I'd like to upload libtool 2.2.10 to unstable.  As far as I know,
this should be mostly bug fixes.  Can I upload it?


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/20100617164844.ga8...@roeckx.be

Re: libtool 2.2.10

[Kurt Roeckx]

On Thu, Jun 17, 2010 at 06:48:44PM +0200, Kurt Roeckx wrote:
 Hi,
 
 I'd like to upload libtool 2.2.10 to unstable.  As far as I know,
 this should be mostly bug fixes.  Can I upload it?

Could someone please give me an answer?


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/20100628175201.ga8...@roeckx.be

Re: libtool 2.2.10

[Kurt Roeckx]

On Mon, Jun 28, 2010 at 07:05:45PM +0100, Adam D. Barratt wrote:
 Hi,
 
 quote
 Wrapper scripts and wrapper executables for programs linked against
 uninstalled shared libraries now support command-line options --lt-debug
 and --lt-dump-script.
 
 Important incompatible changes: - The wrapper command line option
 support described above introduces the following incompatibility: the
 wrapper will remove any command line options that begin with '--lt-*'
 from the argument list before launching (uninstalled) programs. Any
 '--lt-*' option on the command line not recognized by the wrapper will
 result in an error. 
 /quote

I don't expect this to be a problem for building anything, but
this might have some effect on regression tests.  But I think
it's very unlikely that something would pass --lt-* to them.


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/20100628182442.ga9...@roeckx.be

Re: Bug#402179: tar: FTBFS: race condition in test-suite

[Kurt Roeckx]

On Sun, Jan 07, 2007 at 02:46:42PM -0700, Bdale Garbee wrote:
 
 As I've stated before, I'm not sure that fixing this bug for etch is
 really useful.  Of course, if there's a reason to update the tar in etch
 for a security bug or something similar, fixing this too would make good
 sense.  But since it's only a race condition in the regression suite and
 makes no difference to the tar binary itself, and the tar package in
 etch is already built for all relevant release architectures, taking the
 risk of changing the tar package just to fix this isn't obviously
 worthwhile to me.

I agree for the most part.  But if you think this bug shouldn't be fixed
for etch, I think it either needs to be marked as non release critical
or it should be tagged etch-ignore.

I've CC'd the release team, to get their input on it.

Anyway, the only reason I see that we want to fix it in etch now is that
in case we later want a new version of tar in etch we don't get hit by
the problem.


Kurt


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

Re: maildrop lacking courier-authlib dependency on amd64, still

[Kurt Roeckx]

On Sun, Feb 04, 2007 at 11:54:47PM +, Stephen Gran wrote:
 
 [EMAIL PROTECTED]:~$ dpkg -x maildrop_2.0.3-1_amd64.deb tmp/maildrop/
 [EMAIL PROTECTED]:~$ objdump -x tmp/maildrop/usr/bin/maildrop | grep auth
   NEEDED  libcourierauth.so.0
   RPATH   /usr/lib:/usr/lib/courier-authlib
 

You need to either:
- Fix dpkg-shlibdeps to look at all rpath entries.
- Prevent /usr/lib from being in the rpath, or atleast have
  /usr/lib/courier-authlib as first in it.
  
The suggested way for the later is upgrading your libtool
version.  It seems this was done _partialy_.  Lots of the aclocal.m4
files still contain old copies of it.

 The only version of courier-authlib I have locally
 (courier-authlib_0.58-5_amd64.deb) has a correct looking shlibs file.

The problem is not the shlibs file of courier-authlib, the problem is
that dpkg-shlibdeps for some reason doesn't find the library because of
the rpath that maildrop sets.


Kurt


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

Re: maildrop lacking courier-authlib dependency on amd64, still

[Kurt Roeckx]

On Tue, Feb 06, 2007 at 02:22:06PM +0100, Josip Rodin wrote:
  
  BTW, couldn't this also be addressed just by adding a
  -l/usr/lib/courier-authlib option to dh_shlibdeps?

That seems to work too.

 Why does this only happen on amd64? I don't really want an
 architecture-specific kludge in the package, let's fix the tools to be
 consistent. Or at least produce useful error information (e.g. crapping out
 instead of letting bad things pass).

The version you're using of libtool does not work properly (on amd64).
It's also mixing various versions, and I have to wonder why not more is
broken.


Kurt


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

Rebuilds against openssl.

[Kurt Roeckx]

Hi,

I've recently uploaded a version of openssl that changed some defines
into real functions.  Since this was an undesired changed at this point,
I reverted the headers to use the defines again, but the library still
contains the functions.  The version in testing does not have those
functions.

I know atleast the following packages were build on a buildd against
the version that had the functions instead of the defines in the
headers:
libinstrudeo 0.1.4-2
apcupsd 3.14.0-1
tor 0.1.2.8-beta-1
ntop 3:3.2-9
postfix 2.3.7-4

Can those pacakges be binNMUd so they use the defines instead?


Kurt


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

Please approve ntp 1:4.2.2.p4+dfsg-2 for etch.

[Kurt Roeckx]

Hi,

Can ntp version 1:4.2.2.p4+dfsg-2 be hinted into testing?  It contains
some important fixes I'd like to see migrate to testing.

It seems to have built on sparc but was never uploaded.  I've tried
contacting [EMAIL PROTECTED] a few days ago without any actions so far.


Kurt


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

Re: Please approve ntp 1:4.2.2.p4+dfsg-2 for etch.

[Kurt Roeckx]

On Mon, Mar 12, 2007 at 04:21:03PM -0700, Steve Langasek wrote:
 Hi Kurt,
 
 On Mon, Mar 12, 2007 at 07:46:34PM +0100, Kurt Roeckx wrote:
  Can ntp version 1:4.2.2.p4+dfsg-2 be hinted into testing?  It contains
  some important fixes I'd like to see migrate to testing.
 
 +ntp (1:4.2.2.p4+dfsg-2) unstable; urgency=low
 
 +  [ Peter Eisentraut ]
 +  * Removed obsolete logcheck entry
 
 Perhaps obsolete, but then it didn't hurt anything either, so not a late
 change that I'm happy with letting in.
[...]
 Could you comment on the logcheck change?  Specifically, what is it that
 makes this definitively obsolete, the fact that ntp will no longer generate
 such 'recvbuf' messages?

The string is not present anymore in the source.  However it is present
in the version from stable in libntp/recvbuff.c.  The whole function has
been removed.

 +  * Improved formatting and fixed random whitespace in cron job
 
 Hmm, gratuitous diff to be reviewed :/

This is mostly whitespace changes.  And an if [ $? = 0 ] replaced by
if [ $? -eq 0 ], and the then placed on the same line as the if.

Anyway, I'd be happy to remove those 2 changes if needed.


Kurt


 +  [ Kurt Roeckx ]
 +  * Set a default restriction list for ipv6 too. (Closes: #411809)
 
 This change is understandable and I agree it should be let in.
 
 +  * Stop using dhcp provided servers on release and stop.  Thanks
 +to Torne [EMAIL PROTECTED] (Closes: #411200)
 
 A slight nervousness about a behavior change this late that could have side
 effects, but the difference between release/stop and expire/fail is slight
 enough that I won't object.
 
 +  * Don't use the nomodify option for localhost.  Modification
 +is only allowed when authenticated, so having the nomodify
 +option doesn't buy us anything.  It just prevents the resolver
 +slave process who does authenticate itself from properly working
 +(Closes: #385334, #401847)
 
 Yes, this is ok.
 
 +  * Make sure that we disable ntp-server for everybody. (Closes: #410383)
 
 Not relevant for etch release, the sarge version is already covered by the
 existing version check.
 
 
 -- 
 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]

Re: Bug#419111: context: Fails to install: ctxfmtutil: line 12: kpsewhich: command not found

[Kurt Roeckx]

On Sat, Apr 14, 2007 at 08:56:28AM +0200, Frank Küster wrote:
 Dear release people,
 
 I think you know best how to contact buildd admins.
 
 Reversing the order of what
 Kurt Roeckx [EMAIL PROTECTED] wrote:
 
  http://buildd.debian.org/fetch.cgi?pkg=dfsbuildver=1.0.0arch=amd64stamp=1176485127file=log
 
 This one was probably attempted after the first one?  No wonder.  It's
 just that removal of texlive-nearlyeverything failed, and now dpkg
 thinks the files are still present, while they aren't.

Yes, the 2 logs were after each other.

 Now that the debhelper change has been reverted, we can't rebuild
 texlive with fixed tex-common.  We need to upload a reverted tex-common,
 and then rebuild texlive.  Until this has happened, buildds should be
 prevented to install texlive if that is possible, and the buildds need
 to be fixed.  I think they will even fix themselves as soon as they once
 installed and then purged a working version.

What happens if we do install texlive other then it breaks on removal?


Kurt


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

Re: Request of binNMUs for the libpq4 - libpq5 transition

[Kurt Roeckx]

On Sat, Apr 14, 2007 at 05:06:18PM +0200, Andreas Metzler wrote:
 On 2007-04-14 Luk Claes [EMAIL PROTECTED] wrote:
  Can someone please schedule binNMUs for the libpq4 to libpq5 transition once
  libpq5 (postgresql-8.2) is built everywhere?
 
 Hello,
 wouldn't it be better to wait until libpq5 is in testing? Otherwise a
 (newly found) rc-bug in libpq5's source would add more than a 100
 packages out-of-sync in testing and sid.

This could work in this case since libpq4 is from the postgresql-8.1
source package and libpq5 from the postgresql-8.2 source package.

This wouldn't work with if it was from the same source package.

But I'm not sure if we really need to wait.  I think postgresql-8.2
could be hinted into testing with an rc bug if it's really needed.


Kurt


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

BinNMU request for libssl0.9.7.

[Kurt Roeckx]

Hi,

We'd like to remove openssl097.  Can all packages depending on
libssl0.9.7 be binNMUd were possible?

Afaik, this isn't needed on amd64, but is on other arches.


Kurt


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

Re: Please ensure SVGATextMode 1.9-18 does not enter the distro for amd64

[Kurt Roeckx]

On Sat, Jul 28, 2007 at 05:11:36AM +0930, Ron wrote:
 
 Hi,
 
 Looking at the build logs for the latest upload, I see that
 un-blacklisting this for amd64 means the svgatextmode_1.9-15
 release (in testing) has been successfully built for amd64 now.

It was actually build for stable, and uploaded to stable.

 I don't believe we should distribute that one though, since the
 'warning: large integer implicitly truncated to unsigned type'
 is a sign that outb() is being called with the port and value
 parameters reversed.

This is something for the stable release team then.  They should
probably reject svgatextmode_1.9-15 for etch.

 If we can keep anything prior to 1.9-18 still blocked that would
 probably be wise.

I've set it to failed state in stable for now.  Maybe the release team
will consider an upload to proposed updates to fix it?


Kurt


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

Re: IPv6 in Debian

[Kurt Roeckx]

On Mon, Jul 30, 2007 at 07:52:47PM +0200, Tomas Pospisek wrote:
 Hallo Release Team,

 I've read in the release goals:

 RELEASE GOALS
 =

 * full IPv6 support
  Advocate: Martin Zobel-Helas

 and wrote to Martin Zobel-Helas who redirected me here.

 My experience with IPv6 in Debian is foremost that it's a pita.

 Debian enables IPv6 by default.

 *  before A DNS lookup
[...]
 * Software that binds to the first socket found
[...]

Both of those problems seem to be problems in specific pieces of
software.  I suggest you file bugs against those packages and tag them
with the ipv6 tag.

 * The cost of disabling IPv6

I don't think that should be needed, and the software behaving wrong
should get fixed instead.

 So before pushing IPv6 even further into Debian I ask you to consider 
 whether the foundation that is laid today is sane enough or whether it 
 should be improved with priority.

I think the point of adding better ipv6 support is actually fixing those
pieces of software that don't behave properly, in either an ipv4-only or
ipv6-only world.  They should be written that they should work with any
protocol.

 Please don't judge this memorandum based on the fact that the problem in my 
 specific case might sit in front of the keyboard, and instead please take 
 into account that a default instalation should *just* run in the most 
 common cases without the need to tweak - that is without the need to switch 
 off something as exotic as IPv6.

I've never actually had a problem on ipv4-only hosts.  It would be nice
if you could describe your problems in more detail.


Kurt


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

Re: IPv6 in Debian

[Kurt Roeckx]

On Mon, Jul 30, 2007 at 10:53:06PM +0200, Mike Hommey wrote:
 On Mon, Jul 30, 2007 at 10:33:10PM +0200, Kurt Roeckx [EMAIL PROTECTED] 
 wrote:
  I've never actually had a problem on ipv4-only hosts.  It would be nice
  if you could describe your problems in more detail.
 
 The typical problem, which is what Tomas was pointing at with 
 request being done before A requests, is that if the ipv6 module is
 loaded and you are in a ipv4-only environment, you still get a link
 local ipv6 address, and applications (glibc, actually) think (quite
 rightfully, from their PoV) that you are using ipv6.

It seems that even having lo ::1 is enough for glibc to think that you
ipv6 connectivity, which clearly looks wrong to me.


Kurt


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

Re: IPv6 in Debian

[Kurt Roeckx]

[I move this to the ipv6 list, I think this has little to do with
the -release list]

On Tue, Jul 31, 2007 at 12:29:37AM +0200, Tomas Pospisek wrote:

 I was trying to say that I had been bitten by the libc's name resolver 
 does by default an  name lookup before it does an A lookup before and 
 am asking whether that's still a problem as [1] suggest that it was for 
 Ubuntu at least until Dec 06 and whether someone can confirm it. As told I 
 can not reproduce it on my systems any more since I removed ipv6 as soon as 
 it started causing me trouble and as such cannot file a bug report against 
 libc.

It still queries both  and A records as soon as 1 ipv6 is
configured, which you'll always get for lo's ::1.

It appears this is not a problem for me because the nameserver I use
properly supports IPv6.

 You can not build systems that can deal with all and any unforseen 
 fundamental chang in their environments.

 And arguably ipv6 is such a change (since it breaks applications). So 
 arguing that applications don't behave properly or behave wrong is IMHO 
 not correct. They break with ipv6 but not without. ipv6 is a new 
 fundamental property of the system to deal with that came after the apps.

As far as I know, all applications that break are those that are
supposed to have ipv6 support, but the ipv6 support is broken.

It seems that some get a delay they shouldn't because of external
(to Debian) factors.  This is most likely only a problem for people
who only have ipv4 connectivity.  And we should do something about
that.

 I've never actually had a problem on ipv4-only hosts.  It would be nice
 if you could describe your problems in more detail.

 The (concrete!) problems are described in the references I sent:

 [0] https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
 [1] http://lists.debian.org/debian-devel/2000/12/msg01922.html

This seems to be about extra  queries which seem to cause
delays for people with broken nameservers.

I think the rfc4472 referenced in the ubuntu bug report is something
we should get glibc to implement.  It basicly suggests not do do 
lookups in case you're not sure you have ipv6 connectivity. This
would basicly disable ipv6 by default, and atleast was the behaviour I
was expecting when you use AI_ADDRCONFIG.

 [2] 
 http://www.google.com/search?q=dccproc+socket(UDP)%3A+Address+family+not+supported+by+protocol

Which just seems like a broken application.

Anyway, there are other type of applications that have a problem, and
that are those that fail to work if you disable ipv6 by disabling the
ipv6 module.


Kurt


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

Please hint openssl into testing.

[Kurt Roeckx]

Hi,

Could you please hint openssl into testing?  It has a udeb.


Kurt


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

Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch

[Kurt Roeckx]

On Fri, Sep 28, 2007 at 06:23:06PM +, Pierre Habouzit wrote:
   DNS RR is broken on Windows XP since SP2, Windows Vista, most *BSDs,
 Redhat and Fedora, and probably any Linux distribution out there

I've just tested XP SP2 myself in various ways.  I've tried things
like internet explorer, ping, Anthony's python script under cygwin.
They all fall under the not stable, and use a different IP each time.

I let someone test it on Vista, and that does follow rule 9, making it 2
implementations I know of that actually do it.

I haven't seen anybody claim that any of the *BSDs implemented rule 9
that also says he tested it, I've only seen reported of FreeBSD saying
it didn't.


Kurt


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

buildd build order [Was: arm buildd holdup?]

[Kurt Roeckx]

On Sun, Mar 06, 2005 at 10:52:41PM +1100, Hamish Moffatt wrote:
 Goswin wrote:
  Need-build is a good sign. http://buildd.net/ shows you are on place
  37 out of 120. I suggest just waiting unless the buildd has stoped
  altogether.
 
 What is the ordering criteria on the buildds?

According to the documentation:

The packages are ordered by the following criteria (in
this order):

 - out-of-date/uncompiled (the former come first)
 - priority (e.g. required before optional)
 - section (alphabetically)
 - package name (alphabetically)

Note the the priority has nothing do with with the urgency of the
upload, it has no effect on it.

The documentation seems to be a litte out of date, and before
those 4, there is also a rule that lists all packages of higher
priority than standard before the rest.

Basicly, when there are no new/uncompiled packages involved, the
order is by priority, then section, then alphabetically.


Kurt


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

gcc-3.3 3.3.5-9 C++ ABI problem.

[Kurt Roeckx]

Hi,

gcc-3.3 3.3.5-9 was build with the configure option
--disable-__cxa_atexit instead of --enable-__cxa_atexit.  This
causes it to have a different C++ ABI.

This was fixed in the 3.3.5-10 which should be available soon.

I've made a list of source packages that might have been build
with the 3.3.5-9 version so far.  This is based on all packages
uploaded after the gcc-3.3 3.3.5-9 package.  This is a list of
source package who have a binary package with a dependency on the
libstdc++5 package.

This list is probably not complete since people can still be
uploading packages with this broken ABI.  Please make sure you
either have the 3.3.5-8 or 3.3.5-10 version installed if you are
uploading a new package.

This is the list of source packages:
acovea
akregator
bidentd
bincimap
capi4hylafax
capisuite
cloop
cmt
d4x
flwm
glibmm2.4
gtkmm2.4
gtkwave
k3b
kcdlabel
kino
kismet
knetfilter
kwave
latd
lcdf-typetools
mozilla-firefox
mysql-query-browser
nmap
octave2.1
openam
openh323
oprofile
poedit
sdcc
sms-pl
synaptic
t38modem
tagtool
tora
trackballs
wine
wipl



Kurt


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

RFFE for amd64.

[Kurt Roeckx]

Hi,

I would like to see a few packages with amd64 specific bugs be
fixed in sarge.  I currently have 3 such packages:

- libglademm2.0: #279985: Fix a configure problem caused by using
an old libtool version resulting in link failures.

- libhdf4: #251275: Patches hdfi.h to known about amd64.

- esound: #288903: Change control file to also build alsa support
for amd64.


Kurt


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

RFFE for openntpd 3.6.1p1-2.

[Kurt Roeckx]

Hi,

I've uploaded a new version of openntpd which fix what I think
are several important bugs of which only 1 was reported.

Here is the changelog:
  * Change E-mail address to [EMAIL PROTECTED]
  * poll_errors.dpatch: When poll() says there was an error on a socket, it
didn't get checked and on the next poll() call got the same error again
resulting in cpuhog. poll_errors.dpatch (Closes: #307348)
Patch from upstream CVS.
  * Add a Depends on adduser since we use it in the postinst/postrm.
  * Use set -e in postinst/postrm instead of doing /bin/sh -e.
  * Create a defaults file, and mention the -s option in it.
  * freeifaddrs.dpatch: Call freeifaddrs() with the proper pointer.  Patch
from upstream CVS.
  * imsg_memmove.dpatch: Use a memmove() instead of memcpy() as those buffers
might overlap.  Patch from upstream CVS.
  * network_unreachable.dpatch: Do not consider ENETUNREACH as a fatal error.
Patch from upstream CVS.
  * daemonize_settime.dpatch: When started with -s option (which isn't used by
default) daemonize if sending failed instead of waiting for a reply.  This
might be a problem when the network is down.  Patch from upstream CVS.

I've noticed that I forgot to mention 1 change in it:
The init script has changed to no longer have a reload
option since it's not working.  The program sees the
SIGHUP, sets a variable, but then does nothing with it.


Kurt


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

Package without a versioned dependency on libmad0/libid3tag0

[Kurt Roeckx]

Hi,

Because of #310311, some packages do not have a version
dependency on libmad0 and/or libid3tag0 which could break partial
upgrading.

missing libmad0 in sarge this seems to be:
kdelibs4
kwifimanager
libsds0
libsomaplayer0
somaplayer

In unstable:
graveman
kdelibs4
kwifimanager
libsds0
libsomaplayer0
libswfdec0.3
somaplayer
swf-player

The following packages also don't have a version dependency on
libid3tag0:
sarge:
libsds0
libsomaplayer0
somaplayer

unstable:
graveman
libsds0
libsomaplayer0
somaplayer


Should I file bugs against the relevant packages?  (somaplayer is
already filed, the rest probably not.)

Source packages affected in sarge:
somaplayer (somaplayer, libsomaplayer0, libsds0)
kdelibs (kdelibs4)
kdenetwork (kwifimanager)


Kurt


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

Re: Bug reports and severity

[Kurt Roeckx]

On Sun, Jun 19, 2005 at 03:18:27PM +0200, Robert Millan wrote:
 
 I assume we're talking about FTBFS bugs which theoricaly should be reported
 as serious (we have a few GNU/kFreeBSD bugs in the style of #307475, too).

FTBFS are only serious if:
- It build previously on that arch.  Basicly, it comes down to
  that it prevents migration of the package to testing.
And:
- It affects a released arch.


Kurt


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

Re: status of postgresql for sarge?

[Kurt Roeckx]

On Mon, Mar 08, 2004 at 02:58:07PM +, Oliver Elphick wrote:
 
 In order to cure this, we need to change the woody package, either to
 force it to do a dump in the prerm or to save all the shared libraries
 it needs to go with its binaries for use by the new package's postinst.

Afaik, It's recommended to use the pg_dump(all) from the new release
to dump the old database.

This would mean that you need binaries from both versions at the
same time.


Kurt

New dutch spelling check

[Kurt Roeckx]

Hi,

I've recently uploaded a new major version of the dutch spelling
check files.  The changes are rather large and should give better
support for spellchecking for Dutch.  They are also generated
differently upstream, so reviewing the changes between the 2
versions isn't easy.

Please consider appoving a new version of the source package
dutch for 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/20101204145716.ga18...@roeckx.be

Re: New dutch spelling check

[Kurt Roeckx]

On Sat, Dec 04, 2010 at 03:57:16PM +0100, Kurt Roeckx wrote:
 Hi,
 
 I've recently uploaded a new major version of the dutch spelling
 check files.  The changes are rather large and should give better
 support for spellchecking for Dutch.  They are also generated
 differently upstream, so reviewing the changes between the 2
 versions isn't easy.
 
 Please consider appoving a new version of the source package
 dutch for testing.

Can someone either approve or reject it?


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/20101211125254.ga22...@roeckx.be

openssl for testing.

[Kurt Roeckx]

Hi,

Could someone bump openssl's priority so it migrates to testing
sooner? It fixes a security issue.


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/20110212232418.ga9...@roeckx.be

Openssl 1.0.0

[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

Re: Openssl 1.0.0

[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

[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

[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

[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

[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

Bug#619117: perl 5.12 transition

[Kurt Roeckx]

On Wed, Mar 30, 2011 at 03:34:17PM +0200, Julien Cristau wrote:
 On Wed, Feb 23, 2011 at 07:40:26PM +, Dominic Hargreaves wrote:
  I would like to register an interest in carrying out a perl transition
  soon. This would be to perl 5.10.1 to 5.12.x (x = 3 currently). This
  transition has already been in preparation for some time, and I think
  we are in a good position to schedule this now. This is the first major
  transition I've been involved in (I've recently become a co-maintainer
  of the perl package), so please bear with me if I miss anything out.
  You can see the transition tracking bugs at [1].
 
 One thing that came up is that we need to make sure all sid buildd
 chroots have debconf-english installed and not debconf-i18n before that
 happens (debconf-i18n depends on liblocale-gettext-perl, which depends
 on perlapi-5.10.0).  Cc:-ing debian-wb-team so this can be handled
 before the perl transition.

As far as I know all buildds except alkman now have
debconf-english installed.


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/20110406182107.ga23...@roeckx.be

Bug#619117: perl 5.12 transition

[Kurt Roeckx]

On Wed, Apr 06, 2011 at 08:21:07PM +0200, Kurt Roeckx wrote:
 On Wed, Mar 30, 2011 at 03:34:17PM +0200, Julien Cristau wrote:
  On Wed, Feb 23, 2011 at 07:40:26PM +, Dominic Hargreaves wrote:
   I would like to register an interest in carrying out a perl transition
   soon. This would be to perl 5.10.1 to 5.12.x (x = 3 currently). This
   transition has already been in preparation for some time, and I think
   we are in a good position to schedule this now. This is the first major
   transition I've been involved in (I've recently become a co-maintainer
   of the perl package), so please bear with me if I miss anything out.
   You can see the transition tracking bugs at [1].
  
  One thing that came up is that we need to make sure all sid buildd
  chroots have debconf-english installed and not debconf-i18n before that
  happens (debconf-i18n depends on liblocale-gettext-perl, which depends
  on perlapi-5.10.0).  Cc:-ing debian-wb-team so this can be handled
  before the perl transition.
 
 As far as I know all buildds except alkman now have
 debconf-english installed.

alkman is done now too.


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/20110406183002.ga24...@roeckx.be

Bug#622134: transition: openssl 1.0.0

[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

Re: GCC-4.5 as the default for (at least some) architectures

[Kurt Roeckx]

On Tue, Apr 26, 2011 at 08:51:04PM +0200, Aurelien Jarno wrote:
 On Tue, Apr 26, 2011 at 05:03:01PM +0200, Matthias Klose wrote:
  I'll make GCC 4.6 the
  default after the release of GCC 4.5.3, expected later this week, at
  least on amd64, armel, i386 and powerpc.
 
 If you do the switch, please also add mips and mipsel, that would avoid
 you to have to complain in two weeks that these architectures have not
 yet been switched.

Is there a reason not to switch the remaining (release) arches
(ia64, kfreebsd-*, sparc, s390)?  Maybe hurd-i386 too?

I assume you want to release with at least 4.6 on all arches as
the default, so I see no point in waiting with switching if
there are no known issues.


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/20110426192857.ga10...@roeckx.be

Re: Maintainers, porters, and burden of porting [and 1 more messages]

[Kurt Roeckx]

On Wed, Aug 31, 2011 at 02:52:53PM +0100, Ian Jackson wrote:
 Let me make an alternative proposal:
 
  * The root cause bug in the BTS would be given a special tag
(arch-blocker:arch or something).  I will call such a bug which
is open and has existed in this state for 30 days a ripe arch
blocker for arch.
 
Bugs in other affected packages are marked as blocked by the root
cause bug.  These bugs, and the arch blocker itself, may be RC, or
not, as appropriate.  Let us say ripe arch bug to mean ripe arch
blocker, or bug blocked by a ripe arch blocker.

If there is a bug in say eglibc on only arch, and considered to be
RC on that arch, would you then lower the severity of that bug,
and use this new tag to indicate it's RC only on that arch?

This could be useful for arches that are not being considered for
a release, but I don't see the point in doing the same for if it's
currently still considered for a release.  If the bug already
affects testing it will migrate anyway.

But tracking bugs that way might also be useful to see if we
should consider that the arch should be part of the next release
or not.

The effects would be:
 
 1. Any ripe arch bug is ignored for the purposes of testing
propagation.

If they already affect testing, it will already be ignored
anyway.

 2. For a package with an RC ripe arch bug for arch:
   (i) arch will be ignored for testing propagation

So such bugs would automaticly have an effect on release
migration, while this is not something the release team
decides itself.  Or do you only mean that package will
be ignored and can move testing anyway?  Or they can't
move to testing?

   (ii) no builds will be attempted by arch buildds,

You mean we completly stop building anything for $arch?  Or
only the packages that are affected by it?  Other than wasting
some buildd time, I don't see the harm in building things most
of the time.

automatic tests may be skipped on arch, etc.
 
 The workflow would be as follows:
 
  * If a package has an arch-specific bug, the root cause needs to be
identified, by collaboration between porters and maintainers.  This
process should be driven by the maintainer.
 
  * Once the cause has been identified:
 
 - If the root cause is elsewhere, a bug needs to be filed bug
   against that other package.  If such a bug already exists, the
   maintainer of the first package can simply mark their bug as
   blocked by the arch blocker.  This will allow their package to
   migrate unless the arch blocker is new enough.
 
   If no such bug already exists, the maintainer should file a bug
   against the appropriate package (toolchain or libc, perhaps),
   and immediately tag it as an arch blocker.

You can just reassign the bug and mark it as affecting an other
package.  There is no need to have 2 bugs open for the same
problem.


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/20110831200319.gb25...@roeckx.be

Bug#622134: transition: openssl 1.0.0

[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#630201: [kfreebsd-*] please rebuild elfutils/sid, ignoring the 2 known testsuite failures (Re: transition: liblzma 5)

[Kurt Roeckx]

On Sat, Oct 29, 2011 at 11:07:42AM +0200, Julien Cristau wrote:
 On Sat, Oct 29, 2011 at 02:12:25 -0500, Jonathan Nieder wrote:
 
  Julien Cristau wrote:
   On Wed, Oct 26, 2011 at 12:01:41 +0200, Julien Cristau wrote:
  
libdw1 (DWARF parser for elfutils)
  
   FTBFS on kfreebsd, needs a bug filed.
  
   Apparently that's #570805 (thanks, Jakub).
  
  That's a pair of testsuite failures due to a kernel bug and not a
  regression in elfutils as far as I can tell.
  
  kfreebsd buildd admins, is it possible to schedule a rebuild with
  DEB_BUILD_OPTIONS=nocheck, or would it be better to request that
  directly in debian/rules as a temporary workaround?  (Please forgive
  my ignorance.)
  
 I think this should be worked around in the elfutils package.

How do you suggest I work around this?  I really don't like to
ignore those errors.  They're the one that test the platform
specific parts.

Can I instead suggest someone looks at the kernel and fixes it?
It used to work, it works on the porter machines, it just fails
on the buidds.


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/20111029093818.ga22...@roeckx.be

Bug#665969: nmu: apt_0.9.0

[Kurt Roeckx]

On Tue, Apr 17, 2012 at 09:59:09AM +0200, Michael Vogt wrote:
   Problems reported so far include:
   
   E: Method http has died unexpectedly!
   E: Sub-process http received signal 10.
  
  This is #669061
 
 This appears to be Sparc only, right? We do had trouble with
 alignments in the hashsum calculations in the past, maybe that is
 re-occuring with the addition of sha512. 

I've only seen it on sparc, but I didn't try this on many arches.

I've been trying to reproduce this, and it seems to happen after
the first write() call that writes the file in
/var/cache/apt/archives/.



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/20120417203350.ga27...@roeckx.be

Bug#675434: nmu: libnet-ssleay-perl_1.48-1

[Kurt Roeckx]

On Fri, Jun 01, 2012 at 11:07:44AM +0200, Cyril Brulebois wrote:
 Salvatore Bonaccorso car...@debian.org (01/06/2012):
  It was reported [1], that libnet-ssleay-perl does not report the
  correct constant value for SSL_OP_NO_TLSv1_1. There was the following
  change in openssl 1.0.1b-1:
  
   openssl (1.0.1b-1) unstable; urgency=high
   .
 * New upstream version
   - Remaps SSL_OP_NO_TLSv1_1, so applications linked to 1.0.0
 can talk to servers supporting TLS 1.1 but not TLS 1.2
   - Drop rc4_hmac_md5.patch, applied upstream
 
 Does it mean we're going to hit the same kind of issues next time
 there's a similar change in openssl?

This change was made to make sure applications build against
1.0.0 can talk to a server that does TLS 1.1 but not TLS 1.2,
as the changelog says.  This is not something I like to change
again, since it will cause problems.

Everything build against 1.0.1 or 1.0.1a that cares about
SSL_OP_NO_TLSv1_1 should be rebuild against 1.0.1b or later.
If using the defines from the the 1.0.1 and 1.0.1a version,
but using 1.0.1b or laster the SSL_OP_NO_TLSv1_1 will not have
any effect.


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/20120602122135.ga9...@roeckx.be

Bug#675434: nmu: libnet-ssleay-perl_1.48-1

[Kurt Roeckx]

On Sun, Jun 03, 2012 at 01:34:05AM +0200, Cyril Brulebois wrote:
 Hi,
 
 Kurt Roeckx k...@roeckx.be (02/06/2012):
  This change was made to make sure applications build against
  1.0.0 can talk to a server that does TLS 1.1 but not TLS 1.2,
  as the changelog says.  This is not something I like to change
  again, since it will cause problems.
  
  Everything build against 1.0.1 or 1.0.1a that cares about
  SSL_OP_NO_TLSv1_1 should be rebuild against 1.0.1b or later.
  If using the defines from the the 1.0.1 and 1.0.1a version,
  but using 1.0.1b or laster the SSL_OP_NO_TLSv1_1 will not have
  any effect.
 
 do we have better ways to detect that than maintainers noticing and
 pinging us? :/

Scanning all reverse dependencies for that string?


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/20120602234438.ga4...@roeckx.be

openssl 0.9.8g-14

[Kurt Roeckx]

Hi,

Could you please hint openssl in testing?  The changelog:
   * Don't give the warning about security updates when upgrading
 from etch since it doesn't have any known security problems.
   * Automaticly use engines that succesfully initialised.  Patch
 from the 0.9.8h upstream version.  (Closes: #502177)


Kurt


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

libtool 2.2

[Kurt Roeckx]

Hi,

I'm planning on uploading libtool 2.2 to unstable soon.  This includes
an soname bump for libltdl, which seems to have around 130 reverse
dependencies.

This might also result in some packages to FTBFS, or otherwise have
problems upgrading to 2.2 version.

Please let me know when the best time for such an upload is.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: libtool 2.2

[Kurt Roeckx]

On Sun, Feb 15, 2009 at 01:51:00PM +0100, Kurt Roeckx wrote:
 Hi,
 
 I'm planning on uploading libtool 2.2 to unstable soon.  This includes
 an soname bump for libltdl, which seems to have around 130 reverse
 dependencies.

I will change libltdl7-dev to also provide libltdl3-dev, so this
should hopefully mostly be possible using binNMUs.

 This might also result in some packages to FTBFS, or otherwise have
 problems upgrading to 2.2 version.
 
 Please let me know when the best time for such an upload is.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Unblock openssl

[Kurt Roeckx]

Hi,

Can openssl 0.9.8g-16 be hinted to testing?

It fixes a security issue.

It has a udeb.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Security binNMUs for apache2-mpm-itk

[Kurt Roeckx]

On Sun, Jun 14, 2009 at 04:24:17PM +0200, Stefan Fritsch wrote:
   Also, the binNMU for apache2-mpm-itk in unstable I requested on
   debian-release has not been scheduled yet: build against apache2-
   src_2.2.11-6, new version should be
   apache2-mpm-itk_2.2.11-02-1+b2 .
 
 This is still missing.

I've done that one.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Openssl

[Kurt Roeckx]

Hi,

Can openssl 0.9.8k-3 be pushed to testing?  It fixed a number
of security issues.


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

I take a regular look at various arches why packages are not
correctly built.  hppa is the most annoying arch for me. If you
look at the stats you will notice that it's almost always
the lowest in the stats.  The reason it more or less keeps up is
because I put alot of time in looking at the state of the
packages and that packages get retried alot by the buildd
maintainer.

One of the most annoying things about it is that packages only
get uploaded 2 or 3 times a week.  This has as effect that alot
of packages fail to build because others haven't been uploaded
yet.  Alot of packages are uninstallable, and are basicly waiting
for others to be built/uploaded.  With only 2/3 uploads a week
this means that packages are uninstallable for _weeks_.  By the
time the first reason has been fixed, something else already make
it uninstallable again.  And I guess this is also the reason
the release team always needs to take a look at why something
is uninstallable on hppa.  I can deal with this, but because of
this reason, hppa is a low priority port for me.

So it's my understanding that the porters have no idea about the
problems.  So I will start to mail you about problems as soon
as I see them and they look like porting issues specific
to hppa.

Here is a list of packages that failed to build because of instability
on the buildds today:
package | buildd   | error
qgit| penalosa | make: *** [install] Segmentation fault
acpica-unix | peri | make: *** [install] Segmentation fault


This are probabaly porting issues, they atleast seems to
only affect hppa:
package| error
rt-tests   | PTHREAD_PRIO_INHERIT undeclared (NPTL support?)
insighttoolkit | undefined references
axis   | #531995: Cannot override the final method from ResourceBundle
petsc  | petscvariables: No such file or directory

Logs can be found at
https://buildd.debian.org/build.cgi?arch=hppa;pkg=$package


Kurt

On Fri, Jun 19, 2009 at 08:05:56AM +0200, Luk Claes wrote:
 Hmm...
 
 It's right that some of my comments are rather harsh, though you must
 know that I'm not speaking from a personal perspective.
 
 Personally (and as Release Manager), I would be very happy to have a
 good working hppa port for Squeeze and beyond.
 
 I made sure that the hppa port was included into Lenny even when the
 Debian System Administrators (DSA), package maintainers, release team
 members an others were shouting to drop it. I thought it was unfair to
 drop the port just before the release. They accepted my decision as long
 as I would make it clear that it was a *big* exception not to be taken
 lightly. At the time java support was completely dropped, buildds were
 crashing every other day and support for other programing languages
 looked poor and the port was still using linuxthreads as the latest of
 all ports.
 
 After the release of Lenny there were still not much signs of
 improvement to the reliability of the buildds and the move to ntpl (that
 was going to solve almost all issues the maintainers had) seemed to not
 happen and not going to solve everything. The only surprising
 improvement was the regained java support.
 
 It's quite disturbing in my honest opinion that only after us starting a
 thread like this one that we get to know the status of some of the
 porting efforts and lots of vocal support, but not many visible
 improvements. Instead of making sure that there is visibile improvement
 after that, this pattern seems to repeat itself which is not looking
 very promising. I'm sorry if my and others' frustration is ventilated in
 some of the mails. The issues with the buildds are lasting for years
 already with lots of time spent by DSA and others.
 
 I still hope that the hppa porters can prove us wrong, fix the kernel
 issues (which are the probable cause of the unreliability of the
 buildds), finalise the ntpl move and stay on top of porting issues in
 Debian in the future.
 
 Please let us now focus on improving the status of the hppa port in
 general and the buildds in particular!
 
 Cheers
 
 Luk
 
 
 -- 
 To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
 


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: octave3.2 autobuild problems

[Kurt Roeckx]

On Fri, Jun 19, 2009 at 09:49:34PM +0200, Rafael Laboissiere wrote:
 The octave3.2 package failed to autobuild on ia64 and is stuck on
 powerpc.  This is blocking our planned transition of the octave-forge
 packages from octave3.0 to octave3.2 [1].
 
 The failure on caballero is due to the infamous alternatives problem [2] but
 nobody seem to care.  I wish I could ask for this:
 
 gb octave3.2_3.2.0-2 . ia64-but-please-not-on-caballero
  
 but I guess that the syntax is wrong. ;-)

I've given it back, let's see if we're lucky.


 OTOH, the problem with powerpc seems to be easier to fix.  I have asked
 for a dep-wait in the past [3] but I think it is wrong now, since
 arpack_2.1+parpack96.dfsg-2 has migrated into testing.  Please, could the
 dep-wait be removed or the following be done:
 
 gb octave3.2_3.2.0-2 . powerpc

Done that.



Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: HPPA and Squeeze

[Kurt Roeckx]

On Fri, Jun 19, 2009 at 05:15:26PM +0200, Kurt Roeckx wrote:
 So it's my understanding that the porters have no idea about the
 problems.  So I will start to mail you about problems as soon
 as I see them and they look like porting issues specific
 to hppa.

netgen fails to built with an internal compiler error since
atleast April 2008.  Logs are at:
https://buildd.debian.org/build.cgi?pkg=netgen;ver=4.4-15;arch=hppa
https://buildd.debian.org/build.cgi?pkg=netgen;arch=hppa


Kurt


-- 
To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org