Bug#992518: bullseye-pu: package edk2/2020.11-2
Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Fixes a security issue, CVE-2019-11098.
[ Impact ]
The builds we provide shouldn't be impacted by this vulnerability,
at least not as described by the researchers. However, there maybe
other implications - this is purely cautionary.
[ Tests ]
The built-in autopkgtests (actually the newer ones from unstable that are
more complete than the ones in bullseye).
$ ./debian/tests/shell.py
test_aavmf (__main__.BootToShellTest) ... ok
test_aavmf32 (__main__.BootToShellTest) ... ok
test_ovmf32_4m_secboot (__main__.BootToShellTest) ... ok
test_ovmf_4m (__main__.BootToShellTest) ... ok
test_ovmf_4m_ms (__main__.BootToShellTest) ... ok
test_ovmf_4m_secboot (__main__.BootToShellTest) ... ok
test_ovmf_ms (__main__.BootToShellTest) ... ok
test_ovmf_pc (__main__.BootToShellTest) ... ok
test_ovmf_q35 (__main__.BootToShellTest) ... ok
test_ovmf_secboot (__main__.BootToShellTest) ... ok
--
Ran 10 tests in 53.821s
OK
[ Risks ]
The most likely issue is that we introduce a regression that causes
some VMs to fail to boot.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
A cherry pick from upstream that avoids reading GDT from flash.
diff -Nru edk2-2020.11/debian/changelog edk2-2020.11/debian/changelog
--- edk2-2020.11/debian/changelog 2020-12-15 11:42:37.0 -0700
+++ edk2-2020.11/debian/changelog 2021-08-18 16:57:56.0 -0600
@@ -1,3 +1,9 @@
+edk2 (2020.11-2+deb11u1) bullseye; urgency=medium
+
+ * Address Boot Guard TOCTOU vulnerability (CVE-2019-11098) (Closes: #991495)
+
+ -- dann frazier Wed, 18 Aug 2021 16:57:56 -0600
+
edk2 (2020.11-2) unstable; urgency=medium
* autopkgtest: Add allow-stderr to Restrictions to fix failure.
diff -Nru edk2-2020.11/debian/patches/series edk2-2020.11/debian/patches/series
--- edk2-2020.11/debian/patches/series 2020-12-15 11:42:37.0 -0700
+++ edk2-2020.11/debian/patches/series 2021-08-18 16:57:56.0 -0600
@@ -3,3 +3,4 @@
ovmf-vars-generator-Pass-OEM-Strings-to-the-guest.patch
ovmf-vars-generator-ignore-qemu-warnings.patch
ovmf-vars-generator-no-defaults.patch
+UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
diff -Nru
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
---
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
1969-12-31 17:00:00.0 -0700
+++
edk2-2020.11/debian/patches/UefiCpuPkg-Move-MigrateGdt-from-DiscoverMemory-to-Te.patch
2021-08-18 16:57:56.0 -0600
@@ -0,0 +1,189 @@
+From f6ec1dd34fb6b9757b5ead465ee2ea20c182b0ac Mon Sep 17 00:00:00 2001
+From: Guomin Jiang
+Date: Wed, 13 Jan 2021 18:08:09 +0800
+Subject: [PATCH] UefiCpuPkg: Move MigrateGdt from DiscoverMemory to
+ TempRamDone. (CVE-2019-11098)
+
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1614
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3160
+
+The GDT still in flash with commit 60b12e69fb1c8c7180fdda92f008248b9ec83db1
+after TempRamDone
+
+So move the action to TempRamDone event to avoid reading GDT from flash.
+
+Signed-off-by: Guomin Jiang
+Cc: Eric Dong
+Cc: Ray Ni
+Cc: Laszlo Ersek
+Cc: Rahul Kumar
+Cc: Debkumar De
+Cc: Harry Han
+Cc: Catharine West
+Reviewed-by: Ray Ni
+
+Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1614
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=991495
+Origin: upstream,
https://github.com/tianocore/edk2/commit/f6ec1dd34fb6b9757b5ead465ee2ea20c182b0ac
+Last-Updated: 2021-07-26
+
+diff --git a/UefiCpuPkg/CpuMpPei/CpuMpPei.c b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+index 40729a09b9..3c1bad6470 100644
+--- a/UefiCpuPkg/CpuMpPei/CpuMpPei.c
b/UefiCpuPkg/CpuMpPei/CpuMpPei.c
+@@ -429,43 +429,6 @@ GetGdtr (
+ AsmReadGdtr ((IA32_DESCRIPTOR *)Buffer);
+ }
+
+-/**
+- Migrates the Global Descriptor Table (GDT) to permanent memory.
+-
+- @retval EFI_SUCCESS The GDT was migrated successfully.
+- @retval EFI_OUT_OF_RESOURCES The GDT could not be migrated due to lack
of available memory.
+-
+-**/
+-EFI_STATUS
+-MigrateGdt (
+- VOID
+- )
+-{
+- EFI_STATUS Status;
+- UINTN GdtBufferSize;
+- IA32_DESCRIPTOR Gdtr;
+- VOID*GdtBuffer;
+-
+- AsmReadGdtr ((IA32_DESCRIPTOR *) );
+- GdtBufferSize = sizeof (IA32_SEGMENT_DESCRIPTOR) -1 + Gdtr.Limit + 1;
+-
+- Status = PeiServicesAllocatePool (
+- GdtBufferSize,
+-
+- );
+- ASSERT (GdtBuffer != NULL);
+- if (EFI_ERROR (Status)) {
+-return EFI_OUT_OF_RESOURCES
Bug#991415: unblock: kdump-tools/1:1.6.8.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package kdump-tools [ Reason ] Addresses two bugs: [ Benjamin Drung ] * Fix broken status log messages when dumping w/ FTP (Closes: #991412). [ dann frazier ] * Add /var/lib/kdump to debian/kdump-tools.dirs to avoid errors creating the initial set of boot file symlinks (Closes: #991175). [ Impact ] The first can have a significant impact to users who are trying to setup FTP dumps because the output suggests the package is misconfigured even when it isn't. The second can cause a first boot service startup failure because the boot file symlinking process assumes /var/lib/kdump already exists. [ Tests ] I did a manual FTP dump test to verify the correct messages, as well as upgrade/remove/purge tests. [ Risks ] I consider both bug fixes to be trivial. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing unblock kdump-tools/1:1.6.8.4
Bug#986706: unblock: makedumpfile/1:1.6.8-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package makedumpfile
[ Reason ]
Adds necessary fixes for supporting current kernels.
[ Impact ]
makedumpfile will be unable to extract the dmesg from the 5.10 kernel,
and does not support 5.4 and newer kernels on arm64.
[ Tests ]
Forcing a crash dump in an x86 VM and verifying that the dmesg file
is produced and the crash utility is able to analyze the dump.
[ Risks ]
The biggest risk I can think of is that we may have broken support with
some earlier kernel version. But things do work with the kernel version
we're currently planning to release.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
N/A
unblock makedumpfile/1:1.6.8-4
diff -Nru makedumpfile-1.6.8/debian/changelog
makedumpfile-1.6.8/debian/changelog
--- makedumpfile-1.6.8/debian/changelog 2021-01-18 07:50:02.0 -0700
+++ makedumpfile-1.6.8/debian/changelog 2021-04-07 16:32:38.0 -0600
@@ -1,3 +1,13 @@
+makedumpfile (1:1.6.8-4) unstable; urgency=medium
+
+ [ Ioanna Alifieraki ]
+ * Fix failure of dmesg. creation on 5.10+ kernels.
+(Closes: #985896) (LP: #1921403).
+ * Fix makedumpfile failure on arm64 with 5.4 kernels.
+(Closes: #986594) (LP: #1879214)
+
+ -- dann frazier Wed, 07 Apr 2021 16:32:38 -0600
+
makedumpfile (1:1.6.8-3) unstable; urgency=medium
* Drop kdump-tools, which has been split into its own source package.
diff -Nru
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
---
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
1969-12-31 17:00:00.0 -0700
+++
makedumpfile-1.6.8/debian/patches/0002-PATCH-1-2-printk-add-support-for-lockless-ringbuffer.patch
2021-04-07 16:32:38.0 -0600
@@ -0,0 +1,587 @@
+From: John Ogness
+Date: Thu, 19 Nov 2020 02:41:21 +
+Subject: [PATCH 1/2] printk: add support for lockless ringbuffer
+
+* Required for kernel 5.10
+
+Linux 5.10 introduces a new lockless ringbuffer. The new ringbuffer
+is structured completely different to the previous iterations.
+Add support for retrieving the ringbuffer from debug information
+and/or using vmcoreinfo. The new ringbuffer is detected based on
+the availability of the "prb" symbol.
+
+Signed-off-by: John Ogness
+Signed-off-by: Kazuhito Hagio
+
+Origin: upstream,
https://github.com/makedumpfile/makedumpfile/commit/c617ec63339222f3a44d73e36677a9acc8954ccd
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985896
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1921403
+---
+ Makefile | 2 +-
+ dwarf_info.c | 36 +-
+ makedumpfile.c | 103 ++--
+ makedumpfile.h | 58
+ printk.c | 207 +
+ 5 files changed, 399 insertions(+), 7 deletions(-)
+ create mode 100644 printk.c
+
+diff --git a/Makefile b/Makefile
+index b12bbb0..6f4d0e0 100644
+--- a/Makefile
b/Makefile
+@@ -45,7 +45,7 @@ CFLAGS_ARCH += -m32
+ endif
+
+ SRC_BASE = makedumpfile.c makedumpfile.h diskdump_mod.h sadump_mod.h
sadump_info.h
+-SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c
cache.c tools.c
++SRC_PART = print_info.c dwarf_info.c elf_info.c erase_info.c sadump_info.c
cache.c tools.c printk.c
+ OBJ_PART=$(patsubst %.c,%.o,$(SRC_PART))
+ SRC_ARCH = arch/arm.c arch/arm64.c arch/x86.c arch/x86_64.c arch/ia64.c
arch/ppc64.c arch/s390x.c arch/ppc.c arch/sparc64.c
+ OBJ_ARCH=$(patsubst %.c,%.o,$(SRC_ARCH))
+diff --git a/dwarf_info.c b/dwarf_info.c
+index e42a9f5..543588b 100644
+--- a/dwarf_info.c
b/dwarf_info.c
+@@ -614,6 +614,7 @@ search_structure(Dwarf_Die *die, int *found)
+ {
+ int tag;
+ const char *name;
++ Dwarf_Die die_type;
+
+ /*
+* If we get to here then we don't have any more
+@@ -622,9 +623,31 @@ search_structure(Dwarf_Die *die, int *found)
+ do {
+ tag = dwarf_tag(die);
+ name = dwarf_diename(die);
+- if ((tag != DW_TAG_structure_type) || (!name)
+- || strcmp(name, dwarf_info.struct_name))
++ if ((!name) || strcmp(name, dwarf_info.struct_name))
++ continue;
++
++ if (tag == DW_TAG_typedef) {
++ if (!get_die_type(die, _type)) {
++ ERRMSG("Can't get CU die of DW_AT_type.\n");
++ break;
++ }
++
++ /* Resolve typedefs of typedefs. */
++ while ((tag = dwarf_tag(_type)) == DW_TAG_typedef) {
++ if
Bug#985788: unblock: kdump-tools/1:1.6.8.3
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package kdump-tools
[ Reason ]
It contains a single bug fix that fixes a regression which caused kdump-tools
to fail to collect kernel dump files in the common case (the files were
created, but just contained an error message).
[ Impact ]
Data loss - a kernel crash dump will fail to be collected and that
data will be gone after automated reboot.
[ Tests ]
A manual crash dump generation/validation.
[ Risks ]
The code fix is trivial.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
N/A
unblock kdump-tools/1:1.6.8.3
diff -Nru kdump-tools-1.6.8.2/debian/changelog
kdump-tools-1.6.8.3/debian/changelog
--- kdump-tools-1.6.8.2/debian/changelog2021-02-01 13:35:59.0
-0700
+++ kdump-tools-1.6.8.3/debian/changelog2021-03-22 21:39:59.0
-0600
@@ -1,3 +1,10 @@
+kdump-tools (1:1.6.8.3) unstable; urgency=medium
+
+ * kdump-config: Fix storage of local/NFS dump files
+(Closes: #985716) (LP: #1920759).
+
+ -- dann frazier Mon, 22 Mar 2021 21:39:59 -0600
+
kdump-tools (1:1.6.8.2) unstable; urgency=medium
* debian/control: Add Vcs-* tags.
diff -Nru kdump-tools-1.6.8.2/debian/kdump-config.in
kdump-tools-1.6.8.3/debian/kdump-config.in
--- kdump-tools-1.6.8.2/debian/kdump-config.in 2021-02-01 13:35:59.0
-0700
+++ kdump-tools-1.6.8.3/debian/kdump-config.in 2021-03-22 21:39:59.0
-0600
@@ -53,7 +53,10 @@
NFS_RETRANS=${NFS_RETRANS:=3}
NFS_MOUNT_RETRY=${NFS_MOUNT_RETRY:=4}
SSH_KDUMP_RETRY=${SSH_KDUMP_RETRY:=16}
-MAKEDUMP_ARGS=${MAKEDUMP_ARGS:="-c -d 31"}
+MAKEDUMP_ARGS=${MAKEDUMP_ARGS:="-F -c -d 31"}
+# Add '-F' [flatten] to MAKEDUMP_ARGS, if not there:
+[ "${MAKEDUMP_ARGS#-F*}" != "${MAKEDUMP_ARGS}" ] ||
MAKEDUMP_ARGS="${MAKEDUMP_ARGS} -F"
+
KDUMP_CMDLINE_APPEND=${KDUMP_CMDLINE_APPEND:="@KDUMP_CMDLINE_APPEND@"}
KDUMP_KERNEL_HOOK="/etc/kernel/postinst.d/kdump-tools"
[ -d $KDUMP_COREDIR ] || mkdir -p $KDUMP_COREDIR ;
@@ -777,7 +780,7 @@
mkdir -p "$KDUMP_STAMPDIR"
fi
- log_action_msg "running makedumpfile $MAKEDUMP_ARGS $vmcore_file
$KDUMP_CORETEMP"
+ log_action_msg "running makedumpfile $MAKEDUMP_ARGS $vmcore_file |
compress > $KDUMP_CORETEMP"
# shellcheck disable=SC2086
makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress > "$KDUMP_CORETEMP"
ERROR=$?
@@ -876,12 +879,9 @@
FTPPUT_ARGS="$FTPPUT_ARGS -P $FTP_PORT"
fi
- FTP_MAKEDUMP_ARGS="${MAKEDUMP_ARGS}"
- # Add '-F' [flatten] to FTP_MAKEDUMP_ARGS, if not there:
- [ "${FTP_MAKEDUMP_ARGS#-F*}" != "${FTP_MAKEDUMP_ARGS}" ] ||
FTP_MAKEDUMP_ARGS="${FTP_MAKEDUMP_ARGS} -F"
- log_action_msg "sending makedumpfile $FTP_MAKEDUMP_ARGS $vmcore_file
via FTP to $FTP_REMOTE_HOST:$FTP_COREFILE"
+ log_action_msg "sending makedumpfile $MAKEDUMP_ARGS $vmcore_file via
FTP to $FTP_REMOTE_HOST:$FTP_COREFILE"
# shellcheck disable=SC2086
- makedumpfile $FTP_MAKEDUMP_ARGS $vmcore_file | compress | busybox
ftpput $FTPPUT_ARGS "$FTP_REMOTE_HOST" "$FTP_COREFILE" -
+ makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress | busybox ftpput
$FTPPUT_ARGS "$FTP_REMOTE_HOST" "$FTP_COREFILE" -
ERROR=$?
# did we succeed?
@@ -952,12 +952,9 @@
return 1
fi
- SSH_MAKEDUMP_ARGS="${MAKEDUMP_ARGS}"
- # Add '-F' [flatten] to MAKEDUMP_ARGS, if not there:
- [ "${SSH_MAKEDUMP_ARGS#-F*}" != "${SSH_MAKEDUMP_ARGS}" ] ||
SSH_MAKEDUMP_ARGS="${SSH_MAKEDUMP_ARGS} -F"
- log_action_msg "sending makedumpfile $SSH_MAKEDUMP_ARGS $vmcore_file to
$SSH_REMOTE_HOST : $SSH_CORETEMP"
+ log_action_msg "sending makedumpfile $MAKEDUMP_ARGS $vmcore_file to
$SSH_REMOTE_HOST : $SSH_CORETEMP"
# shellcheck disable=SC2086
- makedumpfile $SSH_MAKEDUMP_ARGS $vmcore_file | compress | ssh -i
$SSH_KEY "$SSH_REMOTE_HOST" dd "of=$SSH_CORETEMP"
+ makedumpfile $MAKEDUMP_ARGS $vmcore_file | compress | ssh -i $SSH_KEY
"$SSH_REMOTE_HOST" dd "of=$SSH_CORETEMP"
ERROR=$?
if [ $ERROR -ne 0 ] ; then
log_failure_msg "$NAME: makedumpfile failed, falling back to
'scp'"
Bug#977511: buster-pu: package edk2/0~20181115.85588389-3+deb10u2
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu
[ Reason ]
Address CVE-2019-14584 (#977300), for which the security team has declined to
release a DSA.
[ Impact ]
Possible firmware crash while validating signed payloads.
[ Tests ]
Regression tested by booting a Secure Boot guest.
[ Risks ]
It's a one-liner fix - if it introduced a regression, it could break
certain secure boot guests.
[ Checklist ]
[x] *all* changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in (old)stable
[x] the issue is verified as fixed in unstable
[ Changes ]
A clean cherry-pick from upstream to fix a potential NULL pointer
dreference.
[ Other info ]
N/A
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.9.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru edk2-0~20181115.85588389/debian/changelog
edk2-0~20181115.85588389/debian/changelog
--- edk2-0~20181115.85588389/debian/changelog 2020-09-17 13:45:52.0
-0600
+++ edk2-0~20181115.85588389/debian/changelog 2020-12-15 12:30:28.0
-0700
@@ -1,3 +1,11 @@
+edk2 (0~20181115.85588389-3+deb10u3) buster; urgency=medium
+
+ * CryptoPkg/BaseCryptLib: fix NULL dereference. (CVE-2019-14584)
+(Closes: #977300)
+ - d/p/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
+
+ -- dann frazier Tue, 15 Dec 2020 12:30:28 -0700
+
edk2 (0~20181115.85588389-3+deb10u2) buster; urgency=medium
* Fix integer overflow in DxeImageVerificationHandler. (CVE-2019-14562)
diff -Nru
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
---
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
1969-12-31 17:00:00.0 -0700
+++
edk2-0~20181115.85588389/debian/patches/CryptoPkg-BaseCryptLib-fix-NULL-dereference-CVE-2019.patch
2020-12-15 12:30:28.0 -0700
@@ -0,0 +1,51 @@
+From 26442d11e620a9e81c019a24a4ff38441c64ba10 Mon Sep 17 00:00:00 2001
+From: Jian J Wang
+Date: Thu, 25 Apr 2019 23:42:16 +0800
+Subject: [PATCH] CryptoPkg/BaseCryptLib: fix NULL dereference (CVE-2019-14584)
+
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1914
+
+AuthenticodeVerify() calls OpenSSLs d2i_PKCS7() API to parse asn encoded
+signed authenticode pkcs#7 data. when this successfully returns, a type
+check is done by calling PKCS7_type_is_signed() and then
+Pkcs7->d.sign->contents->type is used. It is possible to construct an asn1
+blob that successfully decodes and have d2i_PKCS7() return a valid pointer
+and have PKCS7_type_is_signed() also return success but have Pkcs7->d.sign
+be a NULL pointer.
+
+Looking at how PKCS7_verify() [inside of OpenSSL] implements checking for
+pkcs7 structs it does the following:
+- call PKCS7_type_is_signed()
+- call PKCS7_get_detached()
+Looking into how PKCS7_get_detatched() is implemented, it checks to see if
+p7->d.sign is NULL or if p7->d.sign->contents->d.ptr is NULL.
+
+As such, the fix is to do the same as OpenSSL after calling d2i_PKCS7().
+- Add call to PKS7_get_detached() to existing error handling
+
+Cc: Xiaoyu Lu
+Cc: Guomin Jiang
+Cc: Jiewen Yao
+Cc: Laszlo Ersek
+Signed-off-by: Jian J Wang
+Reviewed-by: Laszlo Ersek
+Reviewed-by: Jiewen Yao
+
+Origin: upstream,
https://github.com/tianocore/edk2/commit/26442d11e620a9e81c019a24a4ff38441c64ba10
+Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=1914
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977300
+Last-Update: 2020-12-15
+
+Index: edk2/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
+===
+--- edk2.orig/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
edk2/CryptoPkg/Library/BaseCryptLib/Pk/CryptAuthenticode.c
+@@ -106,7 +106,7 @@ AuthenticodeVerify (
+ //
+ // Check if it's PKCS#7 Signed Data (for Authenticode Scenario)
+ //
+- if (!PKCS7_type_is_signed (Pkcs7)) {
++ if (!PKCS7_type_is_signed (Pkcs7) || PKCS7_get_detached (Pkcs7)) {
+ goto _Exit;
+ }
+
diff -Nru edk2-0~20181115.85588389/debian/patches/series
edk2-0~20181115.85588389/debian/patches/series
--- edk2-0~20181115.85588389/debian/patches/series 2020-09-17
13:45:52.0 -0600
+++ edk2-0~20181115.85588389/debian/patches/series 2020-12-15
12:30:28.0 -0700
@@ -27,3 +2
Bug#970518: buster-pu: package edk2/0~20181115.85588389-3+deb10u1
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu [ Reason ] I'd like to fix CVE-2019-14562 in edk2 for buster. [ Impact ] Vulnerability to an integer overflow when parsing signatures of a specially crafted PE file. [ Tests ] Regression tested only using the autopkgtests from the unstable version of the package. [ Risks ] A regression could break the booting of QEMU-emulated machines. [ Checklist ] [X] *all* changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in (old)stable [X] the issue is verified as fixed in unstable [ Changes ] Cherry-picks from upstream to resolve CVE-2019-14562. [ Other info ] N/A -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.8.0-1-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru edk2-0~20181115.85588389/debian/changelog edk2-0~20181115.85588389/debian/changelog --- edk2-0~20181115.85588389/debian/changelog 2020-04-23 13:33:06.0 -0600 +++ edk2-0~20181115.85588389/debian/changelog 2020-09-17 13:45:52.0 -0600 @@ -1,3 +1,13 @@ +edk2 (0~20181115.85588389-3+deb10u2) buster; urgency=medium + + * Fix integer overflow in DxeImageVerificationHandler. (CVE-2019-14562) +(Closes: #968819) + - d/p/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch + - d/p/0002-SecurityPkg-DxeImageVerificationLib-assign-WinCertif.patch + - d/p/0003-SecurityPkg-DxeImageVerificationLib-catch-alignment-.patch + + -- dann frazier Thu, 17 Sep 2020 13:45:52 -0600 + edk2 (0~20181115.85588389-3+deb10u1) buster; urgency=medium * Fix numeric truncation in S3BootScript[Save]*() API. (CVE-2019-14563) diff -Nru edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch --- edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch 1969-12-31 17:00:00.0 -0700 +++ edk2-0~20181115.85588389/debian/patches/0001-SecurityPkg-DxeImageVerificationLib-extract-SecDataD.patch 2020-09-17 13:45:52.0 -0600 @@ -0,0 +1,87 @@ +From 503248ccdf45c14d4040ce44163facdc212e4991 Mon Sep 17 00:00:00 2001 +From: Laszlo Ersek +Date: Tue, 1 Sep 2020 11:12:19 +0200 +Subject: [PATCH 1/3] SecurityPkg/DxeImageVerificationLib: extract + SecDataDirEnd, SecDataDirLeft +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +The following two quantities: + + SecDataDir->VirtualAddress + SecDataDir->Size + SecDataDir->VirtualAddress + SecDataDir->Size - OffSet + +are used multiple times in DxeImageVerificationHandler(). Introduce helper +variables for them: "SecDataDirEnd" and "SecDataDirLeft", respectively. +This saves us multiple calculations and significantly simplifies the code. + +Note that all three summands above have type UINT32, therefore the new +variables are also of type UINT32. + +This patch does not change behavior. + +(Note that the code already handles the case when the + + SecDataDir->VirtualAddress + SecDataDir->Size + +UINT32 addition overflows -- namely, in that case, the certificate loop is +never entered, and the corruption check right after the loop fires.) + +Cc: Jian J Wang +Cc: Jiewen Yao +Cc: Min Xu +Cc: Wenyi Xie +Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 +Signed-off-by: Laszlo Ersek +Message-Id: <20200901091221.20948-2-ler...@redhat.com> +Reviewed-by: Philippe Mathieu-Daudé +Tested-by: Wenyi Xie +Reviewed-by: Min M Xu +Reviewed-by: Jiewen Yao + +Origin: https://github.com/tianocore/edk2/commit/503248ccdf45c14d4040ce44163facdc212e4991 +Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=2215 +Bug-Debian: https://bugs.debian.org/968819 +Last-Update: 2020-09-17 + +Index: edk2/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c +=== +--- edk2.orig/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c edk2/SecurityPkg/Library/DxeImageVerificationLib/DxeImageVerificationLib.c +@@ -1658,6 +1658,8 @@ DxeImageVerificationHandler ( + UINT8*AuthData; + UINTNAuthDataSize; + EFI_IMAGE_DATA_DIRECTORY *SecDataDir; ++ UINT32 SecDataDirEnd; ++ UINT32
Bug#958568: buster-pu: package edk2/0~20181115.85588389-3
Package: release.debian.org Severity: normal Tags: buster User: release.debian@packages.debian.org Usertags: pu There are several security issues that have been marked nodsa, but I think are worth fixing in a stable update. From the changelog: * Fix numeric truncation in S3BootScript[Save]*() API. (CVE-2019-14563) * Fix use-after-free in PcdHiiOsRuntimeSupport. (CVE-2019-14586) * Clear memory before free to avoid potential password leak. (CVE-2019-14558) * Fix double-unmap in SdMmcCreateTrb(). This did not impact any of the images built from this package. (CVE-2019-14587) * Fix memory leak in ArpOnFrameRcvdDpc(). (CVE-2019-14559) * Fix issue that could allow an efi image with a blacklisted hash in the dbx to be loaded. (CVE-2019-14575) (Closes: 952935) * Fix a memory leak in the ARP handler. (CVE-2019-14559) (Closes: #952926) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.5.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled diff -Nru edk2-0~20181115.85588389/debian/changelog edk2-0~20181115.85588389/debian/changelog --- edk2-0~20181115.85588389/debian/changelog 2019-03-15 18:37:44.0 -0600 +++ edk2-0~20181115.85588389/debian/changelog 2020-04-23 13:33:06.0 -0600 @@ -1,3 +1,18 @@ +edk2 (0~20181115.85588389-3+deb10u1) buster; urgency=medium + + * Fix numeric truncation in S3BootScript[Save]*() API. (CVE-2019-14563) + * Fix use-after-free in PcdHiiOsRuntimeSupport. (CVE-2019-14586) + * Clear memory before free to avoid potential password leak. +(CVE-2019-14558) + * Fix double-unmap in SdMmcCreateTrb(). This did not impact any +of the images built from this package. (CVE-2019-14587) + * Fix memory leak in ArpOnFrameRcvdDpc(). (CVE-2019-14559) + * Fix issue that could allow an efi image with a blacklisted hash in the +dbx to be loaded. (CVE-2019-14575) (Closes: 952935) + * Fix a memory leak in the ARP handler. (CVE-2019-14559) (Closes: #952926) + + -- dann frazier Thu, 23 Apr 2020 13:33:06 -0600 + edk2 (0~20181115.85588389-3) unstable; urgency=medium * Security fixes (Closes: #924615): diff -Nru edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-PiDxeS3BootScriptLib-Fix-potential-nume.patch edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-PiDxeS3BootScriptLib-Fix-potential-nume.patch --- edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-PiDxeS3BootScriptLib-Fix-potential-nume.patch 1969-12-31 17:00:00.0 -0700 +++ edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-PiDxeS3BootScriptLib-Fix-potential-nume.patch 2020-04-22 16:55:02.0 -0600 @@ -0,0 +1,156 @@ +From 322ac05f8bbc1bce066af1dabd1b70ccdbe28891 Mon Sep 17 00:00:00 2001 +From: Hao A Wu +Date: Fri, 28 Jun 2019 14:15:55 +0800 +Subject: [PATCH 01/17] MdeModulePkg/PiDxeS3BootScriptLib: Fix potential + numeric truncation (CVE-2019-14563) + +REF:https://bugzilla.tianocore.org/show_bug.cgi?id=2001 + +For S3BootScriptLib APIs: + +S3BootScriptSaveIoWrite +S3BootScriptSaveMemWrite +S3BootScriptSavePciCfgWrite +S3BootScriptSavePciCfg2Write +S3BootScriptSaveSmbusExecute +S3BootScriptSaveInformation +S3BootScriptSaveInformationAsciiString +S3BootScriptLabel (happen in S3BootScriptLabelInternal()) + +possible numeric truncations will happen that may lead to S3 boot script +entry with improper size being returned to store the boot script data. +This commit will add checks to prevent this kind of issue. + +Please note that the remaining S3BootScriptLib APIs: + +S3BootScriptSaveIoReadWrite +S3BootScriptSaveMemReadWrite +S3BootScriptSavePciCfgReadWrite +S3BootScriptSavePciCfg2ReadWrite +S3BootScriptSaveStall +S3BootScriptSaveDispatch2 +S3BootScriptSaveDispatch +S3BootScriptSaveMemPoll +S3BootScriptSaveIoPoll +S3BootScriptSavePciPoll +S3BootScriptSavePci2Poll +S3BootScriptCloseTable +S3BootScriptExecute +S3BootScriptMoveLastOpcode +S3BootScriptCompare + +are not affected by such numeric truncation. + +Signed-off-by: Hao A Wu +Reviewed-by: Laszlo Ersek +Reviewed-by: Eric Dong +Acked-by: Jian J Wang + +Origin: https://github.com/tianocore/edk2/commit/322ac05f8bbc1bce066af1dabd1b70ccdbe28891 +Bug: https://bugzilla.tianocore.org/show_bug.cgi?id=2001 +Bug-Debian: https://bugs.debian.org/952934 +Last-Update: 2020-03-16 + +Index: edk2-0~20181115.85588389/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c +=== +--- edk2-0~20181115.85588389.orig/MdeModulePkg/Library/PiDxeS3BootScriptLib/BootScriptSave.c edk2-0
Bug#924945: stretch-pu: package edk2/0~20161202.7bbe0b3e-1+deb9u1
Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu
Fixes 3 CVEs.
-- System Information:
Debian Release: buster/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.20.0-trunk-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru edk2-0~20161202.7bbe0b3e/debian/changelog
edk2-0~20161202.7bbe0b3e/debian/changelog
--- edk2-0~20161202.7bbe0b3e/debian/changelog 2016-12-09 01:09:39.0
-0700
+++ edk2-0~20161202.7bbe0b3e/debian/changelog 2019-03-18 14:12:49.0
-0600
@@ -1,3 +1,12 @@
+edk2 (0~20161202.7bbe0b3e-1+deb9u1) stretch; urgency=medium
+
+ * Security fixes (Closes: #924615):
+- Fix buffer overflow in BlockIo service (CVE-2018-12180)
+- DNS: Check received packet size before using (CVE-2018-12178)
+- Fix stack overflow with corrupted BMP (CVE-2018-12181)
+
+ -- dann frazier Mon, 18 Mar 2019 14:12:49 -0600
+
edk2 (0~20161202.7bbe0b3e-1) unstable; urgency=medium
* New upstream release.
diff -Nru
edk2-0~20161202.7bbe0b3e/debian/patches/-MdeModulePkg-HiiDB-Avoid-incorrect-results-of-multip.patch
edk2-0~20161202.7bbe0b3e/debian/patches/-MdeModulePkg-HiiDB-Avoid-incorrect-results-of-multip.patch
---
edk2-0~20161202.7bbe0b3e/debian/patches/-MdeModulePkg-HiiDB-Avoid-incorrect-results-of-multip.patch
1969-12-31 17:00:00.0 -0700
+++
edk2-0~20161202.7bbe0b3e/debian/patches/-MdeModulePkg-HiiDB-Avoid-incorrect-results-of-multip.patch
2019-03-18 14:12:49.0 -0600
@@ -0,0 +1,144 @@
+From: Dandan Bi
+Date: Wed, 12 Apr 2017 11:21:52 +0800
+Subject: [PATCH] MdeModulePkg/HiiDB: Avoid incorrect results of multiplication
+
+An example:
+The codes in function Output8bitPixel in Image.c:
+OffsetY = BITMAP_LEN_8_BIT ((UINT32) Image->Width, Ypos);
+
+Both Image->Width and Ypos are of type UINT16. They will be promoted to
+int (signed) first, and then perform the multiplication defined by macro
+BITMAP_LEN_8_BIT. If the result of multiplication between Image->Width and
+Ypos exceeds the range of type int, a potential incorrect results
+will be assigned to OffsetY.
+
+This commit adds explicit UINT32 type cast for 'Image->Width' to avoid
+possible overflow in the int range. And also fix similar issues in
+HiiDatabase.
+
+Cc: Eric Dong
+Cc: Liming Gao
+Cc: Hao Wu
+Contributed-under: TianoCore Contribution Agreement 1.0
+Signed-off-by: Dandan Bi
+Reviewed-by: Hao Wu
+
+Origin:
https://github.com/tianocore/edk2/commit/f76bc44362e5f0a2ea509c07b2f6846bd9833ee8
+Bug-Debian: https://bugs.debian.org/924615
+Last-Update: 2019-03-18
+
+diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
+index e2fa16e6e0..431a5b8454 100644
+--- a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
+@@ -105,7 +105,7 @@ GetImageIdOrAddress (
+ case EFI_HII_IIBT_IMAGE_8BIT_TRANS:
+ Length = sizeof (EFI_HII_IIBT_IMAGE_8BIT_BLOCK) - sizeof (UINT8) +
+BITMAP_LEN_8_BIT (
+- ReadUnaligned16 (&((EFI_HII_IIBT_IMAGE_8BIT_BLOCK *)
CurrentImageBlock)->Bitmap.Width),
++ (UINT32) ReadUnaligned16 (&((EFI_HII_IIBT_IMAGE_8BIT_BLOCK
*) CurrentImageBlock)->Bitmap.Width),
+ ReadUnaligned16 (&((EFI_HII_IIBT_IMAGE_8BIT_BLOCK *)
CurrentImageBlock)->Bitmap.Height)
+ );
+ ImageIdCurrent++;
+@@ -115,7 +115,7 @@ GetImageIdOrAddress (
+ case EFI_HII_IIBT_IMAGE_24BIT_TRANS:
+ Length = sizeof (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof
(EFI_HII_RGB_PIXEL) +
+BITMAP_LEN_24_BIT (
+- ReadUnaligned16 ((VOID *) &((EFI_HII_IIBT_IMAGE_24BIT_BLOCK
*) CurrentImageBlock)->Bitmap.Width),
++ (UINT32) ReadUnaligned16 ((VOID *)
&((EFI_HII_IIBT_IMAGE_24BIT_BLOCK *) CurrentImageBlock)->Bitmap.Width),
+ ReadUnaligned16 ((VOID *) &((EFI_HII_IIBT_IMAGE_24BIT_BLOCK
*) CurrentImageBlock)->Bitmap.Height)
+ );
+ ImageIdCurrent++;
+@@ -453,7 +453,7 @@ Output8bitPixel (
+ // Convert the pixel from 8 bits to corresponding color.
+ //
+ for (Ypos = 0; Ypos < Image->Height; Ypos++) {
+-OffsetY = BITMAP_LEN_8_BIT (Image->Width, Ypos);
++OffsetY = BITMAP_LEN_8_BIT ((UINT32) Image->Width, Ypos);
+ //
+ // All bits are meaningful since the bitmap is 8 bits per pixel.
+ //
+@@ -493,7 +493,7 @@ Output24bitPixel (
+ BitMapPtr = Image->Bitmap;
+
+ for (Ypos = 0; Ypos < Image->Height; Ypos++) {
+-OffsetY = BITMAP_LEN_8_BIT (I
Bug#924701: debdiff
diff -Nru edk2-0~20181115.85588389/debian/changelog
edk2-0~20181115.85588389/debian/changelog
--- edk2-0~20181115.85588389/debian/changelog 2018-11-26 16:34:54.0
-0700
+++ edk2-0~20181115.85588389/debian/changelog 2019-03-15 18:37:44.0
-0600
@@ -1,3 +1,12 @@
+edk2 (0~20181115.85588389-3) unstable; urgency=medium
+
+ * Security fixes (Closes: #924615):
+- Fix buffer overflow in BlockIo service (CVE-2018-12180)
+- DNS: Check received packet size before using (CVE-2018-12178)
+- Fix stack overflow with corrupted BMP (CVE-2018-12181)
+
+ -- dann frazier Fri, 15 Mar 2019 18:37:44 -0600
+
edk2 (0~20181115.85588389-2) unstable; urgency=medium
* debian/rules: Factor out common feature flags across builds.
diff -Nru
edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-HiiDatabase-Fix-potential-integer-overf.patch
edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-HiiDatabase-Fix-potential-integer-overf.patch
---
edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-HiiDatabase-Fix-potential-integer-overf.patch
1969-12-31 17:00:00.0 -0700
+++
edk2-0~20181115.85588389/debian/patches/0001-MdeModulePkg-HiiDatabase-Fix-potential-integer-overf.patch
2019-03-15 18:37:44.0 -0600
@@ -0,0 +1,247 @@
+From ffe5f7a6b4e978dffbe1df228963adc914451106 Mon Sep 17 00:00:00 2001
+From: Ray Ni
+Date: Thu, 7 Mar 2019 18:35:13 +0800
+Subject: [PATCH] MdeModulePkg/HiiDatabase: Fix potential integer overflow
+ (CVE-2018-12181)
+
+REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1135
+
+Contributed-under: TianoCore Contribution Agreement 1.1
+Signed-off-by: Ray Ni
+Cc: Dandan Bi
+Cc: Hao A Wu
+Reviewed-by: Hao Wu
+Reviewed-by: Jian J Wang
+---
+ MdeModulePkg/Universal/HiiDatabaseDxe/Image.c | 126 ++
+ 1 file changed, 103 insertions(+), 23 deletions(-)
+
+diff --git a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
+index 71ebc559c0..80a4ec1114 100644
+--- a/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
b/MdeModulePkg/Universal/HiiDatabaseDxe/Image.c
+@@ -16,6 +16,7 @@ WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER
EXPRESS OR IMPLIED.
+
+ #include "HiiDatabase.h"
+
++#define MAX_UINT240xFF
+
+ /**
+ Get the imageid of last image block: EFI_HII_IIBT_END_BLOCK when input
+@@ -651,8 +652,16 @@ HiiNewImage (
+
+ EfiAcquireLock ();
+
+- NewBlockSize = sizeof (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) - sizeof
(EFI_HII_RGB_PIXEL) +
+- BITMAP_LEN_24_BIT ((UINT32) Image->Width, Image->Height);
++ //
++ // Calcuate the size of new image.
++ // Make sure the size doesn't overflow UINT32.
++ // Note: 24Bit BMP occpuies 3 bytes per pixel.
++ //
++ NewBlockSize = (UINT32)Image->Width * Image->Height;
++ if (NewBlockSize > (MAX_UINT32 - (sizeof (EFI_HII_IIBT_IMAGE_24BIT_BLOCK) -
sizeof (EFI_HII_RGB_PIXEL))) / 3) {
++return EFI_OUT_OF_RESOURCES;
++ }
++ NewBlockSize = NewBlockSize * 3 + (sizeof (EFI_HII_IIBT_IMAGE_24BIT_BLOCK)
- sizeof (EFI_HII_RGB_PIXEL));
+
+ //
+ // Get the image package in the package list,
+@@ -671,6 +680,18 @@ HiiNewImage (
+ //
+ // Update the package's image block by appending the new block to the end.
+ //
++
++//
++// Make sure the final package length doesn't overflow.
++// Length of the package header is represented using 24 bits. So MAX
length is MAX_UINT24.
++//
++if (NewBlockSize > MAX_UINT24 - ImagePackage->ImagePkgHdr.Header.Length) {
++ return EFI_OUT_OF_RESOURCES;
++}
++//
++// Because ImagePackage->ImageBlockSize <
ImagePackage->ImagePkgHdr.Header.Length,
++// So (ImagePackage->ImageBlockSize + NewBlockSize) <= MAX_UINT24
++//
+ ImageBlocks = AllocatePool (ImagePackage->ImageBlockSize + NewBlockSize);
+ if (ImageBlocks == NULL) {
+ EfiReleaseLock ();
+@@ -701,6 +722,13 @@ HiiNewImage (
+ PackageListNode->PackageListHdr.PackageLength += NewBlockSize;
+
+ } else {
++//
++// Make sure the final package length doesn't overflow.
++// Length of the package header is represented using 24 bits. So MAX
length is MAX_UINT24.
++//
++if (NewBlockSize > MAX_UINT24 - (sizeof (EFI_HII_IMAGE_PACKAGE_HDR) +
sizeof (EFI_HII_IIBT_END_BLOCK))) {
++ return EFI_OUT_OF_RESOURCES;
++}
+ //
+ // The specified package list does not contain image package.
+ // Create one to add this image block.
+@@ -902,8 +930,11 @@ IGetImage (
+ // Use the common block code since the definition of these structures is
the same.
+ //
+ CopyMem (, CurrentImageBlock, sizeof
(EFI_HII_IIBT_IMAGE_1BIT_BLOCK));
+-ImageLength = sizeof (EFI_GRAPHICS_OUTPUT_BLT_PIXEL) *
+- ((UINT32) Iibt1bit.Bitmap.Width * Iibt1bit.Bitmap.Height);
++ImageLength = (UINTN) Iibt1bit.Bitmap.Width * Iibt1bit.Bitmap.Height;
++if (ImageLen
Bug#924701: unblock: edk2/0~20181115.85588389-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package edk2 Addresses 3 CVEs. unblock edk2/0~20181115.85588389-3 -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.20.0-trunk-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#770897: unblock: vnc4/4.1.1+X4.3.0-37.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package vnc4 This fixes build failures on arm64 and powerpc (and nothing else). The arm64 fix (#769490) has been runtime tested by starting up a session and remotely running iceweasel under an icewm desktop. All of the changes are under architecture-specific ifdefs, so risk of regression on other architectures is minimal. The NMU that added arm64 support failed to build on powerpc. The root cause of this failure was a toolchain change (introduced in gcc-4.7), and unrelated to the arm64 build. This release also fixes that build failure (#769976). The solution there is also implemented within an architecture-specific ifdef so, again, the risk of regression on other architectures is minimal. In between these two releases, there was an upload to sid that fixed a normal severity bug. After coordination with both the developer behind this upload and the Debian maintainer, I have reverted this fix for the current release to comply with the freeze policy with the intent of reincorporating the fix after these porting fixes have managed to enter testing. unblock vnc4/4.1.1+X4.3.0-37.4 -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 arm64 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash diff -u vnc4-4.1.1+X4.3.0/debian/changelog vnc4-4.1.1+X4.3.0/debian/changelog --- vnc4-4.1.1+X4.3.0/debian/changelog +++ vnc4-4.1.1+X4.3.0/debian/changelog @@ -1,3 +1,25 @@ +vnc4 (4.1.1+X4.3.0-37.4) unstable; urgency=medium + + * Non-maintainer upload. + * Temporarily revert fix for #769891 to qualify for jessie unblock. + * powerpc-undef-pixel.patch: Fix FTBFS on powerpc (Closes: #769976). + + -- dann frazier da...@debian.org Mon, 24 Nov 2014 15:44:08 -0700 + +vnc4 (4.1.1+X4.3.0-37.3) unstable; urgency=medium + + * Non-maintainer upload. + * Strip vnc:// prefix from server name to support URIs (Closes: #769891) + + -- Benjamin Drung benjamin.dr...@profitbricks.com Mon, 17 Nov 2014 11:47:55 +0100 + +vnc4 (4.1.1+X4.3.0-37.2) unstable; urgency=medium + + * Non-maintainer upload. + * arm64-support.patch: Add arm64 support (Closes: #769490) + + -- dann frazier da...@debian.org Fri, 14 Nov 2014 15:50:34 -0700 + vnc4 (4.1.1+X4.3.0-37.1) unstable; urgency=low * Non-maintainer upload. diff -u vnc4-4.1.1+X4.3.0/unix/xc/include/Xmd.h vnc4-4.1.1+X4.3.0/unix/xc/include/Xmd.h --- vnc4-4.1.1+X4.3.0/unix/xc/include/Xmd.h +++ vnc4-4.1.1+X4.3.0/unix/xc/include/Xmd.h @@ -58,7 +58,8 @@ #ifdef CRAY #define WORD64/* 64-bit architecture */ #endif -#if defined(__alpha) || defined(__alpha__) || \ +#if defined (__aarch64__) || \ +defined(__alpha) || defined(__alpha__) || \ defined(__ia64__) || defined(ia64) || \ defined(__sparc64__) || defined(__powerpc64__) || \ defined(__s390x__) || \ diff -u vnc4-4.1.1+X4.3.0/unix/xc/config/cf/linux.cf vnc4-4.1.1+X4.3.0/unix/xc/config/cf/linux.cf --- vnc4-4.1.1+X4.3.0/unix/xc/config/cf/linux.cf +++ vnc4-4.1.1+X4.3.0/unix/xc/config/cf/linux.cf @@ -748,6 +748,17 @@ # define VendorHasX11R6_3libXext YES /* XC or XFree86 = 3.3.1 */ #endif +#ifdef Aarch64Architecture +/* Cargoculted from Arm32Architecture w/ -D_XSERVER64 added */ +# define DefaultCCOptions -fsigned-char +# ifndef OptimizedCDebugFlags +# define OptimizedCDebugFlags -O3 +# endif +# define LinuxMachineDefines -D__aarch64__ +# define ServerOSDefines XFree86ServerOSDefines -DDDXTIME -DPART_NET +# define ServerExtraDefines -DGCCUSESGAS XFree86ServerDefines -D_XSERVER64 +#endif /* Aarch64Architecture */ + #ifdef AlphaArchitecture # ifndef OptimizedCDebugFlags # define OptimizedCDebugFlags DefaultGcc2AxpOpt only in patch2: unchanged: --- vnc4-4.1.1+X4.3.0.orig/debian/patches/arm64-support.patch +++ vnc4-4.1.1+X4.3.0/debian/patches/arm64-support.patch @@ -0,0 +1,96 @@ +Description: Add arm64 support +Author: dann frazier da...@debian.org +Bug-Debian: http://bugs.debian.org/769490 +Last-Update: 2014-11-13 + +diff -urpN vnc4-4.1.1+X4.3.0.orig/unix/xc/config/cf/Imake.cf vnc4-4.1.1+X4.3.0/unix/xc/config/cf/Imake.cf +--- vnc4-4.1.1+X4.3.0.orig/unix/xc/config/cf/Imake.cf 2003-02-18 16:51:45.0 + vnc4-4.1.1+X4.3.0/unix/xc/config/cf/Imake.cf 2014-11-13 22:56:20.646494516 + +@@ -211,6 +211,10 @@ XCOMM $XFree86: xc/config/cf/Imake.cf,v + # define PpcArchitecture + # undef __powerpc__ + # endif ++# ifdef __aarch64__ ++# define Aarch64Architecture ++# undef __powerpc__ ++# endif + #endif /* NetBSD */ + + #ifdef __FreeBSD__ +@@ -727,6 +731,10 @@ XCOMM Keep cpp from replacing path eleme + # define s390Architecture + # undef __s390__ + # endif /* s390 */ ++# ifdef __aarch64__ ++# define Aarch64Architecture ++# undef __aarch64__ ++# endif
Re: Upcoming stable point release (7.4)
On Thu, Jan 23, 2014 at 08:08:56PM +, Adam D. Barratt wrote: Hi, The next point release for wheezy (7.4) is scheduled for Saturday February 8th. Stable NEW will be frozen during the preceding weekend. As usual, base-files can be uploaded at any point before the freeze. Unfortunately linux-2.6 FTBFS on arm - I prepared a fix, which has been build tested on both armel and armhf, and I've uploaded 3.2.54-2. -- 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/20140201150349.GA30089@fluid.dannf
Re: 6.0.7 planning
On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: On Fri, 2013-02-15 at 01:41 +, Ben Hutchings wrote: On Thu, 2013-02-14 at 10:28 -0800, dann frazier wrote: Security update has been uploaded. I'll post the builds somewhere as they become available for anyone interested in testing. Version 2.6.32-48 has also been uploaded. Flagged for acceptance; thanks. All the builds are now in, so we should be ready for lkdi updates when convenient. I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Thoughts? -- 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/20130217213323.gg18...@dannf.org
Re: 6.0.7 planning
On Sun, Feb 17, 2013 at 11:12:18PM +, Ben Hutchings wrote: On Sun, 2013-02-17 at 13:33 -0800, dann frazier wrote: On Sun, Feb 17, 2013 at 03:14:04PM +, Adam D. Barratt wrote: On Fri, 2013-02-15 at 11:32 +, Adam D. Barratt wrote: On Fri, 2013-02-15 at 01:41 +, Ben Hutchings wrote: On Thu, 2013-02-14 at 10:28 -0800, dann frazier wrote: Security update has been uploaded. I'll post the builds somewhere as they become available for anyone interested in testing. Version 2.6.32-48 has also been uploaded. Flagged for acceptance; thanks. All the builds are now in, so we should be ready for lkdi updates when convenient. I gather there's a chance there might need to be further security updates; will that mean we need another update in p-u? Possibly; an alternative would be to release a 48squeeze1 via security to sync up w/ the fixes just before the point release. That would let us go ahead and get the lkdi/d-i updates ready and give us some flexibility to react to any follow-on changes that may appear this week as CVE-2013-0871 is discussed. On the other hand, I know Ben has another fix queued for stable, and I saw a mention of a possible s390/KVM regression - so those may justify the extra p-u update. Thoughts? I would prefer to give users the option to install just the urgent security fixes and delay upgrading to the point release. Releasing a 48squeeze1 means bundling together all those changes. Agreed; and I think I was unclear. I was taking for granted that we *will* do a 46squeeze2 now w/ the CVE-2013-0871 fix and bypass 46squeeze1. 46squeeze2 would provide the security-only option. The question was whether or not we should try and fix p-u by getting a -49 into -stable now w/ the CVE-2013-0871 fix, or just make sure there's a 48squeeze1 in security for after. Ah - but maybe the point you're making is that a 48squeeze1 in security would make 46squeeze2 harder to find/install - if so, I can understand that point. I don't think it's critical that the installer has the same kernel version as the stable suite. We do need to be careful with ordering of the changelog to allow the installer kernel version to be constructed from the later version by running debian/bin/patch.apply, and/or ask the FTP team nicely to ensure the older version remains in squeeze. Ordering it properly shouldn't be a problem. -- 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/20130217233634.gh18...@dannf.org
Re: 6.0.7 planning
On Wed, Feb 13, 2013 at 03:34:51PM +, Ben Hutchings wrote: On Wed, 2013-02-13 at 15:18 +, Adam D. Barratt wrote: On 12.02.2013 02:15, Ben Hutchings wrote: One or other of us will then need to merge the squeeze-security branch into squeeze and upload -48 in time for the point release. Is there an ETA for that? Sorry for chasing, but if we're going to go for the 23rd (which is looking likely atm) we'd be looking at closing p-u-NEW over the weekend and could really do with announcing that asap. (So it'll be uploaded to p-u-NEW over the weekend should be fine, as we can then plan around that.) I can do that but it depends on the security update being finalised first. Security update has been uploaded. I'll post the builds somewhere as they become available for anyone interested in testing. -- 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/20130214182821.gb9...@dannf.org
Re: 6.0.7 planning
On Wed, Feb 13, 2013 at 03:34:51PM +, Ben Hutchings wrote: On Wed, 2013-02-13 at 15:18 +, Adam D. Barratt wrote: On 12.02.2013 02:15, Ben Hutchings wrote: One or other of us will then need to merge the squeeze-security branch into squeeze and upload -48 in time for the point release. Is there an ETA for that? Sorry for chasing, but if we're going to go for the 23rd (which is looking likely atm) we'd be looking at closing p-u-NEW over the weekend and could really do with announcing that asap. (So it'll be uploaded to p-u-NEW over the weekend should be fine, as we can then plan around that.) I can do that but it depends on the security update being finalised first. Yeah, and that should be finalised today, so this weekend seems reasonable. -- 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/20130213162149.ge18...@dannf.org
Re: 6.0.7 planning
On Mon, Feb 11, 2013 at 03:41:03AM +, Ben Hutchings wrote: On Sun, 2013-02-10 at 16:25 +, Adam D. Barratt wrote: Hi, We're somewhat overdue with the next Squeeze point release (6.0.7) and it'd be good to get it done before the wheezy release, so that we can pull in some upgrade fixes. As an opening gambit, some proposed dates, all of which appear to currently work for me: February 23rd March 2nd March 9th No opinion on dates, but here's the state of the Linux kernel: The current version in s-p-u (2.6.32-47) adds support for new SCSI controllers, which should be included in the installer. However there has been disappointingly little testing feedback about this. fyi, I did hear from an HP contact that the hpsa update was working for him on new servers. There are a couple of pending non-security fixes: * [s390] s390/time: fix sched_clock() overflow (Closes: #698382) * Revert time: Avoid making adjustments if we haven't accumulated anything (Closes: #699112, regression in 2.6.32.60) These ought to be included in the point release but should not be need in the installer. Dann/Moritz, do you have any plans for a security or other stable update? Should I upload to stable with just these two fixes? I've been planning a security update, but work travel has been intervening. An upload in the next couple days should be doable though. Given your statement above, do you think this should be based on -47 or -46? I'll probably drop the fix for CVE-2012-3552, at least for this upload. Your suggestion for avoiding the ABI change is good, but I'm not yet confident enough w/ the backport. -- 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/20130211163610.ga13...@dannf.org
Re: Squeeze point release (6.0.6)
On Mon, Sep 24, 2012 at 10:54:00PM +0100, Adam D. Barratt wrote: On Mon, 2012-09-24 at 09:01 +0900, dann frazier wrote: On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: Thanks for the upload; the builds seem to be going well. There don't seem to be any new d-i changes in git, so I assume we just need lkdi, a round of d-i binNMUs and then a d-i-n-i upload? afaik, that's correct. Cool; thanks. All of the kernel builds are (finally) in now; would you have time to take care of the lkdi uploads? Yep, should after work today. -- 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/20120925002142.ga26...@dannf.org
Re: Squeeze point release (6.0.6)
On Sun, Sep 23, 2012 at 05:39:21PM +0100, Adam D. Barratt wrote: On Tue, 2012-09-18 at 11:30 -0600, dann frazier wrote: On Mon, Sep 17, 2012 at 03:58:13PM +0200, Philipp Kern wrote: ok, given the replies, let's settle on this: On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: * Sep 29/30: ok from RT side [...] Sorry, been travelling heavily for the past several days. We do have some changes queued, and I should be able to get a kernel uploaded by this weekend, but probably not sooner since I expect work to keep me pretty busy throught the work week. Thanks for the upload; the builds seem to be going well. There don't seem to be any new d-i changes in git, so I assume we just need lkdi, a round of d-i binNMUs and then a d-i-n-i upload? afaik, that's correct. -- 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/20120924000123.ga14...@dannf.org
Re: Squeeze point release (6.0.6)
On Mon, Sep 17, 2012 at 03:58:13PM +0200, Philipp Kern wrote: Hi, ok, given the replies, let's settle on this: On Fri, Sep 07, 2012 at 09:43:03PM +0200, Philipp Kern wrote: * Sep 29/30: ok from RT side We still need a press officer for somewhen in the evening to send out the announcement, feedback from -live and a note from -kernel if there's still a change staged for the next point release. p-u-NEW will close on the weekend of Sep 22nd/23rd (barring any breakage induced by the ftp-master meeting ;-). Sorry, been travelling heavily for the past several days. We do have some changes queued, and I should be able to get a kernel uploaded by this weekend, but probably not sooner since I expect work to keep me pretty busy throught the work week. -- 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/20120918173003.gf4...@dannf.org
Re: [Call for Test] Please test your package with python-svn/experimental (version 1.7.6-0.1)
On Thu, Jul 19, 2012 at 06:53:01AM +0900, Hideki Yamane wrote: Hi maintainers, I've put pysvn 1.7.6 package to experimental, it is necessary update to put Subversion1.7 to Wheezy. Your package seems to have a dependency for this python-svn package, so please check it with python-svn_1.7.6-0.1 in experimental. If you have any question, please ask me. Thanks! Hideki, svn-load's test suite passes 100% with python-svn_1.7.6-0.1. Thanks! -- 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/20120722184755.ga15...@dannf.org
Re: Squeeze point release (6.0.5)
On Thu, May 03, 2012 at 11:14:38PM +0100, Adam D. Barratt wrote: On Mon, 2012-04-30 at 10:09 -0600, dann frazier wrote: On Mon, Apr 30, 2012 at 04:15:31AM +0100, Ben Hutchings wrote: On Sun, 2012-04-29 at 16:36 +0100, Adam D. Barratt wrote: Is the new version ready for upload? It's looking like the point release will be the 12/13th, so it would be good to have everything ready in p-u by next weekend. I think it's ready, though there may be some security fixes we should throw in as well. Dann? Yeah - there's some security stuff to get in as well; I'll be working on that this week. Thanks for the confirmation. How are things looking? We've got all the changes committed that I think should go in and I'm doing some testing w/ a build this morning. I expect the upload to happen this afternoon. As far as I can see there aren't any changes on d-i's squeeze branch, so I guess we could just binNMU d-i once lkdi-* are sorted? (and then do dini.) Agreed. -- 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/20120504152624.ga26...@dannf.org
Re: Squeeze point release (6.0.5)
On Mon, Apr 30, 2012 at 04:15:31AM +0100, Ben Hutchings wrote: On Sun, 2012-04-29 at 16:36 +0100, Adam D. Barratt wrote: On Thu, 2012-04-26 at 05:00 +0100, Ben Hutchings wrote: I think we're going to need to do another kernel upload before the point release to revert a fix that is worse than the original bug: Subject: Revert autofs: work around unhappy compat problem on x86-64 This reverts commit 82e43e2a64739caf323ac98641e1250c3808c300 (commit a32744d4abae24572eff7269bc17895c41bd0085 upstream). The original bug (#633423) is 6 years old and autofs has a workaround for it which is broken by this fix. systemd doesn't have the workaround, but it also isn't in squeeze. That bug's marked as found in 2.6.32-44, which I assume is the not-yet-released version you were planning on including in the point release? Yes. Is the new version ready for upload? It's looking like the point release will be the 12/13th, so it would be good to have everything ready in p-u by next weekend. I think it's ready, though there may be some security fixes we should throw in as well. Dann? Yeah - there's some security stuff to get in as well; I'll be working on that this week. -- 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/20120430160949.gb10...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Wed, Feb 29, 2012 at 01:20:32PM +, Adam D. Barratt wrote: On 27.02.2012 01:12, dann frazier wrote: Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to do no kernel upload if the release gets scheduled for the first weekend in march - that's one week out, and I'll have spotty availability beginning mid-week. For later weekends, I'm for it. As you most likely saw already, we've scheduled the point release for the 10th; i.e. a week and a bit from now. Feel free to go ahead with the kernel upload, so we can get it chucked at the buildds. If we could look at getting lkdi and d-i sorted fairly quickly after the kernel builds are in, that would be great, so we don't end up with any last minute surprises; let us know if there's anything you'd like us to assist with there. I was hoping we could get away with binNMUing d-i, but we'd need a manual upload for hppa anyway, so we might as well start with a source+hppa upload I suppose... Ack. -- 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/20120229172036.gb19...@dannf.org
Re: Planning for final lenny point release (5.0.10)
On Sat, Feb 25, 2012 at 10:12:11PM +0100, Philipp Kern wrote: Hi, On Fri, Feb 24, 2012 at 08:44:46PM +, Adam D. Barratt wrote: Assuming the technical side still works, I do worry a little that a new DSA three weeks after the announced EOL for security support might confuse people. I suppose we could do a last-minute kernel update via o-p-u, although I don't know if we have any idea how many people actually upgrade to EOL point releases in the relatively short period before the move to archive.d.o. yeah, I wondered the same. I don't actually know when ftp-master gets rid of oldstable on the mirrors. If we'd know that it's still around for a few months I'd say o-p-u. The old suites used to stay on security-master for ages, but AFAICS that's no longer the case neither. Maybe the final announcement should point people at archive already (it could already get synced there at that point, given that it won't change anymore). Ok - sounds like no DSA, but maybe an upload via o-p-u. My vote is to do no kernel upload if the release gets scheduled for the first weekend in march - that's one week out, and I'll have spotty availability beginning mid-week. For later weekends, I'm for it. -- 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/20120227011257.ga17...@dannf.org
Re: Request to upload linux-2.6 (various suites)
On Thu, Dec 22, 2011 at 01:17:16AM +, Ben Hutchings wrote:
I think the following versions should be uploaded soon:
stable-proposed-updates: 2.6.32-40
Upstream stable updates 2.6.32.{47,48,49,50,51}, a few other fixes, and
backport of isci driver.
I can handle this one (if Bastian isn't already working on it...)
-dann
--
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/20111223164921.ge3...@dannf.org
Re: Upcoming Point Releases
On Wed, Sep 07, 2011 at 09:30:50PM +0200, Philipp Kern wrote: Hi, we finally got target dates for the next point releases of both Lenny and Squeeze. Lenny should get 5.0.9 on October 1st; Squeeze will follow on October 8th with 6.0.3. NEW for Lenny will be closed on the weekend of September 24th; NEW for Squeeze on the weekend of October 1st. The upload of debian-installer for Lenny should happen on the closing weekend at the latest; the middle of week 38 would be appreciated, so that we have everything together on the 24th. We have a lenny security update about ready to release (just waiting on a couple builds). I've merged those changes into the lenny branch and I can upload an o-p-u build tomorrow (which I'll do, barring any objection). This should allow for a d-i upload before the weekend. I don't think a d-i upload is strictly necessary - we haven't added any hardware support since the last point release - but it is probably a good idea given the large number of changes since the last update. For Squeeze it would be cool to have the kernel in for testing end of next week (16/17th). The d-i upload should be there the middle of week 39, October 1st at the latest. base-files can be uploaded now, as it will be held in NEW until closing time anyway. Kind regards and thanks for your efforts Philipp Kern -- 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/2011092004.gc18...@dannf.org
Re: Stable update of linux-2.6
On Sun, Apr 03, 2011 at 01:21:03PM +0530, Kamalesh Babulal wrote: * dann frazier da...@dannf.org [2011-04-02 11:23:03]: 2.6.32.36 also fails to build on powerpc/SMP: CC arch/powerpc/kernel/crash.o arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode': arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in this function) arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is reported only once arch/powerpc/kernel/crash.c:176: error: for each function it appears in.) make[1]: *** [arch/powerpc/kernel/crash.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 Hi Dann, Can you please try the following patch, which adds the changes introduced by Kumar Gala to the commit b3df895aeb to my previous patch. Yep, that fixes the build. -dann powerpc: Fix default_machine_crash_shutdown #ifdef build failure Introducing #ifdef to fix the build failure caused by crash_kexec_wait_realmode(), with powerpc build with !SMP. Reported-by: Ben Hutchings b...@decadent.org.uk Reported-by: dann frazier da...@dannf.org Signed-off-by: Kamalesh Babulal kamal...@linux.vnet.ibm.com cc: Paul E. McKenney paul...@linux.vnet.ibm.com cc: Michael Neuling mi...@neuling.org cc: Benjamin Herrenschmidt b...@kernel.crashing.org cc: Anton Blanchard an...@samba.org cc: Kumar Gala ga...@kernel.crashing.org -- 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/20110404215755.ge3...@dannf.org
Re: Stable update of linux-2.6
On Sun, Apr 03, 2011 at 07:33:39AM +1000, Benjamin Herrenschmidt wrote: On Sun, 2011-04-03 at 00:10 +0530, Kamalesh Babulal wrote: * dann frazier da...@dannf.org [2011-04-02 11:23:03]: 2.6.32.36 also fails to build on powerpc/SMP: CC arch/powerpc/kernel/crash.o arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode': arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in this function) arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is reported only once arch/powerpc/kernel/crash.c:176: error: for each function it appears in.) make[1]: *** [arch/powerpc/kernel/crash.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 This build is not reproducible locally, can you please send the .config file. Smells to me like a 32-bit build... Yep, it is. Current upstream has the function crash_kexec_wait_realmode() protected by: #ifdef CONFIG_PPC_STD_MMU_64 Maybe that is missing in .32.36 ? You can disable CONFIG_CRASH_DUMP as a workaround. Is it that useful anyways on 32-bit ? (Does it even work ?) I'm just reporting this as a build-time regression in stable as it caused an issue when we merged recent stable updates into the Debian tree. I've never personally tried to configure kdump on powerpc. fwiw, a quick test shows that kexec doesn't work on my test box: dannf@macmini:~$ sudo kexec -l /boot/vmlinux-2.6.32-5-powerpc --append=root=/dev/hda3 ro --initrd=/boot/initrd.img-2.6.32-5-powerpc get_memory_ranges(): Unsupported platform Could not get memory layout -- 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/20110404221055.gf3...@dannf.org
Re: Stable update of linux-2.6
2.6.32.36 also fails to build on powerpc/SMP: CC arch/powerpc/kernel/crash.o arch/powerpc/kernel/crash.c: In function 'crash_kexec_wait_realmode': arch/powerpc/kernel/crash.c:176: error: 'paca' undeclared (first use in this function) arch/powerpc/kernel/crash.c:176: error: (Each undeclared identifier is reported only once arch/powerpc/kernel/crash.c:176: error: for each function it appears in.) make[1]: *** [arch/powerpc/kernel/crash.o] Error 1 make: *** [arch/powerpc/kernel] Error 2 -- 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/20110402172303.gb2...@dannf.org
another stable kernel update
We've fixed the powerpc FTBFS, an XFS regression and a few other issues, so I'll plan to upload -33 tomorrow. -- 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/20110401005934.ga26...@dannf.org
dropping hppa from testing
The Debian/HPPA porters recently had a discussion[1] about the future of the port. We reached the consensus that, due to limited resources and end-of-life hardware, we should no longer spend our energy on maintaining an official debian port, or creating our own stable releases. Instead, we will focus our efforts on maintaining an installable/useable unstable distribution, likely making use of the debian-ports infrastructure. To that end, I'd like to request that hppa be removed from testing. This by no means reduces our commitment to the support life of the current stable release (lenny), which will still be maintained for at least 1 more year. [1] http://lists.debian.org/debian-hppa/2011/02/msg2.html -- 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/20110203182425.gb11...@dannf.org
Re: Squeeze updates for ia32-libs{,-gtk}
On Wed, Jan 19, 2011 at 07:26:59PM +0100, Philipp Kern wrote: On Wed, Jan 19, 2011 at 07:24:01AM +0100, Thijs Kinkhorst wrote: On Tuesday 18 January 2011 14:54:12 Philipp Kern wrote: I've refreshed the packages and added two changes that I think are important for proper support for the squeeze lifetime: adding security.debian.org to the mirrors list and not disabling secure APT to download the packages. Please see attached debdiffs, built packages are here: http://loeki.tv/~thijs/ia32/ The upload should go through unstable, please ping me after it happened. It happened. Both unblocked. I'm not updating ia32-libs-core since the packages contained in that have seen no significant changes since the last upload. ia32-libs-core is a pain, though. It has a popcon of 0, and I'm pretty sure that nobody actually tested its operation, not even the maintainers. I wonder if we should remove any traces of ia64 in the ia32* stuff instead. Yeah, but it's too late in the freeze for that now, I think? I don't know. Given that there's no RC bug: maybe it is too late. *sigh* fyi, I ran a quick test on ia64. The current bits just segfault: dannf@zx6000:~$ file hello hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, stripped dannf@zx6000:~$ dpkg -l | grep ia32 ii ia32-libs 20110117ia32 shared libraries for use on amd64 and ia64 systems ii ia32-libs-core 20101207core ia32 shared libraries for use on ia64 systems dannf@zx6000:~$ ./hello Segmentation fault I found that just calling the linker segfaulted: dannf@zx6000:~$ /lib32/ld-2.11.2.so Segmentation fault I tried copying over the latest ld from an i386/sid system (2.11.2-8), and that seemed to improve things: dannf@zx6000:~$ sudo cp lib/ld-2.11.2.so /lib32/ dannf@zx6000:~$ ./hello ./hello: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory dannf@zx6000:~$ LD_LIBRARY_PATH=/lib32 ./hello Hello, world! -- 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/20110121045618.gb18...@dannf.org
updated text
Maks I discussed this on IRC and drafted the following text which we believe is ready for inclusion: Debian 6.0 will be the final Debian release to include Linux kernel virtualization featuresets outside of mainline. This means that the OpenVZ and Linux-Vserver featuresets should be considered deprecated, and users should migrate to linux-2.6 upstream merged virtualization solutions like KVM, Linux Containers or Xen. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101102154313.ga24...@dannf.org -- 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/20101102154313.ga24...@dannf.org
Re: Releasability of the HPPA port
On Fri, Aug 06, 2010 at 11:23:08AM +0200, Thibaut VARÈNE wrote: Le 6 août 2010 à 03:46, dann frazier a écrit : On Fri, Aug 06, 2010 at 03:30:41AM +0200, Philipp Kern wrote: Dear HPPA porters, dear HPPA port users, the Release Team is currently wondering if it makes sense to release with HPPA as a regular stable architecture with squeeze. It might be that it is not up to the standards of a regular Debian release. We seem to chase random segmentation faults, causing multiple give-backs to eventually yield a built package. I realize this doesn't address the larger concerns you mention, but.. I've found that a workstation I recently acquired (a c3700) seems to reliably build packages that reliably fail on our existing buildds (subversion, for one). I assume CPU architecture differences allow this box to be immune to the issues causing these builds to fail. Out of curiosity, are you running a 32 or 64bit kernel? It seems weird to me though that C3700 would work and not J6700, since ISTR their respective hardware don't differ that much... Sorry for the delay - wasn't near the machine to check. It is 32-bit. I'll try a 32-bit kernel on peri to see if that changes anything. Due to the formfactor, I don't think HP would be able to host it and my upstream bandwidth at home is too limited. If the project wanted to make this machine a buildd and find hosting for it, I'd be willing to maintain the buildd. IIRC C3700 is B2000-style box. It can be racked sideways with L-shapped support rails. My previous hosting offer still stands, although I believe it might not be the easiest/closest one for you ;-) HTH -- dann frazier -- 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/20100813014508.gb10...@lackof.org
Re: Releasability of the HPPA port
On Fri, Aug 06, 2010 at 03:30:41AM +0200, Philipp Kern wrote: Dear HPPA porters, dear HPPA port users, the Release Team is currently wondering if it makes sense to release with HPPA as a regular stable architecture with squeeze. It might be that it is not up to the standards of a regular Debian release. We seem to chase random segmentation faults, causing multiple give-backs to eventually yield a built package. I realize this doesn't address the larger concerns you mention, but.. I've found that a workstation I recently acquired (a c3700) seems to reliably build packages that reliably fail on our existing buildds (subversion, for one). I assume CPU architecture differences allow this box to be immune to the issues causing these builds to fail. Due to the formfactor, I don't think HP would be able to host it and my upstream bandwidth at home is too limited. If the project wanted to make this machine a buildd and find hosting for it, I'd be willing to maintain the buildd. Especially this is also causing concerns from a security building point of view, as autobuilding has to work for this. If it's not entirely up to our standards, would a separate suite, like it has been done in the past for etch-m68k, help having some sort of release that can be updated independently from the main stable release? Such a suite could also be useful to land larger changes than normally allowed for stable and maybe to continue the hppa port from a stable foundation for some time. I think we do agree that it will be included into stable for the last time. Kind regards, Philipp Kern -- dann frazier -- 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/20100806014649.ga18...@lackof.org
Re: libmikmod/stable on hppa version problem
On Tue, Jul 27, 2010 at 04:55:43PM -0400, Moritz Muehlenhoff wrote: On Tue, Jul 27, 2010 at 10:46:48PM +0200, Thijs Kinkhorst wrote: On freed 16 July 2010, Adam D. Barratt wrote: I guess that only a manual build of a binNMU old scheme on hppa will save you from having a sourceful upload and rebuilds on all architectures. Probably the hppa buildd admins (in Cc) can help here? One issue is that any further updates to the package, either via security or directly through p-u, will have the same problem. The hand-build will fix this particular instance but the source versioning will need to be carefully chosen for any future update in order to avoid the issue occurring again (-6.0.2 not being built from the -6 source also rather violates the principle of least surprise.) Since the issue is still present I'll just make a new sourceful rebuild with a DSA -2 tomorrow. We'll need to uÃpdate libmikmodanyway, part of the original fix was wrong, see the report from Tomas Hoger. great - fyi, I tried to do binNMUs, but I couldn't get the process right. I received rejections for not having the matching source in the archive (also tried adding versioned Source: entries for bin packages in the control file to no avail). -- dann frazier -- 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/20100727212324.gb10...@lackof.org
Re: libmikmod/stable on hppa version problem
On Tue, Jul 27, 2010 at 06:15:23PM -0400, Moritz Muehlenhoff wrote: On Tue, Jul 27, 2010 at 03:23:24PM -0600, dann frazier wrote: On Tue, Jul 27, 2010 at 04:55:43PM -0400, Moritz Muehlenhoff wrote: On Tue, Jul 27, 2010 at 10:46:48PM +0200, Thijs Kinkhorst wrote: On freed 16 July 2010, Adam D. Barratt wrote: I guess that only a manual build of a binNMU old scheme on hppa will save you from having a sourceful upload and rebuilds on all architectures. Probably the hppa buildd admins (in Cc) can help here? One issue is that any further updates to the package, either via security or directly through p-u, will have the same problem. The hand-build will fix this particular instance but the source versioning will need to be carefully chosen for any future update in order to avoid the issue occurring again (-6.0.2 not being built from the -6 source also rather violates the principle of least surprise.) Since the issue is still present I'll just make a new sourceful rebuild with a DSA -2 tomorrow. We'll need to uÃpdate libmikmodanyway, part of the original fix was wrong, see the report from Tomas Hoger. great - fyi, I tried to do binNMUs, but I couldn't get the process right. I received rejections for not having the matching source in the archive (also tried adding versioned Source: entries for bin packages in the control file to no avail). Ok. What version number should I use for the new upload so that it's more recent than the misnamed hppa build? 3.1.11-6.0.1+lenny1 seems like it would work to me. -- dann frazier -- 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/20100727225504.gc10...@lackof.org
Re: libmikmod/stable on hppa version problem
On Thu, Jul 15, 2010 at 11:52:28PM +0200, Luk Claes wrote: On 07/15/2010 10:04 PM, Adam D. Barratt wrote: Hi, On Thu, 2010-07-15 at 21:04 +0200, Thijs Kinkhorst wrote: We have run into a problem with libmikmod on stable-security in the most recent DSA. That was released with the version number 3.1.11-a-6+lenny1, following the usual scheme. However, as it seems hppa had a version that used the old binNMU numbering scheme: 3.1.11-a-6.0.1, which is considered newer: http://packages.debian.org/lenny/libmikmod2 [also visible on http://release.debian.org/proposed-updates/stable.html fwiw] Is there a way that we can solve this for hppa, or is the only way out a new DSA update for all 12 archs with only change a new version number? I've been trying to think of an answer that doesn't necessitate a complete rebuild, but haven't come up with one thus far. Any solution that involves a sourceful upload will need to be rebuilt on all architectures. I'm not sure if the security archive / buildd setup makes it possible to only attempt to build a package on a restricted set of architectures; even if it does, as soon as the package is accepted in to proposed-updates the remaining architectures will then be auto-built for stable. I guess that only a manual build of a binNMU old scheme on hppa will save you from having a sourceful upload and rebuilds on all architectures. Probably the hppa buildd admins (in Cc) can help here? I can certainly do a build/upload if someone points me to the binNMU old scheme process :) -- dann frazier -- 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/20100715215716.gb10...@lackof.org
Re: Migriting haskell-platform
On Mon, May 24, 2010 at 08:11:02AM -0600, dann frazier wrote: On Thu, May 20, 2010 at 02:31:29PM +0200, Joachim Breitner wrote: Hi, Am Mittwoch, den 19.05.2010, 21:31 +0100 schrieb Adam D. Barratt: So far as I can see, libghc6-configfile-dev's breakage is a result of the lack of missingh, so your analysis looks correct. thanks. @hppa-build-admins: the previous version of missingh built correctly on peri, the current version failed on lafayette. Please try again on peri, the higher processor speed could make the difference. Sorry for the late response, I've given back missingh. I can't specify the buildd that will pick it up next, but there are two other sid buildds besides lafayette. fyi, build was successful. -- dann frazier -- 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/20100526145039.ga24...@lackof.org
Re: Migriting haskell-platform
On Thu, May 20, 2010 at 02:31:29PM +0200, Joachim Breitner wrote: Hi, Am Mittwoch, den 19.05.2010, 21:31 +0100 schrieb Adam D. Barratt: So far as I can see, libghc6-configfile-dev's breakage is a result of the lack of missingh, so your analysis looks correct. thanks. @hppa-build-admins: the previous version of missingh built correctly on peri, the current version failed on lafayette. Please try again on peri, the higher processor speed could make the difference. Sorry for the late response, I've given back missingh. I can't specify the buildd that will pick it up next, but there are two other sid buildds besides lafayette. -- dann frazier -- 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/20100524141102.ga17...@lackof.org
Re: hppa and haskell packages
On Wed, Mar 24, 2010 at 05:30:43PM +0100, Joachim Breitner wrote: Hi, I???m well aware that some haskell packages are quite heavy to build. But I???m surprised to see hppa fail where arches like armel and mips* cope. Is there something else broken? These packages??? build failure on hppa prevent a testing migration: hlint (hppa, needs haskell-src-exts) These packages could be added to testing if they would build on hppa: haskell-regex-tdfa (hppa, mipsel) haskell-src-exts (hppa, armel, mips, mipsel, s390) These packages never built on hppa, so the build failure does not hinder the migrations: xmonad-contrib agda Can you possibly try the builds again on a stronger hppa buildd box, if available? I started an agda build on paer 8 days ago - it is still running. Memory does not appear to be an issue (swap is available, but unused). Throwing more CPU at it might improve things - but I don't think a CPU exists with enough cycles to make it build in any reasonable amount of time. strace of the ghc6 process shows an infinite loop of: rt_sigreturn() = -14059 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -14059 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -14059 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -14059 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -14059 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -14059 I don't think the hardware is the issue here - this has got to be a bug somewhere. -- dann frazier -- 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/20100324192453.ga26...@lackof.org
Re: Timeouts
On Mon, Mar 08, 2010 at 10:56:53PM +0100, Joachim Breitner wrote: Hi, Am Montag, den 08.03.2010, 22:42 +0100 schrieb Joachim Breitner: This might be a solution, yes, though I would prefer not to do this. You've managed to get highlighting-kate's build times down, making it build everywhere but on armel (where it got tried on a slw buildd, let's see if this gets better on one of the faster boxes). We have similar problem with agda, could you have a look at that? Maybe Iain Lane can comment on agda. 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? I put that in to cause agda to fail and stop retrying, adn then bumped it back up. The timeout is normally 300 minutes, but agda would continue to generate output even when it had been wedged for over 12 hours. -- dann frazier -- 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/20100309174654.gb2...@lackof.org
Re: Timeouts
[Adding debian-hppa to the CC, since it may require porter help] On Tue, Mar 09, 2010 at 06:38:23PM +, Iain Lane wrote: On Tue, Mar 09, 2010 at 10:46:54AM -0700, dann frazier wrote: On Mon, Mar 08, 2010 at 10:56:53PM +0100, Joachim Breitner wrote: Hi, Am Montag, den 08.03.2010, 22:42 +0100 schrieb Joachim Breitner: This might be a solution, yes, though I would prefer not to do this. You've managed to get highlighting-kate's build times down, making it build everywhere but on armel (where it got tried on a slw buildd, let's see if this gets better on one of the faster boxes). We have similar problem with agda, could you have a look at that? Maybe Iain Lane can comment on agda. 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? I put that in to cause agda to fail and stop retrying, adn then bumped it back up. The timeout is normally 300 minutes, but agda would continue to generate output even when it had been wedged for over 12 hours. I rather suspect that the monotonically increasing memory usage is the problem here. I don't know of a resolution, and the thread with the GHC devs didn't seem to offer anything up. Anyone have any ideas? Dann, did you have a look at the memory usage when the build was going on by any chance? Well, its stuck again on penalosa, so let me check.. da...@penalosa:~$ free total used free sharedbuffers cached Mem: 411700424024401714564 0 7358401202828 -/+ buffers/cache: 4637723653232 Swap: 2650684 442650640 And it doesn't appear to be increasing. ghc is taking ~90% of the cpu, top suggests its mostly system usage: top - 21:49:22 up 10 days, 3:15, 2 users, load average: 1.42, 1.45, 1.39 Tasks: 62 total, 2 running, 60 sleeping, 0 stopped, 0 zombie Cpu(s): 0.7%us, 99.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 4117004k total, 2402860k used, 1714144k free, 735840k buffers Swap: 2650684k total, 44k used, 2650640k free, 1202832k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 819 buildd20 0 224m 198m 21m R 92.2 4.9 48:31.18 ghc 31922 dannf 20 0 3804 1908 1536 R 0.3 0.0 0:00.51 top 1 root 20 0 2144 792 652 S 0.0 0.0 0:20.16 init 2 root 20 0 000 S 0.0 0.0 0:00.00 kthreadd 3 root 20 0 000 S 0.0 0.0 0:00.13 ksoftirqd/0 strace shows ghc looping here: --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x40002b28) = -513 --- SIGVTALRM (Virtual timer expired) @ 0 (0) --- rt_sigreturn() = -819 Anyway, this seems to be something that was introduced with 6.12. I wonder what we can do about this, besides p-a-s. Iain -- dann frazier -- 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/20100309215414.gb9...@lackof.org
Re: Uploading linux-2.6
On Thu, Jan 28, 2010 at 10:50:16PM +, Ben Hutchings wrote: On Mon, 2010-01-25 at 20:19 +0100, Andreas Barth wrote: * Ben Hutchings (b...@decadent.org.uk) [100125 20:14]: On Mon, Jan 25, 2010 at 08:02:31PM +0100, Andreas Barth wrote: * Julien Cristau (jcris...@debian.org) [100125 19:27]: On Mon, Jan 25, 2010 at 18:56:47 +0100, Luk Claes wrote: I guess this means that the next version is no candidate for the release unless it gets a stable ABI (versioning) and should block the kernel from migrating for the time being? The 2.6.30 kernel and the current 2.6.32 one aren't candidates either, so I'm not sure what difference blocking the next one makes. That our testing users don't have to life with strange error messages they wouldn't get if the abi would be bumped properly. OK, maybe we should start numbering ABIs with this next version. I'd appreciate that very much. There has been some argument over whether we should do this or not. Bastian and Max seem to think that many more ABI-changing config changes will still be needed seems likely and do not want to start numbering yet. I'm not convinced that changing the ABI number repeatedly in testing/unstable will even hurt that much since we no longer have to worry about dependent module packages in the archive. It may add to cruft on users' systems but this can be fixed after a reboot with 'apt-get autoremove'. yeah, i think people running sid/testing who do use oot modules shouldn't have much problem w/ frequent module rebuilds - esp if the abi is silently changing and they may really need to rebuild anyway. [Like with a module on my mythbox recently :)] I do want to see this argument resolved before building and uploading, but I also don't want to hold back security and stability fixes. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Wed, Jan 13, 2010 at 10:10:28AM +0100, Frans Pop wrote: On Monday 11 January 2010, Frans Pop wrote: On Thursday 24 December 2009, Frans Pop wrote: For stable (20090123lenny5) all arches except mips were successful. I've already mailed the mips buildd maintainers. I've not heard anything back from the mips buildd maintainers, despite sending several mails. Please retry on a different buildd than ball. It's now built correctly. Problem (error in regexps) has been identified and fixed for future uploads. I'm currently uploading refreshed linux-kernel-di packages built against 2.6.26-21. Once accepted, I can go ahead and refresh d-i. Please let me know if there's any other pending d-i changes for stable that I should wait for. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [(O)SRM] debian-installer update uploaded for Etch and Lenny
On Thu, Dec 24, 2009 at 03:52:26PM +0100, Frans Pop wrote: As all packages needed to build D-I were now available, I have uploaded for both stable and oldstable. An accept is not needed; apparently D-I gets an automatic accept due to by-hand processing of the image tarballs. For oldstable (20070308etch6) all arches have been built successfully. For stable (20090123lenny5) all arches except mips were successful. I've already mailed the mips buildd maintainers. I will run some installation tests over the next few days. If I don't follow up on this mail it means the tests were successful. Are there already plans to do the point releases? It would be great if it could be fairly soon. Changes for stable (Lenny): - improved mirror selection: better support for installation of oldstable and from archive.debian.org - updated mirror lists - update of system date from NTP now also works correctly if the system date after boot is before 1-1-1970 - [arm/armel] QNAP NAS devices: leds and buzzer work again during installs (qcontrol needed update after previous stable update of udev) - [s390] booting (IPL) from CD fixed [1] There's no kernel update for the installer for Lenny. It's probably not needed either, but maybe Dann will want to do an extra D-I upload to include updated kernel udebs after the next kernel upload for p-u. yeah, we've added some new hardware support (intel nics), so I can take care of another d-i update once the kernel in p-u-new has been accepted/built everywhere. The acceptance of this package is currently on hold due to the debian-installer/mips build failure. Is the cause of that known? -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Uploading kernel packages to unstable
On Thu, Dec 24, 2009 at 03:44:54AM +, Ben Hutchings wrote: I would like to upload linux-2.6 tomorrow, fixing the build failure on ia64 and a couple of security bugs. There should be no new binary packages. Any objections? (Dan, do you have vserver ready to add?) Yes, I do. I'll go ahead and commit it. If you do want to avoid new binary packages, feel free to revert before uploading. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [(old)stable] D-I kernel updates
On Thu, Dec 17, 2009 at 05:32:03PM +0100, Frans Pop wrote: Hi Dann, I'm preparing to upload a new version of D-I for both stable and oldstable and was wondering whether or not to update the kernel udebs. Are the current kernel images in (o-)p-u the versions intended for the next point releases? Anything in them worth the effort? p-u has 2.6.26-20; o-p-u has 2.6.18.dfsg.1-26etch1. For both all arches look to be up-to-date, so building and uploading the kernel udebs will be trivial. I can take care of that. hey Frans! p-u still needs an update, so I wouldn't bother there. The bits in o-p-u are candidates for the next oldstable release, though I believe they add no additional hardware support. Feel free to resync them though. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [OSRM] D-I kernel updates
On Thu, Dec 17, 2009 at 08:31:02PM +0100, Frans Pop wrote: Please accept the new kernel udebs (linux-kernel-di-*-2.6) I've just uploaded for Etch. done (pending next queue run) After that I guess another run to process p-u-new by FTP masters will be needed to get them in the archive. After that I will upload debian-installer for both stable and oldstable. Cheers, FJP -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Uploading kernel packages to unstable
On Wed, Dec 16, 2009 at 05:54:29PM +, Ben Hutchings wrote: I intend to upload linux-2.6, linux-latest-2.6 and firmware-nonfree tonight. There should be no new binary packages for linux-2.6. Any objections? No objections here. Micah and I have been working w/ vserver upstream and have a patch ready for 2.6.32. Of course, that means new binary packages, so if we want to avoid NEW processing I can hold off on committing... -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Uploading kernel packages to unstable
On Wed, Dec 16, 2009 at 06:30:21PM +, Ben Hutchings wrote: On Wed, Dec 16, 2009 at 11:10:15AM -0700, dann frazier wrote: On Wed, Dec 16, 2009 at 05:54:29PM +, Ben Hutchings wrote: I intend to upload linux-2.6, linux-latest-2.6 and firmware-nonfree tonight. There should be no new binary packages for linux-2.6. Any objections? No objections here. Micah and I have been working w/ vserver upstream and have a patch ready for 2.6.32. Of course, that means new binary packages, so if we want to avoid NEW processing I can hold off on committing... Can you hold that back for the next upload (hopefully with a stable ABI and therefore changing all package names)? Sure. I'll build some packages out-of-band so micah et. al. can get going on some testing in the meantime. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lenny-and-a-half?
On Sun, Nov 22, 2009 at 04:45:16PM +0100, Luk Claes wrote: Martin Michlmayr wrote: * Noah Meyerhans no...@debian.org [2009-11-20 16:58]: Hi all. Is there work under way for a lenny-and-a-half release? Is there a wiki page or other resource listing ongoing tasks, progress, calls for help, etc? I know about http://wiki.debian.org/LennyAndAHalf, but thus far it doesn't have much content. Since nobody else has responded and I have an interest in lenny-and-a-half, let me share my impression of the current status: when the December freeze was announced, some members of the kernel team said that lenny-and-a-half doesn't make sense. This position has apparently not changed even after the freeze has been moved to March. So afaik nobody is working on lenny-and-a-half at the moment. If you're willing to put in some effort I guess the next step would be ask the security and release team whether they'd support it. I'm personally interested in lenny-and-a-half and would be happy to ensure that it works well on ARM. The Release Team currently has its hands full so will probably not be the one to push for a lenny-and-a-half. As long as new hardware support is possible through the general point releases, that is also the preferred way. Though if there is a more general interest in a lenny-and-a-half the Release Team will happily try to help make it happen. A first step is investigating what hardware support is wanted that is not possible via general point releases though. So any input on what new hardware support is missing is appreciated and even more if it's not possible to have that in a general point release (too much changes or too much risk of breakage without going to a newer kernel for instance). +1 - and in the form of a bug report, please. Note that we don't currently have the resources to manage kernel security updates for etch, etch+half, lenny and lenny+half simultaneously. Unless that changes, we can't consider a lenny+half until after February 2010 - which is just before the squFReeze. Also note that the current plan is to try and release 2.6.32 for squeeze, and those packages should install fine in a lenny environment. We might be able to achieve a poor-man's lenny+half by asking users to use the squeeze installer to install lenny, and pull kernel updates from squeeze/squeeze-security? -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: lenny-and-a-half?
On Sun, Nov 22, 2009 at 09:53:21PM +, Martin Michlmayr wrote: * Martin Michlmayr t...@cyrius.com [2009-11-22 21:52]: squeeze, and those packages should install fine in a lenny environment. We might be able to achieve a poor-man's lenny+half by asking users to use the squeeze installer to install lenny, and pull kernel updates from squeeze/squeeze-security? FWIW, that's what I'm planning to do for some ARM machines that are not supported by lenny. I hacked d-i already to install the kernel from my repo. ... the big problem with this is, of course, that the squeeze kernel doesn't seem to have any security support either. I think that we can/should change that during the freeze - though it is probably appropriate to fix the majority of security issues, which tend to be of low severity, via sid w/ appropriate urgencies. -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Bug#541963: Only 2 packages remaining
On Sat, Nov 21, 2009 at 02:24:07PM +0100, Stéphane Glondu wrote: Josselin Mouette a écrit : now that lablgtk2 supports gtksourceview 2.x, could you please port matita and frama-c to the new version? These are the last two packages to use it. I???m going to request the removal of gtksourceview 1.x soon nevertheless, so this would make matita and frama-c uninstallable. There is a pending (small) transition of ocaml-sqlite3 + lwt + ocsigen + nurpawiki that I would like to see finished before proceeding with lablgtk2 2.14. This is going on for 1 month, and stalled because of hppa build issues. Only the hppa build of nurpawiki is missing, now. It is in incoming. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of the hppa buildds
On Thu, Nov 12, 2009 at 07:57:21AM +0100, Luk Claes wrote: Hi During 6 days already, there is nothing built on hppa. This is obviously blocking a lot of packages to migrate to testing and can not continue much longer. What's the status of fixing the issues that caused this and how long do you think this will continue? hey Luk, Yeah - there was some bad communication between lamont and myself. I agreed to take over buildd maintenance of peri/penalosa, but the baton got lost in the handoff. Things are back in order. Today I finished getting the new penalosa setup as a buildd, and I've resurrected peri which appeared to be having problems talking to w-b. I've worked around the libstdc++/apt problem on both by downgrading to a working version. Expect a lot of debs in incoming RSN. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Status of the hppa buildds
On Thu, Nov 12, 2009 at 08:04:02AM -0500, Carlos O'Donell wrote: On Thu, Nov 12, 2009 at 5:29 AM, Domenico Andreoli ca...@debian.org wrote: What's the status of fixing the issues that caused this and how long do you think this will continue? i suppose the cause is bug #554574 which lets apt unusable. installing previous release of libstdc++6 4.4.2-1 makes apt work again but... read the bug report. The libstdc++ failures are the highest priority item on my list. I'm investigating the failure. Great - I'll leave libstdc++ downgraded on the buildds in the meantime. Let me know when it is safe to upgrade. Please note that the gcj runtime failures have been triaged and fixed by a set of patches I delivered to debian-glibc. Excellent! -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: increasing default value of mmap_min_addr
[Adding qemu maintainers to CC] On Thu, Oct 22, 2009 at 10:18:04AM +0100, Mark Brown wrote: On Wed, Oct 21, 2009 at 02:54:59PM -0600, dann frazier wrote: The kernel team is discussing the possibility of increase the default value of mmap_min_addr in lenny (it has already been done for sid). Obviously this has implications for the wine and dosemu packages (are there others?) qemu I believe (or some other thing used in OpenEmbedded builds). qemu folks - for background see: http://lists.debian.org/debian-release/2009/10/msg00212.html http://lists.debian.org/debian-kernel/2009/10/msg00886.html -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: increasing default value of mmap_min_addr
On Thu, Oct 22, 2009 at 12:31:32PM +0300, Riku Voipio wrote: On Thu, Oct 22, 2009 at 10:18:04AM +0100, Mark Brown wrote: On Wed, Oct 21, 2009 at 02:54:59PM -0600, dann frazier wrote: The kernel team is discussing the possibility of increase the default value of mmap_min_addr in lenny (it has already been done for sid). Obviously this has implications for the wine and dosemu packages (are there others?) qemu I believe (or some other thing used in OpenEmbedded builds). It has been fixed in qemu upstream. How was it fixed - does it tweak the tunable, or work in spite of it? Is the fix something reasonable for a stable update? -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: increasing default value of mmap_min_addr
On Wed, Oct 21, 2009 at 02:54:59PM -0600, dann frazier wrote: hey, The kernel team is discussing the possibility of increase the default value of mmap_min_addr in lenny (it has already been done for sid). Obviously this has implications for the wine and dosemu packages (are there others?) The current proposal is to notify users in the next kernel DSA that we will be making this change in the next point release and point users to a wiki page that explains the problem and describes how to bump the setting in the meantime. I saw some discussion in #505247 about maybe adding a debconf question/stub file in /etc/sysctl.d to drop this value on a per-package basis. Do wine/dosemu have plans to do this? I wonder if we should consider including something like that in stable? I've created the following wiki page, which I plan to reference in the next kernel security advisory (will go out RSN): http://wiki.debian.org/mmap_min_addr Please review for accuracy. Maintainers should pay special attention to the application-specific notes towards the end. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
increasing default value of mmap_min_addr
hey, The kernel team is discussing the possibility of increase the default value of mmap_min_addr in lenny (it has already been done for sid). Obviously this has implications for the wine and dosemu packages (are there others?) The current proposal is to notify users in the next kernel DSA that we will be making this change in the next point release and point users to a wiki page that explains the problem and describes how to bump the setting in the meantime. I saw some discussion in #505247 about maybe adding a debconf question/stub file in /etc/sysctl.d to drop this value on a per-package basis. Do wine/dosemu have plans to do this? I wonder if we should consider including something like that in stable? -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Thu, Sep 10, 2009 at 12:10:28PM -0400, Carlos O'Donell wrote: On Tue, Sep 8, 2009 at 11:53 PM, dann frazierda...@dannf.org wrote: We have been running with UP kernels for quite some time, and they haven't proven to be any more stable. Most recently I've upgraded peri/penalosa to 2.6.31-rc6-based kernels since they were inclusive of the various changes I was pointed to on this list (thanks John/Helge). Where exactly did you get this kernel, do you have a URL reference? peri has been surprisingly stable - uptime of 2 weeks so far, and it seems to be under pretty steady build load. That sounds great. penalosa is a different story - it has been very unstable with uptimes of several hours at most. The hardware/kernel packages are identical to that of peri (afaict), so I'm not sure why. The failure mode results in infinite panics being printed to the console - but every time I've seen it I haven't had enough console history to see the beginning of this crash. I am now logging the console to see if I can capture that. It is of course possible that penalosa is having hardware problems - but I don't know of a way to prove this conclusively. We could maybe swap disks to see if the failure follows the disks or the hardware (though that doesn't eliminate a disk problem). The way to prove this is to put an instrumented kernel on penalosa. I think the way forward is: * You get me a console trace. After about a week of loaded uptime, penalosa returned to instability over the weekend. It began with an Illegal instruction leading to a panic: http://people.debian.org/~dannf/penalosa/penalosa.0 I then rebooted it, and the console was hung immediately after boot: http://people.debian.org/~dannf/penalosa/penalosa.1 Note the rc.local segfault there. I rebooted it again, and it crashed after only a few minutes: http://people.debian.org/~dannf/penalosa/penalosa.2 peri (identical hardware/kernel) has been up for about 20 days now. * I give you an instrumented kernel/initrd. * Repeat. Are you allowed to boot a kernel/initrd that I send you? Note that I don't monitor the build output, so I don't know if we're still seeing the same level of random segfaults in userland. LaMont? Cheers, Carlos. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Mon, Sep 14, 2009 at 03:36:48PM -0400, Carlos O'Donell wrote: On Mon, Sep 14, 2009 at 1:26 PM, dann frazier da...@dannf.org wrote: After about a week of loaded uptime, penalosa returned to instability over the weekend. It began with an Illegal instruction leading to a panic: Â http://people.debian.org/~dannf/penalosa/penalosa.0 I then rebooted it, and the console was hung immediately after boot: Â http://people.debian.org/~dannf/penalosa/penalosa.1 Note the rc.local segfault there. I rebooted it again, and it crashed after only a few minutes: Â http://people.debian.org/~dannf/penalosa/penalosa.2 Exactly how did you install the kernel and what sources were used to build it? I used dpkg -i to install it, sources are here: http://people.debian.org/~dannf/tmp/ To create an unpacked source tree, you can: dget http://people.debian.org/~dannf/tmp/linux-2.6_2.6.31~rc6-1~experimental.1~snapshot.14160.dsc cd linux-2.6-2.6.31~rc6 ./debian/rules setup It is a pretty vanilla 2.6.31-rc6. The trace looks familiar (crash in unwind_once), and I thought it had been fixed by Kyle already. I will put together a kernel for you to boot on penalosa. I don't see any obvious fixes between 2.6.31-rc6 2.6.31 - is the fix in kyle's tree? peri (identical hardware/kernel) has been up for about 20 days now. Please issue a sysrq-t (ctrl^c, send break, t) on peri's console and tell me if it crashes the kernel? Yes, it does. (echo t /proc/sysrq-trigger didn't though, for whatever reason). peri login: [1714067.644000] SysRq : Show State [1714067.644000] taskPC stack pid father [1714067.644000] init S 40103568 0 1 0 0x0010 [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [401ce628] __follow_mount+0x50/0xe0 [1714067.644000] [401ce854] do_lookup+0x7c/0x280 [1714067.644000] [401ce5c8] path_put+0x38/0x48 [1714067.644000] [40104ed4] syscall_exit+0x0/0x14 [1714067.644000] [1714067.644000] kthreadd S 40103568 0 2 0 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [401c06c8] kmem_cache_alloc+0x70/0xc0 [1714067.644000] [1714067.644000] ksoftirqd/0 S 40103568 0 3 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] events/0 S 40103568 0 4 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] cpusetS 40103568 0 5 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] khelper S 40103568 0 6 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] netns S 40103568 0 9 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] async/mgr S 40103568 010 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] kpowerswd S 40103568 052 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] kintegrityd/0 S 40103568 085 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] kblockd/0 S 40103568 087 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] kseriod S 40103568 091 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice+0x170/0x208 [1714067.644000] [1714067.644000] khungtaskdS 40103568 0 113 2 0x [1714067.644000] Backtrace: [1714067.644000] [401121d8] schedule+0x398/0x428 [1714067.644000] [4013ce10] set_user_nice
Re: open issues with the hppa port
On Fri, Sep 11, 2009 at 11:10:23AM -0400, Carlos O'Donell wrote: On Thu, Sep 10, 2009 at 1:06 PM, dann frazierda...@dannf.org wrote: I think the way forward is: * You get me a console trace. * I give you an instrumented kernel/initrd. * Repeat. *nod* Trimming CC. fyi, now that I've started logging the console, penalosa has become strangely stable: da...@penalosa:~$ uptime  16:57:22 up 1 day, 20:00,  2 users,  load average: 1.99, 2.46, 2.30 The first several boots on this kernel wouldn't make it more than an hour or two. Hey! Problem solved! ;-) Please keep me updated on any crashes. How many debian buildd's are there for hppa? What are their names? What hardware are they? Can you get me a detailed list? Debian runs 4 hppa boxes, and I think all of them are building these days. lafayette is hosted by Thibaut @ ESIEE - I'm not sure what hardware it is or what kernel it runs. It only does security builds as I understand it, which should keep the load relatively low. The remaining boxes are hosted here in Fort Collins. paer - this is supposed to be a porterbox (developer access, no buildd), but we've been running a buildd on it for a while because of its relative stability. It is an A-class (PA8700 - 750MHz) paer runs a standard lenny kernel (2.6.26-based). peri and penalosa are identical boxes - both model 9000/785/J6700. They are the ones we currently have running 2.6.31-rc6 kernels. Are you allowed to boot a kernel/initrd that I send you? I don't see why not, assuming these changes don't add a risk of producing bad binaries. To be safe, I think we should be throwing away the packages built when running the instrumented kernel. Is there a way we can do that? Can you find that out for me? That would probably need to be answered by LaMont - he's the buildd admin for these boxes. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Fri, Sep 11, 2009 at 02:06:36PM -0400, Carlos O'Donell wrote: On Fri, Sep 11, 2009 at 1:06 PM, dann frazierda...@dannf.org wrote: lafayette is hosted by Thibaut @ ESIEE - I'm not sure what hardware it is or what kernel it runs. It only does security builds as I understand it, which should keep the load relatively low. Thibaut indicates that this machine may be doing stable and security builds. Whom do I contact to find that out? debian-admin probably (cc'd) The remaining boxes are hosted here in Fort Collins. paer - this is supposed to be a porterbox (developer access, no buildd), but we've been running a buildd on it for a while because of its relative stability. It is an A-class (PA8700 - 750MHz) paer runs a standard lenny kernel (2.6.26-based). peri and penalosa are identical boxes - both model 9000/785/J6700. They are the ones we currently have running 2.6.31-rc6 kernels. What happened to sarti? Loosing a box like that would certainly add load to the others. According to db.debian.org: Status:down: dies in firmware (2007-11) Are you allowed to boot a kernel/initrd that I send you? I don't see why not, assuming these changes don't add a risk of producing bad binaries. To be safe, I think we should be throwing away the packages built when running the instrumented kernel. Is there a way we can do that? Can you find that out for me? That would probably need to be answered by LaMont - he's the buildd admin for these boxes. OK, I'll wait for LaMont to comment. Cheers, Carlos. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Fri, Sep 11, 2009 at 02:01:24PM -0600, LaMont Jones wrote: On Fri, Sep 11, 2009 at 02:06:36PM -0400, Carlos O'Donell wrote: On Fri, Sep 11, 2009 at 1:06 PM, dann frazierda...@dannf.org wrote: What happened to sarti? Loosing a box like that would certainly add load to the others. Sarti failed to power on one day. Are you allowed to boot a kernel/initrd that I send you? I don't see why not, assuming these changes don't add a risk of producing bad binaries. To be safe, I think we should be throwing away the packages built when running the instrumented kernel. Is there a way we can do that? Can you find that out for me? That would probably need to be answered by LaMont - he's the buildd admin for these boxes. OK, I'll wait for LaMont to comment. Simplest way is to change ~buildd/.forward-porters (or whatever it is) to not send the logs to me. second best would be to tell me what not to upload. :-( That would prevent it from getting uploaded, but won't that package get marked as built, preventing other buildds from trying? -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
[correcting lamont's e-mail] LaMont: have you been seeing further random segfault bugs on peri/penalosa over the past week or two? Is this something you can monitor for us? Rest inline.. On Thu, Sep 10, 2009 at 12:10:28PM -0400, Carlos O'Donell wrote: On Tue, Sep 8, 2009 at 11:53 PM, dann frazierda...@dannf.org wrote: We have been running with UP kernels for quite some time, and they haven't proven to be any more stable. Most recently I've upgraded peri/penalosa to 2.6.31-rc6-based kernels since they were inclusive of the various changes I was pointed to on this list (thanks John/Helge). Where exactly did you get this kernel, do you have a URL reference? The debian kernel team does nightly snapshot builds of our source. I took this source built the parisc64 (UP) flavor: http://people.debian.org/~dannf/tmp/ peri has been surprisingly stable - uptime of 2 weeks so far, and it seems to be under pretty steady build load. That sounds great. da...@peri:~$ uptime 16:56:09 up 15 days, 17:13, 2 users, load average: 2.25, 2.39, 2.31 penalosa is a different story - it has been very unstable with uptimes of several hours at most. The hardware/kernel packages are identical to that of peri (afaict), so I'm not sure why. The failure mode results in infinite panics being printed to the console - but every time I've seen it I haven't had enough console history to see the beginning of this crash. I am now logging the console to see if I can capture that. It is of course possible that penalosa is having hardware problems - but I don't know of a way to prove this conclusively. We could maybe swap disks to see if the failure follows the disks or the hardware (though that doesn't eliminate a disk problem). The way to prove this is to put an instrumented kernel on penalosa. I think the way forward is: * You get me a console trace. * I give you an instrumented kernel/initrd. * Repeat. *nod* fyi, now that I've started logging the console, penalosa has become strangely stable: da...@penalosa:~$ uptime 16:57:22 up 1 day, 20:00, 2 users, load average: 1.99, 2.46, 2.30 The first several boots on this kernel wouldn't make it more than an hour or two. Are you allowed to boot a kernel/initrd that I send you? I don't see why not, assuming these changes don't add a risk of producing bad binaries. Note that I don't monitor the build output, so I don't know if we're still seeing the same level of random segfaults in userland. LaMont? Cheers, Carlos. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Wed, Sep 02, 2009 at 09:55:53AM -0400, Carlos O'Donell wrote: Dave, Kyle, Dann, What's the most stable configuration we can create for the buildds, even if it means crippling them with UP kernels? Sorry Carlos - was on vacation not good about keeping up w/ e-mail. We have been running with UP kernels for quite some time, and they haven't proven to be any more stable. Most recently I've upgraded peri/penalosa to 2.6.31-rc6-based kernels since they were inclusive of the various changes I was pointed to on this list (thanks John/Helge). peri has been surprisingly stable - uptime of 2 weeks so far, and it seems to be under pretty steady build load. penalosa is a different story - it has been very unstable with uptimes of several hours at most. The hardware/kernel packages are identical to that of peri (afaict), so I'm not sure why. The failure mode results in infinite panics being printed to the console - but every time I've seen it I haven't had enough console history to see the beginning of this crash. I am now logging the console to see if I can capture that. It is of course possible that penalosa is having hardware problems - but I don't know of a way to prove this conclusively. We could maybe swap disks to see if the failure follows the disks or the hardware (though that doesn't eliminate a disk problem). Note that I don't monitor the build output, so I don't know if we're still seeing the same level of random segfaults in userland. LaMont? -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: [stable] Adding bnx2x driver in 5.0.3
On Sat, Aug 08, 2009 at 03:18:53PM +0200, Luk Claes wrote: Otavio Salvador wrote: Hello dann, On Sun, Jul 26, 2009 at 4:04 PM, dann frazierda...@debian.org wrote: The bnx2x driver was disabled in lenny due to its use of non-free firmware. I have put together a patch that would reenable this driver in lenny's 2.6.26 kernel, making use of the firmware split-out patch that has gone upstream in Linux 2.6.31-rc releases (and is currently in use in the linux-2.6 2.6.30 packages in sid). Really good news :-) I'd like to see if we can enable the use of this driver in 5.0.3. As far as I can tell, the necessary steps would be: - Update the kernel (obviously) - planned for a p-u upload this week - Backport the necessary changes for firmware-nonfree from sid to add the firmware-bnx2x package AFAICS both above are done? yep. - Update kernel-wedge/stable to include bnx2x if available (are there space issues here?) The space usage is neglitable and I think it can be done with a very small risk of regressions. Be sure to use the kernel-wedge of lenny for building it since we've changed kernel-wedge a lot during the 2.6.30 migration and it is not suitable for the lenny usage. What's the status here? I can get this done tomorrow. - Update d-i in 5.0.3 to incorporate this driver Yes, you got the picture right. I offer help if required. This can probably be done already when kernel-wedge is updated? Please don't delay when unnecessary, TIA. Do we have an estimate for 5.0.3 yet? Reason I ask is that there is typically always some kernel changes queued - security or otherwise. I do understand wanting to have p-u in an always-releasable state, but it can be a lot of throwaway work given that a security update would force us to do a complete rebuild. If we have a target date in mind I could work up a schedule (w/ buffer room) to make sure that all the pieces are in place ahead of time. Thanks Luk. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: open issues with the hppa port
On Thu, Jul 30, 2009 at 01:44:03PM -0400, John David Anglin wrote: On Thu, Jul 30, 2009 at 10:50 AM, Andreas Bartha...@not.so.argh.org wrote: You know your porters mailing list best, but I want to highlight some of the issues: http://lists.debian.org/debian-hppa/2009/07/msg2.html I can't comment on this issue. I hope Dave can? Over the past few weeks, I have been testing 2.6.30.y on three different platforms (c3750, rp3440 and A500-7X). I have run identical 32 and 64-bit kernels on the c3750. To the base system, I have applied a collected set of patches. Except for the typo change recently posted to the parisc linux list, all the changes are now in 2.6.31. Thanks Dave. If you can point me to these changesets, I can get them into the 2.6.30 kernel in sid so that we can start getting wider testing sooner. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[stable] Adding bnx2x driver in 5.0.3
The bnx2x driver was disabled in lenny due to its use of non-free firmware. I have put together a patch that would reenable this driver in lenny's 2.6.26 kernel, making use of the firmware split-out patch that has gone upstream in Linux 2.6.31-rc releases (and is currently in use in the linux-2.6 2.6.30 packages in sid). I'd like to see if we can enable the use of this driver in 5.0.3. As far as I can tell, the necessary steps would be: - Update the kernel (obviously) - planned for a p-u upload this week - Backport the necessary changes for firmware-nonfree from sid to add the firmware-bnx2x package - Update kernel-wedge/stable to include bnx2x if available (are there space issues here?) - Update d-i in 5.0.3 to incorporate this driver -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Lenny Point Release
On Fri, Jun 05, 2009 at 08:25:00PM +0200, Philipp Kern wrote: Hi there, we intend to do a Lenny Point Release on Saturday, June 20th. We will clear stable NEW in the coming days and then declare the point release frozen. Please hurry up if you still need something to go into Lenny at that point. A regression was reported yesterday in the linux-2.6 package in proposed-updates. The bug is #533657. Let me know if you think this is worth a delay of the point release. We have a stable upload planned for immediately after 5.0.2, so if the release continues on schedule, we will be able to direct affected users to the p-u apt source for a fix. I also have two builds in progress - one w/ the fix in #533657 and one with the offending patch reverted - in case you decide to delay. Between the two, I would recommend the reversion approach unless we receive some positive feedback from the reporter of the original issue in time. Poor timing I know - my apologies for letting this regression slip in. -- dann frazier -- 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
On Tue, Jun 16, 2009 at 02:50:27PM -0600, Grant Grundler wrote: On Tue, Jun 16, 2009 at 08:25:31AM +0200, Lucas Nussbaum wrote: ... BTW, that firewall was reviewed and approved by Lamont (a pretty well known DD and buildd maintainer). Thibaut Varene (who is a DD) has offered to host HPPA buildd machines as well but hasn't heard any response to that offer either. (Stepping in ; I had some HPPA-related issues in one of my packages - ruby1.9 - so this is based on my experience with that problems) I think that your email summarizes the problem quite well: there are several people willing to offer buildd hosting, help after someone else has investigated the issues, etc. What debian-hppa currently lacks is someone that is willing to proactively detect issues (looking at packages that failed to build, for example), investigate them, and fix them. This can be done cooperating with the package maintainers, but the HPPA side should take the lead. Yup - this is definitely true. debian-hppa needed alot of prodding to look at buildd failures. The fact that HPPA people are asking the release team what are the problems you are talking about? clearly shows that this is broken: the HPPA people should be knowing more than the release team about HPPA issues. Generalizing one person's response (mine) to represent the group is wrong. However I agree the release team has no one who cares about HPPA involved. And yes, it's up to the release team to track bugs and determine the viability of a release based on outstanding bugs. As I said before, I'm ok with NOT having a stable HPPA release. If someone disagrees, then they need to participate in the release team and help debian-hppa focus on critical buildd failures. ie generate the nag mail listing the HPPA-specific issues that need to be resolved. PS: if you want an HPPA-specific issue to play with, http://experimental.debian.net/fetch.php?pkg=ruby1.9ver=1.9.0.1-5arch=hppastamp=1213563978file=logas=raw might be a good candidate. This did take a long time to resolve. Helge described the root cause (ruby did not support LinuxThreads implementation correctly) and resolution plan (migrate HPPA to NTPL). No phase of this problem sounds trivial to debug or resolve. Based on this, I can argue the HPPA response is reasonable even if is unsatisfactory and frustrating to you (as package maintainer). Do you have another HPPA specific issue? Or maybe just remind the list how to find those issues? (Teach a man to fish...) Are we still having random segfaults on paer? If so - that's be a good one to resolve. Not sure if DSA would be willing to grant (heh) you access to that box, or if we should try running a dummy buildd on another rp2470. -- dann frazier -- 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
On Wed, Jun 17, 2009 at 12:01:31AM +0100, Stephen Gran wrote: This one time, at band camp, dann frazier said: Are we still having random segfaults on paer? If so - that's be a good one to resolve. Not sure if DSA would be willing to grant (heh) you access to that box, or if we should try running a dummy buildd on another rp2470. We're running paer on a uniprocessor kernel right now, and I believe the segfaults have mostly gone away (although buildd should chime in if I'm not remembering right - they will see more of the machine than I do). That being said, if the porters and buildd people are happy to put the SMP kernel back on and give him access, DSA have no objection. Ah - well if paer is running stably, then maybe a less invasive option would be to setup duplicate hardware and run a buildd that uploads to /dev/null. I have an rp2470 (same hw is paer) we could probably setup for that. -- dann frazier -- 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
On Sun, Jun 14, 2009 at 08:29:14PM +0200, Thibaut VARENE wrote: On Fri, Jun 12, 2009 at 5:35 PM, dann frazierda...@dannf.org wrote: On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote: It seems to be related to what machine you actually have. And the load - buildds for unstable seem to trip over issues that we don't see elsewhere. Workload more to the point. Yes, workload is what I meant. Almost all my parisc boxen have been running BOINC for years and never puked on it. I'm quite convinced the issues buildds are suffering are much less random than people believe. It's more likely that they are very uncommon corner cases. FWIW, afaik lafayette - the autobuilder I recently provided - seems to be running mostly fine. And as far as I (as the local admin) am concerned, I believe my response time to problems (such as when the first hardware that was committed to this autobuilder failed beyond salvation and had to be entirely replaced) is acceptable. Let me know if that weren't true ;-) HTH T-Bone -- dann frazier -- 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
On Fri, Jun 12, 2009 at 09:16:25AM -0500, James Bottomley wrote: On Fri, 2009-06-12 at 09:55 +0200, Bart Schelstraete wrote: Hello all, Everybody is talking about the 'random crashes' and 'segfaults' in the HPPA version. Over here I'm using the hppa on a small HP-UX workstation, and that has an uptime of 542 days!. So it's not that unstable. I even need to say that I had a lot more crashes with the x86 version then with the hppa version. It seems to be related to what machine you actually have. And the load - buildds for unstable seem to trip over issues that we don't see elsewhere. I run a B180 as my network gateway, handling firewall, web, postfix/postgrey/spamassassin at quite a high volume on a domain. I also used to run it with a PCMCIA wireless card just for chuckles and grins (although I stopped that two years ago when I got a linksys). It runs debian testing and has been completely stable. I only reboot it for updates and in the seven or so years I've been doing this, I haven't had any segfaults or crashes ... have to say I only started using debian kernels on it for the last four or so years, because there used to be big problems with the ones they built. Just to say that I'm personally not so unhappy with deb hppa, and that not everything is bad. I think the main class of problem machines are anything with SMP ... unfortunately, I don't have one, so can't verify. We've tried both SMP and non-SMP kernels. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upcoming Lenny Point Release
On Sun, Jun 07, 2009 at 03:35:16PM -0300, Otavio Salvador wrote: Hello, On Sat, Jun 6, 2009 at 6:01 AM, Holger Levsenhol...@layer-acht.org wrote: Hi, for Debian Edu it would be great if cdebconf would be updated to 0.141 in stable and new d-i initrds would be build, as we are using them directly and are being bitten by #508042, #507372 and #343119. Those bugs were fixed in 0.140, but due to #525209 0.141 is desirable. I'm not sure if it's realistic at all (though the changes are just bugfixes and translation updates), but it would be good to have an answer, so either Debian Edu can use unmodified d-i or we have to fix it ourselves, which would mean branching d-i and a whole lot of more work (for the years to come). I have no problem in prepare that fix for it however it needs a full d-i update to happen. If RM team is OK with it I can take a look at it and prepare the packages during this week. If d-i does respin, it would be cool if we could include an updated lkdi-s390, which would make the fix for #511334 available at install time. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
On Wed, Apr 29, 2009 at 11:17:54AM -0400, Carlos O'Donell wrote: On Tue, Apr 28, 2009 at 5:34 PM, dann frazier da...@dannf.org wrote: * Has progress been made regarding the thread library migration? The thread library migration code is complete, and passes the testsuite without regression, including a bespoke testsuite I wrote to verify the compatibility code works. I've sent the first round of patches to Aurelien Jarno (debian-glibc) for integration, but after discussion it was determined that we would transition to NPTL when glibc releases 2.10 (in about a week). cool - do you have a pointer to the transition plan? The transition plan has only been discussed verbally between Aurelian and myself. In one week the 2.10 release comes out, and I plan to hand Aurelian a new set of patches for debian to include. At this point NPTL is officially turned on, the compat code is in place, and nobody should notice any difference, except that you are now using the new threading infrastructure in the kernel. Kinks may need to be ironed out. Does this, more or less answer your question? Yeah, mostly. Is it the case that anything built w/ a 2.10 glibc will use NPTL, and all previous binaries will use linuxthreads? I run stock: linux-image-2.6.26-1-parisc64-smp (2.6.26-13) on my SMP 2x PA8700 system without any problems. There are several reports of stability on various mixtures of kernel/platform - and the non-buildd debian.org hppa machine seems to be quite stable as well. But, once we start running a buildd on something, instability issues abound. If kernel instability is the next big ticket issue, then I'll help with that after the NPTL transition is complete. Please ping me in two weeks. Cheers, Carlos. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
On Wed, Apr 29, 2009 at 01:02:14PM -0400, Kyle McMartin wrote: On Wed, Apr 29, 2009 at 09:56:12AM -0600, dann frazier wrote: Unpacking busybox-udeb (from udebs/busybox-udeb.udeb) ... dpkg: error processing udebs/cdebconf-newt-terminal.udeb (--unpack): Â subprocess dpkg-split killed by signal (Segmentation fault) Errors were encountered while processing: Â udebs/cdebconf-newt-terminal.udeb make[2]: *** [stamps/tree-unpack-miniiso-stamp] Error 1 make[1]: *** [_build] Error 2 make: *** [build_miniiso] Error 2 Can you give me a recipe to build this by hand so I can try to reproduce on my two local boxes? I tried to reproduce on one of my machines last night, and didn't have any problems. Perhaps its an issue with the machine that does the daily build? Kyle: is this still your box? AFAIK, this is being done on a buildd box now, fjp messaged me on irc saying something to that effect, so I disabled the build on fattire. According to Frans, this machine is admin'd by luk :) Luk: can you check this machine to see if there's something misconfigured/corrupted? I'm unable to reproduce the same failures on my sid box. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
On Tue, Apr 28, 2009 at 05:09:25PM -0400, Carlos O'Donell wrote: On Tue, Apr 28, 2009 at 4:12 PM, Luk Claes l...@debian.org wrote: * What is the status of the different porting efforts? Is there a list of different porting efforts? * Has progress been made regarding the thread library migration? The thread library migration code is complete, and passes the testsuite without regression, including a bespoke testsuite I wrote to verify the compatibility code works. I've sent the first round of patches to Aurelien Jarno (debian-glibc) for integration, but after discussion it was determined that we would transition to NPTL when glibc releases 2.10 (in about a week). cool - do you have a pointer to the transition plan? * Has progress been made regarding proper java support? What is considered proper java support? GCJ? Dave, have you tinkered with GCJ lately? * The machines that host the buildds still seem to have a very unreliable kernel. Is there any update on this? I can't comment on this. Thibaut had planned to setup a second buildd (and I think had it up for a while?) but that box experienced a hardware failure. We're also working on moving one of the buildds to a different platform (rp2470). We have no specific reason to believe that will be any better, but its worth a shot. I run stock: linux-image-2.6.26-1-parisc64-smp (2.6.26-13) on my SMP 2x PA8700 system without any problems. There are several reports of stability on various mixtures of kernel/platform - and the non-buildd debian.org hppa machine seems to be quite stable as well. But, once we start running a buildd on something, instability issues abound. * The debian-installer dailies that are now built again, but seem to fail to build most of the time. Is there any particular reason for this? No idea. Do you have a log? Please make sure to get satisfying answers to all of the above questions in the next couple of weeks (by the 11th of May) or we will as a first step ignore hppa for testing migration purposes. If you need some more time, please let us know, but we're keen to ensure that this doesn't drag on too long :) Cheers, Carlos. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
On Wed, Apr 29, 2009 at 12:57:28AM +0200, Thibaut VARENE wrote: On Tue, Apr 28, 2009 at 11:34 PM, dann frazier da...@dannf.org wrote: On Tue, Apr 28, 2009 at 05:09:25PM -0400, Carlos O'Donell wrote: On Tue, Apr 28, 2009 at 4:12 PM, Luk Claes l...@debian.org wrote: * The machines that host the buildds still seem to have a very unreliable kernel. Is there any update on this? I can't comment on this. Thibaut had planned to setup a second buildd (and I think had it up for a while?) but that box experienced a hardware failure. We're also working on moving one of the buildds to a different platform (rp2470). We have no specific reason to believe that will be any better, but its worth a shot. Yes the supplementary buildd had a major hardware failure today (SBA/LBA failures during last POST and now the GSP can't load PDC anymore. The machine is basically dead). I'm switching the hard drives to another box I have that I used elsewhere (not yet back online as the Debian kernel seems to have major trouble coping with PCI addon NICs - tulip and tg3 HPMC the machine on driver load), and I'm still hoping to get feedback on some hardware donation requests I've made a month or so ago. I hereby take the opportunity to say that I would gladly welcome any rackable parisc system in my server room. :-) I run stock: linux-image-2.6.26-1-parisc64-smp (2.6.26-13) on my SMP 2x PA8700 system without any problems. There are several reports of stability on various mixtures of kernel/platform - and the non-buildd debian.org hppa machine seems to be quite stable as well. But, once we start running a buildd on something, instability issues abound. The only issue I've been aware of so far was the ruby build problem. If there are others, they need more publicity I think. OTOH, ISTR Carlos said most of the problems could go away with the transition to NPTL. Might be worth a try... I hand-built an NPTL environment before and it didn't help, but maybe something has gotten fixed since. But this certainly isn't the only stability issue - both buildds regulary hang hard and need rebooting. The hangs are fairly random - there doesn't appear to be anything consistent about them (not building the same package, running the same command, etc). * The debian-installer dailies that are now built again, but seem to fail to build most of the time. Is there any particular reason for this? No idea. Do you have a log? http://d-i.debian.org/daily-images/hppa/daily/ Problems all appear to be w/ dpkg. build_netboot.log has this: Unpacking console-keymaps-at (from udebs/console-keymaps-at.udeb) ... *** glibc detected *** dpkg: corrupted double-linked list: 0x00100c58 *** dpkg: error processing udebs/dhcp3-client-udeb.udeb (--unpack): subprocess dpkg-split killed by signal (Aborted) build_miniiso.log has this: Unpacking busybox-udeb (from udebs/busybox-udeb.udeb) ... dpkg: error processing udebs/cdebconf-newt-terminal.udeb (--unpack): subprocess dpkg-split killed by signal (Segmentation fault) Errors were encountered while processing: udebs/cdebconf-newt-terminal.udeb make[2]: *** [stamps/tree-unpack-miniiso-stamp] Error 1 make[1]: *** [_build] Error 2 make: *** [build_miniiso] Error 2 I would blame recent failures on failure to build kernel, maybe? AFAICT there was the phonet issue (fixed since then) and it seems recent kernel builds fail to link the btrfs module... These have been fixed in svn and an upload is scheduled for tomorrow. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hppa in danger of being ignored for testing migration and eventual removal
On Tue, Apr 28, 2009 at 07:31:46PM -0400, Brian Szymanski wrote: Luk Claes wrote: Hi, HPPA is clearly the worst at keeping up among the release architectures[0], especially considering that mipsel has some temporary issues that are being worked on. This is causing large problems with migrations. ... [0] https://buildd.debian.org/stats/graph-week-big.png i don't dispute this, but i do find it anomalous/interesting that the ia64 and hppa trajectories match *precisely*. that is, every time the ia64 build percent goes up in a given interval, so does that of hppa. every time one goes down, they both do. what's that about? same buildd maintainer -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
[oldstable] binutils update for mips
With the approval of the current debian maintainer[1], I'd like to
propose an oldstable update for binutils. See below for the
details. debdiff attached.
Risk of regression should be low as this is adding support for a
syntax that was previously unsupported on mips and would cause the
assembler to exit with an error.
[1]
doko [...]should be fine with me, I don't really see what could
break
dannf [...]if you like, i can prepare the package
doko sure, just go ahead
--
dann frazier
---BeginMessage---
hey Matthias,
I'm working on backporting a kernel fix for CVE-2009-0029, which
includes this changeset:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=1a94bc34768e463a93cb3751819709ab0ea80a01
This bit causes a FTBFS on mips:
+#define SYSCALL_ALIAS(alias, name) \
+ asm (\t.globl #alias \n\t.set #alias , #name)
This changeset appears to fix it:
http://sourceware.org/ml/binutils/2007-05/msg00242.html
So - my question for you is, do you think this is a reasonable thing
to add in an etch point release? Or, do you know of another way to
implement this macro without requiring this syntax?
--
dann frazier
---End Message---
diff -u binutils-2.17/debian/patches/00list binutils-2.17/debian/patches/00list
--- binutils-2.17/debian/patches/00list
+++ binutils-2.17/debian/patches/00list
@@ -8,0 +9 @@
+129_mips_set_generic_handler
diff -u binutils-2.17/debian/changelog binutils-2.17/debian/changelog
--- binutils-2.17/debian/changelog
+++ binutils-2.17/debian/changelog
@@ -1,3 +1,11 @@
+binutils (2.17-3+etch1) oldstable; urgency=high
+
+ * Non-maintainer upload.
+ * 129_mips_set_generic_handler.dpatch: Add mips support for
+.set symbol,value gas syntax.
+
+ -- dann frazier da...@debian.org Thu, 16 Apr 2009 12:21:46 -0600
+
binutils (2.17-3) unstable; urgency=low
* debian/rules (configure-multi-stamp): drop i486-kfreebsd-gnu again as
only in patch2:
unchanged:
--- binutils-2.17.orig/debian/patches/129_mips_set_generic_handler.dpatch
+++ binutils-2.17/debian/patches/129_mips_set_generic_handler.dpatch
@@ -0,0 +1,43 @@
+#!/bin/sh -e
+## 129_mips_set_generic_handler.dpatch
+##
+## DP: Description: Add support for .set symbol,value syntax
+## DP: Author: Joseph S. Myers joseph at codesourcery dot com
+## DP: Upstream status: Included
+
+if [ $# -ne 1 ]; then
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1
+fi
+
+[ -f debian/patches/00patch-opts ] . debian/patches/00patch-opts
+patch_opts=${patch_opts:--f --no-backup-if-mismatch}
+
+case $1 in
+ -patch) patch $patch_opts -p1 $0;;
+ -unpatch) patch $patch_opts -p1 -R $0;;
+*)
+echo 2 `basename $0`: script expects -patch|-unpatch as argument
+exit 1;;
+esac
+
+exit 0
+
+...@dpatch@
+--- binutils-2.17/gas/config/tc-mips.c.orig 2009-04-16 12:16:45.0 -0600
binutils-2.17/gas/config/tc-mips.c 2009-04-16 12:17:28.0 -0600
+@@ -12162,6 +12162,14 @@
+ mips_opts.sym32 = TRUE;
+ else if (strcmp (name, nosym32) == 0)
+ mips_opts.sym32 = FALSE;
++ else if (strchr (name, ','))
++{
++ /* Generic .set directive; use the generic handler. */
++ *input_line_pointer = ch;
++ input_line_pointer = name;
++ s_set (0);
++ return;
++}
+ else
+ {
+ as_warn (_(Tried to set unrecognized symbol: %s\n), name);
Re: Please give back ruby1.9/1.9.0.2-9 on hppa and alpha
On Mon, Feb 09, 2009 at 02:25:10PM +0100, Adeodato Sim?? wrote: * Lucas Nussbaum [Thu, 05 Feb 2009 14:43:40 +0100]: On 05/02/09 at 14:12 +0100, Adeodato Sim?? wrote: * Lucas Nussbaum [Mon, 02 Feb 2009 19:04:48 +0100]: On alpha, there's a segfault during the build. Manual builds on porter machines do work, though. Failed again with the same exact segfault. Do you want me to upload a manual build, or wait until an alpha porter gets the chance to take a look? Please upload a manual build this time. If you're in a position to do the same for hppa, please do that as well, else we'll migrate ruby1.9 -9 without hppa. Please reply to this mail if you won't be uploading for hppa, so that we can take the manual action needed. I'd be happy to do a manual upload for hppa if it would build, but this isn't just a problem with the buildds :( -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please give back ruby1.9/1.9.0.2-9 on hppa and alpha
On Mon, Feb 09, 2009 at 06:20:41PM +0100, Lucas Nussbaum wrote: On 09/02/09 at 16:33 +0100, Adeodato Sim? wrote: * dann frazier [Mon, 09 Feb 2009 08:26:40 -0700]: On Mon, Feb 09, 2009 at 02:25:10PM +0100, Adeodato Sim?? wrote: Please upload a manual build this time. If you're in a position to do the same for hppa, please do that as well, else we'll migrate ruby1.9 -9 without hppa. Please reply to this mail if you won't be uploading for hppa, so that we can take the manual action needed. I'd be happy to do a manual upload for hppa if it would build, but this isn't just a problem with the buildds :( Right. However, I've known Lucas has managed in the past to build hppa binaries somewhere (the previous upload, ruby1.9_1.9.0.2-8_hppa.changes, is signed by him), that's why I asked. working on it (on paer.d.o). Thanks Lucas - I'll be very interested if you manage to get this to succeed - I've tried it several times on several machines running a current kernel and found it consistently hangs :( Whomever manages to get it to build, please let me know the recipe used - we'll need to reproduce it for security updates. I also uploaded the alpha binary packages, after building them on albeniz.d.o (nothing special was necessary to get them to build ; there might be something fishy on the buildds). -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please give back ruby1.9/1.9.0.2-9 on hppa and alpha
On Thu, Feb 05, 2009 at 04:51:15PM -0700, dann frazier wrote: On Thu, Feb 05, 2009 at 09:00:43PM +0100, Helge Deller wrote: dann frazier wrote: On Mon, Feb 02, 2009 at 07:04:48PM +0100, Lucas Nussbaum wrote: ruby1.9 still fails to build on hppa and alpha. On hppa, it's caused by a kernel bug, which was partially fixed (at least the kernel doesn't panic() anymore). Since the issue is related to threading, it is possible that retrying could make it build successfully. fyi, I've retried it numerous times on both buildds with no luck. We're not crashing the buildd anymore - thanks to Helge's fix - The kudos belong to James Bottomley btw. I did debugging and testing, but James gave me the final hint to the solution then... but the build hangs indefinitely. I've no objection to it being retried again of course (and I'm not the buildd admin anyway) - I just want to set your expectations. I tried a few times now to find the bug. I'm not sure if it's really due to a) a kernel bug (probably) b) the fact that hppa still uses Linuxthreads (although Dann mentioned in another mail that he saw similar problems with another server which used NPTL instead of Linuxthreads) Since I don't remember the last time I tried, I've started another build in my NPTL chroot running a fixed kernel to verify that I'm still seeing it. And I am. Hangs at: cc -fno-strict-aliasing -g -g -O2 -O2 -g -Wall -Wno-parentheses -fPIC -I. -I.ext/include/hppa-linux -I./include -I. -DRUBY_EXPORT -o dmyext.o -c dmyext.c cc -fno-strict-aliasing -g -g -O2 -O2 -g -Wall -Wno-parentheses -fPIC -L. -rdynamic -Wl,-export-dynamic main.o dln.o dmyencoding.o miniprelude.o array.o bignum.o class.o compar.o complex.o dir.o enum.o enumerator.o error.o eval.o load.o proc.o file.o gc.o hash.o inits.o io.o marshal.o math.o numeric.o object.o pack.o parse.o process.o prec.o random.o range.o rational.o re.o regcomp.o regenc.o regerror.o regexec.o regparse.o regsyntax.o ruby.o signal.o sprintf.o st.o string.o struct.o time.o transcode.o util.o variable.o version.o blockinlining.o compile.o debug.o iseq.o vm.o vm_dump.o thread.o cont.o id.o ascii.o us_ascii.o unicode.o utf_8.o strlcpy.o strlcat.o dmyext.o -lpthread -lrt -ldl -lcrypt -lm -o miniruby ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb ./enc/make_encdb.rb ./enc encdb.h.new C) wrong pthread coding in ruby1.9 If it's due to a) (kernel bug), then it's hard to find and track down. I concentrated on b) and c) for now. LT uses a few signals to synchronize the threads, and ruby plays some small but bad games with signals in it's code, e.g. rb_disable_interrupt() and rb_enable_interrupt() in signal.c. With the attached patch/hack below I tried to work around possible LT-related cornercases in ruby1.9, but the issue stays the same: make test will make the ruby testsuite hang in the test_thread.rb test. It seems some thread is waiting for a signal which will not arrive, since the other thread is a zombie already Anyway, it would be nice if someone with ruby knowledge could reduce the testsuite, so that it will be easier to reproduce the bug. I'm a little lost at this stage. Now since the hppa kernel doesn't crash any longer, building such a testcase should be much easier to create. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please give back ruby1.9/1.9.0.2-9 on hppa and alpha
On Thu, Feb 05, 2009 at 09:00:43PM +0100, Helge Deller wrote: dann frazier wrote: On Mon, Feb 02, 2009 at 07:04:48PM +0100, Lucas Nussbaum wrote: ruby1.9 still fails to build on hppa and alpha. On hppa, it's caused by a kernel bug, which was partially fixed (at least the kernel doesn't panic() anymore). Since the issue is related to threading, it is possible that retrying could make it build successfully. fyi, I've retried it numerous times on both buildds with no luck. We're not crashing the buildd anymore - thanks to Helge's fix - The kudos belong to James Bottomley btw. I did debugging and testing, but James gave me the final hint to the solution then... but the build hangs indefinitely. I've no objection to it being retried again of course (and I'm not the buildd admin anyway) - I just want to set your expectations. I tried a few times now to find the bug. I'm not sure if it's really due to a) a kernel bug (probably) b) the fact that hppa still uses Linuxthreads (although Dann mentioned in another mail that he saw similar problems with another server which used NPTL instead of Linuxthreads) Since I don't remember the last time I tried, I've started another build in my NPTL chroot running a fixed kernel to verify that I'm still seeing it. c) wrong pthread coding in ruby1.9 If it's due to a) (kernel bug), then it's hard to find and track down. I concentrated on b) and c) for now. LT uses a few signals to synchronize the threads, and ruby plays some small but bad games with signals in it's code, e.g. rb_disable_interrupt() and rb_enable_interrupt() in signal.c. With the attached patch/hack below I tried to work around possible LT-related cornercases in ruby1.9, but the issue stays the same: make test will make the ruby testsuite hang in the test_thread.rb test. It seems some thread is waiting for a signal which will not arrive, since the other thread is a zombie already Anyway, it would be nice if someone with ruby knowledge could reduce the testsuite, so that it will be easier to reproduce the bug. I'm a little lost at this stage. Now since the hppa kernel doesn't crash any longer, building such a testcase should be much easier to create. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Please give back ruby1.9/1.9.0.2-9 on hppa and alpha
On Mon, Feb 02, 2009 at 07:04:48PM +0100, Lucas Nussbaum wrote: Hi, hey Lucas! ruby1.9 still fails to build on hppa and alpha. On hppa, it's caused by a kernel bug, which was partially fixed (at least the kernel doesn't panic() anymore). Since the issue is related to threading, it is possible that retrying could make it build successfully. fyi, I've retried it numerous times on both buildds with no luck. We're not crashing the buildd anymore - thanks to Helge's fix - but the build hangs indefinitely. I've no objection to it being retried again of course (and I'm not the buildd admin anyway) - I just want to set your expectations. On alpha, there's a segfault during the build. Manual builds on porter machines do work, though. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
linux-2.6 upload planned
hey, I wanted to give -release -boot a heads up that the kernel team is looking to do a linux-2.6 upload to sid tomorrow. As discussed on the d-i channel, delays in the d-i release have given us a short window to introduce a new build for inclusion in RC2. Changes pending for this update include: - a few local DoS security issues - the hppa kernel fix that was causing crashes during ruby builds (doesn't fix the FTBFS - that may be a userspace issue) - reintroduces a driver for the ia64 rtc (regression) - several other fixes of = important severity from Moritz's recent bug triage -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: linux-2.6 upload planned
On Sat, Jan 10, 2009 at 01:08:01AM +0100, Petr Vyslouzil wrote: hey, I wanted to give -release -boot a heads up that the kernel team is looking to do a linux-2.6 upload to sid tomorrow. As discussed on the d-i channel, delays in the d-i release have given us a short window to introduce a new build for inclusion in RC2. Changes pending for this update include: - a few local DoS security issues - the hppa kernel fix that was causing crashes during ruby builds (doesn't fix the FTBFS - that may be a userspace issue) - reintroduces a driver for the ia64 rtc (regression) - several other fixes of = important severity from Moritz's recent bug triage Are XVR drivers (#508108) going to be included? If not, please, reconsider as they've been successfully tried and tested in several different kernel builds and on different HW. Thanks. Yep! -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: linux-2.6 upload planned
On Sat, Jan 10, 2009 at 07:06:20AM +0100, Christian Perrier wrote: Quoting dann frazier (da...@debian.org): hey, I wanted to give -release -boot a heads up that the kernel team is looking to do a linux-2.6 upload to sid tomorrow. As discussed on the d-i channel, delays in the d-i release have given us a short window to introduce a new build for inclusion in RC2. Changes pending for this update include: - a few local DoS security issues - the hppa kernel fix that was causing crashes during ruby builds (doesn't fix the FTBFS - that may be a userspace issue) - reintroduces a driver for the ia64 rtc (regression) - several other fixes of = important severity from Moritz's recent bug triage Does that include #508108?? yep If there is a release, fixing that one would be worth it from what I read in it. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Tue, Dec 23, 2008 at 11:43:22AM +0100, Helge Deller wrote: Peter Palfrader wrote: Helge Deller schrieb am Dienstag, dem 23. Dezember 2008: Patch in parisc git tree: http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607 So just using an SMP kernel should also work? Probably yes, since some other developers tried initially to reproduce the problem, but they couldn't (as it seems they were running on newer SMP machines). But I don't have a SMP server which is why I can't test myself... Unfortunately, it looks like we're still having problems on the buildds w/ 2.6.26 SMP kernels: http://buildd.debian.org/build.php?pkg=ruby1.9ver=1.9.0.2-9arch=hppafile=log The build doesn't take the system down, but does still hang indefinitely while running miniruby - though the hang location varies. I'll prepare a UP kernel for one of the buildds w/ the up-optimization-removal patch just to see if it improves things. I don't see why it would, other than it seemed to solve the problem on my test box when I first tested the patch. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny (ruby1.9 build problems)
On Tue, Jan 06, 2009 at 12:46:34AM +0100, Helge Deller wrote: CC: linux-paric mailing list Peter Palfrader wrote: On Mon, 05 Jan 2009, dann frazier wrote: On Tue, Dec 23, 2008 at 11:43:22AM +0100, Helge Deller wrote: Peter Palfrader wrote: Helge Deller schrieb am Dienstag, dem 23. Dezember 2008: Patch in parisc git tree: http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607 So just using an SMP kernel should also work? Probably yes, since some other developers tried initially to reproduce the problem, but they couldn't (as it seems they were running on newer SMP machines). But I don't have a SMP server which is why I can't test myself... Unfortunately, it looks like we're still having problems on the buildds w/ 2.6.26 SMP kernels: http://buildd.debian.org/build.php?pkg=ruby1.9ver=1.9.0.2-9arch=hppafile=log The build doesn't take the system down, but does still hang indefinitely while running miniruby - though the hang location varies. I'll prepare a UP kernel for one of the buildds w/ the up-optimization-removal patch just to see if it improves things. I don't see why it would, other than it seemed to solve the problem on my test box when I first tested the patch. It seemed to fix the problem for me as well. fyi, I tested w/ a 2.6.26 32-bit UP kernel w/ the up-optimization-removal patch, and received another hang: http://buildd.debian.org/fetch.cgi?pkg=ruby1.9;ver=1.9.0.2-9;arch=hppa;stamp=1231212073 In principle looking at the logs it looks more like a userspace bugs due to threading functions. Anyway, I'll try to reproduce it here as well. FWIW, I had some additional irq locking code in load_context(), maybe this helps...? I'd be happy to test it if you can point me to a changeset. Yeah, penalosa got stuck again today, this was on the console: Does panalosa has the patched kernel (same one as the one on peri) ? Both machines were running an unpatched SMP 2.6.26 until I upgraded penalosa for the test I refer to above. The thinking being that - though these machines are single CPU - the SMP version should avoid the UP optimization code. The protection ID traps shouldn't happen any longer, and from the buildd logs on peri it does seem like that the ProtID traps don't happen there. There were no protection trap messages in penalosa's dmesg after the above hang. In fact, it contains nothing other than bootup messages. Helge Thanks for all your help so far - its really appreciated. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Tue, Dec 23, 2008 at 01:05:55PM -0700, dann frazier wrote: On Tue, Dec 23, 2008 at 10:47:25AM +0100, Helge Deller wrote: dann frazier wrote: On Wed, Dec 17, 2008 at 11:08:59PM +0100, Helge Deller wrote: dann frazier wrote: On Mon, Dec 15, 2008 at 08:30:25PM +0100, Peter Palfrader wrote: Helge Deller schrieb am Montag, dem 15. Dezember 2008: Matt Taggart wrote: The real problem is that no one is fixing hppa kernel problems. I don't see much point in keeping the archive up to date if nobody is working on fixing the kernel (not currently and I suspect not in the future either). This has been stated on the debian-hppa list several times over a long period and in that time no one (AFAIK) has stepped up to work on it. Matt, We have done quite some bugfixing in the last weeks and upstream 2.6.28-rcX works pretty well now. What does that mean for the lenny 2.6.26 kernel? Well, obviously when there's a fix upstream we will look at backporting this into 2.6.26. I've just posted a short analysis of the problem and a proposed kernel patch in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478717#118 It fixes the kernel crashes for me and should help to do further analysis without crashing the running linux kernel. The patch (and the problem) needs further discussion on parisc-linux kernel mailing list though... Thanks Helge! Just in case its relevant to your investigation, note that this is also an issue when using a pure NPTL environment. Just wanted to give a short update - After quite some debugging by various parisc kernel developers, it seems that buggy TLB flushing code was causing the ruby1.9 build failures / kernel crashes and we developed a workaround for now: http://permalink.gmane.org/gmane.linux.ports.parisc/1028 Patch in parisc git tree: http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607 I assume this patch solves quite some other issues which were seen as well. Excellent! It would be really nice, if this (preliminary) patch could be included in the debian parisc kernel soon... Doing a test build now... Build succeeded, my test case is working reliably (building ncurses-ruby several times), and this fix has been committed. This change should appear in lenny in the next update - not sure if this will happen before 5.0r0 or the first point release yet. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Tue, Dec 23, 2008 at 10:47:25AM +0100, Helge Deller wrote: dann frazier wrote: On Wed, Dec 17, 2008 at 11:08:59PM +0100, Helge Deller wrote: dann frazier wrote: On Mon, Dec 15, 2008 at 08:30:25PM +0100, Peter Palfrader wrote: Helge Deller schrieb am Montag, dem 15. Dezember 2008: Matt Taggart wrote: The real problem is that no one is fixing hppa kernel problems. I don't see much point in keeping the archive up to date if nobody is working on fixing the kernel (not currently and I suspect not in the future either). This has been stated on the debian-hppa list several times over a long period and in that time no one (AFAIK) has stepped up to work on it. Matt, We have done quite some bugfixing in the last weeks and upstream 2.6.28-rcX works pretty well now. What does that mean for the lenny 2.6.26 kernel? Well, obviously when there's a fix upstream we will look at backporting this into 2.6.26. I've just posted a short analysis of the problem and a proposed kernel patch in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478717#118 It fixes the kernel crashes for me and should help to do further analysis without crashing the running linux kernel. The patch (and the problem) needs further discussion on parisc-linux kernel mailing list though... Thanks Helge! Just in case its relevant to your investigation, note that this is also an issue when using a pure NPTL environment. Just wanted to give a short update - After quite some debugging by various parisc kernel developers, it seems that buggy TLB flushing code was causing the ruby1.9 build failures / kernel crashes and we developed a workaround for now: http://permalink.gmane.org/gmane.linux.ports.parisc/1028 Patch in parisc git tree: http://git.kernel.org/?p=linux/kernel/git/kyle/parisc-2.6.git;a=commitdiff;h=378fe7c4cc619b561409206605c723c05358edac;hp=6c4dfa8f8bcf032137aacb3640d7dd9d75b2b607 I assume this patch solves quite some other issues which were seen as well. Excellent! It would be really nice, if this (preliminary) patch could be included in the debian parisc kernel soon... Doing a test build now... -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Wed, Dec 17, 2008 at 11:08:59PM +0100, Helge Deller wrote: dann frazier wrote: On Mon, Dec 15, 2008 at 08:30:25PM +0100, Peter Palfrader wrote: Helge Deller schrieb am Montag, dem 15. Dezember 2008: Matt Taggart wrote: The real problem is that no one is fixing hppa kernel problems. I don't see much point in keeping the archive up to date if nobody is working on fixing the kernel (not currently and I suspect not in the future either). This has been stated on the debian-hppa list several times over a long period and in that time no one (AFAIK) has stepped up to work on it. Matt, We have done quite some bugfixing in the last weeks and upstream 2.6.28-rcX works pretty well now. What does that mean for the lenny 2.6.26 kernel? Well, obviously when there's a fix upstream we will look at backporting this into 2.6.26. I've just posted a short analysis of the problem and a proposed kernel patch in: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478717#118 It fixes the kernel crashes for me and should help to do further analysis without crashing the running linux kernel. The patch (and the problem) needs further discussion on parisc-linux kernel mailing list though... Thanks Helge! Just in case its relevant to your investigation, note that this is also an issue when using a pure NPTL environment. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HPPA and lenny
On Mon, Dec 15, 2008 at 08:30:25PM +0100, Peter Palfrader wrote: Helge Deller schrieb am Montag, dem 15. Dezember 2008: Matt Taggart wrote: The real problem is that no one is fixing hppa kernel problems. I don't see much point in keeping the archive up to date if nobody is working on fixing the kernel (not currently and I suspect not in the future either). This has been stated on the debian-hppa list several times over a long period and in that time no one (AFAIK) has stepped up to work on it. Matt, We have done quite some bugfixing in the last weeks and upstream 2.6.28-rcX works pretty well now. What does that mean for the lenny 2.6.26 kernel? Well, obviously when there's a fix upstream we will look at backporting this into 2.6.26. -- dann frazier -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
freeze exception for fakeroot_1.11
hey,
fakeroot_1.11 fixes a bug that prevents eclipse from building from
source. Since fakeroot is used by sbuild on our buildds, a fakeroot
update is necessary to ensure that we can rebuild eclipse updates
for lenny.
I'm not a fakeroot maintainer, but the maintainer is ok with this:
dannf Clint: looks like eclipse built everywhere, you wanna
ask d-release for a lenny exception?
Clint dannf: no, but feel free
diff -Nru fakeroot-1.10.1/acinclude.m4 fakeroot-1.11/acinclude.m4
--- fakeroot-1.10.1/acinclude.m42008-10-04 12:48:44.0 -0600
+++ fakeroot-1.11/acinclude.m4 2008-11-18 16:21:40.0 -0700
@@ -1 +1 @@
-define(FAKEROOT_VERSION, 1.10.1)
+define(FAKEROOT_VERSION, 1.11)
diff -Nru fakeroot-1.10.1/communicate.c fakeroot-1.11/communicate.c
--- fakeroot-1.10.1/communicate.c 2008-08-03 16:26:49.0 -0600
+++ fakeroot-1.11/communicate.c 2008-11-18 16:18:23.0 -0700
@@ -521,9 +521,9 @@
if(init_get_msg()!=-1){
pid=getpid();
+semaphore_up();
serial++;
buf-serial=serial;
-semaphore_up();
buf-pid=pid;
send_fakem(buf);
diff -Nru fakeroot-1.10.1/configure fakeroot-1.11/configure
--- fakeroot-1.10.1/configure 2008-10-04 12:49:11.0 -0600
+++ fakeroot-1.11/configure 2008-11-18 16:22:07.0 -0700
@@ -1,6 +1,6 @@
#! /bin/sh
# Guess values for system-dependent variables and create Makefiles.
-# Generated by GNU Autoconf 2.61 for fakeroot 1.10.1.
+# Generated by GNU Autoconf 2.61 for fakeroot 1.11.
#
# Report bugs to [EMAIL PROTECTED].
#
@@ -731,8 +731,8 @@
# Identity of this package.
PACKAGE_NAME='fakeroot'
PACKAGE_TARNAME='fakeroot'
-PACKAGE_VERSION='1.10.1'
-PACKAGE_STRING='fakeroot 1.10.1'
+PACKAGE_VERSION='1.11'
+PACKAGE_STRING='fakeroot 1.11'
PACKAGE_BUGREPORT='[EMAIL PROTECTED]'
# Factoring default headers for most tests.
@@ -1397,7 +1397,7 @@
# Omit some internal or obsolete options to make the list less imposing.
# This message is too long to be a string in the A/UX 3.1 sh.
cat _ACEOF
-\`configure' configures fakeroot 1.10.1 to adapt to many kinds of systems.
+\`configure' configures fakeroot 1.11 to adapt to many kinds of systems.
Usage: $0 [OPTION]... [VAR=VALUE]...
@@ -1468,7 +1468,7 @@
if test -n $ac_init_help; then
case $ac_init_help in
- short | recursive ) echo Configuration of fakeroot 1.10.1:;;
+ short | recursive ) echo Configuration of fakeroot 1.11:;;
esac
cat \_ACEOF
@@ -1570,7 +1570,7 @@
test -n $ac_init_help exit $ac_status
if $ac_init_version; then
cat \_ACEOF
-fakeroot configure 1.10.1
+fakeroot configure 1.11
generated by GNU Autoconf 2.61
Copyright (C) 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001,
@@ -1584,7 +1584,7 @@
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
-It was created by fakeroot $as_me 1.10.1, which was
+It was created by fakeroot $as_me 1.11, which was
generated by GNU Autoconf 2.61. Invocation command line was
$ $0 $@
@@ -2402,7 +2402,7 @@
# Define the identity of the package.
PACKAGE='fakeroot'
- VERSION='1.10.1'
+ VERSION='1.11'
cat confdefs.h _ACEOF
@@ -13667,7 +13667,7 @@
# report actual input values of CONFIG_FILES etc. instead of their
# values after options handling.
ac_log=
-This file was extended by fakeroot $as_me 1.10.1, which was
+This file was extended by fakeroot $as_me 1.11, which was
generated by GNU Autoconf 2.61. Invocation command line was
CONFIG_FILES= $CONFIG_FILES
@@ -13720,7 +13720,7 @@
_ACEOF
cat $CONFIG_STATUS _ACEOF
ac_cs_version=\\
-fakeroot config.status 1.10.1
+fakeroot config.status 1.11
configured by $0, generated by GNU Autoconf 2.61,
with options \\`echo $ac_configure_args | sed 's/^ //;
s/[\\\`\$]//g'`\\
diff -Nru fakeroot-1.10.1/debian/changelog fakeroot-1.11/debian/changelog
--- fakeroot-1.10.1/debian/changelog2008-10-04 12:48:29.0 -0600
+++ fakeroot-1.11/debian/changelog 2008-11-18 16:21:08.0 -0700
@@ -1,3 +1,10 @@
+fakeroot (1.11) unstable; urgency=medium
+
+ * communicate.c: patch from dann frazier to fix race condition when
+SysV IPC is used with a threaded application. closes: #499142.
+
+ -- Clint Adams [EMAIL PROTECTED] Tue, 18 Nov 2008 18:20:37 -0500
+
fakeroot (1.10.1) unstable; urgency=low
* Patch from Joe Malicki to increase number of cases where fakeroot
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
pre-approval for flamethrower upload
The primary reason for this upload is to fix a security issue. There's
also an FHS issue resulting from a change in perl since the last
flamethrower upload (which was prior to etch). The remaining issues
are all relatively minor, but also pretty straightforward.
diff -u flamethrower-0.1.8/debian/changelog flamethrower-0.1.8/debian/changelog
--- flamethrower-0.1.8/debian/changelog
+++ flamethrower-0.1.8/debian/changelog
@@ -1,3 +1,20 @@
+flamethrower (0.1.8-2) unstable; urgency=medium
+
+ * Fix /tmp symlink attack vector. Closes: #506350 (CVE-2008-5141)
+ * Rebuilding with current toolchain would cause executables to
+be installed in /usr/local/bin. Fix this by supplying an
+appropriate SITEPREFIX.
+ * Don't package /usr/lib/flamethrower/auto subtree
+ * Lintian cleanup:
+- Remove bogus (empty) line in lsb section of initscript
+- Use $(CURDIR) instead of $(PWD) in rules file, suggested by lintian
+- Don't ignore clean errors from make
+- Update Standards-Version to 3.8.0
+- Swap binary-arch/binary-indep rules
+- List debhelper under Build-Depends instead of Build-Depends-Indep
+
+ -- dann frazier [EMAIL PROTECTED] Fri, 21 Nov 2008 10:46:08 -0700
+
flamethrower (0.1.8-1) unstable; urgency=low
* New upstream release
diff -u flamethrower-0.1.8/debian/control flamethrower-0.1.8/debian/control
--- flamethrower-0.1.8/debian/control
+++ flamethrower-0.1.8/debian/control
@@ -2,8 +2,8 @@
Section: admin
Priority: optional
Maintainer: dann frazier [EMAIL PROTECTED]
-Build-Depends-Indep: debhelper ( 3.0.0)
-Standards-Version: 3.6.2.2
+Build-Depends: debhelper ( 3.0.0)
+Standards-Version: 3.8.0
Package: flamethrower
Architecture: all
diff -u flamethrower-0.1.8/debian/rules flamethrower-0.1.8/debian/rules
--- flamethrower-0.1.8/debian/rules
+++ flamethrower-0.1.8/debian/rules
@@ -5,7 +5,7 @@
PREFIX = $(tmp)/usr
pkg = flamethrower
-tmp = $(PWD)/debian/$(pkg)
+tmp = $(CURDIR)/debian/$(pkg)
configure: configure-stamp
configure-stamp:
@@ -22,7 +22,7 @@
clean:
dh_testdir
rm -f build-stamp configure-stamp
- -$(MAKE) realclean
+ [ ! -f Makefile ] || $(MAKE) realclean
-rm debian/flamethrower.init
dh_clean
@@ -30,10 +30,14 @@
dh_testdir
-dh_testroot
dh_installdirs
- $(MAKE) install PREFIX=$(PREFIX) CONFDIR=$(tmp)
+ $(MAKE) install PREFIX=$(PREFIX) CONFDIR=$(tmp)
SITEPREFIX=$(PREFIX)
+
+ # upstream installs this as executable
+ chmod 644 $(tmp)/usr/lib/flamethrower/*.pm
# this directory tree is empty
rm -rf $(tmp)/usr/lib/perl
+ rm -rf $(tmp)/usr/lib/flamethrower/auto
# let debhelper install this for us
rm -rf $(tmp)/etc/init.d
@@ -44,11 +48,11 @@
mkdir -p $(tmp)/var/log/flamethrower
# Build architecture-independent files here.
-binary-indep: build install
+binary-arch: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
-binary-arch: build install
+binary-indep: build install
dh_testdir
dh_testroot
dh_installdebconf
only in patch2:
unchanged:
--- flamethrower-0.1.8.orig/bin/flamethrower
+++ flamethrower-0.1.8/bin/flamethrower
@@ -9,6 +9,7 @@
use strict;
use File::Path;
+use File::Temp;
use Getopt::Long;
use lib /usr/lib/flamethrower;
@@ -23,7 +24,7 @@
my $version_number = INS_VERSION;
my $conf_file = '/etc/flamethrower/flamethrower.conf';
my $transport = udp-receiver;
-my $tmp_dir = /tmp/.flamethrower.$$;
+my $tmp_dir = File::Temp::tempdir();
my $version_info = EOF;
@@ -283,13 +284,16 @@
#
my $udp_cmd;
my $tar_cmd;
+my $tar_fh;
+my $tar_file;
+($tar_fh, $tar_file) = File::Temp::tempfile();
if($verbose) {
-$udp_cmd = udp-receiver $udp_receiver_options --file
/tmp/multicast.tar.$$;
-$tar_cmd = tar $tar_opts -C $dir -f /tmp/multicast.tar.$$;
+$udp_cmd = udp-receiver $udp_receiver_options --file $tar_file;
+$tar_cmd = tar $tar_opts -C $dir -f $tar_file;
} else {
-$udp_cmd = udp-receiver $udp_receiver_options --file
/tmp/multicast.tar.$$ 2/dev/null;
-$tar_cmd = tar $tar_opts -C $dir -f /tmp/multicast.tar.$$;
+$udp_cmd = udp-receiver $udp_receiver_options --file $tar_file
2/dev/null;
+$tar_cmd = tar $tar_opts -C $dir -f $tar_file;
}
print $udp_cmd\n if($verbose);
@@ -298,7 +302,8 @@
print $tar_cmd\n if($verbose);
!system($tar_cmd) or die(FAILED: $tar_cmd);
-unlink(/tmp/multicast.tar.$$);
+close $tar_fh;
+unlink($tar_file);
}
only in patch2:
unchanged:
--- flamethrower-0.1.8.orig/etc/init.d/flamethrower-server
+++ flamethrower-0.1.8/etc/init.d/flamethrower-server
@@ -22,7 +22,6 @@
# Default-Stop: 0 1 2 6
# Short-Description: Daemon for multicast file distribution
# Description: Daemon for multicast file distribution
-#
### END INIT INFO
kill_em_all
unblock request for firmware-nonfree_0.13
hey, I've just uploaded firmware-nonfree 0.13. It resolves 2 RC bugs: 494936 - bnx2 fails to load on bootup, succeeds on manul load 500692 - FTBFS: depends on linux-support-2.6.25-2 And one 'normal' one (that should be bumped to important, imo): 494703 - iwl3945: Microcode SW Error detected The debdiff is cluttered w/ generated files, so what follows is the diff between the 0.12 and 0.13 tags in svn. Please allow this version to migrate into lenny. Index: debian/changelog === --- debian/changelog(.../0.12) (revision 12282) +++ debian/changelog(.../0.13) (revision 12282) @@ -1,3 +1,12 @@ +firmware-nonfree (0.13) unstable; urgency=low + + * Make firmware-bnx2 trigger update-initramfs (closes: #494936) + * Update to 2.6.26-1 (closes: #500692) + * Update Intel Wireless 3945 firmware, version 15.28.1.6. +(closes: #494703) + + -- dann frazier [EMAIL PROTECTED] Thu, 02 Oct 2008 11:58:37 -0600 + firmware-nonfree (0.12) unstable; urgency=low * Remove Intel Wireless 3945 (old style) firmware. Index: debian/rules.defs === --- debian/rules.defs (.../0.12) (revision 12282) +++ debian/rules.defs (.../0.13) (revision 12282) @@ -1 +1 @@ -KERNELVERSION := 2.6.25-2 +KERNELVERSION := 2.6.26-1 Index: bnx2/defines === --- bnx2/defines(.../0.12) (revision 12282) +++ bnx2/defines(.../0.13) (revision 12282) @@ -4,6 +4,7 @@ bnx2-06-4.0.5.fw bnx2-09-4.0.5.fw longdesc: Broadcom NetXtremeII network adapters +support: initramfs-tools uri: http://ftp.debian.org/debian/pool/non-free/f/firmware-nonfree [bnx2-06-4.0.5.fw_base] Index: iwlwifi/iwlwifi-3945-1.ucode-2.14.1.5 === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Index: iwlwifi/iwlwifi-3945-1.ucode-15.28.1.6 === Cannot display: file marked as a binary type. svn:mime-type = application/octet-stream Property changes on: iwlwifi/iwlwifi-3945-1.ucode-15.28.1.6 ___ Added: svn:mime-type + application/octet-stream -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
