Processing of partman-basicmethods_36_amd64.changes
partman-basicmethods_36_amd64.changes uploaded successfully to localhost along with the files: partman-basicmethods_36.dsc partman-basicmethods_36.tar.gz partman-basicmethods_36_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-crypto_24_amd64.changes
partman-crypto_24_amd64.changes uploaded successfully to localhost along with the files: partman-crypto_24.dsc partman-crypto_24.tar.gz partman-crypto-dm_24_all.udeb partman-crypto-loop_24_all.udeb partman-crypto_24_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-auto-raid_7_amd64.changes
partman-auto-raid_7_amd64.changes uploaded successfully to localhost along with the files: partman-auto-raid_7.dsc partman-auto-raid_7.tar.gz partman-auto-raid_7_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-dmraid_2_amd64.changes
partman-dmraid_2_amd64.changes uploaded successfully to localhost along with the files: partman-dmraid_2.dsc partman-dmraid_2.tar.gz partman-dmraid_2_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-auto_72_amd64.changes
partman-auto_72_amd64.changes uploaded successfully to localhost along with the files: partman-auto_72.dsc partman-auto_72.tar.gz partman-auto_72_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414638: marked as done (partman-crypto: cryptsetup fails for encrypted non-ext2 /tmp)
Your message dated Wed, 05 Dec 2007 12:32:05 + with message-id <[EMAIL PROTECTED]> and subject line Bug#414638: fixed in partman-crypto 24 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: installation-reports Boot method: cd Image version: http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-CD-1.jigdo Date: 2007-03-11 Machine: hp pavillion dv6000 Processor: amd turion64 x2 Memory: 2GB Partitions: FilesystemTypeInodes IUsed IFree IUse% Mounted on /dev/sda1 ext3 54216 10580 43636 20% / tmpfstmpfs257556 2 2575541% /lib/init/rw udev tmpfs257556 487 2570691% /dev tmpfstmpfs257556 1 2575551% /dev/shm /dev/mapper/sda9_crypt ext3 8568832 13242 8901% /home /dev/mapper/sda6_crypt ext2 24096 69 240271% /tmp /dev/sda2 ext3428544 59717 368827 14% /usr /dev/sda8 ext34032007471 3957292% /usr/src /dev/sda5 ext31587204788 1539324% /var Output of lspci -nn and lspci -vnn: peg:/home/markybob# lspci -nn 00:00.0 RAM memory [0500]: nVidia Corporation C51 Host Bridge [10de:02f7] (rev a2) 00:00.1 RAM memory [0500]: nVidia Corporation C51 Memory Controller 0 [10de:02fa] (rev a2) 00:00.2 RAM memory [0500]: nVidia Corporation C51 Memory Controller 1 [10de:02fe] (rev a2) 00:00.3 RAM memory [0500]: nVidia Corporation C51 Memory Controller 5 [10de:02f8] (rev a2) 00:00.4 RAM memory [0500]: nVidia Corporation C51 Memory Controller 4 [10de:02f9] (rev a2) 00:00.5 RAM memory [0500]: nVidia Corporation C51 Host Bridge [10de:02ff] (rev a2) 00:00.6 RAM memory [0500]: nVidia Corporation C51 Memory Controller 3 [10de:027f] (rev a2) 00:00.7 RAM memory [0500]: nVidia Corporation C51 Memory Controller 2 [10de:027e] (rev a2) 00:02.0 PCI bridge [0604]: nVidia Corporation C51 PCI Express Bridge [10de:02fc] (rev a1) 00:03.0 PCI bridge [0604]: nVidia Corporation C51 PCI Express Bridge [10de:02fd] (rev a1) 00:04.0 PCI bridge [0604]: nVidia Corporation C51 PCI Express Bridge [10de:02fb] (rev a1) 00:09.0 RAM memory [0500]: nVidia Corporation MCP51 Host Bridge [10de:0270] (rev a2) 00:0a.0 ISA bridge [0601]: nVidia Corporation MCP51 LPC Bridge [10de:0260] (rev a3) 00:0a.1 SMBus [0c05]: nVidia Corporation MCP51 SMBus [10de:0264] (rev a3) 00:0a.3 Co-processor [0b40]: nVidia Corporation MCP51 PMU [10de:0271] (rev a3) 00:0b.0 USB Controller [0c03]: nVidia Corporation MCP51 USB Controller [10de:026d] (rev a3) 00:0b.1 USB Controller [0c03]: nVidia Corporation MCP51 USB Controller [10de:026e] (rev a3) 00:0d.0 IDE interface [0101]: nVidia Corporation MCP51 IDE [10de:0265] (rev f1) 00:0e.0 IDE interface [0101]: nVidia Corporation MCP51 Serial ATA Controller [10de:0266] (rev f1) 00:10.0 PCI bridge [0604]: nVidia Corporation MCP51 PCI Bridge [10de:026f] (rev a2) 00:10.1 Audio device [0403]: nVidia Corporation MCP51 High Definition Audio [10de:026c] (rev a2) 00:14.0 Bridge [0680]: nVidia Corporation MCP51 Ethernet Controller [10de:0269] (rev a3) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 03:00.0 Network controller [0280]: Broadcom Corporation Dell Wireless 1390 WLAN Mini-PCI Card [14e4:4311] (rev 01) 05:00.0 VGA compatible controller [0300]: nVidia Corporation GeForce Go 7200 [10de:01d6] (rev a1) 07:05.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd Unknown device [1180:0832] 07:05.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 19) 07:05.2 System peripheral [0880]: Ricoh Co Ltd Unknown device [1180:0843] (rev 01) 07:05.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 0a) 07:05.4 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 05) lspci -vnn 00:00.0 RAM memory [0500]: nVidia Corporation C51 Host Bridge [10de:02f7] (rev a2) Subsystem: Hewlett-Packard Company Unknown device [103c:30b7] Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface
Bug#439660: marked as done (partman-efi: Support for amd64)
Your message dated Wed, 05 Dec 2007 12:32:07 + with message-id <[EMAIL PROTECTED]> and subject line Bug#439660: fixed in partman-efi 14 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: partman-efi Hi, gnu-efi recently got support for amd64. I think it makes sense to also use this package on amd64, so can support for amd64 be added? Kurt --- End Message --- --- Begin Message --- Source: partman-efi Source-Version: 14 We believe that the bug you reported is fixed in the latest version of partman-efi, which is due to be installed in the Debian FTP archive: partman-efi_14.dsc to pool/main/p/partman-efi/partman-efi_14.dsc partman-efi_14.tar.gz to pool/main/p/partman-efi/partman-efi_14.tar.gz partman-efi_14_amd64.udeb to pool/main/p/partman-efi/partman-efi_14_amd64.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Frans Pop <[EMAIL PROTECTED]> (supplier of updated partman-efi package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 05 Dec 2007 13:20:33 +0100 Source: partman-efi Binary: partman-efi Architecture: source amd64 Version: 14 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Frans Pop <[EMAIL PROTECTED]> Description: partman-efi - Add to partman support for EFI boot partitions (udeb) Closes: 439660 Changes: partman-efi (14) unstable; urgency=low . [ Colin Watson ] * Move sanity-checking scripts from finish.d to check.d. Requires partman-base 106. * Use 'mkdir -p' rather than more awkward test-then-create constructions. . [ Frans Pop ] * Move deletion of SVN directories to install-rc script. * Improve the way install-rc is called. * Add amd64 to supported architectures. Closes: #439660. . [ Updated translations ] * Belarusian (be.po) by Hleb Rubanau * Bengali (bn.po) by Jamil Ahmed * Danish (da.po) by Claus Hindsgaul * Basque (eu.po) by Piarres Beobide * Italian (it.po) by Stefano Canepa * Malayalam (ml.po) by Praveen|പ്രവീണ് A|എ * Panjabi (pa.po) by A S Alam * Portuguese (Brazil) (pt_BR.po) by Felipe Augusto van de Wiel (faw) * Romanian (ro.po) by Eddy Petrișor * Vietnamese (vi.po) by Clytie Siddall Files: a36ba8b9ae7223ffc58eb0825a2ee85a 667 debian-installer standard partman-efi_14.dsc 1dcf80fd2892b8c438dbc32edcba653b 37416 debian-installer standard partman-efi_14.tar.gz 2f8d70f13df571185cb492c01f084bcd 21380 debian-installer standard partman-efi_14_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHVpitgm/Kwh6ICoQRAu8zAKDSOC0cIYzd3l3/OhdAIpIejQu4DACfdtD4 /S9GvYhZ7902S0ZpeVX3BSU= =Gfby -END PGP SIGNATURE- --- End Message ---
Bug#454493: Display PCI slot for nics, if available
dann frazier <[EMAIL PROTECTED]> writes: > Currently this patch only attempts to load the acpiphp driver - it > should probably try and load others as well (e.g. pciehp & shchp, and > the future possible pci_slot). Why acpihp isn't loaded by udev automaticaly? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Partman reorganization - day 1
As agreed with Max yesterday, I've started by doing uploads for almost all pending changes in partman. After that I've started on the reorganization, the first part of which is now completed. I've run a test install for the current status and have not seen any regressions. The changes today should not cause any changes in functionality. Most just moved code around. Along the way I've also fixed a few bugs. Before the upload: - partman-crypto (fairly serious issue) * Remove progresscancel capability again after erase progress bar to avoid all following progress bars to become cancelable as well. Ensure backup capability is retained. - partman-auto * lvm-wipe-disk(): needs device-mapper support while removing devices (for some reason we now need to have dm-mod loaded when removing LVM data; I'm pretty sure that was not the case for Etch) * lvm-wipe-disk(): fix restart logic After the upload: - partman-crypto (minor error in recent commit) * finish.d/crypto_config: fix script error when $tmp is empty I also committed this change in partman/Makefile because dpkg-shlibdeps gave a warning that libld.so.2 was unused: -LIBS=-lparted -ldl +LIBS=-lparted If someone knows this to be incorrect, please shout. Overview of the reorganization == Most commits are just moving files containing library functions around, including updates for all scripts that source them: partman-base: ./definitions.sh-> ./lib/base.sh partman-partitioning: ./resize.sh -> ./lib/resize.sh partman-lvm: ./lvm_tools.sh -> ./lib/lvm-base.sh partman-crypto: ./crypto_tools.sh -> ./lib/crypto-base.sh partman-auto: ./recipes.sh-> ./lib/recipes.sh ./auto-shared.sh-> ./lib/auto-shared.sh partman-auto-lvm: ./auto-lvm_tools.sh -> ./lib/auto-lvm.sh Then there are two commits that add a 'memfree' function in base.sh and updates partman-crypto to use that. I intend to also use that function tomorrow to dynamically load LVM and crypto support only if there is sufficient memory. The last commit is by far the most invasive. It is based on a change proposed by Jérémy in #396023, but takes his suggestion a bit further. The commit moves everything that has to do with disk labels (including four templates) from partman-base to partman-partitioning. Among others it moves the default_disk_label function from base.sh in p-base to a new function library file new-label.sh [1] in p-partitioning. Main reason is that this function is only called from a few specific places and thus having it in base.sh is just not efficient, especially given that it is ~150 lines of code. The new function create_new_label is now only used from p-partitioning itself, but intention is to also use it from partman-auto when using guided partitioning of a whole disk. I'll work on that tomorrow as well. Cheers, FJP [1] It just occurs to me that disk-label.sh is probably be a better name... signature.asc Description: This is a digitally signed message part.
Bug#454493: Display PCI slot for nics, if available
Package: hw-detect
Version: 1.58
Severity: wishlist
Tags: patch
The linux kernel may expose slot information for PCI devices in
sysfs. Currently slot info is only exposed if the PCI device is
hotpluggable and the associated hotplug driver is loaded. However,
work is underway[1] to expose slot information for non-hotplug pci
devices that are exposed via ACPI.
This patch to hw-detect adds slot information, if available, to the
network device name. Its not uncommon for HP (or our customers) to
have systems with many network devices, and knowing the physical slot
number of an adapter makes configuration that much easier.
Currently this patch only attempts to load the acpiphp driver - it
should probably try and load others as well (e.g. pciehp & shchp, and
the future possible pci_slot).
Attached is a screen shot of a d-i build w/ this patch. Some nics
share the same slot because they are dual-port cards, and some nics
have no slot info because they are not hotplug and I'm using a
standard kernel that does not yet have non-hotplug slot support.
[1] http://lkml.org/lkml/2007/11/12/263
http://lkml.org/lkml/2007/11/14/331
http://lkml.org/lkml/2007/11/17/126
Index: hw-detect/debian/changelog
===
--- hw-detect/debian/changelog (revision 50286)
+++ hw-detect/debian/changelog (working copy)
@@ -1,3 +1,9 @@
+hw-detect (1.59) UNRELEASED; urgency=low
+
+ * Display the PCI slot for network device, if exported in sysfs
+
+ -- dann frazier <[EMAIL PROTECTED]> Tue, 04 Dec 2007 18:02:24 -0700
+
hw-detect (1.58) unstable; urgency=low
* Install acpi-support-base, needed now to get power button shutdowns to
Index: hw-detect/sysfs-update-devnames.sh
===
--- hw-detect/sysfs-update-devnames.sh (revision 50286)
+++ hw-detect/sysfs-update-devnames.sh (working copy)
@@ -2,6 +2,35 @@
# Make sure that /etc/network/devnames is up to date, using sysfs. In
# hotplug land, we may not get a chance to update it otherwise.
+# This currently only works for hotplug devices, but may work for
+# others devices in the future.
+iface_to_slot() {
+ iface="$1"
+
+ if [ ! -h "/sys/class/net/$iface/device" ]; then
+ return 1
+ fi
+
+ modprobe acpiphp || true
+
+ if [ ! -d /sys/bus/pci/slots ]; then
+ return 2
+ fi
+
+ ifdevpath=$(readlink "/sys/class/net/$iface/device")
+ ifaddr=${ifdevpath##*/}
+ ifaddr=${ifaddr%.*}
+
+ ifslot=""
+ for slot in /sys/bus/pci/slots/*; do
+ if [ "$ifaddr" = "$(cat $slot/address)" ]; then
+ echo ${slot##*/}
+ return 0
+ fi
+ done
+ return 4
+}
+
if [ ! -d /sys/class/net ] || ! type lspci >/dev/null 2>&1; then
exit
fi
@@ -14,12 +43,13 @@
[ -f "/sys/class/net/$dev/device/device" ]; then
vendor="$(sed 's/^0x//' "/sys/class/net/$dev/device/vendor")"
device="$(sed 's/^0x//' "/sys/class/net/$dev/device/device")"
+ slot="[Slot $(iface_to_slot $dev)] " || slot=""
# 'tail -n 1' because for some reason lspci outputs two
# Device: lines.
vendorname="$(lspci -d "$vendor:$device" -m -v | grep ^Vendor:
| tail -n 1 | sed 's/^Vendor:[[:space:]]*//; s/,/\\,/g')"
devicename="$(lspci -d "$vendor:$device" -m -v | grep ^Device:
| tail -n 1 | sed 's/^Device:[[:space:]]*//; s/,/\\,/g')"
- if [ "$vendorname" ] || [ "$devicename" ]; then
- echo "$dev:$vendorname $devicename" >>
/etc/network/devnames
+ if [ "$vendorname" ] || [ "$devicename" ] || [ "$slot" ]; then
+ echo "$dev:$slot$vendorname $devicename" >>
/etc/network/devnames
fi
elif [ "$(readlink -f /sys/class/net/$dev/device/bus)" =
/sys/bus/ieee1394 ] || \
[ "$(readlink -f /sys/class/net/$dev/device/bus)" =
/sys/bus/firewire ]; then
--
dann frazier
<>
Processing of partman-base_113_amd64.changes
partman-base_113_amd64.changes uploaded successfully to localhost along with the files: partman-base_113.dsc partman-base_113.tar.gz partman-base_113_amd64.udeb partman-utils_113_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Partman reorganization - day 1
On Wednesday 05 December 2007, Frans Pop wrote: > As agreed with Max yesterday, I've started by doing uploads for almost > all pending changes in partman. After that I've started on the > reorganization, the first part of which is now completed. I've run a test > install for the current status and have not seen any regressions. Some quick info about testing. I've tested this with the following udebs included in localudebs: partman-base, partman-utils partman-partitioning partman-crypto, partman-crypto-dm, partman-crypto-loop partman-lvm partman-auto partman-auto-crypto partman-auto-lvm They can be included in a mini.iso by adding the following in pkg-lists/netboot/local (auto-crypto pulls in all others as dependencies): bootstrap-base partman-auto-crypto Other udebs only have relatively trivial changes and including only these ensured the backwards compatibility definitions.sh symlink was also tested. All of the udebs listed above will need to be uploaded at the same time. signature.asc Description: This is a digitally signed message part.
partman-crypto_24_amd64.changes ACCEPTED
Accepted: partman-crypto-dm_24_all.udeb to pool/main/p/partman-crypto/partman-crypto-dm_24_all.udeb partman-crypto-loop_24_all.udeb to pool/main/p/partman-crypto/partman-crypto-loop_24_all.udeb partman-crypto_24.dsc to pool/main/p/partman-crypto/partman-crypto_24.dsc partman-crypto_24.tar.gz to pool/main/p/partman-crypto/partman-crypto_24.tar.gz partman-crypto_24_amd64.udeb to pool/main/p/partman-crypto/partman-crypto_24_amd64.udeb Override entries for your package: partman-crypto-dm_24_all.udeb - optional debian-installer partman-crypto-loop_24_all.udeb - optional debian-installer partman-crypto_24.dsc - source debian-installer partman-crypto_24_amd64.udeb - standard debian-installer Announcing to [EMAIL PROTECTED] Closing bugs: 414638 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-auto_72_amd64.changes ACCEPTED
Accepted: partman-auto_72.dsc to pool/main/p/partman-auto/partman-auto_72.dsc partman-auto_72.tar.gz to pool/main/p/partman-auto/partman-auto_72.tar.gz partman-auto_72_amd64.udeb to pool/main/p/partman-auto/partman-auto_72_amd64.udeb Override entries for your package: partman-auto_72.dsc - source debian-installer partman-auto_72_amd64.udeb - standard debian-installer Announcing to [EMAIL PROTECTED] Closing bugs: 425829 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-lvm_56_amd64.changes ACCEPTED
Accepted: partman-lvm_56.dsc to pool/main/p/partman-lvm/partman-lvm_56.dsc partman-lvm_56.tar.gz to pool/main/p/partman-lvm/partman-lvm_56.tar.gz partman-lvm_56_all.udeb to pool/main/p/partman-lvm/partman-lvm_56_all.udeb Override entries for your package: partman-lvm_56.dsc - source debian-installer partman-lvm_56_all.udeb - standard debian-installer Announcing to [EMAIL PROTECTED] Closing bugs: 451970 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-partitioning_53_amd64.changes
partman-partitioning_53_amd64.changes uploaded successfully to localhost along with the files: partman-partitioning_53.dsc partman-partitioning_53.tar.gz partman-partitioning_53_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-efi_14_amd64.changes
partman-efi_14_amd64.changes uploaded successfully to localhost along with the files: partman-efi_14.dsc partman-efi_14.tar.gz partman-efi_14_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-lvm_56_amd64.changes
partman-lvm_56_amd64.changes uploaded successfully to localhost along with the files: partman-lvm_56.dsc partman-lvm_56.tar.gz partman-lvm_56_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-efi_14_amd64.changes ACCEPTED
Accepted: partman-efi_14.dsc to pool/main/p/partman-efi/partman-efi_14.dsc partman-efi_14.tar.gz to pool/main/p/partman-efi/partman-efi_14.tar.gz partman-efi_14_amd64.udeb to pool/main/p/partman-efi/partman-efi_14_amd64.udeb Override entries for your package: partman-efi_14.dsc - source debian-installer partman-efi_14_amd64.udeb - standard debian-installer Announcing to [EMAIL PROTECTED] Closing bugs: 439660 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-auto-raid_7_amd64.changes ACCEPTED
Accepted: partman-auto-raid_7.dsc to pool/main/p/partman-auto-raid/partman-auto-raid_7.dsc partman-auto-raid_7.tar.gz to pool/main/p/partman-auto-raid/partman-auto-raid_7.tar.gz partman-auto-raid_7_all.udeb to pool/main/p/partman-auto-raid/partman-auto-raid_7_all.udeb Override entries for your package: partman-auto-raid_7.dsc - source debian-installer partman-auto-raid_7_all.udeb - standard debian-installer Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-partitioning_53_amd64.changes ACCEPTED
Accepted: partman-partitioning_53.dsc to pool/main/p/partman-partitioning/partman-partitioning_53.dsc partman-partitioning_53.tar.gz to pool/main/p/partman-partitioning/partman-partitioning_53.tar.gz partman-partitioning_53_amd64.udeb to pool/main/p/partman-partitioning/partman-partitioning_53_amd64.udeb Override entries for your package: partman-partitioning_53.dsc - source debian-installer partman-partitioning_53_amd64.udeb - optional debian-installer Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-base_113_amd64.changes ACCEPTED
Accepted: partman-base_113.dsc to pool/main/p/partman-base/partman-base_113.dsc partman-base_113.tar.gz to pool/main/p/partman-base/partman-base_113.tar.gz partman-base_113_amd64.udeb to pool/main/p/partman-base/partman-base_113_amd64.udeb partman-utils_113_amd64.udeb to pool/main/p/partman-base/partman-utils_113_amd64.udeb Override entries for your package: partman-base_113.dsc - source debian-installer partman-base_113_amd64.udeb - standard debian-installer partman-utils_113_amd64.udeb - extra debian-installer Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of partman-md_38_amd64.changes
partman-md_38_amd64.changes uploaded successfully to localhost along with the files: partman-md_38.dsc partman-md_38.tar.gz partman-md_38_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454493: Display PCI slot for nics, if available
On Wednesday 05 December 2007, dann frazier wrote: > This patch to hw-detect adds slot information, if available, to the > network device name. Its not uncommon for HP (or our customers) to > have systems with many network devices, and knowing the physical slot > number of an adapter makes configuration that much easier. I have several reservations against this patch: - to have it work for all installation methods you'd need to to include this acpi module (and others?) in initrds, which is something we don't do lightly [1] - the "slot" indication is not translatable in the current patch - the descriptions are already quite long and this will truncate some of them even more than they already are - I'm not sure that as a user it would be clear to me what exactly a Slot is in this context - looking at your screenshot it does not seem to add all that much identification as there are still several NICs with identical slots - it seems only a partial solution as not all NICs will be get a slot identifier - I'm not sure that it makes sense to print slot if it's the only identification We've had other requests to provide additional identification of NICs (see #450605 and merged BRs) and so far we (or at least I) have been thinking of some way to display the MAC address, possibly by allowing to switch between display of the current descriptions and MAC address. For me at least making the slot identification translatable (which is not that hard) would be a blocker for acceptance of this patch. On Thursday 06 December 2007, dann frazier wrote: > I believe that currently the only way to know if a machine supports > acpiphp is to load it. This seems to match up pretty well with my > observations of other acpi drivers. acpid seems to take ownership of > loading acpi modules like battery, fan, thermal, etc - it simply > modprobes them and lets the driver do the discovery. Maybe it should > also be loading acpiphp? Perhaps. > > Does d-i do anything wrt loading acpi drivers today (other than > installing acpid into the target)? For x86 some acpi modules are available during install and are loaded (thermal, fan and processor). For powerpc some drivers are loaded for some systems to avoid the fans running wild. See in rootskel/src/lib/debian-installer-startup.d: S05acpi-linux-x86, S05fancontrol-linux-powerpc Cheers, FJP [1] As a porter you have of course quite considerable freedom to decide what to include in initrds for "your" arches. signature.asc Description: This is a digitally signed message part.
Bug#454493: Display PCI slot for nics, if available
On Wed, Dec 05, 2007 at 05:03:41PM -0200, Otavio Salvador wrote: > dann frazier <[EMAIL PROTECTED]> writes: > > > Currently this patch only attempts to load the acpiphp driver - it > > should probably try and load others as well (e.g. pciehp & shchp, and > > the future possible pci_slot). > > Why acpihp isn't loaded by udev automaticaly? I'm probably not the best person to answer that question, but I can give you some handwavy guesswork :) I'm guessing that you're asking this because you've seen other pci hotplug drivers get loaded by udev. I've noticed this too - shpchp loads on some of my boxes, so I looked to see why. Turns out that shpchp registers itself as a driver for pci devices that are in the pci bridge class, so this mapping is available to udev in modules.pcimap. acpiphp doesn't register itself for any pci devices - in fact, the machine I test on doesn't show any pci bridges devices in lspci, so I'm assuming they're transparent to udev as well. The devices on this bridge work just fine, they are just not hotpluggable until the acpiphp module is loaded. I wondered if this was always the case with ACPI-described bridges, so I asked Matthew Wilcox: willy: is it the case that pci bridges described by ACPI never (or not always) appear as pci devices themselves? dannf: No correlation. If they're PCI-PCI bridges, they will show up in the PCI namespace, but there's no way to tell whether or not they support acpiphp I believe that currently the only way to know if a machine supports acpiphp is to load it. This seems to match up pretty well with my observations of other acpi drivers. acpid seems to take ownership of loading acpi modules like battery, fan, thermal, etc - it simply modprobes them and lets the driver do the discovery. Maybe it should also be loading acpiphp? Perhaps. Does d-i do anything wrt loading acpi drivers today (other than installing acpid into the target)? -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-md_38_amd64.changes ACCEPTED
Accepted: partman-md_38.dsc to pool/main/p/partman-md/partman-md_38.dsc partman-md_38.tar.gz to pool/main/p/partman-md/partman-md_38.tar.gz partman-md_38_all.udeb to pool/main/p/partman-md/partman-md_38_all.udeb Override entries for your package: partman-md_38.dsc - source debian-installer partman-md_38_all.udeb - standard debian-installer Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-basicmethods_36_amd64.changes ACCEPTED
Accepted: partman-basicmethods_36.dsc to pool/main/p/partman-basicmethods/partman-basicmethods_36.dsc partman-basicmethods_36.tar.gz to pool/main/p/partman-basicmethods/partman-basicmethods_36.tar.gz partman-basicmethods_36_all.udeb to pool/main/p/partman-basicmethods/partman-basicmethods_36_all.udeb Override entries for your package: partman-basicmethods_36.dsc - source debian-installer partman-basicmethods_36_all.udeb - optional debian-installer Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
partman-dmraid_2_amd64.changes ACCEPTED
Accepted: partman-dmraid_2.dsc to pool/main/p/partman-dmraid/partman-dmraid_2.dsc partman-dmraid_2.tar.gz to pool/main/p/partman-dmraid/partman-dmraid_2.tar.gz partman-dmraid_2_all.udeb to pool/main/p/partman-dmraid/partman-dmraid_2_all.udeb Override entries for your package: partman-dmraid_2.dsc - source debian-installer partman-dmraid_2_all.udeb - optional debian-installer Announcing to [EMAIL PROTECTED] Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#425829: marked as done (partman-auto: Broken usage of dmsetup)
Your message dated Wed, 05 Dec 2007 12:32:02 + with message-id <[EMAIL PROTECTED]> and subject line Bug#425829: fixed in partman-auto 72 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: partman-auto Version: 69 Severity: important With the introduction of the code to deallocate LVM volumes, the script auto-shared.sh in partman-auto now includes explicit calls to dmsetup without depending on it, which means that these commands currently fail. I'm not sure if a dependency on dmsetup should be added to partman-auto or that the script should check if it is available or not. After all, dmsetup is not strictly required for partman-auto itself, but only for lvm and crypto setups. pgpZbt2ZcKg2x.pgp Description: PGP signature --- End Message --- --- Begin Message --- Source: partman-auto Source-Version: 72 We believe that the bug you reported is fixed in the latest version of partman-auto, which is due to be installed in the Debian FTP archive: partman-auto_72.dsc to pool/main/p/partman-auto/partman-auto_72.dsc partman-auto_72.tar.gz to pool/main/p/partman-auto/partman-auto_72.tar.gz partman-auto_72_amd64.udeb to pool/main/p/partman-auto/partman-auto_72_amd64.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Frans Pop <[EMAIL PROTECTED]> (supplier of updated partman-auto package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 05 Dec 2007 13:17:01 +0100 Source: partman-auto Binary: partman-auto Architecture: source amd64 Version: 72 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Frans Pop <[EMAIL PROTECTED]> Description: partman-auto - Automatically partition storage devices (partman) (udeb) Closes: 425829 Changes: partman-auto (72) unstable; urgency=low . * Revert support for erasing encrypted LVM volumes introduced in (69). There are too many problems with it and starting fresh seems better than stacking change on change to fix it. Closes: #425829. * lvm-wipe-disk(): needs device-mapper support while removing devices. * lvm-wipe-disk(): fix restart logic. . [ Updated translations ] * Dzongkha (dz.po) by Jurmey Rabgay * French (fr.po) by Christian Perrier * Malayalam (ml.po) by Praveen|പ്രവീണ് A|എ * Polish (pl.po) by Bartosz Fenski * Slovak (sk.po) by Ivan Masár Files: 4fa9190e993c3cd3ef6c366476b697bd 698 debian-installer standard partman-auto_72.dsc 1bb5c980b5af9350d8a39bab30dcac1d 107237 debian-installer standard partman-auto_72.tar.gz cbd74b5a095f21c9b5c187f49ab909d5 77308 debian-installer standard partman-auto_72_amd64.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHVpisgm/Kwh6ICoQRAtKeAJ9+BUsH0usE9v2nBm4s1mld+FUoPQCg01FD sBb7fiagvA7tsw+QnUMb5Ps= =B49g -END PGP SIGNATURE- --- End Message ---
Bug#451970: marked as done (partman-lvm: allow to 'reuse' logical volumes)
Your message dated Wed, 05 Dec 2007 12:32:08 + with message-id <[EMAIL PROTECTED]> and subject line Bug#451970: fixed in partman-lvm 56 has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: debian-installer Version: 20070308 Severity: normal I had first installed i386 system with encrypted /home and swap. Then I decided to install also amd64 build -- reusing both encrypted partitions. Although I checked out smth like 'delete data' in the encryption setup menu, which I treated as 'preserve/don"t touch', it did reinitialize them and I had to recreate filesystems on top. So I think 'Delete data' must be named 'Wipe out data', and another item in the menu should be 'Reuse' or 'Keep existing encrypted volume' Thanks in advance! -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (990, 'unstable'), (900, 'testing'), (300, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.22-2-686 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/bash --- End Message --- --- Begin Message --- Source: partman-lvm Source-Version: 56 We believe that the bug you reported is fixed in the latest version of partman-lvm, which is due to be installed in the Debian FTP archive: partman-lvm_56.dsc to pool/main/p/partman-lvm/partman-lvm_56.dsc partman-lvm_56.tar.gz to pool/main/p/partman-lvm/partman-lvm_56.tar.gz partman-lvm_56_all.udeb to pool/main/p/partman-lvm/partman-lvm_56_all.udeb A summary of the changes between this version and the previous one is attached. Thank you for reporting the bug, which will now be closed. If you have further comments please address them to [EMAIL PROTECTED], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Frans Pop <[EMAIL PROTECTED]> (supplier of updated partman-lvm package) (This message was generated automatically at their request; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Format: 1.7 Date: Wed, 05 Dec 2007 13:21:09 +0100 Source: partman-lvm Binary: partman-lvm Architecture: source all Version: 56 Distribution: unstable Urgency: low Maintainer: Debian Install System Team Changed-By: Frans Pop <[EMAIL PROTECTED]> Description: partman-lvm - Adds support for LVM to partman (udeb) Closes: 451970 Changes: partman-lvm (56) unstable; urgency=low . [ Frans Pop ] * Only check partition flags if we've not already determined the device is used for LVM. * Don't create label and partition for LVM volumes if they already have a partition. Needed to allow to use existing file systems on LVM volumes but additional changes will be needed for that to be properly supported. Closes: #451970. . [ Max Vozeler ] * Replace code to commit partman changes to disk with call to commit_changes from partman-base (>= 113) and version the dependency accordingly. . [ Updated translations ] * Belarusian (be.po) by Hleb Rubanau * Dzongkha (dz.po) by Jurmey Rabgay * Esperanto (eo.po) by Serge Leblanc * Korean (ko.po) by Sunjae Park * Malayalam (ml.po) by Praveen|പ്രവീണ് A|എ * Norwegian Bokmål (nb.po) by Hans Fredrik Nordhaug * Polish (pl.po) by Bartosz Fenski * Romanian (ro.po) by Eddy Petrișor * Slovak (sk.po) by Ivan Masár Files: 970721fa2b7c0d8a078aa48e0c55a1c8 694 debian-installer standard partman-lvm_56.dsc 8c397137fca1ae6db0f3dd918874e76e 179977 debian-installer standard partman-lvm_56.tar.gz 3016c391d50af2e2dac64631900832e6 184560 debian-installer standard partman-lvm_56_all.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHVpitgm/Kwh6ICoQRAq32AKCXdkkC6VHS6pMI2o5s7uEOfD1PhwCgsi1a GjWXm0qTaWNusoK/g1t4jBU= =hg8F -END PGP SIGNATURE- --- End Message ---
Bug#454493: Display PCI slot for nics, if available
dann frazier <[EMAIL PROTECTED]> writes: <...> > I believe that currently the only way to know if a machine supports > acpiphp is to load it. This seems to match up pretty well with my > observations of other acpi drivers. acpid seems to take ownership of > loading acpi modules like battery, fan, thermal, etc - it simply > modprobes them and lets the driver do the discovery. Maybe it should > also be loading acpiphp? Perhaps. Maybe we might then think about something general for this type of problem. > Does d-i do anything wrt loading acpi drivers today (other than > installing acpid into the target)? Yes. thermal and fan modules, IIRC but I'd also want to get batteries detected so laptop-detect could work better. I'm thinking that we might consider to have an acpi-support-udeb package for that kind of thing be centralized on one cannonical place. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
