Bug#922720: ca-certificates-java: update-ca-certificates fails with bashism in jks-keystore
Package: ca-certificates-java Version: 20170929~deb9u1 Severity: important Dear Maintainer, After upgrading to Debian 9.8 today, the following error results whenever I run update-ca-certificates: -- $ sudo update-ca-certificates Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... /etc/ca-certificates/update.d/jks-keystore: 56: [: amd64: unexpected operator done. done. -- This appears to be due to a bashism introduced by the fix for 874276: --- $ checkbashisms /etc/ca-certificates/update.d/jks-keystore possible bashism in /etc/ca-certificates/update.d/jks-keystore line 56 (should be 'b = a'): if [ "$arch" == "armhf" ]; then --- Thanks, Steve -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-8-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) Versions of packages ca-certificates-java depends on: ii ca-certificates 20161130+nmu1+deb9u1 ii libnss3 2:3.26.2-1.1+deb9u1 ii oracle-java8-installer [openjdk-7-jre-headless] 8u201-1~webupd8~1 ca-certificates-java recommends no packages. ca-certificates-java suggests no packages. -- Configuration Files: /etc/default/cacerts [Errno 13] Permission denied: '/etc/default/cacerts' -- no debconf information
Bug#744304: Still a problem in Jessie
control: severity -1 important This is a significant regression for Jessie. If the admin relied on RESOLVCONF=yes in /etc/default/bind9, the host will lose access to all names provided by the local named. This could cause any number of failures depending on the nature of the dependency. Please consider fixing this in Jessie ASAP. Thanks, Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#592539: Improved patch
Thanks for taking a look, C.J. I incorporated your fix for the typo
you mentioned in your postscript. I also rebased the patch against the
latest source; see the bug report for details.
I will also take a look at improving the handling of the dhcpd6.leases
file, as it appears to deviate from the handling of the v4
dhcpd.leases file. Thanks for your suggestions.
-Steve
On Jan 21, 2015, at 3:13 PM, C.J. Adams-Collier wrote:
> Hello Steven, ALCON,
>
> I've applied your patch to the 4.2.4 .deb source from Ubuntu Trusty and
> removed the apparmor and apport references:
>
> http://archive.ubuntu.com/ubuntu/pool/main/i/isc-dhcp/isc-dhcp_4.2.4-7ubuntu12.dsc
>
> I doubt that you used this source for the base of your patch, but it
> applied with only one rejection, so it was close enough for me. There
> were compile-time problems on my Wheezy build machine relating to
> apport / apparmor, but these were easy enough to deal with using
>
>$ grep -rsil -e apport -e apparmor isc-dhcp-4.2.4 | grep -v changelog
>
> Still, it would be nice to have the source you built from so that I
> could skip this stage. It would be nicer still if the patch applied to
> 4.2.2 (Wheezy) or 4.3.1 (Jessie).
>
> Once installed, I verified that stopping and starting the daemon did not
> cause an outage with the v4 server. It did not; I was able to request
> v4 leases on all interfaces as expected. I then modified
> the /etc/default/isc-dhcp-server config file to set the following
> variables:
>
>V6_ENABLED="true"
>INTERFACES_V6="vl78 eth4.100 eth4.101 eth3"
>
> A re-start of the daemon succeeded for v4, but failed for v6 due to a
> missing dhcpd6.leases file:
>
>Jan 21 09:17:35 sip1 dhcpd: Can't open lease database
> /var/lib/dhcp/dhcpd6.leases: No such file or directory --
>Jan 21 09:17:35 sip1 dhcpd: check for failed database rewrite
> attempt!
>Jan 21 09:17:35 sip1 dhcpd: Please read the dhcpd.leases manual page
> if you
>Jan 21 09:17:35 sip1 dhcpd: don't know what to do about this.
>
> It might be nice if the daemon grepped the log for this message and gave
> a more specific error message. I created the leases file with:
>
>$ sudo touch /var/lib/dhcp/dhcpd6.leases
>
> Re-starting succeeded for v4 and failed again for v6 because I had not
> written any subnet6 declarations and the daemon had no interfaces on
> which to listen. It might be nice if the daemon grepped the log for
> this message and gave a more specific error message:
>
>Jan 21 09:39:53 sip1 dhcpd: No subnet6 declaration for eth3
> (fe80::290:bff:fe0a:6c2).
>...
>Jan 21 09:39:53 sip1 dhcpd: No subnet6 declaration for eth4.101
> (fe80::290:bff:fe0a:e08b).
>...
>Jan 21 09:39:53 sip1 dhcpd: No subnet6 declaration for eth4.100
> (fe80::290:bff:fe0a:e08b).
>...
>Jan 21 09:39:53 sip1 dhcpd: No subnet6 declaration for vl78
> (2607:ff08:f5:1337::1).
>Jan 21 09:39:53 sip1 dhcpd: ** Ignoring requests on vl78. If this is
> not what
>Jan 21 09:39:53 sip1 dhcpd:you want, please write a subnet6
> declaration
>Jan 21 09:39:53 sip1 dhcpd:in your dhcpd.conf file for the network
> segment
>Jan 21 09:39:53 sip1 dhcpd:to which interface vl78 is attached. **
>Jan 21 09:39:53 sip1 dhcpd:
>Jan 21 09:39:53 sip1 dhcpd:
>Jan 21 09:39:53 sip1 dhcpd: Not configured to listen on any interfaces!
>
> I added a subnet6 declaration for the vl78 interface
> to /etc/dhcp/dhcpd6.conf and re-started the service successfully:
>
># vl78
>
>subnet6 2607:ff08:f5:1337::0/64 {
> # ::ac10:4e66 -::ac10:4e6d = ::172.16.78.102 - ::172.16.78.109 ;
> matches v4 subnet range
> range6 2607:ff08:f5:1337::ac10:4e66 2607:ff08:f5:1337::ac10:4e6d;
>
>
> option dhcp6.name-servers
> 2607:ff08:f5:1337::64,2607:ff08:f5:1337::19,2607:ff08:f5:3a::2;
> option dhcp6.domain-search "esd.colliertech.org","colliertech.org";
>
> # laptop / virtual machine
> host ubuntu0 {
>host-identifier option dhcp6.client-id
> 00:01:00:01:1c:52:b8:47:08:00:27:04:be:09;
>fixed-address6 2607:ff08:f5:1337::5d;
> }
>}
>
> At this point, I was able to solicit the server for an address from my
> laptop VM client, ubuntu0. Logs from server:
>
>Jan 21 15:02:44 sip1 dhcpd: Solicit message from
> fe80::a00:27ff:fe04:be09 port 546, transaction ID 0xC6EFEB00
>Jan 21 15:02:44 sip1 dhcpd: Sending Advertise to
> fe80::a00:27ff:fe04:be09 port 546
>Jan 21 15:02:45 sip1 dhcpd: Request message from
> fe80::a00:27ff:fe04:be09 port 546, transaction ID 0xD04C9800
>
Bug#592539: [PATCH] IPv6 Server Support
Attached an updated patch for IPv6 server support. This cleans up the
unnecessary translations that were in my previous patch, fixes some
bugs (thanks to C.J. Adams-Collier for one bug fix), and I've rebased
against the latest head.
Feedback still sought on the folowing points:
* the convention around "true" vs "yes" for values in /etc/default is
not clear to me; it seems debconf always goes with true/false for a
boolean, but many other scripts in /etc/default seem to use "yes".
I just used "true".
* Three new debconf values are added, with accompanying documentation;
this impacts the translations but I don't see any way around it
given the nature of the changes.
Any feedback or suggestions welcome.
Thanks,
Steve
diff --git a/debian/dhcpd6.conf b/debian/dhcpd6.conf
new file mode 100644
index 000..551a80c
--- /dev/null
+++ b/debian/dhcpd6.conf
@@ -0,0 +1,106 @@
+#
+# Sample configuration file for ISC dhcpdv6 for Debian
+#
+#
+
+# IPv6 address valid lifetime
+# (at the end the address is no longer usable by the client)
+# (set to 30 days, the usual IPv6 default)
+default-lease-time 2592000;
+
+# IPv6 address preferred lifetime
+# (at the end the address is deprecated, i.e., the client should use
+# other addresses for new connections)
+# (set to 7 days, the usual IPv6 default)
+preferred-lifetime 604800;
+
+# T1, the delay before Renew
+# (default is 1/2 preferred lifetime)
+# (set to 1 hour)
+option dhcp-renewal-time 3600;
+
+# T2, the delay before Rebind (if Renews failed)
+# (default is 3/4 preferred lifetime)
+# (set to 2 hours)
+option dhcp-rebinding-time 7200;
+
+# Enable RFC 5007 support (same than for DHCPv4)
+allow leasequery;
+
+# Global definitions for name server address(es) and domain search list
+#option dhcp6.name-servers 3ffe:501::100:200:ff:fe00:3f3e;
+#option dhcp6.domain-search "test.example.com","example.com";
+
+# Set preference to 255 (maximum) in order to avoid waiting for
+# additional servers when there is only one
+##option dhcp6.preference 255;
+
+# Server side command to enable rapid-commit (2 packet exchange)
+##option dhcp6.rapid-commit;
+
+# The delay before information-request refresh
+# (minimum is 10 minutes, maximum one day, default is to not refresh)
+# (set to 6 hours)
+option dhcp6.info-refresh-time 21600;
+
+# The path of the lease file
+#dhcpv6-lease-file-name "/var/lib/dhcp/dhcpd6.leases";
+
+# Static definition (must be global)
+#host myclient {
+# # The entry is looked up by this
+# host-identifier option
+# dhcp6.client-id 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2;
+
+# # A fixed address
+# fixed-address6 3ffe:501::100::1234;
+
+# # A fixed prefix
+# fixed-prefix6 3ffe:501::101::/64;
+
+# # Override of the global definitions,
+# # works only when a resource (address or prefix) is assigned
+# option dhcp6.name-servers 3ffe:501::100:200:ff:fe00:4f4e;
+
+# # For debug (to see when the entry statements are executed)
+# # (log "sol" when a matching Solicitation is received)
+# ##if packet(0,1) = 1 { log(debug,"sol"); }
+#}
+
+#host otherclient {
+## This host entry is hopefully matched if the client supplies a DUID-LL
+## or DUID-LLT containing this MAC address.
+#hardware ethernet 01:00:80:a2:55:67;
+#
+#fixed-address6 3ffe:501::100::4321;
+#}
+
+# The subnet where the server is attached
+# (i.e., the server has an address in this subnet)
+#subnet6 3ffe:501::100::/64 {
+# # Two addresses available to clients
+# # (the third client should get NoAddrsAvail)
+# range6 3ffe:501::100::10 3ffe:501::100::11;
+#
+# # Use the whole /64 prefix for temporary addresses
+# # (i.e., direct application of RFC 4941)
+# range6 3ffe:501::100:: temporary;
+#
+# # Some /64 prefixes available for Prefix Delegation (RFC 3633)
+# prefix6 3ffe:501::100:: 3ffe:501::111:: /64;
+#}
+
+# A second subnet behind a relay agent
+#subnet6 3ffe:501::101::/64 {
+# range6 3ffe:501::101::10 3ffe:501::101::11;
+#
+# # Override of the global definitions,
+# # works only when a resource (address or prefix) is assigned
+# option dhcp6.name-servers 3ffe:501::101:200:ff:fe00:3f3e;
+#
+#}
+
+# A third subnet behind a relay agent chain
+#subnet6 3ffe:501::102::/64 {
+# range6 3ffe:501::102::10 3ffe:501::102::11;
+#}
diff --git a/debian/isc-dhcp-server.config b/debian/isc-dhcp-server.config
index 412c4b3..9bb7894 100644
--- a/debian/isc-dhcp-server.config
+++ b/debian/isc-dhcp-server.config
@@ -13,12 +13,18 @@ INITCONFFILE=/etc/default/isc-dhcp-server
# preserve the configuration.
if [ -r ${INITCONFFILE} ]; then
. ${INITCONFFILE}
+ db_set isc-dhcp-server/v4_enabled "${V4_ENABLED:-true}"
+ db_set isc-dhcp-server/v6_enabled "${V6_ENABLED:-false}"
db_set isc-dhcp-server/interfaces "${INTERFACES}"
+ db_set isc-dhcp-server/interfaces_v6 "${INTERFACES_V6}"
fi
db_title "DHCP Server"
+db_input low isc-dhcp-server/v4_enabled || true
+db_input low isc-dhcp-server/v6_enabled
Bug#714470: installation-report: UEFI boot fails after install
Package: installation-reports Version: 2.49 Severity: important Tags: d-i Dear Maintainer, I was unable to boot into the installed system with UEFI support. I had to disable UEFI and boot in legacy mode instead in order to install the legacy version of grub to have a working system. -- Package-specific info: Boot method: USB thumb drive Image version: http://cdimage.debian.org/debian-cd/7.1.0/amd64/iso-cd/debian-7.1.0-amd64-netinst.iso Date: Machine: Intel DCCP847DYE Partitions: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[E] Comments/Problems: Overall the install went fine until the reboot. I booted the netinst image from a USB thumb drive. I noted during install that the uefi version of GRUB was installed, and the disk partitioned with a UEFI partition. But upon reboot, the bios refused to boot the drive, as though it had no boot loader on it at all. I made several different attempts to select the boot device explicitly and to reorder the boot devices, but the bios would attempt to boot the hard drive (no GRUB messages ever appeared); the boot did not hang, it simply fell back to other boot methods (e.g. the USB drive or it attempted net booting). I was able to install successfully by disabling UEFI boot in the bios screen and reinstalling. Then, the PC version of grub was installed and the legacy boot worked fine. The drive is a 128GB Samsung mSATA drive. -- Please make sure that the hardware-summary log file, and any other installation logs that you think would be useful are attached to this report. Please compress large files using gzip. Once you have filled out this report, mail it to sub...@bugs.debian.org. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="7 (wheezy) - installer build 20130613" X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux nuc 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: Kernel driver in use: agpgart-intel lspci -knn: 00:02.0 VGA compatible controller [0300]: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0106] (rev 09) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: 00:19.0 Ethernet controller [0200]: Intel Corporation 82579V Gigabit Network Connection [8086:1503] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: Kernel driver in use: e1000e lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: 00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: Kernel driver in use: ehci_hcd lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation QS77 Express Chipset LPC Controller [8086:1e56] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] lspci -knn: Kernel driver in use: ahci lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04) lspci -knn: Subsystem: Intel Corporation Device [8086:2044] usb-list: usb-list: Bus 01 Device 01: EHCI Host Controller [1d6b:0002] usb-list:Level 00 Parent 00 Port 00 Class 09(hub ) Subclass 00 Protocol 00 usb-list:
Bug#667858: linux-image-2.6.32-5-amd64: Crash in ext3 mark_inode_dirty
On Apr 6, 2012, at 10:51 PM, Ben Hutchings wrote: > More importantly, a machine check exception (MCE) indicates faulty > hardware - this could be the processor, motherboard, memory (if it has > ECC) or even an expansion card. Whatever it is, that is quite likely to > be the cause of the problem and must be fixed before we do any > investigation of software. You should find some record of the MCE in > the kernel log which may provide a hint as to what is faulty. Thanks for responding. /var/log/mcelog contains a few cycles of thermal events (like below), but nothing since Feb. 3. The most recent crash was yesterday morning. Is the mention of MCE generated by reportbug talking about this thermal event, or does that mean there is something more recent that's not showing up in /var/log/mcelog? $ ls -l /var/log/mcelog -rw-r--r-- 1 root root 23569 Feb 3 08:15 /var/log/mcelog $ tail /var/log/mcelog MCE 0 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 1 THERMAL EVENT TSC 11634544f0 Processor core is above trip temperature. Throttling enabled. STATUS 3 MCGSTATUS 0 MCE 1 HARDWARE ERROR. This is *NOT* a software problem! Please contact your hardware vendor CPU 1 THERMAL EVENT TSC 11636e2d01 Processor core below trip temperature. Throttling disabled STATUS 2 MCGSTATUS 0 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#667858: linux-image-2.6.32-5-amd64: Crash in ext3 mark_inode_dirty
Package: linux-2.6 Version: 2.6.32-41squeeze2 Severity: important The kernel sometimes crashes, rendering the system unresponsive. The stack trace is visible on the TV monitor connected via HDMI. The stack trace is always the same, beginning at a write system call and ending at __mark_inode_dirty. The system is used as a MythTV frontend and backend. It spends a lot of time suspended so it could be related to suspend/resume. This had gone on for quite a while with the standard Lenny kernel. After upgrading to Squeeze a few weeks ago, the problem continues to occur so I'm reporting the bug now. I will upload a photo of the stack trace; here are the function names: __mark_inode_dirty __block_commit_write ext3_ordered_write_end ext3_xattr_get generic_file_buffered_write __generic_file_aio_write __switch_to cpumask_any_but generic_file_aio_write do_sync_write autoremove_wake_function handle_mm_fault do_fork vfs_write sys_write system_call_fastpath Thanks, Steve -- Package-specific info: ** Version: Linux version 2.6.32-5-amd64 (Debian 2.6.32-41squeeze2) (da...@debian.org) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Thu Mar 22 17:26:33 UTC 2012 ** Command line: BOOT_IMAGE=/boot/vmlinuz-2.6.32-5-amd64 root=UUID=3c9beddf-b59c-4c7a-8022-14f268cec832 ro quiet ** Tainted: PM (17) * Proprietary module has been loaded. * System experienced a machine check exception. ** Kernel log: [18035.230578] e100 :07:08.0: restoring config space at offset 0xf (was 0x38080100, writing 0x3808010b) [18035.230593] e100 :07:08.0: restoring config space at offset 0x5 (was 0x1, writing 0x1101) [18035.230598] e100 :07:08.0: restoring config space at offset 0x4 (was 0x0, writing 0x59004000) [18035.230603] e100 :07:08.0: restoring config space at offset 0x3 (was 0x0, writing 0x2010) [18035.230609] e100 :07:08.0: restoring config space at offset 0x1 (was 0x290, writing 0x2900017) [18035.230766] HDA Intel :00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [18035.230772] HDA Intel :00:1b.0: setting latency timer to 64 [18035.230807] HDA Intel :00:1b.0: irq 31 for MSI/MSI-X [18035.230843] uhci_hcd :00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [18035.230849] uhci_hcd :00:1d.0: setting latency timer to 64 [18035.230870] usb usb2: root hub lost power or was reset [18035.230889] uhci_hcd :00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19 [18035.230895] uhci_hcd :00:1d.1: setting latency timer to 64 [18035.230915] usb usb3: root hub lost power or was reset [18035.230932] uhci_hcd :00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18 [18035.230937] uhci_hcd :00:1d.2: setting latency timer to 64 [18035.230957] usb usb4: root hub lost power or was reset [18035.230973] uhci_hcd :00:1d.3: PCI INT D -> GSI 16 (level, low) -> IRQ 16 [18035.230978] uhci_hcd :00:1d.3: setting latency timer to 64 [18035.230998] usb usb5: root hub lost power or was reset [18035.231037] ehci_hcd :00:1d.7: PCI INT A -> GSI 23 (level, low) -> IRQ 23 [18035.231044] ehci_hcd :00:1d.7: setting latency timer to 64 [18035.231054] pci :00:1e.0: setting latency timer to 64 [18035.231063] ata_piix :00:1f.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18 [18035.231068] ata_piix :00:1f.1: setting latency timer to 64 [18035.232098] ata6: port disabled. ignoring. [18035.232117] ahci :00:1f.2: setting latency timer to 64 [18035.866191] ata2: SATA link down (SStatus 0 SControl 300) [18035.866221] ata4: SATA link down (SStatus 0 SControl 300) [18035.866464] C-Media PCI :07:01.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 [18035.872361] ata5.00: ACPI cmd ef/03:0c:00:00:00:a0 (SET FEATURES) filtered out [18035.872365] ata5.00: ACPI cmd ef/03:42:00:00:00:a0 (SET FEATURES) filtered out [18035.872369] ata5.00: ACPI cmd f5/00:00:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out [18036.000264] ata5.00: configured for UDMA/33 [18036.176039] firewire_core: skipped bus generations, destroying all nodes [18036.176068] pci :00:1e.0: wake-up capability disabled by ACPI [18036.176076] e100 :07:08.0: PME# disabled [18036.193816] parport_pc 00:07: activated [18036.194328] serial 00:09: activated [18036.196134] e100: eth0 NIC Link is Up 100 Mbps Full Duplex [18036.492023] sd 0:0:0:0: [sda] Starting disk [18036.676037] firewire_core: rediscovered device fw0 [18040.904014] ata3: link is slow to respond, please be patient (ready=0) [18040.904021] ata1: link is slow to respond, please be patient (ready=0) [18041.240026] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [18041.344287] ata1.00: configured for UDMA/133 [18041.352025] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [18041.385162] sd 2:0:0:0: [sdb] Starting disk [18041.451601] ata3.00: configured for UDMA/133 [18041.748017] usb 5-2: reset low speed USB device using uhci_hcd and address 2 [18042.059284] PM: Finishing wakeup. [18042.059287] Restarting tasks ... done. [18042.429462] CPU0 attaching NULL sch
Bug#422777: Experimental ati driver fixed it for me
I hit the same problem, and the above-mentioned version of xserver-xorg-video-ati (1:6.6.191-1) fixed the problem for me with no obvious side effects. -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#362282: Still no sound with ICH7, AMD64
Is there a specific cause for this "ICH7 no sound" problem? This bug report log suggests to wait for alsa-lib_1.0.11-7, and another poster suggests that dist-upgrade to 1.0.11-6 fixed the problem for him. But I'm running AMD64 and I'm stuck at 1.0.11-4 of the alsa-lib packages, because of the bi-arch build problem. I tried building 1.0.11-7 from source myself and ran into the same problem. Is there a specific patch I can try to get my sound working again? I looked through the Debian changelogs of alsa-base and alsa-lib and I didn't see anything indicating a bug like this had been fixed. I had everything working fine several weeks or a month ago, with kernel 2.6.16, but now I get no sound at all (after a few dist-upgrades). I also built the latest alsa kernel modules (1.0.11) with the Debian alsa-source package, and that didn't help either. Thanks for any help. -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#366656: linux-source-2.6.16: Please apply ThinkPad suspend patch from OSDL bug 3022
Package: linux-source-2.6.16 Severity: normal Tags: patch There is a well documented issue where certain ThinkPads with Radeon video chipsets use too much power while suspended. The GPU needs special treatment to put it to sleep, otherwise it continues to burn a lot of power while suspended (mine lasts just a few hours while suspended). For more information see: http://www.thinkwiki.org/wiki/Problem_with_high_power_drain_in_ACPI_sleep http://bugme.osdl.org/show_bug.cgi?id=3022 >From the OSDL bug report I obtained the following patch: http://bugme.osdl.org/attachment.cgi?id=7899&action=view Which solved the problem for me (mine is a ThinkPad T40, model 2373-94U). If possible, please include the patch in the stock Debian kernel. Since it is based on a whitelist of known ThinkPad models it seems to be pretty safe. The patch does require using the radeonfb framebuffer console driver; I accomplished this simply by adding radeonfb to /etc/modules. Thanks, Steve -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.15-hamachi Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301967: apt-get and dependent packages
Rick Nelson wrote: >apt-get doesn't pull in dependant packages :( > >you'll need to 'apt-get install sendmail sendmail-bin ...', or use >dselect which will also select dependant packages What on earth are you talking about?? Of course apt-get pulls in dependent packages. And specifically, it will install sendmail-bin if you request sendmail. For example: [EMAIL PROTECTED]:sihde]$ sudo apt-get install sendmail at mailx mutt Reading Package Lists... Done Building Dependency Tree... Done The following extra packages will be installed: rmail sendmail-base sendmail-bin sendmail-cf sensible-mda Suggested packages: urlview aspell mixmaster openssl ca-certificates sendmail-doc logcheck sasl2-bin libsasl2-modules libsasl2-modules-plain libsasl2-digestmd5-plain libsasl2-digestmd5-des Recommended packages: resolvconf The following NEW packages will be installed: at mailx mutt rmail sendmail sendmail-base sendmail-bin sendmail-cf sensible-mda 0 upgraded, 9 newly installed, 0 to remove and 0 not upgraded. Need to get 2243kB/3661kB of archives. After unpacking 9490kB of additional disk space will be used. Do you want to continue? [Y/n] -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#283605: NTLM patch in openldap
As of 2.1.30-4, the Debian openldap packages included the NTLM patch but it's broken as of 2.1.30-6. I filed bug 305559 against libldap2 with a patch to get it working. Once that bug is fixed, it should be possible simply to rebuild the exchange connector and NTLM support will be enabled by default. -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305559: libldap2: NTLM patch still not correctly integrated
Package: libldap2
Version: 2.1.30-6
Severity: normal
Tags: patch
The NTLM patch that was applied in 2.1.30-4 and is also mentioned in
the changelog for 2.1.30-6 still doesn't work. The included patch
fixes the problem. After applying the patch and recompiling, the
ldap_ntlm_bind symbol does show up in the libraries. The real test is
when recompiling ximian-connector does its configure script find and
enable ntlm support -- and it does, so everything seems fine:
checking for ldap_ntlm_bind... yes
Detailed explanation:
ntlm_bind didn't make it into the library:
nm /usr/lib/libldap.a | grep ntlm_bind
There are several problems:
1. libraries/libldap/Makefile.in mentions ntlm.c as a SRC, but not
ntlm.lo as an OBJ. Thus, ntlm.c is never compiled.
2. If we do add ntlm.lo to OBJS, it fails to compile, complaining
about too many args for ldap_send_initial_request. This is because
the ntlm.c included is the one from the patch against openldap 2.2,
not against openldap 2.1. In other words, this patch:
http://cvs.gnome.org/viewcvs/*checkout*/evolution-exchange/docs/openldap-ntlm.diff?rev=1.2
was applied, but instead this patch should have been applied:
http://cvs.gnome.org/viewcvs/*checkout*/evolution-exchange/docs/openldap-ntlm.diff?rev=1.1
The included patch against the Debian openldap2 2.1.30-6 source will
synchronize it with the correct (older) patch supplied by the
Evolution folks -- rev 1.1, the one that is intended to apply against
openldap 2.1.
BTW, this also addresses the wishlist bug 262604.
Ideally, evolution-exchange should be rebuilt after this patch is
applied and libldap2-dev is rebuilt. Then it will support NTLM by
default. I'll file that as a separate bug against evolution-exchange.
Thanks,
Steve
diff -Naur openldap2-2.1.30.orig/libraries/libldap/Makefile.in
openldap2-2.1.30/libraries/libldap/Makefile.in
--- openldap2-2.1.30.orig/libraries/libldap/Makefile.in 2005-04-20
18:55:08.579460944 +
+++ openldap2-2.1.30/libraries/libldap/Makefile.in 2005-04-20
18:54:03.414839895 +
@@ -21,7 +21,7 @@
OBJS = bind.lo open.lo result.lo error.lo compare.lo search.lo \
controls.lo messages.lo references.lo extended.lo cyrus.lo \
modify.lo add.lo modrdn.lo delete.lo abandon.lo \
- sasl.lo sbind.lo kbind.lo unbind.lo cancel.lo cache.lo \
+ sasl.lo sbind.lo kbind.lo ntlm.lo unbind.lo cancel.lo cache.lo \
filter.lo free.lo sort.lo passwd.lo whoami.lo \
getdn.lo getentry.lo getattr.lo getvalues.lo addentry.lo \
request.lo os-ip.lo url.lo sortctrl.lo vlvctrl.lo \
diff -Naur openldap2-2.1.30.orig/libraries/libldap/ntlm.c
openldap2-2.1.30/libraries/libldap/ntlm.c
--- openldap2-2.1.30.orig/libraries/libldap/ntlm.c 2005-04-20
18:55:08.579460944 +
+++ openldap2-2.1.30/libraries/libldap/ntlm.c 2005-04-20 18:54:08.864137145
+
@@ -30,7 +30,6 @@
{
BerElement *ber;
int rc;
- ber_int_t id;
Debug( LDAP_DEBUG_TRACE, "ldap_ntlm_bind\n", 0, 0, 0 );
@@ -51,9 +50,8 @@
assert( LBER_VALID( ber ) );
- LDAP_NEXT_MSGID( ld, id );
rc = ber_printf( ber, "{it{istON}" /*}*/,
-id, LDAP_REQ_BIND,
+++ld->ld_msgid, LDAP_REQ_BIND,
ld->ld_version, dn, tag,
cred );
@@ -69,8 +67,14 @@
return ld->ld_errno;
}
+#ifndef LDAP_NOCACHE
+ if ( ld->ld_cache != NULL ) {
+ ldap_flush_cache( ld );
+ }
+#endif /* !LDAP_NOCACHE */
+
/* send the message */
- *msgidp = ldap_send_initial_request( ld, LDAP_REQ_BIND, dn, ber, id );
+ *msgidp = ldap_send_initial_request( ld, LDAP_REQ_BIND, dn, ber );
if(*msgidp < 0)
return ld->ld_errno;
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (990, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.11-hamachi
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages libldap2 depends on:
ii libc6 2.3.2.ds1-21 GNU C Library: Shared libraries an
ii libgnutls11 1.0.16-13GNU TLS library - runtime library
ii libsasl22.1.19-1.5 Authentication abstraction library
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#294995: java-package: please support unlimited crypto policy files jce_policy*.zip
Package: java-package
Version: 0.20
Severity: wishlist
On Sun's download pages, there is a section at the end called Other
Downloads. There, one can download jce_policy-x_y_z.zip (where x_y_z
is the java version number). This zip contains a US_export_policy.jar
and a local_policy.jar that are meant to replace the jars by the same
name in jre/lib/security.
The new jars allow unlimited strength crypto; for example, AES with
256-bit key will not work without these jars.
It would be nice if java-package supported this. I see several
possibilities:
1. Just build it in to the scripts; if the user is building a Sun
package and the script detects an appropriately named jce_policy-* in
the same directory as the .bin file, prompt the user and ask if he'd
like to use it. If so, replace the jars in jre/lib/security with the
new ones before building the .deb.
2. Enhance make-jpkg to build tiny sun-j2{sdk,re}1.{4,5}-jce-policy
.debs from the jce_policy-*.zip files that contain only the two jars,
and dpkg-divert the old jars appropriately.
3. Supply a shell script that will assist the admin in setting up a
local diversion.
I think I like #2 the best. #1 has the problem that it's difficult to
tell whether a given sun-j2sdk* package has the crypto jars or not.
#3 will certainly work but doesn't seem entirely satisfactory.
Thoughts? I can contribute something if that will help.
Thanks,
Steve
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (900, 'unstable'), (890, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.8-hamachi
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages java-package depends on:
ii coreutils 5.2.1-2The GNU core utilities
ii debhelper 4.2.30 helper programs for debian/rules
ii fakeroot 1.2.4 Gives a fake root environment
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291940: 290964 is related
It appears that bug 290964 (against kernel-image-2.6.10-1-686) is essentially the same as this bug. -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#291940: kernel-source-2.6.10: IPv6-in-IPv4 tunnel hangs at shutdown, "Waiting for to become free"
Package: kernel-source-2.6.10 Version: 2.6.10-4 Severity: important My IPv6-in-IPv4 tunnel causes 2.6.10 to hang on shutdown (every time). The tunnel is named henet0; the message printed over and over is: unregister_netdevice: waiting for henet0 to become free. Usage count = 1 I verified that the hang also happens with 2.6.10 vanilla (i.e., Debian patches removed). It worked fine with 2.6.8 (Debian). Apparently there were issues with unregister_netdevice that were solved previously, but this appears to be a new bug with 2.6.10. This has been discussed recently on the linux-netdev mailing list; here are some links: http://marc.theaimsgroup.com/?l=linux-netdev&m=110585721626841&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=110476395824647&w=2 http://marc.theaimsgroup.com/?l=linux-netdev&m=110405248721053&w=2 This appears similar to Debian bug 291029 but I'm filing it as a separate bug, because 291029 involves a bridge device whereas this involves a 6-in-4 tunnel device. From perusing the discussion on linux-netdev it sounds like they may be separate issues. This message on linux-netdev had a patch; it wasn't clear whether it was supposed to fix this problem, but I tried it anyway and it did not: http://marc.theaimsgroup.com/?l=linux-netdev&m=110451354301328&w=2 For now, I'm hanging back at 2.6.8 because I don't like the idea that I can't reboot the box remotely. Thanks, Steve -- System Information: Debian Release: 3.1 APT prefers unstable APT policy: (900, 'unstable'), (890, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.8-hamachi Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages kernel-source-2.6.10 depends on: ii binutils 2.15-5 The GNU assembler, linker and bina ii bzip2 1.0.2-2high-quality block-sorting file co ii coreutils [fileutils] 5.2.1-2The GNU core utilities ii fileutils 5.2.1-2The GNU file management utilities -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#289245: java-package: alternatives not removed when sun-j2sdk* is removed
On Sat, 08 Jan 2005 03:54:43 +0100, Jeroen van Wolffelaar wrote: [...] > I can see a few reasons why those packages exist at all: a way to get > depended on and suggested if one tries to fulfil dependencies in sarge, > and a way users to track whether they are uptodate java-wise. The latter > isn't being done at the moment, so I'll disregard that. Fir former > however I can understand: Due to these *debian packages, if one needs a > 'java2-compiler', apt will come and suggest that the *debian package can > fulfil that depends, and in turn need a not-yet-created package. The former is an interesting point, which I hadn't considered. However we should note that the circular dependency complicates this process too. If you set up your own private apt repository with the generated packages and add it to your sources.list it will work OK, but most people won't do that and instead this is the sequence of events they must suffer through: apt-get install [something-depending-on-java2-runtime] [Hmm, what's this sun-j2sdk1.4debian package maybe I'll try this...] apt-get install sun-j2sdk1.4debian [FAILS] [Hmm, that didn't work I guess I need java-package] apt-get install java-package [figure out how it works, download sun stuff] make-jpkg j2sdk... [sun-j2sdk*.deb packages are created] dpkg -i sun-j2sdk*.deb [FAILS because it depends on sun-j2sdk*debian] apt-get install sun-j2sdk1.4debian [finally it all works -- sun-j2sdk1.4debian can be installed since sun-j2sdk1.4 is installed but not configured -- after sun-j2sdk1.4debian is installed, sun-j2sdk1.4 configuration can complete] Yes it works, but it's not exactly smooth. OTOH, if sun-j2sdk1.4debian didn't depend on the sun-j2sdk1.4 package, the "dpkg -i sun-j2sdk1.4*.deb" would succeed and then when the user tried, e.g., "apt-get install libjava-whatever" the sun-j2sdk1.4debian package would be automatically installed without incident. This would clean up the above process slightly, but how much difference that would make is a matter of opinion I guess. > > Otoh, I see no compelling reason for the *debian packages to be depended > on by the generated packages... those two scripts (install and remove) > can just as well be pasted into the generated packages, much > safer... I agree, it seems better if the scripts necessary to configure/remove the package are actually part of the package. Note, however, that this means sun-j2sdk1.4debian would be completely empty except for changelog, etc. > > I'll need to think this over a bit more, meanwhile, any input welcome on > what do with this. Just dropping all *debian packages from java-package > sounds tempting, but otoh, I'm not sure whether it's a good idea. Either way sounds OK to me, but considering your first point above it's probably true that without the *debian packages it is much harder to learn of the existence of this java-package system. -Steve -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
