Bug#1061894: apr: NMU diff for 64-bit time_t transition

2024-03-08 Thread Steve Langasek 
The NMU was buggy because symbols files are in a non-standard location, so
did not get updated by our transition scripts; with the result that packages
rebuilt against libapr1t64 still had a dependency on libapr1.  Please find
attached a full NMU debdiff for an updated NMU.

On Wed, Feb 28, 2024 at 01:17:59AM +, Steve Langasek wrote:
> Dear maintainer,
> 
> Please find attached a final version of this patch for the time_t
> transition.  This patch is being uploaded to unstable.
> 
> Note that this adds a versioned build-dependency on dpkg-dev, to guard
> against accidental backports with a wrong ABI.
> 
> Thanks!
> 
> 
> -- System Information:
> Debian Release: trixie/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
> Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
> Shell: /bin/sh linked to /usr/bin/dash
> Init: systemd (via /run/systemd/system)

> diff -Nru apr-1.7.2/debian/changelog apr-1.7.2/debian/changelog
> --- apr-1.7.2/debian/changelog2023-02-26 20:51:24.0 +
> +++ apr-1.7.2/debian/changelog2024-02-28 01:17:18.0 +
> @@ -1,3 +1,10 @@
> +apr (1.7.2-3.1) unstable; urgency=medium
> +
> +  * Non-maintainer upload.
> +  * Rename libraries for 64-bit time_t transition.  Closes: #1061894
> +
> + -- Steve Langasek   Wed, 28 Feb 2024 01:17:18 +
> +
>  apr (1.7.2-3) unstable; urgency=medium
>  
>* Add more fixes for atomics from upstream, in particular for
> diff -Nru apr-1.7.2/debian/control apr-1.7.2/debian/control
> --- apr-1.7.2/debian/control  2023-02-03 16:18:13.0 +
> +++ apr-1.7.2/debian/control  2024-02-28 01:17:18.0 +
> @@ -3,7 +3,7 @@
>  Priority: optional
>  Maintainer: Debian Apache Maintainers 
>  Uploaders: Stefan Fritsch 
> -Build-Depends: debhelper-compat (= 13),
> +Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
>   autoconf,
>   mawk,
>   uuid-dev,
> @@ -19,7 +19,10 @@
>  Homepage: https://apr.apache.org/
>  Rules-Requires-Root: no
>  
> -Package: libapr1
> +Package: libapr1t64
> +Provides: ${t64:Provides}
> +Replaces: libapr1
> +Breaks: libapr1 (<< ${source:Version})
>  Architecture: any
>  Depends: ${shlibs:Depends}, ${misc:Depends}
>  Pre-Depends: ${misc:Pre-Depends}
> @@ -33,7 +36,7 @@
>  Package: libapr1-dev
>  Architecture: any
>  Section: libdevel
> -Depends: libapr1 (= ${binary:Version}), uuid-dev, ${misc:Depends}, 
> libsctp-dev [linux-any], python3:any
> +Depends: libapr1t64 (= ${binary:Version}), uuid-dev, ${misc:Depends}, 
> libsctp-dev [linux-any], python3:any
>  Conflicts: libapr1.0-dev, libapr0-dev
>  Description: Apache Portable Runtime Library - Development Headers
>   APR is Apache's Portable Runtime Library, designed to be a support library
> diff -Nru apr-1.7.2/debian/libapr1.docs apr-1.7.2/debian/libapr1.docs
> --- apr-1.7.2/debian/libapr1.docs 2023-02-02 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.docs 1970-01-01 00:00:00.0 +
> @@ -1 +0,0 @@
> -NOTICE
> diff -Nru apr-1.7.2/debian/libapr1.install apr-1.7.2/debian/libapr1.install
> --- apr-1.7.2/debian/libapr1.install  2023-02-02 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.install  1970-01-01 00:00:00.0 +
> @@ -1 +0,0 @@
> -usr/lib/*/libapr-1.so.*
> diff -Nru apr-1.7.2/debian/libapr1.lintian-overrides 
> apr-1.7.2/debian/libapr1.lintian-overrides
> --- apr-1.7.2/debian/libapr1.lintian-overrides2023-02-02 
> 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.lintian-overrides1970-01-01 
> 00:00:00.0 +
> @@ -1 +0,0 @@
> -libapr1: package-name-doesnt-match-sonames libapr-1-0
> diff -Nru apr-1.7.2/debian/libapr1.symbols apr-1.7.2/debian/libapr1.symbols
> --- apr-1.7.2/debian/libapr1.symbols  2023-02-02 21:18:42.0 +
> +++ apr-1.7.2/debian/libapr1.symbols  1970-01-01 00:00:00.0 +
> @@ -1,2 +0,0 @@
> -here for the purpose of tricking debhelper...bwahahahaha.
> -
> diff -Nru apr-1.7.2/debian/libapr1t64.docs apr-1.7.2/debian/libapr1t64.docs
> --- apr-1.7.2/debian/libapr1t64.docs  1970-01-01 00:00:00.0 +
> +++ apr-1.7.2/debian/libapr1t64.docs  2023-02-02 21:18:42.0 +
> @@ -0,0 +1 @@
> +NOTICE
> diff -Nru apr-1.7.2/debian/libapr1t64.install 
> apr-1.7.2/debian/libapr1t64.install
> --- apr-1.7.2/debian/libapr1t64.install   1970-01-01 00:00:00.0 
> +
> +++ apr-1.7.2/debian/libapr1t64.install   2023-02-02 21:18:42.0 
> +
> @@ -0,0 +1 @@
>

Bug#1061894: apr: NMU diff for 64-bit time_t transition

2024-02-27 Thread Steve Langasek 
Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru apr-1.7.2/debian/changelog apr-1.7.2/debian/changelog
--- apr-1.7.2/debian/changelog  2023-02-26 20:51:24.0 +
+++ apr-1.7.2/debian/changelog  2024-02-28 01:17:18.0 +
@@ -1,3 +1,10 @@
+apr (1.7.2-3.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1061894
+
+ -- Steve Langasek   Wed, 28 Feb 2024 01:17:18 +
+
 apr (1.7.2-3) unstable; urgency=medium
 
   * Add more fixes for atomics from upstream, in particular for
diff -Nru apr-1.7.2/debian/control apr-1.7.2/debian/control
--- apr-1.7.2/debian/control2023-02-03 16:18:13.0 +
+++ apr-1.7.2/debian/control2024-02-28 01:17:18.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Apache Maintainers 
 Uploaders: Stefan Fritsch 
-Build-Depends: debhelper-compat (= 13),
+Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
  autoconf,
  mawk,
  uuid-dev,
@@ -19,7 +19,10 @@
 Homepage: https://apr.apache.org/
 Rules-Requires-Root: no
 
-Package: libapr1
+Package: libapr1t64
+Provides: ${t64:Provides}
+Replaces: libapr1
+Breaks: libapr1 (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -33,7 +36,7 @@
 Package: libapr1-dev
 Architecture: any
 Section: libdevel
-Depends: libapr1 (= ${binary:Version}), uuid-dev, ${misc:Depends}, libsctp-dev 
[linux-any], python3:any
+Depends: libapr1t64 (= ${binary:Version}), uuid-dev, ${misc:Depends}, 
libsctp-dev [linux-any], python3:any
 Conflicts: libapr1.0-dev, libapr0-dev
 Description: Apache Portable Runtime Library - Development Headers
  APR is Apache's Portable Runtime Library, designed to be a support library
diff -Nru apr-1.7.2/debian/libapr1.docs apr-1.7.2/debian/libapr1.docs
--- apr-1.7.2/debian/libapr1.docs   2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.docs   1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-NOTICE
diff -Nru apr-1.7.2/debian/libapr1.install apr-1.7.2/debian/libapr1.install
--- apr-1.7.2/debian/libapr1.install2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.install1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libapr-1.so.*
diff -Nru apr-1.7.2/debian/libapr1.lintian-overrides 
apr-1.7.2/debian/libapr1.lintian-overrides
--- apr-1.7.2/debian/libapr1.lintian-overrides  2023-02-02 21:18:42.0 
+
+++ apr-1.7.2/debian/libapr1.lintian-overrides  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-libapr1: package-name-doesnt-match-sonames libapr-1-0
diff -Nru apr-1.7.2/debian/libapr1.symbols apr-1.7.2/debian/libapr1.symbols
--- apr-1.7.2/debian/libapr1.symbols2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.symbols1970-01-01 00:00:00.0 +
@@ -1,2 +0,0 @@
-here for the purpose of tricking debhelper...bwahahahaha.
-
diff -Nru apr-1.7.2/debian/libapr1t64.docs apr-1.7.2/debian/libapr1t64.docs
--- apr-1.7.2/debian/libapr1t64.docs1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.docs2023-02-02 21:18:42.0 +
@@ -0,0 +1 @@
+NOTICE
diff -Nru apr-1.7.2/debian/libapr1t64.install 
apr-1.7.2/debian/libapr1t64.install
--- apr-1.7.2/debian/libapr1t64.install 1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.install 2023-02-02 21:18:42.0 +
@@ -0,0 +1 @@
+usr/lib/*/libapr-1.so.*
diff -Nru apr-1.7.2/debian/libapr1t64.lintian-overrides 
apr-1.7.2/debian/libapr1t64.lintian-overrides
--- apr-1.7.2/debian/libapr1t64.lintian-overrides   1970-01-01 
00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.lintian-overrides   2024-02-28 
01:17:10.0 +
@@ -0,0 +1,2 @@
+libapr1t64: package-name-doesnt-match-sonames libapr-1-0
+libapr1t64: package-name-doesnt-match-sonames libapr1
diff -Nru apr-1.7.2/debian/libapr1t64.symbols 
apr-1.7.2/debian/libapr1t64.symbols
--- apr-1.7.2/debian/libapr1t64.symbols 1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.symbols 2024-02-28 01:17:10.0 +
@@ -0,0 +1,2 @@
+here for the purpose of tricking debhelper...bwahahahaha.
+

Bug#1061893: apr-util: NMU diff for 64-bit time_t transition

2024-02-27 Thread Steve Langasek 
Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru apr-util-1.6.3/debian/changelog apr-util-1.6.3/debian/changelog
--- apr-util-1.6.3/debian/changelog 2023-02-03 20:15:18.0 +
+++ apr-util-1.6.3/debian/changelog 2024-02-28 01:16:25.0 +
@@ -1,3 +1,10 @@
+apr-util (1.6.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1061893
+
+ -- Steve Langasek   Wed, 28 Feb 2024 01:16:25 +
+
 apr-util (1.6.3-1) unstable; urgency=medium
 
   [ Stefan Fritsch ]
diff -Nru apr-util-1.6.3/debian/control apr-util-1.6.3/debian/control
--- apr-util-1.6.3/debian/control   2023-02-02 22:42:28.0 +
+++ apr-util-1.6.3/debian/control   2024-02-28 01:16:24.0 +
@@ -3,7 +3,7 @@
 Uploaders: Stefan Fritsch 
 Section: libs
 Priority: optional
-Build-Depends: debhelper-compat (= 11),
+Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 11),
autoconf,
mawk,
libldap2-dev,
@@ -22,7 +22,10 @@
 Vcs-Git: https://salsa.debian.org/apache-team/apr-util.git
 Homepage: https://apr.apache.org/
 
-Package: libaprutil1
+Package: libaprutil1t64
+Provides: ${t64:Provides}
+Replaces: libaprutil1
+Breaks: libaprutil1 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends},
@@ -39,7 +42,7 @@
 Package: libaprutil1-ldap
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -56,7 +59,7 @@
 Package: libaprutil1-dbd-mysql
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -73,7 +76,7 @@
 Package: libaprutil1-dbd-sqlite3
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -90,7 +93,7 @@
 Package: libaprutil1-dbd-odbc
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -107,7 +110,7 @@
 Package: libaprutil1-dbd-pgsql
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -124,7 +127,7 @@
 Package: libaprutil1-dev
 Architecture: any
 Section: libdevel
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  libldap2-dev,
  libexpat1-dev,
  libapr1-dev,
diff -Nru apr-util-1.6.3/debian/libaprutil1.docs 
apr-util-1.6.3/debian/libaprutil1.docs
--- apr-util-1.6.3/debian/libaprutil1.docs  2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.docs  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-NOTICE
diff -Nru apr-util-1.6.3/debian/libaprutil1.install 
apr-util-1.6.3/debian/libaprutil1.install
--- apr-util-1.6.3/debian/libaprutil1.install   2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.install   1970-01-01 00:00:00.0 
+
@@ -1,3 +0,0 @@
-usr/lib/*/libaprutil-1.so.*
-usr/lib/*/apr-util-1/apr_dbm*.so*
-usr/lib/*/apr-util-1/apr_crypt*.so*
diff -Nru apr-util-1.6.3/debian/libaprutil1.lintian-overrides 
apr-util-1.6.3/debian/libaprutil1.lintian-overrides
--- apr-util-1.6.3/debian/libaprutil1.lintian-overrides 2023-02-01 
21:35:51.0 +
+++ apr-util-1.6.3/debian/libaprutil1.lintian-overrides 1970-01-01 
00:00:00.0 +
@@ -1,2 +0,0 @@
-libaprutil1: symbols-declares-dependency-on-other-package
-libaprutil1: package-name-doesnt-match-sonames libaprutil-1-0
diff -Nru apr-util-1.6.3/debian/libaprutil1.symbols 
apr-util-1.6.3/debian/libaprutil1.symbols
--- apr-util-1.6.3/debian/libaprutil1.symbols   2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.symbols   1970-01-01 00:00:00.0 
+
@@ -1

Bug#1061894: apr: NMU diff for 64-bit time_t transition

2024-01-30 Thread Steve Langasek 
Source: apr
Followup-For: Bug #1061894

Apologies, an oversight in the conversion script caused us to fail to
update strict versioned dependencies on the previous package name.
Please find attached a fixed patch.

This has also now been uploaded to experimental.
diff -Nru apr-1.7.2/debian/changelog apr-1.7.2/debian/changelog
--- apr-1.7.2/debian/changelog  2023-02-26 20:51:24.0 +
+++ apr-1.7.2/debian/changelog  2024-01-31 06:04:49.0 +
@@ -1,3 +1,11 @@
+apr (1.7.2-3.1~exp2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+  * Fix uninstallable packages from the previous upload.
+
+ -- Steve Langasek   Wed, 31 Jan 2024 06:04:49 +
+
 apr (1.7.2-3) unstable; urgency=medium
 
   * Add more fixes for atomics from upstream, in particular for
diff -Nru apr-1.7.2/debian/control apr-1.7.2/debian/control
--- apr-1.7.2/debian/control2023-02-03 16:18:13.0 +
+++ apr-1.7.2/debian/control2024-01-31 06:04:48.0 +
@@ -19,7 +19,10 @@
 Homepage: https://apr.apache.org/
 Rules-Requires-Root: no
 
-Package: libapr1
+Package: libapr1t64
+Provides: ${t64:Provides}
+Replaces: libapr1
+Breaks: libapr1 (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -33,7 +36,7 @@
 Package: libapr1-dev
 Architecture: any
 Section: libdevel
-Depends: libapr1 (= ${binary:Version}), uuid-dev, ${misc:Depends}, libsctp-dev 
[linux-any], python3:any
+Depends: libapr1t64 (= ${binary:Version}), uuid-dev, ${misc:Depends}, 
libsctp-dev [linux-any], python3:any
 Conflicts: libapr1.0-dev, libapr0-dev
 Description: Apache Portable Runtime Library - Development Headers
  APR is Apache's Portable Runtime Library, designed to be a support library
diff -Nru apr-1.7.2/debian/libapr1.docs apr-1.7.2/debian/libapr1.docs
--- apr-1.7.2/debian/libapr1.docs   2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.docs   1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-NOTICE
diff -Nru apr-1.7.2/debian/libapr1.install apr-1.7.2/debian/libapr1.install
--- apr-1.7.2/debian/libapr1.install2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.install1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libapr-1.so.*
diff -Nru apr-1.7.2/debian/libapr1.lintian-overrides 
apr-1.7.2/debian/libapr1.lintian-overrides
--- apr-1.7.2/debian/libapr1.lintian-overrides  2023-02-02 21:18:42.0 
+
+++ apr-1.7.2/debian/libapr1.lintian-overrides  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-libapr1: package-name-doesnt-match-sonames libapr-1-0
diff -Nru apr-1.7.2/debian/libapr1.symbols apr-1.7.2/debian/libapr1.symbols
--- apr-1.7.2/debian/libapr1.symbols2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.symbols1970-01-01 00:00:00.0 +
@@ -1,2 +0,0 @@
-here for the purpose of tricking debhelper...bwahahahaha.
-
diff -Nru apr-1.7.2/debian/libapr1t64.docs apr-1.7.2/debian/libapr1t64.docs
--- apr-1.7.2/debian/libapr1t64.docs1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.docs2023-02-02 21:18:42.0 +
@@ -0,0 +1 @@
+NOTICE
diff -Nru apr-1.7.2/debian/libapr1t64.install 
apr-1.7.2/debian/libapr1t64.install
--- apr-1.7.2/debian/libapr1t64.install 1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.install 2023-02-02 21:18:42.0 +
@@ -0,0 +1 @@
+usr/lib/*/libapr-1.so.*
diff -Nru apr-1.7.2/debian/libapr1t64.lintian-overrides 
apr-1.7.2/debian/libapr1t64.lintian-overrides
--- apr-1.7.2/debian/libapr1t64.lintian-overrides   1970-01-01 
00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.lintian-overrides   2024-01-31 
06:04:48.0 +
@@ -0,0 +1,2 @@
+libapr1t64: package-name-doesnt-match-sonames libapr-1-0
+libapr1t64: package-name-doesnt-match-sonames libapr1
diff -Nru apr-1.7.2/debian/libapr1t64.symbols 
apr-1.7.2/debian/libapr1t64.symbols
--- apr-1.7.2/debian/libapr1t64.symbols 1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.symbols 2024-01-31 06:04:48.0 +
@@ -0,0 +1,2 @@
+here for the purpose of tricking debhelper...bwahahahaha.
+

Bug#1061893: apr-util: NMU diff for 64-bit time_t transition

2024-01-30 Thread Steve Langasek 
Source: apr-util
Followup-For: Bug #1061893

Apologies, an oversight in the conversion script caused us to fail to
update strict versioned dependencies on the previous package name.
Please find attached a fixed patch.

This has also now been uploaded to experimental.
diff -Nru apr-util-1.6.3/debian/changelog apr-util-1.6.3/debian/changelog
--- apr-util-1.6.3/debian/changelog 2023-02-03 20:15:18.0 +
+++ apr-util-1.6.3/debian/changelog 2024-01-31 05:58:19.0 +
@@ -1,3 +1,11 @@
+apr-util (1.6.3-1.1~exp2) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+  * Fix uninstallable packages from the previous upload.
+
+ -- Steve Langasek   Wed, 31 Jan 2024 05:58:19 +
+
 apr-util (1.6.3-1) unstable; urgency=medium
 
   [ Stefan Fritsch ]
diff -Nru apr-util-1.6.3/debian/control apr-util-1.6.3/debian/control
--- apr-util-1.6.3/debian/control   2023-02-02 22:42:28.0 +
+++ apr-util-1.6.3/debian/control   2024-01-31 05:58:19.0 +
@@ -22,7 +22,10 @@
 Vcs-Git: https://salsa.debian.org/apache-team/apr-util.git
 Homepage: https://apr.apache.org/
 
-Package: libaprutil1
+Package: libaprutil1t64
+Provides: ${t64:Provides}
+Replaces: libaprutil1
+Breaks: libaprutil1 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends},
@@ -39,7 +42,7 @@
 Package: libaprutil1-ldap
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -56,7 +59,7 @@
 Package: libaprutil1-dbd-mysql
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -73,7 +76,7 @@
 Package: libaprutil1-dbd-sqlite3
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -90,7 +93,7 @@
 Package: libaprutil1-dbd-odbc
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -107,7 +110,7 @@
 Package: libaprutil1-dbd-pgsql
 Architecture: any
 Multi-Arch: same
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  ${shlibs:Depends},
  ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -124,7 +127,7 @@
 Package: libaprutil1-dev
 Architecture: any
 Section: libdevel
-Depends: libaprutil1 (= ${binary:Version}),
+Depends: libaprutil1t64 (= ${binary:Version}),
  libldap2-dev,
  libexpat1-dev,
  libapr1-dev,
diff -Nru apr-util-1.6.3/debian/libaprutil1.docs 
apr-util-1.6.3/debian/libaprutil1.docs
--- apr-util-1.6.3/debian/libaprutil1.docs  2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.docs  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-NOTICE
diff -Nru apr-util-1.6.3/debian/libaprutil1.install 
apr-util-1.6.3/debian/libaprutil1.install
--- apr-util-1.6.3/debian/libaprutil1.install   2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.install   1970-01-01 00:00:00.0 
+
@@ -1,3 +0,0 @@
-usr/lib/*/libaprutil-1.so.*
-usr/lib/*/apr-util-1/apr_dbm*.so*
-usr/lib/*/apr-util-1/apr_crypt*.so*
diff -Nru apr-util-1.6.3/debian/libaprutil1.lintian-overrides 
apr-util-1.6.3/debian/libaprutil1.lintian-overrides
--- apr-util-1.6.3/debian/libaprutil1.lintian-overrides 2023-02-01 
21:35:51.0 +
+++ apr-util-1.6.3/debian/libaprutil1.lintian-overrides 1970-01-01 
00:00:00.0 +
@@ -1,2 +0,0 @@
-libaprutil1: symbols-declares-dependency-on-other-package
-libaprutil1: package-name-doesnt-match-sonames libaprutil-1-0
diff -Nru apr-util-1.6.3/debian/libaprutil1.symbols 
apr-util-1.6.3/debian/libaprutil1.symbols
--- apr-util-1.6.3/debian/libaprutil1.symbols   2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.symbols   1970-01-01 00:00:00.0 
+
@@ -1,357 +0,0 @@
-libaprutil-1.so.0 libaprutil1 #MINVER#
-| libaprutil1-ldap , libaprutil1 #MINVER#
-| 
libaprutil1-dbd-sqlite3|libaprutil1-dbd-mysql|libaprutil1-dbd-odbc|libaprutil1-dbd-pgsql|libaprutil1-dbd-freetds
 , libaprutil1 #MINVER#
- _crypt_blowfish_rn@Base 1.5.0
- _crypt_gensalt_blowfish_rn@Base 1.5.0
- _crypt_output_magic@Base 1.5.0
- apr__memzero_explicit@Base 1.6.0
- apr_base64_decode@Base 1.2.7+dfsg
- apr_base64_decode_binary@Base 1.2.7+dfsg
- apr_base64_decode_len@Base 1.2.7+dfsg
- apr_base64_encode@Base 1.2.7+dfsg
- apr_base64_encode_binary@Base 1.2.7+dfsg
- apr_base64_encode_len@Base 1.2.7+dfsg
- apr_bcrypt_encode@Base

Bug#1061894: apr: NMU diff for 64-bit time_t transition

2024-01-29 Thread Steve Langasek 
Source: apr
Version: 1.7.2-3
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
apr as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for apr
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru apr-1.7.2/debian/changelog apr-1.7.2/debian/changelog
--- apr-1.7.2/debian/changelog  2023-02-26 20:51:24.0 +
+++ apr-1.7.2/debian/changelog  2024-01-30 00:57:09.0 +
@@ -1,3 +1,10 @@
+apr (1.7.2-3.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Tue, 30 Jan 2024 00:57:09 +
+
 apr (1.7.2-3) unstable; urgency=medium
 
   * Add more fixes for atomics from upstream, in particular for
diff -Nru apr-1.7.2/debian/control apr-1.7.2/debian/control
--- apr-1.7.2/debian/control2023-02-03 16:18:13.0 +
+++ apr-1.7.2/debian/control2024-01-30 00:57:09.0 +
@@ -19,7 +19,10 @@
 Homepage: https://apr.apache.org/
 Rules-Requires-Root: no
 
-Package: libapr1
+Package: libapr1t64
+Provides: ${t64:Provides}
+Replaces: libapr1
+Breaks: libapr1 (<< ${source:Version})
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Pre-Depends: ${misc:Pre-Depends}
diff -Nru apr-1.7.2/debian/libapr1.docs apr-1.7.2/debian/libapr1.docs
--- apr-1.7.2/debian/libapr1.docs   2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.docs   1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-NOTICE
diff -Nru apr-1.7.2/debian/libapr1.install apr-1.7.2/debian/libapr1.install
--- apr-1.7.2/debian/libapr1.install2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.install1970-01-01 00:00:00.0 +
@@ -1 +0,0 @@
-usr/lib/*/libapr-1.so.*
diff -Nru apr-1.7.2/debian/libapr1.lintian-overrides 
apr-1.7.2/debian/libapr1.lintian-overrides
--- apr-1.7.2/debian/libapr1.lintian-overrides  2023-02-02 21:18:42.0 
+
+++ apr-1.7.2/debian/libapr1.lintian-overrides  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-libapr1: package-name-doesnt-match-sonames libapr-1-0
diff -Nru apr-1.7.2/debian/libapr1.symbols apr-1.7.2/debian/libapr1.symbols
--- apr-1.7.2/debian/libapr1.symbols2023-02-02 21:18:42.0 +
+++ apr-1.7.2/debian/libapr1.symbols1970-01-01 00:00:00.0 +
@@ -1,2 +0,0 @@
-here for the purpose of tricking debhelper...bwahahahaha.
-
diff -Nru apr-1.7.2/debian/libapr1t64.docs apr-1.7.2/debian/libapr1t64.docs
--- apr-1.7.2/debian/libapr1t64.docs1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.docs2023-02-02 21:18:42.0 +
@@ -0,0 +1 @@
+NOTICE
diff -Nru apr-1.7.2/debian/libapr1t64.install 
apr-1.7.2/debian/libapr1t64.install
--- apr-1.7.2/debian/libapr1t64.install 1970-01-01 00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.install 2023-02-02 21:18:42.0 +
@@ -0,0 +1 @@
+usr/lib/*/libapr-1.so.*
diff -Nru apr-1.7.2/debian/libapr1t64.lintian-overrides 
apr-1.7.2/debian/libapr1t64.lintian-overrides
--- apr-1.7.2/debian/libapr1t64.lintian-overrides   1970-01-01 
00:00:00.0 +
+++ apr-1.7.2/debian/libapr1t64.lintian-overrides   2024

Bug#1061893: apr-util: NMU diff for 64-bit time_t transition

2024-01-29 Thread Steve Langasek 
Source: apr-util
Version: 1.6.3-1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
apr-util as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for apr-util
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru apr-util-1.6.3/debian/changelog apr-util-1.6.3/debian/changelog
--- apr-util-1.6.3/debian/changelog 2023-02-03 20:15:18.0 +
+++ apr-util-1.6.3/debian/changelog 2024-01-30 00:55:31.0 +
@@ -1,3 +1,10 @@
+apr-util (1.6.3-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Tue, 30 Jan 2024 00:55:31 +
+
 apr-util (1.6.3-1) unstable; urgency=medium
 
   [ Stefan Fritsch ]
diff -Nru apr-util-1.6.3/debian/control apr-util-1.6.3/debian/control
--- apr-util-1.6.3/debian/control   2023-02-02 22:42:28.0 +
+++ apr-util-1.6.3/debian/control   2024-01-30 00:55:31.0 +
@@ -22,7 +22,10 @@
 Vcs-Git: https://salsa.debian.org/apache-team/apr-util.git
 Homepage: https://apr.apache.org/
 
-Package: libaprutil1
+Package: libaprutil1t64
+Provides: ${t64:Provides}
+Replaces: libaprutil1
+Breaks: libaprutil1 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${shlibs:Depends},
diff -Nru apr-util-1.6.3/debian/libaprutil1.docs 
apr-util-1.6.3/debian/libaprutil1.docs
--- apr-util-1.6.3/debian/libaprutil1.docs  2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.docs  1970-01-01 00:00:00.0 
+
@@ -1 +0,0 @@
-NOTICE
diff -Nru apr-util-1.6.3/debian/libaprutil1.install 
apr-util-1.6.3/debian/libaprutil1.install
--- apr-util-1.6.3/debian/libaprutil1.install   2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.install   1970-01-01 00:00:00.0 
+
@@ -1,3 +0,0 @@
-usr/lib/*/libaprutil-1.so.*
-usr/lib/*/apr-util-1/apr_dbm*.so*
-usr/lib/*/apr-util-1/apr_crypt*.so*
diff -Nru apr-util-1.6.3/debian/libaprutil1.lintian-overrides 
apr-util-1.6.3/debian/libaprutil1.lintian-overrides
--- apr-util-1.6.3/debian/libaprutil1.lintian-overrides 2023-02-01 
21:35:51.0 +
+++ apr-util-1.6.3/debian/libaprutil1.lintian-overrides 1970-01-01 
00:00:00.0 +
@@ -1,2 +0,0 @@
-libaprutil1: symbols-declares-dependency-on-other-package
-libaprutil1: package-name-doesnt-match-sonames libaprutil-1-0
diff -Nru apr-util-1.6.3/debian/libaprutil1.symbols 
apr-util-1.6.3/debian/libaprutil1.symbols
--- apr-util-1.6.3/debian/libaprutil1.symbols   2023-02-01 21:35:51.0 
+
+++ apr-util-1.6.3/debian/libaprutil1.symbols   1970-01-01 00:00:00.0 
+
@@ -1,357 +0,0 @@
-libaprutil-1.so.0 libaprutil1 #MINVER#
-| libaprutil1-ldap , libaprutil1 #MINVER#
-| 
libaprutil1-dbd-sqlite3|libaprutil1-dbd-mysql|libaprutil1-dbd-odbc|libaprutil1-dbd-pgsql|libaprutil1-dbd-freetds
 , libaprutil1 #MINVER#
- _crypt_blowfish_rn@Base 1.5.0
- _crypt_gensalt_blowfish_rn@Base 1.5.0
- _crypt_output_magic@Base 1.5.0
- apr__memzero_explicit@Base 1.6.0
- apr_base64_decode@Base 1.2.7+dfsg
- apr_base64_decode_binary@Base 1.2.7+dfsg
- apr_base64_decode_len@Base 1.2.

Bug#666260: apr-util: Please drop obsolete versioned build-dependency on binutils

2012-03-29 Thread Steve Langasek 
Package: apr-util
Version: 1.4.1-1.1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Hi folks,

When doing tests to cross-build the Ubuntu archive, I found that the
apr-util package has a versioned build-dependency on a very old version of
binutils - one satisfied by lenny and later.  This versioned
build-dependency confuses cross-architecture dependency resolution.  I think
it's best if it's just dropped from the package.

Please find attached a patch to do this.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
=== modified file 'debian/control'
--- debian/control	2012-01-08 20:44:17 +
+++ debian/control	2012-03-30 03:35:04 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Apache Maintainers debian-apache@lists.debian.org
 Uploaders: Stefan Fritsch s...@debian.org, Peter Samuelson pe...@p12n.org
-Build-Depends: debhelper ( 6.0.7~), autoconf, autotools-dev, mawk, libldap2-dev, libexpat1-dev, libdb-dev, libpcre3-dev, dpatch (= 1.11), binutils (= 2.14.90.0.7), libapr1-dev (= 1.3.2), libsqlite3-dev, libpq-dev, python, libmysqlclient-dev, freetds-dev, unixodbc-dev, doxygen, libssl-dev
+Build-Depends: debhelper ( 6.0.7~), autoconf, autotools-dev, mawk, libldap2-dev, libexpat1-dev, libdb-dev, libpcre3-dev, dpatch (= 1.11), libapr1-dev (= 1.3.2), libsqlite3-dev, libpq-dev, python, libmysqlclient-dev, freetds-dev, unixodbc-dev, doxygen, libssl-dev
 Standards-Version: 3.9.2
 Vcs-Browser: http://svn.debian.org/wsvn/pkg-apache/trunk/apr-util
 Vcs-svn: svn://svn.debian.org/pkg-apache/trunk/apr-util

Bug#619179: apr-util: please wipe out dependency_libs from .la files (Policy 10.2)

2011-03-21 Thread Steve Langasek 
Package: apr-util
Version: 1.3.9+dfsg-5
Severity: normal
Tags: patch
User: vor...@debian.org
Usertags: multiarch

Hi guys,

The attached patch has just been applied to the Ubuntu apr-util package, to
null out the dependency_libs field in the libtool .la files being shipped in
the -dev package.  This is generally a good idea because it avoids causing
consumers of your library to require other .la files listed here to be
available at build time when they're not actually needed (i.e., in the
dynamic linking common case).  It's specifically a good idea right now
because multiarch is imminent, and that means the .la files referenced here
are going to *move* soon, causing build failures for anything using libtool
to build against apr-util.  As long as apr-util is going to need a rebuild
to fix up the invalid .la references, it would be nice to get rid of them
altogether.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
=== modified file 'debian/rules'
--- debian/rules2011-03-16 15:40:01 +
+++ debian/rules2011-03-21 20:07:15 +
@@ -105,6 +105,9 @@
dh_installdirs -a
 
$(MAKE) install DESTDIR=$(CURDIR)/debian/tmp
+   for file in debian/tmp/usr/lib/*.la); do \
+   sed -i /dependency_libs/ s/'.*'/''/ $$file ; \
+   done
 
 binary-indep: build install

Bug#619179: apr-util: please wipe out dependency_libs from .la files (Policy 10.2)

2011-03-21 Thread Steve Langasek 
On Mon, Mar 21, 2011 at 10:00:37PM +0100, Stefan Fritsch wrote:
 version: 1.3.10+dfsg-1

 On Monday 21 March 2011, Steve Langasek wrote:
  The attached patch has just been applied to the Ubuntu apr-util
  package, to null out the dependency_libs field in the libtool .la
  files being shipped in the -dev package.  This is generally a good

 AFAICS this is already fixed in 1.3.10+dfsg-1. Please reopen if I have 
 missed something.

Ah ok, thanks for the quick response!  The patch was bad anyway, had a
syntax error I didn't catch before submitting.  So it's all good. :)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#464930: ssl-cert: please use 'hostname -f' in /usr/sbin/make-ssl-cert

2008-02-09 Thread Steve Langasek 
Package: ssl-cert
Version: 1.0.14
Severity: important
Tags: patch
User: [EMAIL PROTECTED]
Usertags: ubuntu-patch origin-ubuntu hardy

make-ssl-cert currently uses 'hostname' to set the cn of the default snake
oil certificate.  This results in a cn set to a relative hostname, not an
FQDN (which would be given by 'hostname -f').  This yields a suboptimal
certificate: OpenLDAP, for instance, will map 'localhost' to the fqdn when
verifying certificates, which will properly fail to match the relative
hostname in most cases, and there's also the issue that having a certificate
that only works with the relative hostname ensures that users will only
/connect/ using the relative hostname, opening a subtle attack vector in the
form of hostname collisions in the domain search list.

The attached patch implements this change in the most trivial fashion.
However, it's probably also reasonable to have the unqualified hostname as
an alternative name in the certificate for convenience; in that case, it
makes sense to add a subjectAlternativeName to the snakeoil cert as well,
including the value of $(hostname).  If you prefer, I can look at
implementing this.

Incidentally, is this package actually maintained today?  I notice that the
maintainer is listed as Debian Apache Maintainers, and that none of the
uploaders listed have been active in Apache maintenance for some time...

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]
diff -Nru ssl-cert-1.0.14/debian/changelog ssl-cert-1.0.14/debian/changelog
--- ssl-cert-1.0.14/debian/changelog	2007-02-02 22:47:27.0 -0800
+++ ssl-cert-1.0.14/debian/changelog	2008-02-09 14:15:27.0 -0800
@@ -1,3 +1,13 @@
+ssl-cert (1.0.14-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Use 'hostname -f' for the snakeoil CN instead of 'hostname', since
+relative hostnames are subject to namespace collisions that could be
+exploited (and also because OpenLDAP doesn't care for them when
+connecting to localhost).
+
+ -- Steve Langasek [EMAIL PROTECTED]  Sat, 09 Feb 2008 22:13:25 +
+
 ssl-cert (1.0.14) unstable; urgency=low
 
   * Non-maintainer upload to fix pending l10n issues.
diff -Nru /tmp/jDzpFqLCPH/ssl-cert-1.0.14/make-ssl-cert /tmp/rrqcQpBL77/ssl-cert-1.0.14/make-ssl-cert
--- ssl-cert-1.0.14/make-ssl-cert	2006-05-18 05:02:20.0 -0700
+++ ssl-cert-1.0.14/make-ssl-cert	2008-02-09 14:15:45.0 -0800
@@ -56,7 +56,7 @@
  LocalityName=Everywhere
  OrganisationName=OCOSA
  OUName=Office for Complication of Otherwise Simple Affairs
- HostName=$(hostname)
+ HostName=$(hostname -f)
  Email=[EMAIL PROTECTED]
 }

Bug#397886: apache2.2-common: non wanted behaviour during upgrade: charset MUST not be created without user consent

2006-11-10 Thread Steve Langasek 
On Fri, Nov 10, 2006 at 05:52:32PM +0100, Steinar H. Gunderson wrote:

 Anyhow, looking at the changelog, this option is supposed only to be enabled
 for new installations, and the logic in the postinst seems correct. Are you
 really upgrading, or is this a new installation?

It's a new install of the apache2.2-common package, which is a rename of
apache2-common.  dpkg can't detect such package name changes as upgrades.

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


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

Bug#397310: followup

2006-11-09 Thread Steve Langasek 
On Thu, Nov 09, 2006 at 05:47:46PM +0100, [EMAIL PROTECTED] wrote:
 authentication with plain file works, so the culprit seems to be the pam
 module.

You're probably experiencing a different problem than that initially
reported here, i.e., bug #394097 in libapache2-mod-auth-pam.

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


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

Bug#397539: apache2-mpm-prefork: apache2 no longer works after upgrade (Invalid command 'DAVLockDB')

2006-11-08 Thread Steve Langasek 
severity 397539 important
thanks

On Wed, Nov 08, 2006 at 08:56:06AM -0600, Peter Samuelson wrote:

 [Steve Langasek]
   Forcing reload of web server (apache2)...Syntax error on line 1 of 
   /etc/apache2/mods-enabled/dav.conf:
   Invalid command 'DAVLockDB', perhaps misspelled or defined by a module 
   not included in the server configuration
failed!

  Alas, I can confirm this; a2enmod dav gives me this error with the
  dav.conf and dav.load shipped with apache2.2-common.

 I don't get it - no dav.conf is shipped with the apache2.2-common I've
 got.  I also see no evidence that dav.conf has ever existed in the svn
 repository.

Hmm, I have one on my system, and I didn't put it there.  I see now that
apache2.2-common ships dav.load but *not* dav.conf; still, something in the
history of this package created dav.conf automatically for me, and it's
broken.

apache2 (2.0.47-2) unstable; urgency=low

  * Move dav.conf to dav_fs.conf (Closes: #201530) 
  * Fix the manual, and only ship it once. (Closes: #201648)
  * Enable SymLinksIfOwnerMatch for cgi-bin (Closes: #200829)

 -- Thom May [EMAIL PROTECTED]  Wed, 16 Jul 2003 10:24:28 +0100

This is the first mention of dav.conf I find in the changelog -- and that
predates sarge.  It's possible I've had the orphaned file on my system due
to handling that far back (and Vincent has as well), and the file just
recently began to be a problem due to changes in apache2.2-common.

Given that our only known explanation for this problem, then, involves
unreleased packages (sarge didn't ship this file and woody didn't include
apache2), this bug is not release-critical.  I leave it to the maintainers'
discretion to determine whether the bug should be fixed or closed.

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


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

Bug#397539: apache2-mpm-prefork: apache2 no longer works after upgrade (Invalid command 'DAVLockDB')

2006-11-07 Thread Steve Langasek 
On Wed, Nov 08, 2006 at 02:19:21AM +0100, Vincent Lefevre wrote:
 Package: apache2-mpm-prefork
 Version: 2.2.3-3
 Severity: grave
 Justification: renders package unusable

 Aftr the upgrade of Apache2, I get the error:

 Forcing reload of web server (apache2)...Syntax error on line 1 of 
 /etc/apache2/mods-enabled/dav.conf:
 Invalid command 'DAVLockDB', perhaps misspelled or defined by a module not 
 included in the server configuration
  failed!

Alas, I can confirm this; a2enmod dav gives me this error with the dav.conf
and dav.load shipped with apache2.2-common.  And a strings
/usr/lib/apache2/modules/mod_dav.so shows no mention of this DAVLockDB
command; it appears to be defined only by mod_dav_fs.so, so presumably this
command needs to be moved to dav_fs.conf.

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


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

Bug#392058: apache2.2-common: apache fails to start

2006-10-10 Thread Steve Langasek 
On Tue, Oct 10, 2006 at 10:47:27AM +1300, Ian McDonald wrote:
 Starting web server (apache2)...apache2: Syntax error on line 185 of
 /etc/apache2/apache2.conf: Syntax error on line 1 of
 /etc/apache2/mods-enabled/php5.load: API module structure `php5_module'
 in file /usr/lib/apache2/modules/libphp5.so is garbled - perhaps this is
 not an Apache module DSO?
  failed!
   invoke-rc.d: initscript apache2, action start failed.

This is because you have installed the one version of libapache2-mod-php5
which apache2.2-common does not conflict with, that was uploaded against the
wrong ABI.  The conflict needs to be updated, but this is not
release-critical.

 When I comment these out it still fails:

   Starting web server (apache2)...Syntax error on line 141 of
   /etc/apache2/apache2.conf:
   Invalid command 'Order', perhaps misspelled or defined by a module not
   included in the server configuration
failed!

 This section of the file is:

 Files ~ ^\.ht
 Order allow,deny
 Deny from all
 /Files

 and then I comment and it fails:

Starting web server (apache2)...Syntax error on line 142 of
/etc/apache2/apache2.conf:
Invalid command 'Deny', perhaps misspelled or defined by a module not
included in the server configuration
 failed!

 and then I gave up.

I'm not sure what the root cause of this is, but it looks like mod_access
(or the apache2 equivalent?) is no longer being compiled into the binary as
it was in previous versions.  That might warrant an RC severity on its own..

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


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

Bug#390823: apache2-common cannot be purged.

2006-10-05 Thread Steve Langasek 
On Thu, Oct 05, 2006 at 09:11:04AM -0600, Steve Langasek wrote:
 So it's my recommendation to downgrade and wontfix this bug, since there's
 no way to fix apache2-common's postrm script after the fact without
 introducing a dummy package that re-breaks our dependency logic.

Oh, alternatively, apache2.2-common's postinst script could have as its last
line:

   rm -f /var/lib/dpkg/info/apache2-common.postrm

Since apache2.2-common's conflict with apache2-common ensures that the
package is at least in state removed before this postinst is run.

Yes, release management has clearly scrambled my wits.

:-)

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


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

Bug#390823: apache2-common cannot be purged.

2006-10-05 Thread Steve Langasek 
On Tue, Oct 03, 2006 at 11:09:06AM +0200, Pierre Habouzit wrote:
   it should have been made an empty package, without maintainer scripts,
 so that it could be purged, as it's superseeded with apache2.2-common.

Totally not an option.  The entire justification for renaming apache2-common
to apache2.2-common is to force the upgrade or removal of apache2 module
packages which depend on apache2-common and are built for a previous ABI. If
apache2-common continued to exist and be installable, it would need to
conflict with all the old versions of the apache2 modules, and it should
then be a real package again instead of a dummy package, reverting the
rename to apache2.2-common.

But I don't think that's actually a good idea; large numbers of versioned
conflicts are bad for apt, and it's hard to get such versioned conflicts
right when a simple rebuild (binNMU) of a package invalidates the version
assumptions in either direction.

   [madcoder mad] LC_ALL=C sudo dpkg --purge apache2-common
 (Reading database ... 142646 files and directories currently installed.)
 Removing apache2-common ...
   Purging configuration files for apache2-common ...
   find: /etc/apache2: Permission denied
 update-rc.d: /etc/init.d/apache2 exists during rc.d purge (use -f to
 force)
   dpkg: error processing apache2-common (--purge):
  subprocess post-removal script returned error exit status 1
 Errors were encountered while processing:
  apache2-common

As for purging apache2-common, the obvious problem is that purging
apache2-common is going to remove config files that are now shared with
apache2.2-common, and that's a Bad Thing.  It is not, however, unique; I
have seen other upgrade scenarios before where config files changed owners,
no dummy package was possible (because the package name change is
deliberate, representing an API/ABI change, just like this one), and purging
therefore would have a detrimental effect on the system.  I don't think such
bugs should be treated as RC, irritating though they are, because it's not
really common practice for users to purge removed packages after upgrade
anyway.

So it's my recommendation to downgrade and wontfix this bug, since there's
no way to fix apache2-common's postrm script after the fact without
introducing a dummy package that re-breaks our dependency logic.  If people
feel strongly about purging apache2-common, they can always rm
/var/lib/dpkg/info/apache2-common.postrm by hand, which is also irritating
but not that rare in the history of Debian either. :-P

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


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

Bug#391094: packaging errors remove old apache2 but prevent install of apache2.2

2006-10-05 Thread Steve Langasek 
On Thu, Oct 05, 2006 at 09:36:29AM +0200, David Paleino wrote:
 Hi Moshe,
 it's not that serious problem.
 You can solve by simply doing a:

 # dpkg --force-overwrite -i
 /var/cache/apt/archives/apache2.2-common_2.2.3-1_i386.deb

Which can break your system in all kinds of other subtle ways...

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


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

Bug#390893: apache2-common pre-removal script error (undefined symbol: apr_get_userid)

2006-10-03 Thread Steve Langasek 
reassign 390893 apache2
found 390893 2.2.3-1
thanks

On Tue, Oct 03, 2006 at 04:21:02PM +0200, Tom wrote:
 Removing apache2-common ...
 Stopping apache 2.0 web server...apache2:
Syntax error on line 116 of /etc/apache2/apache2.conf:
Syntax error on line 1 of /etc/apache2/mods-enabled/userdir.load:
Cannot load /usr/lib/apache2/modules/mod_userdir.so into server:
/usr/lib/apache2/modules/mod_userdir.so: undefined symbol: apr_get_userid
  failed!
 invoke-rc.d: initscript apache2, action stop failed.
 dpkg: error processing apache2-common (--remove):
  subprocess pre-removal script returned error exit status 1
 Errors were encountered while processing:
  apache2-common
 E: Sub-process /usr/bin/dpkg returned an error code (1)

The bug is really in the mpm packages, which are allowed (by the package
relationships) to be unpacked before apache2-common's removal, thus breaking
apache2-common's prerm script due to the ABI mismatch.

I think a Pre-Depends on apache2.2-common is going to be needed here to
preserve the necessary unpack order.  In any event, it can't be fixed in
apache2-common, since that's the package that's been removed. :)

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


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

Bug#358543: apache: fails to install

2006-03-22 Thread Steve Langasek 
severity 358543 important
tags 358543 unreproducible moreinfo
thanks

On Wed, Mar 22, 2006 at 07:20:51PM -0800, Nathan Paul Simons wrote:
 Package: apache
 Severity: grave
 Justification: renders package unusable

 Upon install of apache, I get the following error message:

 dpkg: error processing apache (--configure):
  subprocess post-installation script returned error exit status 1
 Errors were encountered while processing:
  apache
 E: Sub-process /usr/bin/dpkg returned an error code (1)

No one else seems to be having this problem.  What version are you trying to
install?

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


signature.asc
Description: Digital signature

Bug#344481: Mysterious crash in php4-rrdtool

2005-12-22 Thread Steve Langasek 
On Fri, Dec 23, 2005 at 02:44:21AM +0100, Artur R. Czechowski wrote:
 On Thu, Dec 22, 2005 at 04:45:25PM -0800, Steve Langasek wrote:
  On Fri, Dec 23, 2005 at 01:09:31AM +0100, Artur R. Czechowski wrote:
   The rrd_graph_options() gets a string with parameters. The begin if this
   string is (at least in my case, but this is common value in rrdtools):
   --start -2d
   The rrd_graph_options calls getopt_long to split parameters into tokens.
   You can see the code in rrdtool's sources, file rrd_graph.c, line 2965.
   getopt_long reckognises the --start parameter correctly and, according to
   struct option returns opt as s. But, for some strange reasons, it sets
   optarg for NULL.
  Erm, don't you need to write --start=-2d if you want an optarg that begins
  with a hyphen?
 No. The s: in optstring and 1 as a second value in {start,1,0,'s'} always
 makes next token a parameter.

Ok.

  Anyway, I don't see where any of the other packages you've mentioned are
  providing a broken implementation of getopt_long.  Shouldn't you check where
  this broken function is coming from, and file the bug there?
 Wish I know how to do it. Simple grep in sources gives no results.
 That's why it is so mysterious to me and I am asking for help at wider
 auditorium.

Break on rrd_graph_options, step into getopt_long, run bt to see what lib it
says it's in.

 Because only apache/php4(module) is a problematic combination I suspect
 an apache. If it is sufficient for you I have no objections against
 reassigning this bug to apache package.

I'd rather see some analysis to show where the bug actually belongs instead
of guessing and reassigning.

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


signature.asc
Description: Digital signature

Bug#336651: libapr0: Need to compile --with-devrandom=/dev/urandom

2005-10-31 Thread Steve Langasek 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

severity 336651 normal
thanks

On Mon, Oct 31, 2005 at 12:44:06PM -0600, Mark A. Hershberger wrote:
 Package: libapr0
 Version: 2.0.54-5
 Severity: grave

 libapr should be compiled using /dev/urandom so that tools like svn
 can actually function on servers where there is less entropy available.

 http://svn.haxx.se/users/archive-2005-08/0818.shtml

This does not meet the definition of a grave bug.  It is quite likely that
it is not a bug at all -- /dev/urandom is *not* a proper replacement for
/dev/random when real entropy is needed, and the Debian packages should not
sacrifice security casually.

- -- 
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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDZwomKN6ufymYLloRAvgJAJ9kgqijeAzXxfsDMsn943EDH8PitACfYHu6
PTfSnhrLbI6XZbHbTTMCQdI=
=jTmr
-END PGP SIGNATURE-


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

Bug#335438: libsvncpp-dev and libapr0-dev cannot be installed together

2005-10-25 Thread Steve Langasek 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

reassign 335438 libsvn0-dev
severity 335438 important
thanks

On Mon, Oct 24, 2005 at 09:45:49PM +1000, Adam Conrad wrote:
 Matthias Klose wrote:

  Package: libsvncpp-dev,libapr0-dev
  Severity: serious

  that means, that pysvn's build-deps cannot be installed
  anymore. Please coordinate, if these these packages should depend on
  libdb4.2-dev or libdb4.3-dev.

 They should depend on libdb4.3-dev (and build against libdb4.3).  I'm
 committing changes to pkg-subversion right now to fix up libsvn0 and
 friends to switch over to db4.3... With any luck, we can rid our systems
 of db4.2 sometime in the next 6 months. :/

So this bug rightly belongs to libsvn0-dev, which is the package that has to
be changed.

Downgrading, though, because libsvn0-dev itself is perfectly installable in
spite of the collateral damage, and we want the current subversion package
to reach testing first for the imlib transition before uploads are made to
try to fix this.

- -- 
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/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDXg/bKN6ufymYLloRAl9bAJ0RCjPgMByo86Y3PCB4u7LlZGIufQCZAUvA
0ffPJ2yzYz++QiiV8tvHiRI=
=WbzH
-END PGP SIGNATURE-


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

Bug#335438: libsvncpp-dev and libapr0-dev cannot be installed together

2005-10-25 Thread Steve Langasek 
On Tue, Oct 25, 2005 at 02:40:31PM +0200, Matthias Klose wrote:

  reassign 335438 libsvn0-dev
  severity 335438 important
  thanks

  On Mon, Oct 24, 2005 at 09:45:49PM +1000, Adam Conrad wrote:
   Matthias Klose wrote:

Package: libsvncpp-dev,libapr0-dev
Severity: serious

that means, that pysvn's build-deps cannot be installed
anymore. Please coordinate, if these these packages should depend on
libdb4.2-dev or libdb4.3-dev.

   They should depend on libdb4.3-dev (and build against libdb4.3).  I'm
   committing changes to pkg-subversion right now to fix up libsvn0 and
   friends to switch over to db4.3... With any luck, we can rid our systems
   of db4.2 sometime in the next 6 months. :/

  So this bug rightly belongs to libsvn0-dev, which is the package that has to
  be changed.

 care to explain, what should be changed in this package?

It should be changed to libdb4.3?

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


signature.asc
Description: Digital signature

Bug#301819: apache2: FTBS on sarge

2005-03-28 Thread Steve Langasek 
tags 301819 unreproducible moreinfo
severity 301819 important
thanks

On Mon, Mar 28, 2005 at 05:26:36PM +0200, Peter Palfrader wrote:
 apache2 does not build from source on sarge (i386).

 It looks like the configures fail with

 | Configuring Apache Portable Runtime Utility library...
 |
 | checking for APR-util... reconfig
 | configuring package in srclib/apr-util now
 | configure: warning: CFLAGS= -pipe -I/usr/include/xmltok 
 -I/usr/include/openssl -Wall -O2: invalid host type
 | configure: warning: LDFLAGS=-ldl -lexpat -lcrypt -ldb-4.2: invalid host type
 | configure: error: can only configure for one host and one target at a time
 | configure failed for srclib/apr-util

I can't reproduce this here, using exactly the same versions of build-deps
as mentioned in your report.  Even linking /bin/sh to dash doesn't trigger
this bug.  Are there any other oddities that could be relevant here?  Are
you passing non-standard CFLAGS on the commandline?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Processed: Re: Bug#259211: apache segfault after upgrade from woody

2004-07-14 Thread Steve Langasek 
On Wed, Jul 14, 2004 at 08:44:54AM +0200, Fabio Massimo Di Nitto wrote:
 On Wed, 14 Jul 2004, GOTO Masanori wrote:
 
   Djoum this is a very old and known problem, the only known workaround to
   it is to enable libapache-mod-ssl, even if unconfigured. We are all
   waiting for the libc6 maintainer to fix this issue.
  
   Jeff please it's time to fix this issue. This bug has to stay RC since it
   breaks unreleated packages.
 
  What's problem?  What's bug do you say about?  We already added
  conflicts: old php.

 Both Jeff and Steve know all the details about it and they have been
 working on this problem. Please talk to them directly.

Er, Goto, http://sources.redhat.com/bugzilla/show_bug.cgi?id=77 lists you
as the responsible?

-- 
Steve Langasek
postmodern programmer

Re: Bug#205553: Backtrace php4-imap/apache SEGV

2004-02-01 Thread Steve Langasek 
On Mon, Feb 02, 2004 at 02:16:48AM +0100, Jeroen van Wolffelaar wrote:
 I have a stable reporduction case now in a chroot, and have succeed in
 getting backtraces out of it.

 It is with a recompiled libssl0.9.7, without the db_strip, to get a more
 useful one. As I don't know much about gdb, any hints on getting better
 backtraces would be appreciated (I now just gdb'd /usr/sbin/apache with
 -X -F)

 The problem is the starting point, mail_getquota. It's an internal
 function in PHP's imap module, used ONLY when the corresponding PHP
 functions are called. However, the SIGSEGV happens at startup, and in ny
 whole fscking chroot there is no single php script anywhere.

 So, it gets wrongly called? Then there must be a serious fuckup of
 symbols somewhere, or otherwise I really don't understand. It also
 states about a possible stack overwrite at the end of the bt, so there
 is an accidental buffer overflow somewhere? Or is this function called
 somehow on startup... that would be really wierd.

There seem to be two problems at work here: one, that in spite of having
recompiled libssl0.9.7, the function names listed appear to be fairly
useless (possibly because the lib was never built with -g in the first
place, so stripping the library or not doesn't make a difference), and
two, that the stack is a royal mess and appears to be at least partially
(if not wholly) corrupted.  For instance, it's a safe bet that
0x0001 and 0x0010 appearing on the stack indicates a bug.

This is pretty much in keeping with the other backtraces I've seen of
this bug, which is why (combined with other problems such as apache's
double-initialization startup and the fact that it's not reproducible on
my own systems) it's been so hard to pin down.

 In the case of the buffer overflow, I guess that stack trace is useless
 and just plain wrong?

I wouldn't trust any of the reported stack contents in this case as
indicating the actual source of the bug, no.

Regards,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Bug#230143: php4-imap - depends against apache modul, breaks cgi installs

2004-01-30 Thread Steve Langasek 
reassign 230143 apache
quit

On Fri, Jan 30, 2004 at 11:36:25PM +0100, Fabio Massimo Di Nitto wrote:

 First of all none of you have provide any reason why this should be an
 apache failure. If libapache-mod-ssl breaks why is that an apache bug?
 Investigate before reassigning like we have been doing hell a lot of time
 for php4 brokness.

If apache fails to install, that's an apache bug, not a php4-imap bug.

-- 
Steve Langasek
postmodern programmer



 On Fri, 30 Jan 2004, Steve Langasek wrote:
 
  reassign 230143 apache
  thanks
 
  On Thu, Jan 29, 2004 at 10:53:58AM +0100, Bastian Blank wrote:
   reopen 230143
   thanks
 
   On Wed, Jan 28, 2004 at 03:43:15PM -0600, Steve Langasek wrote:
 php4-imap depends against libapache-mod-ssl. this breaks cgi installs.
Bullshit.  It requires you to install libapache-mod-ssl and its
dependencies on cgi-using systems, but it does not *break* anything.
 
   libapache-mod-ssl depends against apache. the installation of apache
   breaks.
 
  If apache fails to install, that's an apache bug, not a php4-imap bug.


pgp1cwHOtHxGR.pgp
Description: PGP signature