Bug#420894: debian-installer-manual: [appendix/preseed] apt-setup/local0/repository string does not contain 'deb'
Package: debian-installer-manual Severity: normal Hello, The pressed appendix mention : #Additional repositories, local[0-9] available #d-i apt-setup/local0/repository string \ # deb http://local.server/debian stable main This adds a 'deb deb http://local.server/debian stable main' in the sources.list This just need to remove the 'deb' in each translation. Rémi Demarthe. -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-4-686 Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Bug#420894: debian-installer-manual: [appendix/preseed] apt-setup/local0/repository string does not contain 'deb'
reassign 420894 installation-guide tags 420894 + pending thanks On Wednesday 25 April 2007 18:07, Rémi Demarthe wrote: #Additional repositories, local[0-9] available #d-i apt-setup/local0/repository string \ # deb http://local.server/debian stable main This adds a 'deb deb http://local.server/debian stable main' in the sources.list This just need to remove the 'deb' in each translation. Fixed in SVN. Thanks.
Processed: Re: Bug#420894: debian-installer-manual: [appendix/preseed] apt-setup/local0/repository string does not contain 'deb'
Processing commands for [EMAIL PROTECTED]: reassign 420894 installation-guide Bug#420894: debian-installer-manual: [appendix/preseed] apt-setup/local0/repository string does not contain 'deb' Bug reassigned from package `debian-installer-manual' to `installation-guide'. tags 420894 + pending Bug#420894: debian-installer-manual: [appendix/preseed] apt-setup/local0/repository string does not contain 'deb' There were no tags set. Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of flash-kernel_1.2_arm.changes
flash-kernel_1.2_arm.changes uploaded successfully to localhost along with the files: flash-kernel_1.2.dsc flash-kernel_1.2.tar.gz flash-kernel_1.2_arm.deb flash-kernel-installer_1.2_arm.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
flash-kernel_1.2_arm.changes ACCEPTED
Accepted: flash-kernel-installer_1.2_arm.udeb to pool/main/f/flash-kernel/flash-kernel-installer_1.2_arm.udeb flash-kernel_1.2.dsc to pool/main/f/flash-kernel/flash-kernel_1.2.dsc flash-kernel_1.2.tar.gz to pool/main/f/flash-kernel/flash-kernel_1.2.tar.gz flash-kernel_1.2_arm.deb to pool/main/f/flash-kernel/flash-kernel_1.2_arm.deb Override entries for your package: flash-kernel-installer_1.2_arm.udeb - standard debian-installer flash-kernel_1.2.dsc - source utils flash-kernel_1.2_arm.deb - optional utils Announcing to [EMAIL PROTECTED] Closing bugs: 403017 411551 413373 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413373: marked as done (Patch for flash-kernel to improve speed)
Your message dated Wed, 25 Apr 2007 12:02:02 + with message-id [EMAIL PROTECTED] and subject line Bug#413373: fixed in flash-kernel 1.2 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) ---BeginMessage--- Package: flash-kernel Version: 1.1 Tags: Patch The attached patch reduces the running time of flash-kernel on the NSLU2 by almost 30 seconds. The change should also apply to the Thecus N2100, but I am not able to test it. # /usr/bin/time -f elapsed %e system %S user %U flash-kernel Flashing kernel: done. Flashing initramfs: done. elapsed 122.09 system 2.93 user 0.72 # /usr/bin/time -f elapsed %e system %S user %U ./flash-kernel Flashing kernel: done. Flashing initramfs: done. elapsed 93.85 system 2.95 user 0.78 Gordon -- Gordon Farquharson --- flash-kernel.orig 2007-03-03 11:42:45.0 -0700 +++ flash-kernel 2007-03-03 13:30:35.0 -0700 @@ -131,10 +131,9 @@ size=$(grep Ramdisk /proc/mtd | cut -d -f 2) size=$(printf %d 0x$size) isize=$(wc -c $ifile | awk '{print $1}') - cat $ifile $tmp pad=$(expr $size - $isize - 16) if [ $pad -gt 0 ]; then - dd if=/dev/zero bs=$pad count=1 2/dev/null $tmp + dd if=$ifile of=$tmp ibs=4M conv=sync 2/dev/null fi ( sercomm_header $isize ---End Message--- ---BeginMessage--- Source: flash-kernel Source-Version: 1.2 We believe that the bug you reported is fixed in the latest version of flash-kernel, which is due to be installed in the Debian FTP archive: flash-kernel-installer_1.2_arm.udeb to pool/main/f/flash-kernel/flash-kernel-installer_1.2_arm.udeb flash-kernel_1.2.dsc to pool/main/f/flash-kernel/flash-kernel_1.2.dsc flash-kernel_1.2.tar.gz to pool/main/f/flash-kernel/flash-kernel_1.2.tar.gz flash-kernel_1.2_arm.deb to pool/main/f/flash-kernel/flash-kernel_1.2_arm.deb 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. Martin Michlmayr [EMAIL PROTECTED] (supplier of updated flash-kernel 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, 25 Apr 2007 13:51:12 +0200 Source: flash-kernel Binary: flash-kernel-installer flash-kernel Architecture: source arm Version: 1.2 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Martin Michlmayr [EMAIL PROTECTED] Description: flash-kernel - utility to write kernel and initramfs to MTD flash flash-kernel-installer - Configure flash to boot the system (udeb) Closes: 403017 411551 413373 Changes: flash-kernel (1.2) unstable; urgency=low . [ Martin Michlmayr ] * Make the parsing code more robust so searching for foo won't match foo2. Thanks, Rod Whitby. * Print an error when the subarchitecture of the kernel doesn't match that of the device. Closes: #411551. . [ Rod Whitby ] * Add support for Iomega NAS 100d. Closes: #403017. . [ Gordon Farquharson ] * Reduce the running time of flash-kernel on the NSLU2 by almost 30 seconds. Closes: #413373. . [ Updated translations ] * Basque (eu.po) by Piarres Beobide Files: 62a85b3757e15b45ba8143a427f844bf 698 utils optional flash-kernel_1.2.dsc 64d9c5edbaebf6a3bfafe2f2a5e1b61e 23988 utils optional flash-kernel_1.2.tar.gz 774270cb72ae7de10739b7c2e24f7f34 7284 utils optional flash-kernel_1.2_arm.deb 2f1a6ffc109eb84b3ab091c1b573e41e 7036 debian-installer standard flash-kernel-installer_1.2_arm.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGL0FiKb5dImj9VJ8RAmPQAKCYDFOIUQ2IpD4Voe823QHO+WJKOQCfWG8N pSIBHHTlCMSgTLebh90WlzE= =bTla -END PGP SIGNATURE- ---End Message---
Bug#403017: marked as done (Patch to flash-kernel for nas100d support)
Your message dated Wed, 25 Apr 2007 12:02:02 + with message-id [EMAIL PROTECTED] and subject line Bug#403017: fixed in flash-kernel 1.2 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) ---BeginMessage--- Package: flash-kernel Version: 0.9 Tags: patch Could you please apply the attached patch to flash-kernel? It tightens up the grep match patterns (I got stung because I had both filesystem and filesystem2 partitions), and adds support for flashing the Iomega NAS 100d. With this patch, and the kernel patches I sent Martin previously, Debian kernel 2.6.19 runs nicely on the NAS100d. Next, I'll be looking at what else needs to be done to support it in the installer. This is not etch-critical, but would save me having to hand-edit this file each time I do a test debian-installer installation. Thanks, -- Rod Index: flash-kernel === --- flash-kernel(revision 43316) +++ flash-kernel(working copy) @@ -19,7 +19,7 @@ } mtdblock() { - grep $1 /proc/mtd | cut -d: -f 1 | sed 's/mtd/\/dev\/mtdblock/' + grep \$1\ /proc/mtd | cut -d: -f 1 | sed 's/mtd/\/dev\/mtdblock/' } # See http://www.nslu2-linux.org/wiki/Info/BootFlash -- the NSLU2 uses a @@ -128,7 +128,7 @@ ) $mtdkernel || error failed. echo done. 2 printf Flashing initramfs: 2 - size=$(grep Ramdisk /proc/mtd | cut -d -f 2) + size=$(grep \Ramdisk\ /proc/mtd | cut -d -f 2) size=$(printf %d 0x$size) isize=$(wc -c $ifile | awk '{print $1}') cat $ifile $tmp @@ -143,6 +143,30 @@ ) $mtdramdisk || error failed. echo done. 2 ;; + Iomega NAS 100d) + check_mtd + mtdramdisk=$(mtdblock filesystem) + if [ -z $mtdramdisk ]; then + error Cannot find mtd partition 'filesystem' + fi + mtdkernel=$(mtdblock kernel) + if [ -z $mtdkernel ]; then + error Cannot find mtd partition 'kernel' + fi + printf Flashing kernel: 2 + cat $kfile $mtdkernel || error failed. + echo done. 2 + printf Flashing initramfs: 2 + size=$(grep \filesystem\ /proc/mtd | cut -d -f 2) + size=$(printf %d 0x$size) + isize=$(wc -c $ifile | awk '{print $1}') + pad=$(expr $size - $isize) + ( + cat $ifile + dd if=/dev/zero bs=$pad count=1 2/dev/null + ) $mtdramdisk || error failed. + echo done. 2 + ;; Thecus N2100) check_mtd mtdramdisk=$(mtdblock ramdisk) @@ -160,7 +184,7 @@ ) $mtdkernel || error failed. echo done. 2 printf Flashing initramfs... 2 - size=$(grep ramdisk /proc/mtd | cut -d -f 2) + size=$(grep \ramdisk\ /proc/mtd | cut -d -f 2) size=$(printf %d 0x$size) isize=$(wc -c $ifile | awk '{print $1}') pad=$(expr $size - $isize) ---End Message--- ---BeginMessage--- Source: flash-kernel Source-Version: 1.2 We believe that the bug you reported is fixed in the latest version of flash-kernel, which is due to be installed in the Debian FTP archive: flash-kernel-installer_1.2_arm.udeb to pool/main/f/flash-kernel/flash-kernel-installer_1.2_arm.udeb flash-kernel_1.2.dsc to pool/main/f/flash-kernel/flash-kernel_1.2.dsc flash-kernel_1.2.tar.gz to pool/main/f/flash-kernel/flash-kernel_1.2.tar.gz flash-kernel_1.2_arm.deb to pool/main/f/flash-kernel/flash-kernel_1.2_arm.deb 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. Martin Michlmayr [EMAIL PROTECTED] (supplier of updated flash-kernel 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, 25 Apr 2007 13:51:12 +0200 Source: flash-kernel Binary:
Bug#411551: marked as done (avoid flashing kernel for wrong subarch)
Your message dated Wed, 25 Apr 2007 12:02:02 + with message-id [EMAIL PROTECTED] and subject line Bug#411551: fixed in flash-kernel 1.2 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) ---BeginMessage--- Package: flash-kernel Severity: wishlist To avoid misflashes with a kernel for some other subarch, it should check the subarch of the kernel and not flash if it doesn't match the machine subarch. -- see shy jo signature.asc Description: Digital signature ---End Message--- ---BeginMessage--- Source: flash-kernel Source-Version: 1.2 We believe that the bug you reported is fixed in the latest version of flash-kernel, which is due to be installed in the Debian FTP archive: flash-kernel-installer_1.2_arm.udeb to pool/main/f/flash-kernel/flash-kernel-installer_1.2_arm.udeb flash-kernel_1.2.dsc to pool/main/f/flash-kernel/flash-kernel_1.2.dsc flash-kernel_1.2.tar.gz to pool/main/f/flash-kernel/flash-kernel_1.2.tar.gz flash-kernel_1.2_arm.deb to pool/main/f/flash-kernel/flash-kernel_1.2_arm.deb 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. Martin Michlmayr [EMAIL PROTECTED] (supplier of updated flash-kernel 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, 25 Apr 2007 13:51:12 +0200 Source: flash-kernel Binary: flash-kernel-installer flash-kernel Architecture: source arm Version: 1.2 Distribution: unstable Urgency: low Maintainer: Debian Install System Team debian-boot@lists.debian.org Changed-By: Martin Michlmayr [EMAIL PROTECTED] Description: flash-kernel - utility to write kernel and initramfs to MTD flash flash-kernel-installer - Configure flash to boot the system (udeb) Closes: 403017 411551 413373 Changes: flash-kernel (1.2) unstable; urgency=low . [ Martin Michlmayr ] * Make the parsing code more robust so searching for foo won't match foo2. Thanks, Rod Whitby. * Print an error when the subarchitecture of the kernel doesn't match that of the device. Closes: #411551. . [ Rod Whitby ] * Add support for Iomega NAS 100d. Closes: #403017. . [ Gordon Farquharson ] * Reduce the running time of flash-kernel on the NSLU2 by almost 30 seconds. Closes: #413373. . [ Updated translations ] * Basque (eu.po) by Piarres Beobide Files: 62a85b3757e15b45ba8143a427f844bf 698 utils optional flash-kernel_1.2.dsc 64d9c5edbaebf6a3bfafe2f2a5e1b61e 23988 utils optional flash-kernel_1.2.tar.gz 774270cb72ae7de10739b7c2e24f7f34 7284 utils optional flash-kernel_1.2_arm.deb 2f1a6ffc109eb84b3ab091c1b573e41e 7036 debian-installer standard flash-kernel-installer_1.2_arm.udeb Package-Type: udeb -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFGL0FiKb5dImj9VJ8RAmPQAKCYDFOIUQ2IpD4Voe823QHO+WJKOQCfWG8N pSIBHHTlCMSgTLebh90WlzE= =bTla -END PGP SIGNATURE- ---End Message---
Processed: Re: Bug#410065: installation-report: d-i rc1, NSLU2: minor network-console and boot issues
Processing commands for [EMAIL PROTECTED]: reassign 410065 installation-guide-arm Bug#410065: installation-report: d-i rc1, NSLU2: minor network-console and boot issues Bug reassigned from package `installation-reports' to `installation-guide-arm'. retitle 410065 Describe NSLU2 installation in installation guide Bug#410065: installation-report: d-i rc1, NSLU2: minor network-console and boot issues Changed Bug title to Describe NSLU2 installation in installation guide from installation-report: d-i rc1, NSLU2: minor network-console and boot issues. severity 410065 wishlist Bug#410065: Describe NSLU2 installation in installation guide Severity set to `wishlist' from `normal' owner 410065 ! Bug#410065: Describe NSLU2 installation in installation guide Owner recorded as Martin Michlmayr [EMAIL PROTECTED]. -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Introduction
* Frans Pop [EMAIL PROTECTED] [2007-02-26 17:48]: From where would I run anna-install? Is there some infrastructure or would I need to add a d-i startup script? Somewhere in rootskel, or else in hw-detect. The last is probably more logical. Background: installations on NSLU2 run in lowmem level2, so some udebs need to be manually selected by users. In order to install them automatically, the idea was to run anna-install from a script in rootskel or hw-detect. I just tested this and it doesn't work. I logged in and ran anna-install for each udeb I wanted, and then continued the installation. However, these udebs were not installed by the time I came to partman (which meant that partman didn't found my disk because the SCSI/USB modules were not installed). -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Proposed release goal: Switch to GRUB2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, We, the GRUB team, want to swtich to GRUB2 due many reasons, basicaly: - easier to maintain; - better codebase; - multi-arch support; - active upstream; Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. Thoughts? - -- 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. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iD8DBQFGL1DELqiZQEml+FURAjBlAJkB5uboOSV1mcD0C0WRBQq9mwNC5ACfbqzv 8gUD2xUCb7ffuPYDhFP70LQ= =+J7O -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 09:59:51AM -0300, Otavio Salvador wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, We, the GRUB team, want to swtich to GRUB2 due many reasons, basicaly: - easier to maintain; - better codebase; - multi-arch support; - active upstream; Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. Thoughts? I wonder if we will also move from yaboot-installer to grub2-installer on powerpc, and if you have given any thought to that migration path ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
Sven Luther [EMAIL PROTECTED] writes: I wonder if we will also move from yaboot-installer to grub2-installer on powerpc, and if you have given any thought to that migration path ? Our main goal is to switch i386 and amd64 first. We intend to use GRUB2 as much as possible also to reduce the duplication work maintaining too many boot-loaders but it's not our main goal right now to move it as default to other arches. Depending of how well it goes, we can try to revisit this and maybe move other arches too. Obviously it'll have the final word from the porting team who has the need knownledge to decide if it's worth or not to move for it. The migration from yaboot shouldn't be hard to handle since its configuration format can, probably, be converted as well. The migration path, as for i386 too, could be the installation of the package with a debconf note asking for the installation of the boot-loader using grub-installer and the removal of previous boot-loader. I wouldn't like to get my boot-loader replaced without any notice. -- 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]
Bug#415388: marked as done (installation-report: Debian on NSLU2 with RC2 with firmware)
Your message dated Wed, 25 Apr 2007 15:23:53 +0200 with message-id [EMAIL PROTECTED] and subject line should work 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) ---BeginMessage--- Package: installation-reports Version: 2.29 Severity: minor -- Package-specific info: Boot method: network Image version: http://www.slug-firmware.net debian-etch-rc2-20070308.zip Date: 20070313 Machine: NSLU2 Partitions: /dev/sda1 1 23100 185550749+ 8e Linux LVM /dev/sda2 23101 23586 3903795 82 Linux swap / Solaris /dev/sda3 * 23587 24321 5903887+ 83 Linux - is root 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: [ ] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [ ] Install base system:[O] Clock/timezone setup: [E] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: Due to low memory situation, the external USB disk was partitioned and the root partition created on a regular machine. Thus the partioning portion of the installer only needed to setup swap; the rest was not tested. LVM was setup post-install. The network install had to be done through a proxy service provided over a local link. This meant that clock update via NTP was not possible. Perhaps the network install should not assume that TIME can be setup via NTP. One difficulty with such installs is the lack of feedback from the machine while it is installing. Perhaps there could be the option of offering a splitvt-based monitoring of the install. Overall, I was pleased and suprised at the ease of installation given the limited resources this machine has. Great work! I am really please with this slug which is currently playing some music in the background! Thanks and regards, Kapil. -- 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 [EMAIL PROTECTED] == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=4.0 (installer build 20070308) X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == umame -a: Linux LKG80FE41 2.6.18-4-ixp4xx #1 Thu Feb 22 14:00:55 UTC 2007 armv5tel unknown lspci -nn: 00:01.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) lspci -nn: 00:01.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) lspci -nn: 00:01.2 USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0] (rev 04) lspci -vnn: 00:01.0 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) (prog-if 10) lspci -vnn: Subsystem: NEC Corporation USB [1033:0035] lspci -vnn: Flags: bus master, medium devsel, latency 8, IRQ 28 lspci -vnn: Memory at 4800 (32-bit, non-prefetchable) [size=4K] lspci -vnn: Capabilities: [40] Power Management version 2 lspci -vnn: lspci -vnn: 00:01.1 USB Controller [0c03]: NEC Corporation USB [1033:0035] (rev 43) (prog-if 10) lspci -vnn: Subsystem: NEC Corporation USB [1033:0035] lspci -vnn: Flags: bus master, medium devsel, latency 8, IRQ 27 lspci -vnn: Memory at 48001000 (32-bit, non-prefetchable) [size=4K] lspci -vnn: Capabilities: [40] Power Management version 2 lspci -vnn: lspci -vnn: 00:01.2 USB Controller [0c03]: NEC Corporation USB 2.0 [1033:00e0] (rev 04) (prog-if 20) lspci -vnn: Subsystem: NEC Corporation USB 2.0 [1033:00e0] lspci -vnn: Flags: bus master, medium devsel, latency 68, IRQ 26 lspci -vnn: Memory at 48002000 (32-bit, non-prefetchable) [size=256] lspci -vnn: Capabilities: [40] Power Management version 2 lspci -vnn: modulemap: 1033:0035 ohci_hcd modulemap: 1033:0035 ohci_hcd modulemap: 1033:00e0 ehci_hcd lsmod: Module Size Used by lsmod: reiserfs 269556 0 lsmod: ext3 137704 1 lsmod: jbd59368 1 ext3 lsmod: mbcache 9188 1 ext3 lsmod: vfat 13152 0 lsmod: fat53660 1 vfat lsmod: sd_mod
Re: Proposed release goal: Switch to GRUB2
Op 25-04-2007 om 10:18 schreef Otavio Salvador: Sven Luther [EMAIL PROTECTED] writes: I wonder if we will also move from yaboot-installer to grub2-installer on powerpc, and if you have given any thought to that migration path ? Our main goal is to switch i386 and amd64 first. My advice to make that switch (and switch back) more easy, is to implement a bootselector. Menu-item-number would the current confirm install grub, which is a 'boolean'. bootselector is 'multi select'. Cheers Geert Stappers submitter of http://bugs.debian.org/413263 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 09:59:51AM -0300, Otavio Salvador wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, We, the GRUB team, want to swtich to GRUB2 due many reasons, basicaly: - easier to maintain; - better codebase; - multi-arch support; - active upstream; Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). I would like to offer grub-legacy as an option (even in d-i) for the release. It's good to have a fallback in case it is needed. But of course, it's been in maintainance mode only for a while now, and adding new features to it is out of the question at this point (the same applies to upstream). The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. Also note that the user interface (grub-install + update-grub) is backwards compatible. The change could well remain unnoticed :-) After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. Let's see if we can try to prevent this from happening again. I think the key points are: - Fight wishlist requests. grub2 is feature-rich, and upstream welcomes new development. New features should be added and dealt with through upstream (unless they're debian-specific, of course). - Merge bugfixes in upstream, fast. Jason and I have commit access and good relation which them. I think that can help. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
Robert Millan [EMAIL PROTECTED] writes: Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). I would like to offer grub-legacy as an option (even in d-i) for the release. It's good to have a fallback in case it is needed. But of course, it's been in maintainance mode only for a while now, and adding new features to it is out of the question at this point (the same applies to upstream). If we keep it on expert mode only I don't have any problem with it. I think that, depending of raised issues we can opt by dropping it or not. -- 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]
Re: Proposed release goal: Switch to GRUB2
[EMAIL PROTECTED] (Geert Stappers) writes: Op 25-04-2007 om 10:18 schreef Otavio Salvador: Sven Luther [EMAIL PROTECTED] writes: I wonder if we will also move from yaboot-installer to grub2-installer on powerpc, and if you have given any thought to that migration path ? Our main goal is to switch i386 and amd64 first. My advice to make that switch (and switch back) more easy, is to implement a bootselector. Menu-item-number would the current confirm install grub, which is a 'boolean'. bootselector is 'multi select'. You mean for the both grub and grub2? Well, we want to reduce the grub usage and then this shouldn't looks to be the best way of doing it. -- 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]
Bug#420894: debian-installer-manual: [appendix/preseed] apt-setup/local0/repository string does not contain 'deb'
Op 25-04-2007 om 11:52 schreef Frans Pop: On Wednesday 25 April 2007 18:07, Rémi Demarthe wrote: This just need to remove the 'deb' in each translation. Fixed in SVN. Thanks. What about fixing it in the Etch SVN branch also? HtH GSt
Bug#420894: debian-installer-manual: [appendix/preseed] apt-setup/local0/repository string does not contain 'deb'
On Wednesday 25 April 2007 16:02, Geert Stappers wrote: What about fixing it in the Etch SVN branch also? Not needed. Trunk will be published for Etch. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#420950: i translated tamil tasksel package
tags 420950 pending thanks Quoting senthil kumar ([EMAIL PROTECTED]): package: tasksel version: 1.1 translate: tamil status: installed i download from translation underway and modified that package i install its working good ... i want to upload this file Commited. However, the translation still has 2 fuzzies. You maybe forgot to remove the markers? signature.asc Description: Digital signature
Processed: Re: Bug#420950: i translated tamil tasksel package
Processing commands for [EMAIL PROTECTED]: tags 420950 pending Bug#420950: i translated tamil tasksel package There were no tags set. Tags added: pending thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#413263: Proposed release goal: Switch to GRUB2
Op 25-04-2007 om 10:54 schreef Otavio Salvador: [EMAIL PROTECTED] (Geert Stappers) writes: My advice to make that switch (and switch back) more easy, is to implement a bootselector. bootloaderselector. You mean for the both grub and grub2? Well, we want to reduce the grub usage and then this shouldn't looks to be the best way of doing it. The bootloaderselector supports trancient for one bootloader to another. This is a part from DI-ROOT/installer/doc/devel/menu-item-numbers.txt | 7000 - 8000 Post-base-install | 7000 apt-setup | pkgsel | 7300 palo-installer (hppa) | grub-installer (i386) | yaboot-installer (powerpc/powermac_newworld, powerpc/chrp*) | quik-installer (powerpc/powermac_oldworld) | zipl-installer (s390) | arcboot-installer (mips) | delo-installer (mipsel) | silo-installer (sparc) | vmelilo-installer (m68k/vme*) | glantank-installer (arm/iop32x) | 7500 lilo-installer (i386) | 7600 elilo-installer (ia64, i386) | 7700 nobootloader (all) | 7800 finish-install With grub2 and bootloaderselector this will become | 7000 - 8000 Post-base-install | 7000 apt-setup | pkgsel + 7200 bootloaderselector (all) . 7500 palo-installer (hppa) | grub-installer (i386) + grub2-installer (i386,amd64,powerpc,...) | yaboot-installer (powerpc/powermac_newworld, powerpc/chrp*) | quik-installer (powerpc/powermac_oldworld) | zipl-installer (s390) | arcboot-installer (mips) | delo-installer (mipsel) | silo-installer (sparc) | vmelilo-installer (m68k/vme*) | glantank-installer (arm/iop32x) . lilo-installer (i386) . elilo-installer (ia64, i386) . nobootloader (all) | 7800 finish-install So all installers at the same menu-item-number. The one selected by bootloaderselector will be installed. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 10:52:50AM -0300, Otavio Salvador wrote: Robert Millan [EMAIL PROTECTED] writes: Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). I would like to offer grub-legacy as an option (even in d-i) for the release. It's good to have a fallback in case it is needed. But of course, it's been in maintainance mode only for a while now, and adding new features to it is out of the question at this point (the same applies to upstream). If we keep it on expert mode only I don't have any problem with it. I think that, depending of raised issues we can opt by dropping it or not. We should probably do the transition in installed testing/sid systems and decide upon the results what do we do for d-i. popcon can provide useful info if we do this. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of debian-installer-utils_1.48_amd64.changes
debian-installer-utils_1.48_amd64.changes uploaded successfully to localhost along with the files: debian-installer-utils_1.48.dsc debian-installer-utils_1.48.tar.gz di-utils-shell_1.48_all.udeb di-utils-reboot_1.48_all.udeb di-utils-exit-installer_1.48_all.udeb di-utils-terminfo_1.48_all.udeb di-utils_1.48_amd64.udeb di-utils-mapdevfs_1.48_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
debian-installer-utils_1.48_amd64.changes ACCEPTED
Accepted: debian-installer-utils_1.48.dsc to pool/main/d/debian-installer-utils/debian-installer-utils_1.48.dsc debian-installer-utils_1.48.tar.gz to pool/main/d/debian-installer-utils/debian-installer-utils_1.48.tar.gz di-utils-exit-installer_1.48_all.udeb to pool/main/d/debian-installer-utils/di-utils-exit-installer_1.48_all.udeb di-utils-mapdevfs_1.48_amd64.udeb to pool/main/d/debian-installer-utils/di-utils-mapdevfs_1.48_amd64.udeb di-utils-reboot_1.48_all.udeb to pool/main/d/debian-installer-utils/di-utils-reboot_1.48_all.udeb di-utils-shell_1.48_all.udeb to pool/main/d/debian-installer-utils/di-utils-shell_1.48_all.udeb di-utils-terminfo_1.48_all.udeb to pool/main/d/debian-installer-utils/di-utils-terminfo_1.48_all.udeb di-utils_1.48_amd64.udeb to pool/main/d/debian-installer-utils/di-utils_1.48_amd64.udeb Override entries for your package: debian-installer-utils_1.48.dsc - source debian-installer di-utils-exit-installer_1.48_all.udeb - extra debian-installer di-utils-mapdevfs_1.48_amd64.udeb - standard debian-installer di-utils-reboot_1.48_all.udeb - standard debian-installer di-utils-shell_1.48_all.udeb - standard debian-installer di-utils-terminfo_1.48_all.udeb - standard debian-installer di-utils_1.48_amd64.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]
Re: Proposed release goal: Switch to GRUB2
On Wednesday 25 April 2007 14:59, Otavio Salvador wrote: We, the GRUB team, want to swtich to GRUB2 due many reasons, basicaly: - better codebase; Is grub2 fundamentally different from grub, or is it basically based on the current grub but just developed further? - multi-arch support; Do you really mean multi-arch or just supports more architectures? Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). How well has the new grub been tested so far? Are there any use cases that grub2 is not known to support that grub does support? Have all the regular installs already been checked (e.g. root on raid1)? Has e.g. support for Xen been checked? Has grub2 been checked for obvious past issues we've had in grub (like /dev/cciss/c0d0 support)? Has been checked that grub2 scripts don't write to stdout? Does grub2 solve any of the issues we currently have with grub? - xfs support - lvm support - wrong detection of correct boot device in BIOS It would be really nice to have a wiki page comparable to the one for the initrd generator change [1] that gives an overview of such issues. The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. Does the conversion program support all possible features in a current grub menu.lst or are there areas where this is uncertain? How widely has the conversion script been tested? After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. If you really mean to deprecate grub in favor of grub2, then you should probably rename grub2 to grub at some point before the release of Lenny. Cheers, FJP [1] http://wiki.debian.org/InitrdReplacementOptions pgpxNk5vrs6OV.pgp Description: PGP signature
Re: Proposed release goal: Switch to GRUB2
Frans Pop [EMAIL PROTECTED] writes: On Wednesday 25 April 2007 14:59, Otavio Salvador wrote: We, the GRUB team, want to swtich to GRUB2 due many reasons, basicaly: - better codebase; Is grub2 fundamentally different from grub, or is it basically based on the current grub but just developed further? - multi-arch support; A complete rewrite code. Do you really mean multi-arch or just supports more architectures? Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). How well has the new grub been tested so far? It has some regular users and they hadn't complained about issue since some time. We're hopping to get a new snapshot in next week or so. Are there any use cases that grub2 is not known to support that grub does support? Not that I'm aware of but probably has. Have all the regular installs already been checked (e.g. root on raid1)? I hadn't check raid1 myself. Has e.g. support for Xen been checked? It works. Has grub2 been checked for obvious past issues we've had in grub (like /dev/cciss/c0d0 support)? It should support. Is difficult to test it without hardware access. Has been checked that grub2 scripts don't write to stdout? Yes. Does grub2 solve any of the issues we currently have with grub? - xfs support Looks like. - lvm support I hadn't check - wrong detection of correct boot device in BIOS I hadn't check It would be really nice to have a wiki page comparable to the one for the initrd generator change [1] that gives an overview of such issues. Yes, that's on my todo list. The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. Does the conversion program support all possible features in a current grub menu.lst or are there areas where this is uncertain? The current sid version basically uses the same code and should work. The new code is being written and should cope with all them. How widely has the conversion script been tested? Not finished yet but shouldn't be too complex and difficult to test. After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. If you really mean to deprecate grub in favor of grub2, then you should probably rename grub2 to grub at some point before the release of Lenny. Yes. It's still being dicussed if we'll or not do it. It's mostly depend of how stable grub2 proves to be. -- 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]
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 09:59:51AM -0300, Otavio Salvador wrote: We, the GRUB team, want to swtich to GRUB2 due many reasons, basicaly: - easier to maintain; - better codebase; - multi-arch support; support for multiple architectures :) Our current plan is to finish the update-grub2 merging on upstream side (being handled by Robert) and then upload a new package to Debian. This package after moving to lenny ought be set as default boot-loader in grub-installer (while we still offer grub as an option during the test cicle). Frans already asked most of the questions that I had. A few others: Is anybody else using grub2 as a default bootloader today? Has testing of grub2 explicitly included testing on older x86 systems, given that we've found that i486 was effectively not tested at all thoroughly before the etch release (the distro in general, not grub in particular)? The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. Hrm. What was wrong with the existing format? :/ Those are the kinds of upstream changes that are most aggravating for administrators (or at least for this administrator here :). After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. If the intent really is to drop grub1, I agree that grub2 should be renamed to 'grub' to ensure a smooth upgrade path. The migration path, as for i386 too, could be the installation of the package with a debconf note asking for the installation of the boot-loader using grub-installer and the removal of previous boot-loader. I wouldn't like to get my boot-loader replaced without any notice. At least in the case of x86, I'm not sure how that's any different from what happens with any other upgrade of the bootloader. I guess the grub1 boot sector is incompatible with grub2, and this is what has to be rewritten on upgrade? On Wed, Apr 25, 2007 at 02:02:18PM -0300, Otavio Salvador wrote: Has grub2 been checked for obvious past issues we've had in grub (like /dev/cciss/c0d0 support)? It should support. Is difficult to test it without hardware access. Well, those are the kinds of things that I think should be checked before asking the installer team to commit to using it by default. After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. If you really mean to deprecate grub in favor of grub2, then you should probably rename grub2 to grub at some point before the release of Lenny. Yes. It's still being dicussed if we'll or not do it. It's mostly depend of how stable grub2 proves to be. Again, if grub2 isn't stable enough to be called 'grub', then I really think it's not stable enough to be made the default in d-i either. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#419386: installation-report: Installation issues
On Mon, Apr 16, 2007 at 06:56:59PM +0200, Frans Pop wrote: reopen 419386 reassign 419386 netcfg 1.37 forcemerge 419386 410560 thanks In going through the log, I noted something else in choosing a connection I was offered eth0 or eth1. eth0 is I think the firewire connection and was the default That has been reported before, but should not happen according to the code. The log by itself looks OK: eth1 is detected as having a link and should thus be default. Could you run an installation using the image at [1]? This has a modified netcfg with additional debugging statements. You only need to proceed up to (and including) network configuration, then save the syslog, and after that you can abort the installation. Please make a note of what interface is offered as default. If it is not the firewire interface, you may need to reboot the installer and try again. TIA, FJP [1] http://people.debian.org/~fjp/tmp/netcfg-debug_mini.iso Mini-installation worked, I am not sure where the syslog saved to. Installation chose the correct adatpor I will be re-installing sometime later this week. Too many odd minor events eg - crontab -e calls up mc not vim - iceweasel has died on me on various occasions - Printer is not properly integrated Nothing I can write a bug report on but do not want to fix each item, instead will be reinstall and pay more attention to the installations Many thanks -- Henry Wed Apr 25 20:00:13 BST 2007 -- Henry Wed Apr 25 19:56:18 BST 2007 signature.asc Description: Digital signature
Bug#419386: installation-report: Installation issues
On Wednesday 25 April 2007 21:01, Henry Bremridge wrote: Mini-installation worked, I am not sure where the syslog saved to. During the installation the syslog is in /var/log/syslog. you can use the Save debug logs option in the main menu to get it off the system. Installation chose the correct adatpor Hmm. If you cannot reproduce the original issue, the log is probably not much use... Thanks for trying anyway. Please let us know if you do your reinstall if you could reproduce the issue or not. If not, I think we can close the report. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of linux-modules-di-amd64-2.6_1.04_amd64.changes
linux-modules-di-amd64-2.6_1.04_amd64.changes uploaded successfully to localhost along with the files: linux-modules-di-amd64-2.6_1.04.dsc linux-modules-di-amd64-2.6_1.04.tar.gz loop-aes-modules-2.6.20-1-amd64-di_1.04_amd64.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of linux-modules-di-i386-2.6_1.04_i386.changes
linux-modules-di-i386-2.6_1.04_i386.changes uploaded successfully to localhost along with the files: linux-modules-di-i386-2.6_1.04.dsc linux-modules-di-i386-2.6_1.04.tar.gz loop-aes-modules-2.6.20-1-486-di_1.04_i386.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-modules-di-amd64-2.6_1.04_amd64.changes is NEW
linux-modules-di-amd64-2.6_1.04.dsc to pool/main/l/linux-modules-di-amd64-2.6/linux-modules-di-amd64-2.6_1.04.dsc linux-modules-di-amd64-2.6_1.04.tar.gz to pool/main/l/linux-modules-di-amd64-2.6/linux-modules-di-amd64-2.6_1.04.tar.gz (new) loop-aes-modules-2.6.20-1-amd64-di_1.04_amd64.udeb extra debian-installer loop-AES crypto modules This package contains loop-AES crypto modules. Changes: linux-modules-di-amd64-2.6 (1.04) unstable; urgency=low . * Built against loop-aes version 3.1f-2. Override entries for your package: linux-modules-di-amd64-2.6_1.04.dsc - source debian-installer Announcing to [EMAIL PROTECTED] Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
linux-modules-di-i386-2.6_1.04_i386.changes is NEW
linux-modules-di-i386-2.6_1.04.dsc to pool/main/l/linux-modules-di-i386-2.6/linux-modules-di-i386-2.6_1.04.dsc linux-modules-di-i386-2.6_1.04.tar.gz to pool/main/l/linux-modules-di-i386-2.6/linux-modules-di-i386-2.6_1.04.tar.gz (new) loop-aes-modules-2.6.20-1-486-di_1.04_i386.udeb extra debian-installer loop-AES crypto modules This package contains loop-AES crypto modules. Changes: linux-modules-di-i386-2.6 (1.04) unstable; urgency=low . * Built against loop-aes version 3.1f-2. Override entries for your package: linux-modules-di-i386-2.6_1.04.dsc - source debian-installer Announcing to [EMAIL PROTECTED] Your package contains new components which requires manual editing of the override file. It is ok otherwise, so please be patient. New packages are usually added to the override file about once a week. You may have gotten the distribution wrong. You'll get warnings above if files already exist in other distributions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of linux-kernel-di-amd64-2.6_1.24_amd64.changes
linux-kernel-di-amd64-2.6_1.24_amd64.changes uploaded successfully to localhost along with the files: linux-kernel-di-amd64-2.6_1.24.dsc linux-kernel-di-amd64-2.6_1.24.tar.gz kernel-image-2.6.20-1-amd64-di_1.24_amd64.udeb nic-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-extra-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-shared-modules-2.6.20-1-amd64-di_1.24_amd64.udeb serial-modules-2.6.20-1-amd64-di_1.24_amd64.udeb usb-serial-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ppp-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ide-modules-2.6.20-1-amd64-di_1.24_amd64.udeb pata-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ide-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb cdrom-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb firewire-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb scsi-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb scsi-modules-2.6.20-1-amd64-di_1.24_amd64.udeb scsi-common-modules-2.6.20-1-amd64-di_1.24_amd64.udeb scsi-extra-modules-2.6.20-1-amd64-di_1.24_amd64.udeb plip-modules-2.6.20-1-amd64-di_1.24_amd64.udeb floppy-modules-2.6.20-1-amd64-di_1.24_amd64.udeb loop-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ipv6-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ext2-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ext3-modules-2.6.20-1-amd64-di_1.24_amd64.udeb jfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ntfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb reiserfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb xfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb fat-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ufs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb qnx4-modules-2.6.20-1-amd64-di_1.24_amd64.udeb md-modules-2.6.20-1-amd64-di_1.24_amd64.udeb usb-modules-2.6.20-1-amd64-di_1.24_amd64.udeb usb-storage-modules-2.6.20-1-amd64-di_1.24_amd64.udeb pcmcia-storage-modules-2.6.20-1-amd64-di_1.24_amd64.udeb fb-modules-2.6.20-1-amd64-di_1.24_amd64.udeb input-modules-2.6.20-1-amd64-di_1.24_amd64.udeb mouse-modules-2.6.20-1-amd64-di_1.24_amd64.udeb irda-modules-2.6.20-1-amd64-di_1.24_amd64.udeb parport-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-pcmcia-modules-2.6.20-1-amd64-di_1.24_amd64.udeb pcmcia-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-usb-modules-2.6.20-1-amd64-di_1.24_amd64.udeb sata-modules-2.6.20-1-amd64-di_1.24_amd64.udeb core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb acpi-modules-2.6.20-1-amd64-di_1.24_amd64.udeb crc-modules-2.6.20-1-amd64-di_1.24_amd64.udeb crypto-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ata-modules-2.6.20-1-amd64-di_1.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 linux-kernel-di-i386-2.6_1.46_i386.changes
linux-kernel-di-i386-2.6_1.46_i386.changes uploaded successfully to localhost along with the files: linux-kernel-di-i386-2.6_1.46.dsc linux-kernel-di-i386-2.6_1.46.tar.gz kernel-image-2.6.20-1-486-di_1.46_i386.udeb nic-modules-2.6.20-1-486-di_1.46_i386.udeb nic-extra-modules-2.6.20-1-486-di_1.46_i386.udeb nic-shared-modules-2.6.20-1-486-di_1.46_i386.udeb serial-modules-2.6.20-1-486-di_1.46_i386.udeb usb-serial-modules-2.6.20-1-486-di_1.46_i386.udeb ppp-modules-2.6.20-1-486-di_1.46_i386.udeb ide-modules-2.6.20-1-486-di_1.46_i386.udeb pata-modules-2.6.20-1-486-di_1.46_i386.udeb ide-core-modules-2.6.20-1-486-di_1.46_i386.udeb cdrom-core-modules-2.6.20-1-486-di_1.46_i386.udeb cdrom-modules-2.6.20-1-486-di_1.46_i386.udeb firewire-core-modules-2.6.20-1-486-di_1.46_i386.udeb scsi-core-modules-2.6.20-1-486-di_1.46_i386.udeb scsi-modules-2.6.20-1-486-di_1.46_i386.udeb scsi-common-modules-2.6.20-1-486-di_1.46_i386.udeb scsi-extra-modules-2.6.20-1-486-di_1.46_i386.udeb plip-modules-2.6.20-1-486-di_1.46_i386.udeb floppy-modules-2.6.20-1-486-di_1.46_i386.udeb loop-modules-2.6.20-1-486-di_1.46_i386.udeb ipv6-modules-2.6.20-1-486-di_1.46_i386.udeb ext3-modules-2.6.20-1-486-di_1.46_i386.udeb jfs-modules-2.6.20-1-486-di_1.46_i386.udeb ntfs-modules-2.6.20-1-486-di_1.46_i386.udeb reiserfs-modules-2.6.20-1-486-di_1.46_i386.udeb xfs-modules-2.6.20-1-486-di_1.46_i386.udeb fat-modules-2.6.20-1-486-di_1.46_i386.udeb ufs-modules-2.6.20-1-486-di_1.46_i386.udeb qnx4-modules-2.6.20-1-486-di_1.46_i386.udeb md-modules-2.6.20-1-486-di_1.46_i386.udeb usb-modules-2.6.20-1-486-di_1.46_i386.udeb usb-storage-modules-2.6.20-1-486-di_1.46_i386.udeb pcmcia-storage-modules-2.6.20-1-486-di_1.46_i386.udeb fb-modules-2.6.20-1-486-di_1.46_i386.udeb input-modules-2.6.20-1-486-di_1.46_i386.udeb mouse-modules-2.6.20-1-486-di_1.46_i386.udeb irda-modules-2.6.20-1-486-di_1.46_i386.udeb parport-modules-2.6.20-1-486-di_1.46_i386.udeb nic-pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb nic-usb-modules-2.6.20-1-486-di_1.46_i386.udeb sata-modules-2.6.20-1-486-di_1.46_i386.udeb core-modules-2.6.20-1-486-di_1.46_i386.udeb acpi-modules-2.6.20-1-486-di_1.46_i386.udeb crc-modules-2.6.20-1-486-di_1.46_i386.udeb crypto-modules-2.6.20-1-486-di_1.46_i386.udeb efi-modules-2.6.20-1-486-di_1.46_i386.udeb ata-modules-2.6.20-1-486-di_1.46_i386.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
Steve Langasek [EMAIL PROTECTED] writes: Frans already asked most of the questions that I had. A few others: Is anybody else using grub2 as a default bootloader today? Not yet. Has testing of grub2 explicitly included testing on older x86 systems, given that we've found that i486 was effectively not tested at all thoroughly before the etch release (the distro in general, not grub in particular)? No but since we'll be offering grub as alternative for a while it could be sorted out. The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. Hrm. What was wrong with the existing format? :/ Those are the kinds of upstream changes that are most aggravating for administrators (or at least for this administrator here :). hehe it has been much improved and added some neat features. :-) After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. If the intent really is to drop grub1, I agree that grub2 should be renamed to 'grub' to ensure a smooth upgrade path. I also agree but I don't think we should decide it until we have it as default for a while. After that we can decide if we drop or not grub1. The migration path, as for i386 too, could be the installation of the package with a debconf note asking for the installation of the boot-loader using grub-installer and the removal of previous boot-loader. I wouldn't like to get my boot-loader replaced without any notice. At least in the case of x86, I'm not sure how that's any different from what happens with any other upgrade of the bootloader. I guess the grub1 boot sector is incompatible with grub2, and this is what has to be rewritten on upgrade? Yes, it's incompatible but until the user run grub-install he would still being using the previous release. On Wed, Apr 25, 2007 at 02:02:18PM -0300, Otavio Salvador wrote: Has grub2 been checked for obvious past issues we've had in grub (like /dev/cciss/c0d0 support)? It should support. Is difficult to test it without hardware access. Well, those are the kinds of things that I think should be checked before asking the installer team to commit to using it by default. Well yes and no. I and Robert will upload the new packages with update-grub2 and the last fixes in few days (maybe next week?) and after we have it all sorted out we could change it while keeping grub1 as an option. After doing it, we intend to drop grub from archive since it's a bunch of patches difficult to maintain and hard to follow. If you really mean to deprecate grub in favor of grub2, then you should probably rename grub2 to grub at some point before the release of Lenny. Yes. It's still being dicussed if we'll or not do it. It's mostly depend of how stable grub2 proves to be. Again, if grub2 isn't stable enough to be called 'grub', then I really think it's not stable enough to be made the default in d-i either. We hope it's but we won't be sure until we do that change since we wouldn't get the needed group of testers. :( -- 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]
linux-kernel-di-amd64-2.6_1.24_amd64.changes ACCEPTED
Accepted: acpi-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/acpi-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ata-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ata-modules-2.6.20-1-amd64-di_1.24_amd64.udeb cdrom-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/cdrom-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb crc-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/crc-modules-2.6.20-1-amd64-di_1.24_amd64.udeb crypto-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/crypto-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ext2-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ext2-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ext3-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ext3-modules-2.6.20-1-amd64-di_1.24_amd64.udeb fat-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/fat-modules-2.6.20-1-amd64-di_1.24_amd64.udeb fb-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/fb-modules-2.6.20-1-amd64-di_1.24_amd64.udeb firewire-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/firewire-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb floppy-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/floppy-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ide-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ide-core-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ide-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ide-modules-2.6.20-1-amd64-di_1.24_amd64.udeb input-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/input-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ipv6-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ipv6-modules-2.6.20-1-amd64-di_1.24_amd64.udeb irda-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/irda-modules-2.6.20-1-amd64-di_1.24_amd64.udeb jfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/jfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb kernel-image-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/kernel-image-2.6.20-1-amd64-di_1.24_amd64.udeb linux-kernel-di-amd64-2.6_1.24.dsc to pool/main/l/linux-kernel-di-amd64-2.6/linux-kernel-di-amd64-2.6_1.24.dsc linux-kernel-di-amd64-2.6_1.24.tar.gz to pool/main/l/linux-kernel-di-amd64-2.6/linux-kernel-di-amd64-2.6_1.24.tar.gz loop-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/loop-modules-2.6.20-1-amd64-di_1.24_amd64.udeb md-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/md-modules-2.6.20-1-amd64-di_1.24_amd64.udeb mouse-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/mouse-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-extra-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-extra-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-pcmcia-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-pcmcia-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-shared-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-shared-modules-2.6.20-1-amd64-di_1.24_amd64.udeb nic-usb-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/nic-usb-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ntfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/ntfs-modules-2.6.20-1-amd64-di_1.24_amd64.udeb parport-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/parport-modules-2.6.20-1-amd64-di_1.24_amd64.udeb pata-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/pata-modules-2.6.20-1-amd64-di_1.24_amd64.udeb pcmcia-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/pcmcia-modules-2.6.20-1-amd64-di_1.24_amd64.udeb pcmcia-storage-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/pcmcia-storage-modules-2.6.20-1-amd64-di_1.24_amd64.udeb plip-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to pool/main/l/linux-kernel-di-amd64-2.6/plip-modules-2.6.20-1-amd64-di_1.24_amd64.udeb ppp-modules-2.6.20-1-amd64-di_1.24_amd64.udeb to
linux-kernel-di-i386-2.6_1.46_i386.changes is NEW
acpi-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/acpi-modules-2.6.20-1-486-di_1.46_i386.udeb ata-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ata-modules-2.6.20-1-486-di_1.46_i386.udeb cdrom-core-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/cdrom-core-modules-2.6.20-1-486-di_1.46_i386.udeb cdrom-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/cdrom-modules-2.6.20-1-486-di_1.46_i386.udeb (new) core-modules-2.6.20-1-486-di_1.46_i386.udeb standard debian-installer Core modules This package contains core modules for the kernel, that will almost always be needed. crc-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/crc-modules-2.6.20-1-486-di_1.46_i386.udeb crypto-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/crypto-modules-2.6.20-1-486-di_1.46_i386.udeb efi-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/efi-modules-2.6.20-1-486-di_1.46_i386.udeb ext3-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ext3-modules-2.6.20-1-486-di_1.46_i386.udeb fat-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/fat-modules-2.6.20-1-486-di_1.46_i386.udeb fb-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/fb-modules-2.6.20-1-486-di_1.46_i386.udeb firewire-core-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/firewire-core-modules-2.6.20-1-486-di_1.46_i386.udeb floppy-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/floppy-modules-2.6.20-1-486-di_1.46_i386.udeb ide-core-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ide-core-modules-2.6.20-1-486-di_1.46_i386.udeb ide-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ide-modules-2.6.20-1-486-di_1.46_i386.udeb input-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/input-modules-2.6.20-1-486-di_1.46_i386.udeb ipv6-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ipv6-modules-2.6.20-1-486-di_1.46_i386.udeb irda-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/irda-modules-2.6.20-1-486-di_1.46_i386.udeb jfs-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/jfs-modules-2.6.20-1-486-di_1.46_i386.udeb kernel-image-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/kernel-image-2.6.20-1-486-di_1.46_i386.udeb linux-kernel-di-i386-2.6_1.46.dsc to pool/main/l/linux-kernel-di-i386-2.6/linux-kernel-di-i386-2.6_1.46.dsc linux-kernel-di-i386-2.6_1.46.tar.gz to pool/main/l/linux-kernel-di-i386-2.6/linux-kernel-di-i386-2.6_1.46.tar.gz loop-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/loop-modules-2.6.20-1-486-di_1.46_i386.udeb md-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/md-modules-2.6.20-1-486-di_1.46_i386.udeb mouse-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/mouse-modules-2.6.20-1-486-di_1.46_i386.udeb nic-extra-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-extra-modules-2.6.20-1-486-di_1.46_i386.udeb nic-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-modules-2.6.20-1-486-di_1.46_i386.udeb nic-pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb nic-shared-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-shared-modules-2.6.20-1-486-di_1.46_i386.udeb nic-usb-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-usb-modules-2.6.20-1-486-di_1.46_i386.udeb ntfs-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ntfs-modules-2.6.20-1-486-di_1.46_i386.udeb parport-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/parport-modules-2.6.20-1-486-di_1.46_i386.udeb pata-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pata-modules-2.6.20-1-486-di_1.46_i386.udeb pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb pcmcia-storage-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pcmcia-storage-modules-2.6.20-1-486-di_1.46_i386.udeb plip-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/plip-modules-2.6.20-1-486-di_1.46_i386.udeb ppp-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ppp-modules-2.6.20-1-486-di_1.46_i386.udeb qnx4-modules-2.6.20-1-486-di_1.46_i386.udeb
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 05:14:09PM -0300, Otavio Salvador wrote: The upgrade from grub to grub2 will be transparent since menu.list can be automaticaly converted to the new format and this will be in place when we start the default boot-loader change. Hrm. What was wrong with the existing format? :/ Those are the kinds of upstream changes that are most aggravating for administrators (or at least for this administrator here :). hehe it has been much improved and added some neat features. :-) Which tells me nothing. There was nothing missing from menu.lst for me that I felt needed to be improved with a new format... The migration path, as for i386 too, could be the installation of the package with a debconf note asking for the installation of the boot-loader using grub-installer and the removal of previous boot-loader. I wouldn't like to get my boot-loader replaced without any notice. At least in the case of x86, I'm not sure how that's any different from what happens with any other upgrade of the bootloader. I guess the grub1 boot sector is incompatible with grub2, and this is what has to be rewritten on upgrade? Yes, it's incompatible but until the user run grub-install he would still being using the previous release. Ok. This means that the actual upgrade from grub1 to grub2 should be totally safe for all users by default, because grub-install is not automatically run, yes? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposed release goal: Switch to GRUB2
Steve Langasek [EMAIL PROTECTED] writes: On Wed, Apr 25, 2007 at 05:14:09PM -0300, Otavio Salvador wrote: Hrm. What was wrong with the existing format? :/ Those are the kinds of upstream changes that are most aggravating for administrators (or at least for this administrator here :). hehe it has been much improved and added some neat features. :-) Which tells me nothing. There was nothing missing from menu.lst for me that I felt needed to be improved with a new format... The new grub.cfg behaves more like a shell, it can scripting capabilities and allow more freedom to the user do what he wish to. For reference: http://grub.enbug.org/grub.cfg At least in the case of x86, I'm not sure how that's any different from what happens with any other upgrade of the bootloader. I guess the grub1 boot sector is incompatible with grub2, and this is what has to be rewritten on upgrade? Yes, it's incompatible but until the user run grub-install he would still being using the previous release. Ok. This means that the actual upgrade from grub1 to grub2 should be totally safe for all users by default, because grub-install is not automatically run, yes? Yes. It won't change the system until user runs grub-install by himself. It would deserve a note while upgrading to ask the user to do it as soon as possible and if we opt to keep grub available we can also explain how to revert to upgrade if need. -- 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]
Re: nano-udeb: Depends: libc6 (= 2.5)
Op 21-04-2007 om 16:40 schreef Frans Pop: On Saturday 21 April 2007 09:13, Geert Stappers wrote: When is libc 2.5 expected to arrive? http://buildd.debian.org/~jeroen/status/package.php?p=glibc It did arrive:-) Cheers Geert Stappers ( telling the readers of the list archive that it is fixed ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
RE: nano-udeb: Depends: libc6 (= 2.5)
-Original Message- From: Geert Stappers [mailto:[EMAIL PROTECTED] Sent: 25 April 2007 22:15 To: debian-boot@lists.debian.org Subject: Re: nano-udeb: Depends: libc6 (= 2.5) Op 21-04-2007 om 16:40 schreef Frans Pop: On Saturday 21 April 2007 09:13, Geert Stappers wrote: When is libc 2.5 expected to arrive? http://buildd.debian.org/~jeroen/status/package.php?p=glibc It did arrive:-) unfortunately it still seems to be backed up out of testing by a missing build-dep on gcc-4.2 :) No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.463 / Virus Database: 269.6.0/775 - Release Date: 24/04/2007 17:43
linux-modules-di-amd64-2.6_1.04_amd64.changes ACCEPTED
Accepted: linux-modules-di-amd64-2.6_1.04.dsc to pool/main/l/linux-modules-di-amd64-2.6/linux-modules-di-amd64-2.6_1.04.dsc linux-modules-di-amd64-2.6_1.04.tar.gz to pool/main/l/linux-modules-di-amd64-2.6/linux-modules-di-amd64-2.6_1.04.tar.gz loop-aes-modules-2.6.20-1-amd64-di_1.04_amd64.udeb to pool/main/l/linux-modules-di-amd64-2.6/loop-aes-modules-2.6.20-1-amd64-di_1.04_amd64.udeb Override entries for your package: linux-modules-di-amd64-2.6_1.04.dsc - optional debian-installer loop-aes-modules-2.6.20-1-amd64-di_1.04_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]
linux-modules-di-i386-2.6_1.04_i386.changes ACCEPTED
Accepted: linux-modules-di-i386-2.6_1.04.dsc to pool/main/l/linux-modules-di-i386-2.6/linux-modules-di-i386-2.6_1.04.dsc linux-modules-di-i386-2.6_1.04.tar.gz to pool/main/l/linux-modules-di-i386-2.6/linux-modules-di-i386-2.6_1.04.tar.gz loop-aes-modules-2.6.20-1-486-di_1.04_i386.udeb to pool/main/l/linux-modules-di-i386-2.6/loop-aes-modules-2.6.20-1-486-di_1.04_i386.udeb Override entries for your package: linux-modules-di-i386-2.6_1.04.dsc - optional debian-installer loop-aes-modules-2.6.20-1-486-di_1.04_i386.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]
linux-kernel-di-i386-2.6_1.46_i386.changes ACCEPTED
Accepted: acpi-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/acpi-modules-2.6.20-1-486-di_1.46_i386.udeb ata-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ata-modules-2.6.20-1-486-di_1.46_i386.udeb cdrom-core-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/cdrom-core-modules-2.6.20-1-486-di_1.46_i386.udeb cdrom-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/cdrom-modules-2.6.20-1-486-di_1.46_i386.udeb core-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/core-modules-2.6.20-1-486-di_1.46_i386.udeb crc-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/crc-modules-2.6.20-1-486-di_1.46_i386.udeb crypto-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/crypto-modules-2.6.20-1-486-di_1.46_i386.udeb efi-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/efi-modules-2.6.20-1-486-di_1.46_i386.udeb ext3-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ext3-modules-2.6.20-1-486-di_1.46_i386.udeb fat-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/fat-modules-2.6.20-1-486-di_1.46_i386.udeb fb-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/fb-modules-2.6.20-1-486-di_1.46_i386.udeb firewire-core-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/firewire-core-modules-2.6.20-1-486-di_1.46_i386.udeb floppy-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/floppy-modules-2.6.20-1-486-di_1.46_i386.udeb ide-core-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ide-core-modules-2.6.20-1-486-di_1.46_i386.udeb ide-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ide-modules-2.6.20-1-486-di_1.46_i386.udeb input-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/input-modules-2.6.20-1-486-di_1.46_i386.udeb ipv6-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ipv6-modules-2.6.20-1-486-di_1.46_i386.udeb irda-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/irda-modules-2.6.20-1-486-di_1.46_i386.udeb jfs-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/jfs-modules-2.6.20-1-486-di_1.46_i386.udeb kernel-image-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/kernel-image-2.6.20-1-486-di_1.46_i386.udeb linux-kernel-di-i386-2.6_1.46.dsc to pool/main/l/linux-kernel-di-i386-2.6/linux-kernel-di-i386-2.6_1.46.dsc linux-kernel-di-i386-2.6_1.46.tar.gz to pool/main/l/linux-kernel-di-i386-2.6/linux-kernel-di-i386-2.6_1.46.tar.gz loop-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/loop-modules-2.6.20-1-486-di_1.46_i386.udeb md-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/md-modules-2.6.20-1-486-di_1.46_i386.udeb mouse-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/mouse-modules-2.6.20-1-486-di_1.46_i386.udeb nic-extra-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-extra-modules-2.6.20-1-486-di_1.46_i386.udeb nic-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-modules-2.6.20-1-486-di_1.46_i386.udeb nic-pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb nic-shared-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-shared-modules-2.6.20-1-486-di_1.46_i386.udeb nic-usb-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/nic-usb-modules-2.6.20-1-486-di_1.46_i386.udeb ntfs-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ntfs-modules-2.6.20-1-486-di_1.46_i386.udeb parport-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/parport-modules-2.6.20-1-486-di_1.46_i386.udeb pata-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pata-modules-2.6.20-1-486-di_1.46_i386.udeb pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pcmcia-modules-2.6.20-1-486-di_1.46_i386.udeb pcmcia-storage-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/pcmcia-storage-modules-2.6.20-1-486-di_1.46_i386.udeb plip-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/plip-modules-2.6.20-1-486-di_1.46_i386.udeb ppp-modules-2.6.20-1-486-di_1.46_i386.udeb to pool/main/l/linux-kernel-di-i386-2.6/ppp-modules-2.6.20-1-486-di_1.46_i386.udeb qnx4-modules-2.6.20-1-486-di_1.46_i386.udeb to
Re: nano-udeb: Depends: libc6 (= 2.5)
On Wednesday 25 April 2007 23:51, peter green wrote: unfortunately it still seems to be backed up out of testing by a missing build-dep on gcc-4.2 :) I would not expect testing to be really usable to build the installer for quite some time. pgp0d5VLcAtGN.pgp Description: PGP signature
Re: Proposed release goal: Switch to GRUB2
On Wed, Apr 25, 2007 at 05:14:09PM -0300, Otavio Salvador wrote: Steve Langasek [EMAIL PROTECTED] writes: Frans already asked most of the questions that I had. A few others: Is anybody else using grub2 as a default bootloader today? Not yet. Just an entry point, which may or may not be important here. Sun has decided to make grub2 the default for opensolaris, including their powerpc opensolaris port. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]