Bug#1066630: Patch to address Debian Bug report #1066630
The following patch results in a clean build. I will work to get the
patch
uploaded. (I am not a Debian Developer)
Index: libnet-ldapapi-perl/Makefile.PL
===
--- libnet-ldapapi-perl.orig/Makefile.PL 2024-03-29 07:00:25.037139644
+
+++ libnet-ldapapi-perl/Makefile.PL 2024-04-02 07:07:21.401195313 +
@@ -124,7 +124,7 @@
'DEFINE'=> '-DMOZILLA_LDAP',
) : (
'LIBS' => ["-L$lib_ldap $ldap_lib"],
- 'DEFINE'=> '-DOPENLDAP',
+ 'DEFINE'=> '-DOPENLDAP -DLDAP_DEPRECATED=1',
)),
'depend'=> { 'LDAPapi.c' => 'constant.h' },
'clean' => { 'FILES' => 'constant.h' },
The patch is from Quanah Gibson-Mount . Thanks.
Bill
Bug#1066630: Confirming the build problem
This is a confirmed bug. I am working on a solution. Bill
Bug#1052304: kafs failure testing
I spent a couple days bisecting kernels attempting to isolate this bug to a specific kernel. What I found was that the simple test that I included in the initial bug report, i.e. ls /afs/ca-zephyr.org, is not sufficient to test for failure. This test can succeed multiple times and then sometime later fail. Which meant that my bisection attempts where pretty much useless. I will work on a better test for this issue. Bill -- "Can't sing louder than the guns when I'm gone, so I guess I'll have to do it while I'm here." Phil Ochs
Bug#866952: xen-system-amd64: Xen 4.8 Install on Stretch Crashes on Boot
Package: xen-system-amd64 Version: 4.8.1-1+deb9u1 Severity: critical Justification: breaks the whole system Dear Maintainer, * What led up to the situation? Initially an attempt was made to upgrade an existing Jessie Xen 4.4 system to Stretch Xen 4.8. When that failed I decided to start with a fresh Stretch install. * What exactly did you do (or not do) that was effective (or ineffective)? - First, I just replaced 'jessie' with 'stretch' in sources.list and ran 'apt-get dist-upgrade'. The resulting system crashed on boot. - Second, I installed a new stretch system, updated my puppet manifest to support Xen 4.8, ran puppet, and rebooted. The resulting system crashed on boot exactly the same as my first attempt. - Third, I installed a new stretch system and installed only the xen-system-amd64 package. The resulting system crashed on boot exactly the same as my first attempt. * What was the outcome of this action? Here is the output captured from a serial console connection. [0.00] Linux version 4.9.0-3-amd64 (debian-ker...@lists.debian.org) (gc) [0.00] Command line: placeholder root=UUID=54dcd810-baaf-4dfd-9442-4a728 [0.00] x86/fpu: Legacy x87 FPU detected. [0.00] x86/fpu: Using 'eager' FPU context switches. [0.00] Released 0 page(s) [0.00] e820: BIOS-provided physical RAM map: [0.00] Xen: [mem 0x-0x0009dfff] usable [0.00] Xen: [mem 0x000a-0x000f] reserved [0.00] Xen: [mem 0x0010-0xcf378fff] usable [0.00] Xen: [mem 0xcf379000-0xcf38efff] reserved [0.00] Xen: [mem 0xcf38f000-0xcf3cdfff] ACPI data [0.00] Xen: [mem 0xcf3ce000-0xcfff] reserved [0.00] Xen: [mem 0xe000-0xefff] reserved [0.00] Xen: [mem 0xfe00-0x] reserved [0.00] Xen: [mem 0x0001-0x00062fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.6 present. [0.00] Hypervisor detected: Xen [0.00] e820: last_pfn = 0x63 max_arch_pfn = 0x4 [0.00] MTRR: Disabled [0.00] x86/PAT: MTRRs disabled, skipping PAT initialization too. [0.00] x86/PAT: Configuration [0-7]: WB WT UC- UC WC WP UC UC [0.00] e820: last_pfn = 0xcf379 max_arch_pfn = 0x4 [0.00] RAMDISK: [mem 0x0200-0x0325] [0.00] ACPI: Early table checksum verification disabled [0.00] ACPI: RSDP 0x000F1150 24 (v02 DELL ) [0.00] ACPI: XSDT 0x000F1254 9C (v01 DELL PE_SC3 00) [0.00] ACPI: FACP 0xCF3B3F9C F4 (v03 DELL PE_SC3 00) [0.00] ACPI: DSDT 0xCF38F000 003DD0 (v01 DELL PE_SC3 00) [0.00] ACPI: FACS 0xCF3B6000 40 [0.00] ACPI: FACS 0xCF3B6000 40 [0.00] ACPI: APIC 0xCF3B3478 00015E (v01 DELL PE_SC3 00) [0.00] ACPI: SPCR 0xCF3B35D8 50 (v01 DELL PE_SC3 00) [0.00] ACPI: HPET 0xCF3B362C 38 (v01 DELL PE_SC3 00) [0.00] ACPI: RMAD 0xCF3B3668 000198 (v01 DELL PE_SC3 00) [0.00] ACPI: MCFG 0xCF3B38C4 3C (v01 DELL PE_SC3 00) [0.00] ACPI: WD__ 0xCF3B3904 000134 (v01 DELL PE_SC3 00) [0.00] ACPI: SLIC 0xCF3B3A3C 000176 (v01 DELL PE_SC3 00) [0.00] ACPI: ERST 0xCF392F70 000270 (v01 DELL PE_SC3 00) [0.00] ACPI: HEST 0xCF3931E0 0003A8 (v01 DELL PE_SC3 00) [0.00] ACPI: BERT 0xCF392DD0 30 (v01 DELL PE_SC3 00) [0.00] ACPI: EINJ 0xCF392E00 000170 (v01 DELL PE_SC3 00) [0.00] ACPI: SRAT 0xCF3B3BC0 000370 (v01 DELL PE_SC3 00) [0.00] ACPI: TCPA 0xCF3B3F34 64 (v02 DELL PE_SC3 00) [0.00] ACPI: SSDT 0xCF3B7000 0043F4 (v01 INTEL PPM RCM 80) [0.00] Setting APIC routing to Xen PV. [0.00] NUMA turned off [0.00] Faking a node at [mem 0x-0x00062fff] [0.00] NODE_DATA(0) allocated [mem 0x5e6228000-0x5e622cfff] [0.00] Zone ranges: [0.00] DMA [mem 0x1000-0x00ff] [0.00] DMA32[mem 0x0100-0x] [0.00] Normal [mem 0x0001-0x00062fff] [0.00] Device empty [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x1000-0x0009dfff] [0.00] node 0: [mem 0x0010-0xcf378fff] [0.00] node 0: [mem 0x0001
Bug#633652: emacs on a text console - please help me overcome the shock
--On Tuesday, August 23, 2011 08:35:58 AM +0800 jida...@jidanni.org wrote: "r" == rdiezmail-emacs writes: r> The console mode has been a shock. There is no mouse at all. I cannot r> navigate the menus as usual, menu-bar-open is weird and unfriendly. r> But, worst of all, some key combinations do not work well. But that's the way it must be here on Debian, if you are root. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633652 My question is how do all those high powered Debian Developers cope? Don't tell me they don't use emacs. Or not as root. Not even when administering their system? If you are truly using the console then it is likely that some of the issues have nothing to do with emacs and everything to do with the console terminal emulation. At a base level emacs is depending on escape sequences to move the cursor around, but I expect it is doing a lot fancier things that only a good terminal emulator will keep up with. And I would add that I don't really want anyone working on improving console terminal emulation---there are too many other things to do that need to be done and no one spends much time on the console these days. As a side note I really hate modal editors like vi and its decendents, but I know enough of it to be able to work on consoles when emacs is not installed yet or the terminal emulation is not up to it. It is just part of managing the system in my view. Finally, when I am editing text I find that a mouse slows everything down. I do just fine with character cell xterms and no mouse. I do think it is worth getting color to work when possible. The syntax highlighting helps me spot stupid errors early. Bill -- Bill MacAllister Infrastructure Delivery Group, Stanford University -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
