Re: Relocation errors in cdebconf plugins
I've committed a fix for this problem, the cdebconf plugin is included in the library reduction step and mlock is included in the reduced libc. This will be in the next daily build. -- see shy jo signature.asc Description: Digital signature
Re: Addition of Newer Kernel @ etch 1/2
If we want to prepare for this possibility, the one issue that the d-i folks pointed out is that we'd probably want to refactor our meta packages such that we could have both metapackages for the latest 2.6.N and additional packages for the latest 2.6.N+, so users can track whichever they prefer. One suggestion was to use linux-image-etch-foo for tracking 2.6.N and something like linux-image-etch+-foo for tracking the 2.6.N+ update. Notice that this issue rejoins the discussion about metapackages we had concerning the 2.6.16-only etch branch, where i proposed already a similar scheme (altough having the normal linux-image-foo for etch, and another set of metapackages for the latest sid version not aimed at etch). Could you also please discuss with the d-i people the oportunity of, not including the .udeb generation into the main linux-2.6 packages, but integrating them again in a single source linux-2.6-udebs or whatever package, which would hold all arches, over the current situation ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Persistent device names
On Wed, May 17, 2006 at 01:07:29PM +0900, Junichi Uekawa wrote: Hi, - Are there likely to be architecture specific issues with persistent device naming? - Or with filesystems other than ext2/ext3? Nothing I know about. tree /dev/disk/ should give you some ideas. by-label links are user friendly, but may become ambiguous if users carelessly duplicate file systems using dd. by-uuid links have the same problem *and* need a suitable identifier in the file system metadata. by-id links are more unique but linked to the physical hardware (you can't have it both ways...) and are a bit ugly. by-path links are very descriptive and really unique, but are *really* unique and will change if a disk is moved to a different bus position or something like this. Some enterprise-level storage systems have disk-level duplication system, as such, filesystem-label-based mount-point would not be the end-all way of approaching the problem. It might be less error-prone if bus/card info is used in addition to the filesystem UUID. I was thinking the same thing. UUID + by-path if two UUIDs are the same, with the first of them responding to UUID and the subsequent to a UUID-# kind of scheme or something, where # is ordered by growing path or something. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]: Re: The powerpc port should be removed from etch release candidates ...]
On Wed, May 17, 2006 at 12:18:28AM -0400, Albert Cahalan wrote: On 5/12/06, Sven Luther [EMAIL PROTECTED] wrote: There was an easy way not to problong the discussion. Restore the svn commit acces, which you could have done all those weeks ago if you had not been too proud and afraid to lose face. Better: do like Linus, and take away access from all but one person. BSD has always had nasty fights over commit access. Commit bits are greatly political in nature. They can not be removed without hurt. Thus the existance of OpenBSD and DragonflyBSD. Linux doesn't suffer this way. The closest thing ever was the IDE maintainer being changed a couple times. (so avoid MAINTAINERS files too) Feelings can't get hurt all that much if there isn't any status to revoke. Both SVN and CVS have a server-centric model that ultimately leads to nasty poltics. The alternatives are git, Mercurial, and monotone. It does mean forking and fragmentation of the code base, which would not be best for d-i and debian. But yes, having a distributed revision system would be helpful in these cases, and if people don't come to their sense and this issue be solved, i will be left only to create a svk-based duplicate of the d-i svn repo, and make this one the authoritative version for the packages i upload or changes i make. Imagine the mess this will cause :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [D-I] Preparing for update in stable
This is a follow-up to [1] which proposed a plan for the update of D-I using the latest kernel update for stable in preparation for Sarge r3. Follow-ups please in principle _only_ to d-release and d-boot and maybe to one of the CCed lists if relevant for them. On Friday 21 April 2006 02:01, Frans Pop wrote: In more detail: 1) Upload new i386 kernel udebs for both 2.4 and 2.6 to s-p-u (I've already prepared a set) 2) Get these acked by SRM so they actually show up in s-p-u; s-p-u already has debian-installer sections, I'm not sure if the acceptance queue and approval stuff supports udebs though (aj?) 3) Try a local build of d-i using a sources.list that has both stable and s-p-u in it [1]. After a bit of a wait, stage 2 was completed and I have completed the test in stage 3. Building the installer using s-p-u to get kernel udebs worked as expected and the mini.iso booted with the correct kernel and ran successfully for the first installation steps. Attached are the patches that are needed in the installer to make use of the new kernels. One patch for d-i itself and one for base-installer (for alpha). Patches for kernel udeb packages not included as they are trivial. Some comments on the patch for debian-installer: - AMD64 currently has _no_ kernel updates in their s-p-u Packages file; I understand that Joerg Jaspert needs to work on this for AMD64 to be included in the r3 point release. It will probably also need work by him to get the udebs into the debian-installer section in s-p-u. - The following architectures have no ABI version in the packages names and thus do not need a change in their config files: arm, m68k, mips, mipsel - Powerpc did not have any ABI version in the kernel-image package names, but with this release they have been added for 2.6.8 (not for 2.4.27!). As there also seem to be (new?) meta-packages, base-installer should continue to work. - The other arches all has an ABI change from 2 to 3. Request to d-i porters: please check if the changes for your architecture are complete. So, the next steps are: 4) If this works, poke^Wask porters to upload updated kernels udebs for their arches. We are going to delay step 4 until the kernel security updates that are currently being prepared are available in s-p-u. These do not include an ABI change. 5) Upload new base-installer. 6) Get those uploads acked by SRM. 7) Upload d-i and let the buildds do their stuff. The steps after that are: 8) Prepare necessary updates for debian-cd (if any). 9) Release r3 with very clear communication (debian-announce) that old installer images may break and that preferably new images should be used. Also communicate that availability of CD images may take up to a week. 10) Generate new package lists for debian-cd with new kernel versions. 11) Build and test images for all arches (with porter help). Cheers, FJP [1] http://lists.debian.org/debian-release/2006/04/msg00122.html Index: debian/postinst === --- debian/postinst (revision 36545) +++ debian/postinst (working copy) @@ -513,7 +513,7 @@ trykernel=kernel-image-$version-$flavor ;; alpha) - version=2.4.27-2 + version=2.4.27-3 if dmesg | grep -q ^Processors:; then CPUS=`dmesg | grep ^Processors: | cut -d: -f2` else Index: config/powerpc/power3.cfg === --- config/powerpc/power3.cfg (revision 37370) +++ config/powerpc/power3.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot # The version of the kernel to use. -KERNELVERSION = 2.6.8-power3 +KERNELVERSION = 2.6.8-3-power3 KERNEL_FLAVOUR = di KERNELNAME = vmlinux KERNELIMAGEVERSION = $(KERNELVERSION) Index: config/powerpc/powerpc.cfg === --- config/powerpc/powerpc.cfg (revision 37370) +++ config/powerpc/powerpc.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot floppy floppy-2.4 hd-media cdrom-minimal netboot-minimal # monolithic # The version of the kernel to use. -KERNELVERSION = 2.6.8-powerpc +KERNELVERSION = 2.6.8-3-powerpc # Targets for 2.4 kernel images will use this version instead. KERNELVERSION_2.4 = 2.4.27-powerpc KERNEL_FLAVOUR = di Index: config/powerpc/power4.cfg === --- config/powerpc/power4.cfg (revision 37370) +++ config/powerpc/power4.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot # The version of the kernel to use. -KERNELVERSION = 2.6.8-power4 +KERNELVERSION = 2.6.8-3-power4 KERNEL_FLAVOUR = di KERNELNAME = vmlinux KERNELIMAGEVERSION = $(KERNELVERSION) Index: config/alpha.cfg === --- config/alpha.cfg (revision 37370) +++ config/alpha.cfg (working copy) @@ -1,7 +1,7 @@ MEDIUM_SUPPORTED = cdrom netboot miniiso # The version
AMD64 HP v1402kr
I tried the di netinst as I was experiencing strange problems with the Ubuntu dapper installer. A similar problem that I had with 'Ubuntu dapper' persisted with debootstrap: http://static.natalian.org/2006-05-16/amd64/di-20060516/ When choosing a mirror, how come there is no Korean mirror? There is amd64 on ftp.kr.debian.org When it failed I think (as my notes aren't very clear) it said look at /var/log/debian-installer though there weren't any logs to be found there. Nor on the /target Not sure where I obtained the logs in the end. Later I tried the installer again. This time I wiped out all the partitions on the HP machine. I think an earlier 7G fat32 partition which I'll assume is the rescue patition was causing grief. The install worked from a blank hard drive. On the netinst I was too lazy to enter in the IP details and then at the choosing mirror stage, of course it couldn't reach a mirror. The error message then Bad archive mirror wasn't really apt. Perhaps a check to see the network is configured first? Not sure. Best wishes, -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Persistent device names
On May 17, Junichi Uekawa [EMAIL PROTECTED] wrote: Some enterprise-level storage systems have disk-level duplication system, as such, filesystem-label-based mount-point would not be the end-all way of approaching the problem. Can you describe which designs require this? I have never heard of such a setup, and I have some doubts that it's something that should be supported. It might be less error-prone if bus/card info is used in addition to the filesystem UUID. by-path names are unique enough, anyway. -- ciao, Marco signature.asc Description: Digital signature
Re: S/390 and persistent device naming (was: s390 update - partman requirements)
On Wed, May 17, 2006 at 12:51:50AM +0200, Frans Pop wrote: - Must save exact informations about the root device or any device which is needed for them if it is LVM/MD. s390 don't have device autoconfiguration and therefor must know, which device it needs to be configured to get the root. No idea about this. But I have one. partman-md and partman-lvm have to save the partman devicespec of the underlaying devices somewhere in /var/lib/partman/$dev. Than a special script in finish.d can just travel through them and save the informations somewhere else. Bastian -- We have found all life forms in the galaxy are capable of superior development. -- Kirk, The Gamesters of Triskelion, stardate 3211.7 signature.asc Description: Digital signature
Re: Persistent device names
On Wed, May 17, 2006 at 01:00:45AM +0200, Frans Pop wrote: - We should like to keep support for devfs and regular device names in the installer; loosing that would mean no support for 2.2/2.4 installs (although those are likely to be dropped anyway) and no support for installs of Sarge and I think may be a problem for debian-edu. However, if it is unavoidable, we could drop this requirement. As we don't use the devfs names in the installed system, the removal of support for them will not affect sarge. - Are there likely to be architecture specific issues with persistent device naming? - Or with filesystems other than ext2/ext3? Nope. It is just another name for the same device. - A special case is for installations from usb-stick in combination with a scsi or SATA harddisk controller. In that case d-i will see the USB stick as the first SCSI controller (sda) and the real SCSI/SATA harddisks will come after that. This also results in errors on reboot as the grub setup and fstab will be incorrect as then the usb stick will not be present and sda will be assigned to the real disk controller. Similar cases for installs to any kind of external disk drive. It seems to me that persistent device naming will probably fix fstab in this case, but possibly not the grub configuration. The root parameter on the kernel command line needs to include the persistent name. This will fix the boot but not the mapping which is needed to instlal grub again. - Probably unrelated, but worth mentioning. If the user installs to hdb and has BIOS set to boot from hdb, the grub configuration will be incorrect. (Same for hdc, hdd of course.) -v? - Identify where changes will be needed. This will be at least partman and will probably include most bootloader installers. And we should drop the devfs compat rules from udev. At least in my tests they produced more harm than good. Bastian -- There is an order of things in this universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 signature.asc Description: Digital signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Josselin Mouette wrote: Le mercredi 17 mai 2006 à 00:37 +0200, Attilio Fiandrotti a écrit : The above library requirements apply to both GTK 2.9.0 and 2006-03- 26 CVS snapshot (which is older than 2.9.0 ). More recent GTK CVS snapshots require glib 2.11, pango 1.11 ( and DFB 0.9.25 i think). Does the 2006-03-26 integrate all the necessary changes for DFB? More interestingly, would it be possible to extract the necessary patches for DFB and to apply them to 2.8? If they are not invasive, that's probably a better way to go. That would be possible, but some patching of Makefile is required, as shown in this patchfile [0] for GTK 2.8.10 from DFB's CVS repository, where the GDKDFB project lived for many years before entering GTK mainline. Also, some bugfixes applied to the DFB backend after it was merged into GTK mainline should be backported. I just filed reports (and a patch) for two bugs [1][2] that currently prevent GTK 2.9.1 from compiling with the DFB backend. If GTK team fixes those bugs before GTK 2.9.2 is released, we could build the GTKDFB libraries without the need for patches to original source tarballs. Note that GTK 2.9.1 requires pango 1.13 (not udeb-packaged yet), while GTK 2.9.0 requires only pango 1.12 (available as udeb): if at GTK 2.9.2 release time pango 1.13 should not have udeb-packaged yet, backporting patches for bugs 342091 and 342093 to GTK 2.9.0 could be an option too. frienly Attilio [0] http://www.directfb.org/index.php/viewcvs.cgi/gdk-directfb/gtk- directfb.patch?rev=1.91content-type=text/vnd.viewcvs-markup [1] http://bugzilla.gnome.org/show_bug.cgi?id=342091 [2] http://bugzilla.gnome.org/show_bug.cgi?id=342093 Tiscali ADSL 4 Mega Flat Naviga senza limiti a 19,95 Euro al mese con 4 Megabps di velocita'. Attiva subito: hai 2 MESI di canone adsl GRATIS! In piu', se sei raggiunto dalla rete Tiscali, telefoni senza pagare il canone Telecom. Scopri subito come risparmiare! http://abbonati.tiscali.it/prodotti/adsl/tc/4flat/
Bug#367634: installation-report: LSISAS1064 controller not discovered
Package: installation-reports Boot method: CD Image version: debian-testing-amd64-businesscard.iso daily from 20060517 Date: Wed May 17 13:19:29 CEST 2006 Machine: Sun Fire X4200 Processor: Dual Opteron 275 Memory: 4GB Partitions: none Output of lspci and lspci -n: debian-2:~# lspci :00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 13) :00:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) :00:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 13) :00:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) :00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07) :00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05) :00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03) :00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02) :00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05) :00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 NorthBridge :01:01.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 03) :01:01.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 03) :01:02.0 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 03) :01:02.1 Ethernet controller: Intel Corp. 82546EB Gigabit Ethernet Controller (Copper) (rev 03) :02:03.0 SCSI storage controller: LSI Logic / Symbios Logic: Unknown device 0050 (rev 02) :03:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) :03:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b) :03:03.0 VGA compatible controller: ATI Technologies Inc Rage XL (rev 27) :04:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 13) :04:01.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) :04:02.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 13) :04:02.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01) debian-2:~# lspci -n :00:01.0 0604: 1022:7450 (rev 13) :00:01.1 0800: 1022:7451 (rev 01) :00:02.0 0604: 1022:7450 (rev 13) :00:02.1 0800: 1022:7451 (rev 01) :00:06.0 0604: 1022:7460 (rev 07) :00:07.0 0601: 1022:7468 (rev 05) :00:07.1 0101: 1022:7469 (rev 03) :00:07.2 0c05: 1022:746a (rev 02) :00:07.3 0680: 1022:746b (rev 05) :00:18.0 0600: 1022:1100 :00:18.1 0600: 1022:1101 :00:18.2 0600: 1022:1102 :00:18.3 0600: 1022:1103 :00:19.0 0600: 1022:1100 :00:19.1 0600: 1022:1101 :00:19.2 0600: 1022:1102 :00:19.3 0600: 1022:1103 :01:01.0 0200: 8086:1010 (rev 03) :01:01.1 0200: 8086:1010 (rev 03) :01:02.0 0200: 8086:1010 (rev 03) :01:02.1 0200: 8086:1010 (rev 03) :02:03.0 0100: 1000:0050 (rev 02) :03:00.0 0c03: 1022:7464 (rev 0b) :03:00.1 0c03: 1022:7464 (rev 0b) :03:03.0 0300: 1002:4752 (rev 27) :04:01.0 0604: 1022:7450 (rev 13) :04:01.1 0800: 1022:7451 (rev 01) :04:02.0 0604: 1022:7450 (rev 13) :04:02.1 0800: 1022:7451 (rev 01) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [E] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] Comments/Problems: Hi, I've tried to install that server with different mediums (inofficial amd64 sarge d-i, sarge i386 d-i, etch beta2 amd64, etch daily amd64) but none of them seems to support the SAS controller card Finally I was able to install the machine with hints from [0] and [1] I do not know for sure if the LSI drivers [3] are already part of official kernel. I'll try to figure that out by now. If more details are required feel free to contact me. [0] http://www.inserve.se/edu/debian/ [1] http://ioctl.org/unix/debian/x4100 [3] http://www.lsilogic.com/products/sas_ics/lsisas1064.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Tue, May 16, 2006 at 09:48:30AM +0200, Frans Pop wrote: On Tuesday 16 May 2006 09:09, Sven Luther wrote: It is scheduled for release during may, which may or not be delayed a bit. This is way this is an important point to get feedaback from the release team and from the gtk-gnome team now. I am CCing them on this. As you are not the d-i or g-i release manager and currently not even on the d-i team, it is _not_ your place to do this. You have just managed to loose any credit you had started building again by being reasonable in the discussions over the last few days. If this is the way you will behave, I _will_ get you banned from the debian-boot list. Hello Frans, could you stop using debian-release for the purpose of bashing Sven Luther ? Thanks in advance, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: libdebian-installer Packages support proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, May 17, 2006 at 02:14:05AM +0200, Sven Luther wrote: On Tue, May 16, 2006 at 11:02:43PM +0200, Frans Pop wrote: On Tuesday 16 May 2006 19:59, Bastian Blank wrote: I'll implement that after the higher priority tasks (aka partman) are sorted out. As there was no response yes, I don't think anyone wants to help. Speaking only for myself of course, I still have your message on my TODO list. However, it is a fairly hard question with no simple answers and both being at Debconf and having to waste lots of time on the issues with Sven have resulted in my not having been able to really sit down for it. You are the only one who chose this course of action, that resulted in wasting so much time, for both you, me, the DPL, and i don't know how many innocent onlookers. I may be one of the innocent onlookers. On the other hand: I prefer to be part of the d-i team So I'm accused by Sven Luther of kicking out Sven Luther and I should demand an apology by Sven Luther in Sven Luther style. But because I care about d-i, i'm going spend my energy on d-i. Cheers Geert Stappers -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFEaxtpOSINbgwa/7sRAtBwAJ9HCtUxxVPoplUSAiCaXRvtospX2ACgnUqA JvA1SNze50W2NGGUIe633Y8= =qLtA -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Persistent device names
Hi, Some enterprise-level storage systems have disk-level duplication system, as such, filesystem-label-based mount-point would not be the end-all way of approaching the problem. Can you describe which designs require this? I have never heard of such a setup, and I have some doubts that it's something that should be supported. High-end storage systems available from EMC and HP (at least) have mirror-copy and snapshot-copy features, which provides similar kind of feature-set to LVM snapshots. With LVM snapshots it will be less problem, because LVM volumes are somewhat more logical in its nature and we will have persistent path with LVM names; making filesystem UUID moot. However, for storage-based mirror-copy volumes, they will show up to the operating system as different SCSI/FC disks with same filesystem UUID. It might be less error-prone if bus/card info is used in addition to the filesystem UUID. by-path names are unique enough, anyway. by-path sounds like decently unique, as long as SCSI/FC cards are detected in the same proper order. regards, junichi -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: dhcp3-client and D-I
On Wed, May 17, 2006 at 01:14:25AM +1000, Andrew Pollock wrote: [ ... ] Okay. I've had a preliminary play with ipconfig over the weekend. Seems relatively straightforward to slot it into netcfg's dhcp.c. What I need to understand is the necessity to set a vendor-class-identifier attribute in with the request, is this a nicety or a need-to-have? ipconfig won't do it. The other thing that ipconfig doesn't currently do is send the hostname with the request, which is an optional feature for some people on cable. That's potentially fixable though, as one of the ways of invoking ipconfig includes a hostname. I've built a udeb from ipconfig, and twiddled with netcfg enough to test it out, I've just been having some problems rebuilding d-i, but I'll try again during the week. Is the source of the ipconfig udeb public available? If yes: Where? regards Andrew Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processing of s390-sysconfig-writer_0.1_s390.changes
s390-sysconfig-writer_0.1_s390.changes uploaded successfully to localhost along with the files: s390-sysconfig-writer_0.1.dsc s390-sysconfig-writer_0.1.tar.gz s390-sysconfig-writer_0.1_s390.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
s390-sysconfig-writer_0.1_s390.changes is NEW
(new) s390-sysconfig-writer_0.1.dsc standard debian-installer (new) s390-sysconfig-writer_0.1.tar.gz standard debian-installer (new) s390-sysconfig-writer_0.1_s390.udeb standard debian-installer Sysconfig writer Write sysconfig config files. Changes: s390-sysconfig-writer (0.1) unstable; urgency=low . * First release. Announcing to debian-devel-changes@lists.debian.org 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]
distributed version control systems
On Wed, May 17, 2006 at 07:53:48AM +0200, Sven Luther wrote: On Wed, May 17, 2006 at 12:18:28AM -0400, Albert Cahalan wrote: [ ... ] Both SVN and CVS have a server-centric model that ultimately leads to nasty poltics. The alternatives are git, Mercurial, and monotone. Another alternative is darcs ( http://abridgegame.org/darcs/ ) It does mean forking and fragmentation of the code base, which would not be best for d-i and debian. But yes, having a distributed revision system would be helpful in these cases, and if people don't come to their sense and this issue be solved, i will be left only to create a svk-based duplicate of the d-i svn repo, and make this one the authoritative version for the packages i upload or changes i make. Imagine the mess this will cause :) I do see the smilely, but I don't understand it. The Imagine the mess this cause makes me worry. Where will be the mess? Is it a threat? Worried Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367634: installation-report: LSISAS1064 controller not discovered
On Wed, May 17, 2006 at 01:33:31PM +0200, Bjoern Boschman wrote: Package: installation-reports Boot method: CD Image version: debian-testing-amd64-businesscard.iso daily from 20060517 Date: Wed May 17 13:19:29 CEST 2006 A visit at http://amd64.debian.net/debian-installer/daily/ revealed builds date april 8th. AFAIK there is _no_ 20060517 AMD64 d-i build Machine: Sun Fire X4200 Processor: Dual Opteron 275 Memory: 4GB Groovy! Output of lspci and lspci -n: debian-2:~# lspci :02:03.0 SCSI storage controller: LSI Logic / Symbios Logic: Unknown device 0050 (rev 02) debian-2:~# lspci -n :02:03.0 0100: 1000:0050 (rev 02) Hi, I've tried to install that server with different mediums (inofficial amd64 sarge d-i, sarge i386 d-i, etch beta2 amd64, etch daily amd64) but none of them seems to support the SAS controller card Finally I was able to install the machine with hints from [0] and [1] I do not know for sure if the LSI drivers [3] are already part of official kernel. I'll try to figure that out by now. If more details are required feel free to contact me. [0] http://www.inserve.se/edu/debian/ [1] http://ioctl.org/unix/debian/x4100 [3] http://www.lsilogic.com/products/sas_ics/lsisas1064.html The lsilogic page mentions: * Supported by Fusion MPT drivers with full operating system support: * Windows(R) 2000, XP, Server 2003 * Linux(TM) * Solaris SPARC * SCO - UnixWare(TM) and Open Server * Novell(R) NetWare(R) I have no clue how much freedom there is that driver, if I understand it correct, then it is a MPT card, that should work. I suggest that you help / support making daily AMD64 d-i builds now you have an installed AMD64. Thank you for reporting the PCI ID of the card. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367634: Fwd: support for Symbios Logic 53c1030 PCI-X
Hello, We have received two requests for the inclusion of mpt* modules for AMD64 in Debian Installer. The first is listed below, the second is #367634. AFAICT mpt* modules should be included in the scsi-extra-modules as kernel-wedge defines them there. AFAIK mpt* should be available in 2.6.15 and thus in the current udebs. I noticed that in scsi-modules linux-kernel-amd64-2.6 the scsi-modules do not take the default set from kernel-wedge, but have a specific set. This seems illogical. Is there a specific reason for this? Could someone please look into this? Cheers, FJP -- Forwarded Message -- Subject: support for Symbios Logic 53c1030 PCI-X Date: Monday 15 May 2006 18:26 From: Radim Vocka [EMAIL PROTECTED] To: debian-boot@lists.debian.org Would it be possible to include the support for LSI Logic / Symbios Logic 53c1030 PCI-X Fusion-MPT Dual Ultra320 SCSI controler in the AMD64 etch installer? It seems the Fusion MPT device driver would be needed. Best regards Radim Vocka -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] --- pgpzMlOsl7ZIy.pgp Description: PGP signature
Re: graphics or text as default?
Il giorno mar, 16/05/2006 alle 19.11 +0200, chantra ha scritto: Hi, Even though I prefer the textual installer or even no installers ;) see http://www.debuntu.org/2006/05/14/51-how-to-installing-debian-etch-from-a-running-debian-based-system/ I reckon graphical as default is best. Why? Just because awared user will instantly look toward FXs menus, but a non-awared user, will simply not know what to do. A good alternative, will be to show a box with: 1.Install In Graph mode 2.Install in Text Mode Stefano Canepa wrote: Hi all, the CD images with both graphical and textual installer will run graphical as default? At my LUG when we explain the installation process to new users we present Mandriva and Debian and many users choise to install Mandriva just for it's graphical installer or better graphical partitioner. I do like the textual installer more but new users like clicking on menus. :) Regards sc I would have never imagine that my simple question about default installer would have result in so long discussion, I will think twice or more before asking questions to the list in the future ;) Bye Stefano -- Stefano Canepa aka sc: [EMAIL PROTECTED] http://www.stefanocanepa.it Three great virtues of a programmer: laziness, impatience and hubris. Le tre grandi virtù di un programmatore: pigrizia, impazienza e arroganza. (Larry Wall) signature.asc Description: Questa è una parte del messaggio firmata digitalmente
Bug#367402: software raid jfs
On Tuesday 16 May 2006 23:21, Karl Schmidt wrote: using the debian-testing-amd64-netinst.iso from may 13 Wiped disk and tried this one again - Dropped down into shell just before the grub install and chroot /target added backports to sources.list apt-get update apt-get install linux-image-2.6.15-1-amd64-k8 I don't get this. Why do you need backports if you are installing testing? If you selected a sarge mirror to install tasks after installing the base system from the netinst, you are doing something that is very much not supported (and the next beta release of the installer will no longer allow it). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367696: FTBFS: needs an update for 2.6.16
Package: linux-kernel-di-alpha-2.6 Version: 0.05 Severity: serious Can someone please update Alpha to 2.6.16. Automatic build of linux-kernel-di-alpha-2.6_0.05 on juist by sbuild/alpha 0.44 ... Checking for source dependency conflicts... Reading package lists... Building dependency tree... E: Couldn't find package linux-image-2.6.15-1-alpha-generic apt-get failed. Package installation failed Trying to reinstall removed packages: Trying to uninstall newly installed packages: Source-dependencies not satisfied; skipping linux-kernel-di-alpha-2.6 -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Persistent device names
On Wed, May 17, 2006 at 01:00:45AM +0200, Frans Pop wrote: To discuss this subject, I've still wanted to set up a discussion with at least Marco, you, Joey and Colin, but for different reasons have not gotten around to that. As I'll be on holiday for a few weeks after Debconf, let me at least list the issues that I've had in mind and that should be considered when implementing changes for persistent device naming. Please add to the list and comment. - We should like to keep support for devfs and regular device names in the installer; loosing that would mean no support for 2.2/2.4 installs (although those are likely to be dropped anyway) and no support for installs of Sarge and I think may be a problem for debian-edu. However, if it is unavoidable, we could drop this requirement. But do 2.4 and 2.2 not use traditional device names after booting into the installed system? - Are there likely to be architecture specific issues with persistent device naming? - Or with filesystems other than ext2/ext3? - Persistent device naming is mostly needed to get rid of errors on reboot. Most common case is where a system has multiple disk controllers and the order in which their drivers are loaded is different after the reboot than in d-i leading to a different order in device names. Yes, and it would also help with upcoming issues. For instance, the 2.6 kernels seem to move towards supporting ordinary (PATA) IDE via libata, meaning that hdaX devices would also become sdaX in the future. With persistent names this wouldn't be a problem. In addition, persistent names could be good for complex cases like root-on-lvm-on-crypto-on-md-on-disks. I've been considering whether it would be a good idea to introduce a new parameter (for initramfs-tools/yaird) specifying a comma-separated list of all devices needed to bring up the root dev. Something along the lines of rootdeps=/dev/sda1,/dev/sda2,/dev/mapper/mainvg-rootlv. Then the initramfs/initrd could do its best to bring up all those devices before trying to mount root via the persistent device. This would help with the complex scenarios... It wouldn't help with grub/lilo/etc though. Re, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367706: installation-reports
Package: installation-reports Boot method: Network Image version: 17-05-2006 www.debian.org (amd64 daily snapshot) Date: 17-05-2006 20:00 CET Machine: Noname Processor: AMD Athlon 64 3200+ Memory: 1 GB Partitions: Output of lspci and lspci -n: lspci :00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3) :00:01.0 ISA bridge: nVidia Corporation CK804 ISA Bridge (rev a3) :00:01.1 SMBus: nVidia Corporation CK804 SMBus (rev a2) :00:02.0 USB Controller: nVidia Corporation CK804 USB Controller (rev a2) :00:02.1 USB Controller: nVidia Corporation CK804 USB Controller (rev a3) :00:06.0 IDE interface: nVidia Corporation CK804 IDE (rev f2) :00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) :00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3) :00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2) :00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3) :00:0b.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) :00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) :00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) :00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3) :00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration :00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller :00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control :01:08.0 Network controller: RaLink Ralink RT2500 802.11 Cardbus Reference Card (rev 01) :01:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) :01:0d.0 Multimedia audio controller: Creative Labs SB Audigy LS :02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8053 Gigabit Ethernet Controller (rev 15) :03:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01) :05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600 GT] (rev a2) lspci -n :00:00.0 0580: 10de:005e (rev a3) :00:01.0 0601: 10de:0050 (rev a3) :00:01.1 0c05: 10de:0052 (rev a2) :00:02.0 0c03: 10de:005a (rev a2) :00:02.1 0c03: 10de:005b (rev a3) :00:06.0 0101: 10de:0053 (rev f2) :00:07.0 0101: 10de:0054 (rev f3) :00:08.0 0101: 10de:0055 (rev f3) :00:09.0 0604: 10de:005c (rev a2) :00:0a.0 0680: 10de:0057 (rev a3) :00:0b.0 0604: 10de:005d (rev a3) :00:0c.0 0604: 10de:005d (rev a3) :00:0d.0 0604: 10de:005d (rev a3) :00:0e.0 0604: 10de:005d (rev a3) :00:18.0 0600: 1022:1100 :00:18.1 0600: 1022:1101 :00:18.2 0600: 1022:1102 :00:18.3 0600: 1022:1103 :01:08.0 0280: 1814:0201 (rev 01) :01:0c.0 0c00: 1106:3044 (rev 46) :01:0d.0 0401: 1102:0007 :02:00.0 0200: 11ab:4362 (rev 15) :03:00.0 0180: 1095:3132 (rev 01) :05:00.0 0300: 10de:0140 (rev a2) Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Create file systems:[ ] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] Comments/Problems: Could not manually perform partitioning. I could see only /dev/sda as a whole disk but no partitions. I could create new partitions, but the old ones were not visible! I could not afford going from scratch while other OS was installed. Please see attached dmesg output. I tried to erase one partition, but did not help Kind regards, Bohdan ered TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 NET: Registered protocol family 8 NET: Registered protocol family 20 ACPI wakeup devices: HUB0 XVR0 XVR1 XVR2 XVR3 USB0 USB2 MMAC MMCI UAR1 ACPI: (supports S0 S1 S4 S5) RAMDISK: Compressed image found at block 0 VFS: Mounted root (ext2 filesystem). Freeing unused kernel memory: 148k freed ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt Link [APCF] enabled at IRQ 23 GSI 16 sharing vector 0xB1 and IRQ 16 ACPI: PCI Interrupt :00:02.0[A] - Link [APCF] - GSI 23 (level, low) - IRQ 16 PCI: Setting latency timer of device :00:02.0 to 64 ohci_hcd :00:02.0: OHCI Host Controller ohci_hcd :00:02.0: new USB bus registered, assigned bus number 1 ohci_hcd :00:02.0: irq 16, io mem 0xfe02f000 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ieee1394: Initialized config rom entry `ip1394' SCSI subsystem
Re: partman-crypto: dm-crypt status update
On Tue, May 16, 2006 at 07:56:53AM +0200, Frans Pop wrote: On Sunday 14 May 2006 21:59, David Härdeman wrote: The only known bug so far is that the /target filesystem isn't cleanly unmounted when it's on an encrypted partition. Any suggestions on where to start looking? Well, the installer just runs 'umount -a' in prebaseconfig's [1] 95umount script. I'd suggest you check that is actually where the error happens by adding a 'set -x' and maybe 'mount 2' before and after the umount to see what's happening. It may be a busybox issue. It is, running umount -a in a shell gives: ~ # umount -a BusyBox v1.1.2 (Debian 1:1.1.2-1) multi-call binary Usage: umount [flags] FILESYSTEM|DIRECTORY -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
improve choose language option
Hi, Just a small remarks about the choose language parts during the installation. I see that if I choose chinese or another asian language, I cannot read/understand the language list, if I validate the language. So why not keep the language list in english so if you made an error during your choice, you will be able to change the language instead of reboot your computer. Friendly, -- === ,''`. Xavier Oswald [EMAIL PROTECTED] : :' : GNU/LINUX Debian Debian-Edu Contributor `. `' GnuPG Key ID 0x88BBB51E `-938D D715 6915 8860 9679 4A0C A430 C6AA 88BB B51E === -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: distributed version control systems
On Wed, May 17, 2006 at 04:57:44PM +0200, Geert Stappers wrote: On Wed, May 17, 2006 at 07:53:48AM +0200, Sven Luther wrote: On Wed, May 17, 2006 at 12:18:28AM -0400, Albert Cahalan wrote: [ ... ] Both SVN and CVS have a server-centric model that ultimately leads to nasty poltics. The alternatives are git, Mercurial, and monotone. Another alternative is darcs ( http://abridgegame.org/darcs/ ) It does mean forking and fragmentation of the code base, which would not be best for d-i and debian. But yes, having a distributed revision system would be helpful in these cases, and if people don't come to their sense and this issue be solved, i will be left only to create a svk-based duplicate of the d-i svn repo, and make this one the authoritative version for the packages i upload or changes i make. Imagine the mess this will cause :) I do see the smilely, but I don't understand it. The Imagine the mess this cause makes me worry. Where will be the mess? Is it a threat? Nope. Imagine i upload a new nobootloader version, with some changes in it. I either upload it directly, without revision system, or with my own shadow copy of the d-i svn like above. Now, someone else needs to modify nobootloader. He is not aware of my changes, commits to the d-i svn, and uploads the package. My changes are lost. Next time i upload my changes, i may well not notice that there was another upload, and the other changes are lost. (Well, probably not, because i will have some svk based tool to merge those changes into my tree). So, we end up in a mess, because there is no more only a single authoritative (or even juste a single) copy of the repository for the package. This is the reason why i am arguing against the current proposal which doesn't restore my svn d-i access, and why i have not even tried to do any d-i work since then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: partman-crypto: dm-crypt status update
(No need to CC me; I read the list.) On Wednesday 17 May 2006 22:00, you wrote: It is, running umount -a in a shell gives: ~ # umount -a BusyBox v1.1.2 (Debian 1:1.1.2-1) multi-call binary Usage: umount [flags] FILESYSTEM|DIRECTORY Suggest you file a bug with severity serious about this against busybox. pgpPLGvT4nVy7.pgp Description: PGP signature
Re: libdebian-installer Packages support proposal
On Wed, May 17, 2006 at 02:47:37PM +0200, Geert Stappers wrote: On Wed, May 17, 2006 at 02:14:05AM +0200, Sven Luther wrote: On Tue, May 16, 2006 at 11:02:43PM +0200, Frans Pop wrote: On Tuesday 16 May 2006 19:59, Bastian Blank wrote: I'll implement that after the higher priority tasks (aka partman) are sorted out. As there was no response yes, I don't think anyone wants to help. Speaking only for myself of course, I still have your message on my TODO list. However, it is a fairly hard question with no simple answers and both being at Debconf and having to waste lots of time on the issues with Sven have resulted in my not having been able to really sit down for it. You are the only one who chose this course of action, that resulted in wasting so much time, for both you, me, the DPL, and i don't know how many innocent onlookers. I may be one of the innocent onlookers. On the other hand: I prefer to be part of the d-i team So I'm accused by Sven Luther of kicking out Sven Luther and I should demand an apology by Sven Luther in Sven Luther style. Oh, so you are the mysterious anonymous third guy, who felt, together with Frans and Joey, that they could no longer work on d-i if i was around ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#367194: FTBFS: missing build-depends on debhelper
Processing commands for [EMAIL PROTECTED]: tags 367194 pending Bug#367194: FTBFS: missing build-depends on debhelper Tags were: patch 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#367194: FTBFS: missing build-depends on debhelper
tags 367194 pending thanks As trivial at it looks, here is the patch that should fix the issue: Actually, I had commited a fix, but forgot to tag the bug accordingly. The fix completely changes Build-Depends-Indep in Build-Depends...because the dependency on po-debconf is needed as we run dh_installdebconf in the binary-arch target signature.asc Description: Digital signature
Bug#367714: busybox: umount -a not working
Package: busybox Version: 1:1.1.2-1 Severity: normal umount seems to have lost the -a option, which breaks unmounting the target fs in the final steps of debian-installer ~ # umount -a BusyBox v1.1.2 (Debian 1:1.1.2-1) multi-call binary Usage: umount [flags] FILESYSTEM|DIRECTORY See thread on debian-boot: http://lists.debian.org/debian-boot/2006/05/msg00714.html -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-rc1 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages busybox depends on: ii libc6 2.3.6-7GNU C Library: Shared libraries busybox recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Relocation errors in cdebconf plugins
On Wed, May 17, 2006 at 12:49:28AM -0500, Joey Hess wrote: I've committed a fix for this problem, the cdebconf plugin is included in the library reduction step and mlock is included in the reduced libc. This will be in the next daily build. Thanks Joey. I will try to come up with a description of the problem and pointer to EXTRAUDEBS that we can add to doc/plugins.txt. I haven't had time yet to check RTLD_NOW, but hope to find time to look into it this weekend. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: D-I-internals workshop at Debconf
Hi Frans On Wed, May 17, 2006 at 01:21:09AM +0200, Frans Pop wrote: I'll be giving a workshop explaining the technical side of the installer on Thursday 18-5 from 20:20 - 22:00 UTC (if my timezone calculations are correct). The paper that goes with the workshop is available at: http://people.debian.org/~fjp/talks/debconf6 A few remarks: * loading additional components — expanding the installer to its full functionality) ( is missing * I wonder about the mini.iso installation method. Never heard of it, found also no reference to it on http://www.debian.org/devel/debian-installer/. Ah, it's mentioned later in chapter 3 again. Maybe refer to this in a footnote! * -The relaxed policy requirements make one of the reasons that udebs should to be installed on a normal system. +The relaxed policy requirements are one of the reasons that udebs should *not* be installed on a normal system. * -Note the special section. +Note the special debian-installer section. Or do you refer to something different? Is is sometimes useful to use only one of Section: debian-installer XC-Package-Type: udeb? * You use both Sarge (capitalised) and sid notation! I suggest to link to this document from somewhere below www.debian.org/devel/debian-installer/. Maybe you should create a new page for developer documentation which contains useful links. Jens -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[g-i] Dejavu as default font
I just applied the necessary changes needed to make ttf-dejavu the default font for the graphical installer. The tests I run recently got debconf to just crash if dejavu was used as default font, and I don't actually know what fixed it. The change will take effect as soon as a new version of rootskel-gtk will be uploaded and available in the archives. regards, Davide signature.asc Description: Digital signature
Re: removing 2.4 from etch/sid
On Wednesday 17 May 2006 22:12, Thiemo Seufer wrote: It will AFAICS break all remaining d-i with 2.4 because those try to install a 2.4 kernel from testing by default. Yes, installs will break to some degree. If no 2.4 kernel is available, d-i will display a list of other available kernels (probably 2.6). However, crossinstalling kernel versions (i.e. installing running 2.4 setting up target with 2.6) is not really supported. It will probably lead to errors and at least some packages incorrectly installed or missing. Full CD installs are of course not affected. IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Full CD installations using that release could then still install 2.4 and we could set completing switches to 2.6 as the main goal for d-i Etch RC1. I could also understand if m68k would keep a 2.4 kernel for a while longer. As it is not a release arch, it might be acceptable for release managers to keep a m68k 2.4 kernel in testing/unstable. 2.2 should probably be dropped completely. Whether we will be able to keep 2.4 support in d-i if all other architectures have dropped it is uncertain though [1]. Cheers, FJP [1] This depends mainly on changes needed to support persistent device naming in d-i which is very much needed for Etch. pgpbqCR2TbByH.pgp Description: PGP signature
Processed: severity of 367714 is serious, reassign 367714 to busybox-udeb
Processing commands for [EMAIL PROTECTED]: # Automatically generated email from bts, devscripts version 2.9.20 severity 367714 serious Bug#367714: busybox: umount -a not working Severity set to `serious' from `normal' reassign 367714 busybox-udeb Bug#367714: busybox: umount -a not working Bug reassigned from package `busybox' to `busybox-udeb'. End of message, 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]
rootskel-gtk_0.07_i386.changes ACCEPTED
Accepted: rootskel-gtk_0.07.dsc to pool/main/r/rootskel-gtk/rootskel-gtk_0.07.dsc rootskel-gtk_0.07.tar.gz to pool/main/r/rootskel-gtk/rootskel-gtk_0.07.tar.gz rootskel-gtk_0.07_i386.udeb to pool/main/r/rootskel-gtk/rootskel-gtk_0.07_i386.udeb Announcing to debian-devel-changes@lists.debian.org Closing bugs: 363661 Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: removing 2.4 from etch/sid
On Thu, May 18, 2006 at 12:24:57AM +0200, Frans Pop wrote: I could also understand if m68k would keep a 2.4 kernel for a while longer. As it is not a release arch, it might be acceptable for release managers to keep a m68k 2.4 kernel in testing/unstable. 2.2 should probably be dropped completely. Whether we will be able to keep 2.4 support in d-i if all other architectures have dropped it is uncertain though [1]. The m68k porters just had a discussion about this and we're fine with whatever ya'll decide to do. We can always keep some unofficial kernels and installers around if necessary. In other words, don't worry about holding on to any kernels just for us. I hope to keep some 2.4 and 2.2 support in d-i until we get everything moved, but I'll try to keep it out of the way or in a branch. -- Stephen R. Marenka If life's not fun, you're not doing it right! [EMAIL PROTECTED] signature.asc Description: Digital signature
Re: removing 2.4 from etch/sid
Frans Pop wrote: [snip] IMO the question whether 2.4 should be removed now and if so for which architectures is something to be decided between the kernel team and porters. If a porter needs more time to switch to 2.6 for the installer, he should probably come up with a migration plan and timeline. Purely from a d-i release management point of view, it would be nice if the removal of 2.4 could be delayed until just after the next beta release. The release date for that depends on the progress of AMD64 archive migration (it is not yet installable from testing). Switching d-i reqires stable kernels for all subarchitectures, those are now mostly done for mips/mipsel. I hope we complete the move to 2.6 in 3-6 weeks. Thiemo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#363661: marked as done (Add kfreebsd-i386 and kfreebsd-amd64 in a few Architecture fields)
Your message dated Wed, 17 May 2006 16:17:13 -0700
with message-id [EMAIL PROTECTED]
and subject line Bug#363661: fixed in rootskel-gtk 0.07
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: debian-installer
Severity: important
Tags: patch
Hi,
This patch adds kfreebsd-i386 and kfreebsd-amd64 in a few Architecture (and
Build-Depends) fields of installer and packages where these arches were missing.
-- System Information:
Debian Release: testing/unstable
Architecture: kfreebsd-i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: GNU/kFreeBSD 5.4-1-686
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ANSI_X3.4-1968) (ignored: LC_ALL
set to C)
Index: installer/debian/control
===
--- installer/debian/control(revision 36546)
+++ installer/debian/control(working copy)
@@ -6,7 +6,7 @@
Standards-Version: 3.6.2
Build-Conflicts: libnewt-pic [mipsel]
# NOTE: Do not edit the next line by hand. See comment below.
-Build-Depends: debhelper (= 4), apt, apt-utils, gnupg,
debian-archive-keyring, dpkg (= 1.13.9), grep-dctrl, bc, debiandoc-sgml,
libbogl-dev, glibc-pic, libparted1.6-13, libslang2-pic, libnewt-pic [!mipsel],
libnewt-dev [mipsel], libtextwrap1, libvolume-id0, cramfsprogs [powerpc ia64
mips mipsel arm armeb], genext2fs (= 1.3-7.1), e2fsprogs, mklibs (= 0.1.15),
mkisofs, genromfs [sparc], hfsutils [powerpc], dosfstools [i386 ia64 m68k
amd64], cpio, devio [arm armeb], syslinux (= 2.11-0.1) [i386 amd64], palo
[hppa], elilo [ia64], yaboot [powerpc], aboot (= 0.9b-2) [alpha], silo
[sparc], sparc-utils [sparc], genisovh [mips], delo [mipsel], tip22 [mips],
colo (= 1.21-1) [mipsel], sibyl [mips mipsel], atari-bootstrap [m68k], vmelilo
[m68k], m68k-vme-tftplilo [m68k], amiboot [m68k], tofrodos [i386 amd64], mtools
(= 3.9.9-1) [i386 ia64 m68k amd64], modutils [arm i386 mips mipsel powerpc
s390 sparc], module-init-tools [i386 powerpc amd64 alpha hppa ia64 sparc mips
mipsel arm armeb], bf-utf-source [!s390 !s390x], upx-ucl-beta (=
1:1.91+0.20030910cvs-2) [i386], mkvmlinuz [powerpc]
+Build-Depends: debhelper (= 4), apt, apt-utils, gnupg,
debian-archive-keyring, dpkg (= 1.13.9), grep-dctrl, bc, debiandoc-sgml,
libbogl-dev [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386], glibc-pic,
libparted1.6-13, libslang2-pic, libnewt-pic [!mipsel], libnewt-dev [mipsel],
libtextwrap1, libvolume-id0 [!kfreebsd-i386 !kfreebsd-amd64 !hurd-i386],
cramfsprogs [powerpc ia64 mips mipsel arm armeb], genext2fs (= 1.3-7.1),
e2fsprogs, mklibs (= 0.1.15), mkisofs, genromfs [sparc], hfsutils [powerpc],
dosfstools [i386 ia64 m68k amd64], cpio, devio [arm armeb], syslinux (=
2.11-0.1) [i386 amd64], palo [hppa], elilo [ia64], yaboot [powerpc], aboot (=
0.9b-2) [alpha], silo [sparc], sparc-utils [sparc], genisovh [mips], delo
[mipsel], tip22 [mips], colo (= 1.21-1) [mipsel], sibyl [mips mipsel],
atari-bootstrap [m68k], vmelilo [m68k], m68k-vme-tftplilo [m68k], amiboot
[m68k], tofrodos [i386 kfreebsd-i386 amd64 kfreebsd-amd64], mtools (= 3.9.9-1)
[i386 kfreebsd-i386 ia64 m68k amd64 kfreebsd-amd64], modutils [arm i386 mips
mipsel powerpc s390 sparc], module-init-tools [i386 powerpc amd64 alpha hppa
ia64 sparc mips mipsel arm armeb], bf-utf-source [!s390 !s390x], upx-ucl-beta
(= 1:1.91+0.20030910cvs-2) [i386], mkvmlinuz [powerpc]
# This package has the worst Build-Depends in Debian, so it deserves some
# explanation. Note that this comment can also be used to generate a
# Build-Depends line, by running the debian/genbuilddeps program.
Index: packages/arch/i386/grub-installer/debian/control
===
--- packages/arch/i386/grub-installer/debian/control(revision 36546)
+++ packages/arch/i386/grub-installer/debian/control(working copy)
@@ -7,7 +7,7 @@
Standards-Version: 3.6.1
Package: grub-installer
-Architecture: i386 hurd-i386 amd64
+Architecture: i386 hurd-i386 kfreebsd-i386 amd64 kfreebsd-amd64
Provides: bootable-system
Depends: cdebconf-udeb, kernel-installer, created-fstab, di-utils (= 1.15),
di-utils-mapdevfs, os-prober, ${dmidecode}
XB-Installer-Menu-Item: 73
Index: packages/rootskel-gtk/debian/control
===
--- packages/rootskel-gtk/debian/control(revision 36546)
+++ packages/rootskel-gtk/debian/control(working copy)
@@ -7,6 +7,6 @@
Package: rootskel-gtk
XC-Package-Type: udeb
-Architecture: alpha amd64 arm hppa i386
Processing of cdrom-detect_1.14_i386.changes
cdrom-detect_1.14_i386.changes uploaded successfully to localhost along with the files: cdrom-detect_1.14.dsc cdrom-detect_1.14.tar.gz cdrom-detect_1.14_all.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cdrom-detect_1.14_i386.changes ACCEPTED
Accepted: cdrom-detect_1.14.dsc to pool/main/c/cdrom-detect/cdrom-detect_1.14.dsc cdrom-detect_1.14.tar.gz to pool/main/c/cdrom-detect/cdrom-detect_1.14.tar.gz cdrom-detect_1.14_all.udeb to pool/main/c/cdrom-detect/cdrom-detect_1.14_all.udeb Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367402: software raid jfs
On Thursday 18 May 2006 02:12, you wrote: Frans Pop wrote: On Tuesday 16 May 2006 23:21, Karl Schmidt wrote: using the debian-testing-amd64-netinst.iso from may 13 Wiped disk and tried this one again - Dropped down into shell just before the grub install and chroot /target added backports to sources.list apt-get update apt-get install linux-image-2.6.15-1-amd64-k8 I don't get this. Why do you need backports if you are installing testing? Because I think there is a problem with the drivers that might be fixed in a later kernel. There is what appears as massive file corruption soon after an normal testing install. (my hunch is the SATA II drivers or in forcedeth). It could be jfs or software raid - but my money is on the new hardware and new drivers. This is a Tyan S2865 (I think the Tyan S2877 has the same problems) with a nForce 4 ultra chip set. There is also a driver problem with the second Ethernet on this motherboard - but I can live with that for now. If you selected a sarge mirror to install tasks after installing the base system from the netinst, you are doing something that is very much not supported (and the next beta release of the installer will no longer allow it). I did it from the command line after the base install and before grub. If there is no command line it will keep people from working around many other problems. It is still not supported to do things that way. Better just install Etch. Or use a proper backported (but unofficial) installation image like: http://kmuto.jp/b.cgi/debian/d-i-2615.htm Is there anywhere you can point me to see a mailing list or the change log on the drivers for the nForce 4 ultra chip set? No, sorry. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] Proposal for installs without network connection
I've committed the needed changes for this in apt-setup. Code has been tested and seems to work. This includes a new template for which I'd appreciate a review before I make it translatable. I've also uploaded a new version of cdrom-detect that makes sure apt-mirror-setup is installed; this also brings the code in line with iso-scan again. Template: apt-setup/use_mirror Type: boolean Default: true Description: Use network mirror? The next step of the installation will be to install additional packages based on tasks. As you are installing from CD-ROM, you have the option to use a network mirror as source to retrieve packages in addition to those available on the CD-ROM. . If you are installing from a netinst CD and you choose not to use a mirror, you will end up with only a very minimal base system. . If you choose to also use a mirror and a package is available both on the CD-ROM and on the mirror, the installer will only retrieve it from the mirror if the version of the package on the mirror is more recent than the one included on the CD-ROM. On Tuesday 18 April 2006 21:45, Joey Hess wrote: Good so far, my only quibble is that cdrom/base_installable is kind of a not very useful abstraction over /cdrom/.disk/base_installable. I have been thinking about that. The advantage of using it is that you only need to read it once and can then forget about worrying if the CD is still inserted or even random read errors. I've not implemented it for now though. 5) Add following functionality in apt-setup postinst if cdrom/base_installable is true: - copy debconf values for suite and codename from cdrom/ to mirror/ - ask new question (with a nice explanation in its description): a) use both normal mirror and mirror for security updates b) use only mirror for security updates c) don't use network mirrors a. and b. seem confusible to me, could it be reduced to a boolean that just asks if it wants to use a mirror? IMHO we can leave security updates out of this; if there's a network the only sane action is to add the security sources. OK. Implemented like that. pgp2ubAqG27Ti.pgp Description: PGP signature
Bug#367783: busybox-udeb: segfaults on 'tr'
Package: busybox-udeb Version: 1:1.1.2-1 Severity: critical # echo Create | tr '[A-Z]' '[a-z]' Segmentation fault pgpreORsR7WnY.pgp Description: PGP signature
Bug#64571: is it me you looking for?
Do not bignore me please, I found your email somewhere and now decibded ato write you. I am coming to your place in few weeks and thbaought we can meet each other. Let me know if you do naot mind. I am a nice pretty giral. Don't reply to this email. Email me direclty at [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Write Access to repository for translate
Hi, Team. I'm translating D-I manual to Japanese. The translated files had been committed to kmuto up to now. (Thanks kmuto!) However, I think that I should be commit myself. Could you add me to commiter for translating D-I manual? My alioth's account is 'nabetaro-guest'. Regards. -- ++ KURASAWA Nozomu (nabetaro) nabetaro @ caldron.jp GnuPG FingerPrint: C4E5 7063 FD75 02EB E71D 559B ECF6 B9D2 8147 ADFB ++ pgpqL0RJbQSZS.pgp Description: PGP signature
Re: Write Access to repository for translate
On Thursday 18 May 2006 03:27, [EMAIL PROTECTED] wrote: I'm translating D-I manual to Japanese. The translated files had been committed to kmuto up to now. (Thanks kmuto!) However, I think that I should be commit myself. Could you add me to commiter for translating D-I manual? My alioth's account is 'nabetaro-guest'. I have no problems with that, but would like to receive an OK on the request from Kenshi. pgpsdYFJgZmK0.pgp Description: PGP signature
Re: improve choose language option
On Wednesday 17 May 2006 21:33, Xavier Oswald wrote: I see that if I choose chinese or another asian language, I cannot read/understand the language list, if I validate the language. I have no idea what you mean here. The language list in localechooser _always_ shows both the English name of the language (first column) and the translated name (second column). If you see anything different, please tell us exactly which image you are using and provide a link to a screenshot. pgpOcOGgOo9gA.pgp Description: PGP signature
Re: Quem te admira muito;;;;
Your message was not posted to the debian-security-announce mailing list. It has instead been forwarded to the security team and the listmaster team. The debian-security-announce list is a moderated mailing list on which security-related announcements are made by the security team for Debian GNU/Linux. Here are the email addresses that you should contact about security-related questions with Debian: * [EMAIL PROTECTED] will reach only the security team * [EMAIL PROTECTED] will reach most Debian developers * [EMAIL PROTECTED] will reach only the security team If you simply want to subscribe to the debian-security-announce list, please send an email to [EMAIL PROTECTED] with a subject of subscribe, and follow the procedure you'll receive. -- Thanks, Debian Security Officers -- apt-get: deb http://security.debian.org/ stable/updates main dpkg-ftp: ftp://security.debian.org/debian-security dists/stable/updates/main Mailing list: debian-security-announce@lists.debian.org Package info: `apt-cache show pkg' and http://packages.debian.org/pkg -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Quem te admira muito;;;;
General info Subscription/unsubscription/info requests should always be sent to the -request address of a mailing list. If a mailing list is called for example [EMAIL PROTECTED], then the -request address can be inferred from this to be: [EMAIL PROTECTED]. To subscribe to a mailing list, simply send a message with the word subscribe in the Subject: field to the -request address of that list. To unsubscribe from a mailing list, simply send a message with the word (you guessed it :-) unsubscribe in the Subject: field to the -request address of that list. In the event of an address change, it would probably be the wisest to first send an unsubscribe for the old address (this can be done from the new address), and then a new subscribe to the new address (the order is important). Most (un)subscription requests are processed automatically without human intervention. Do not send multiple (un)subscription or info requests in one mail. Only one will be processed per mail. NOTE: The -request server usually does quite a good job in discriminating between (un)subscribe requests and messages intended for the maintainer. If you'd like to make sure a human reads your message, make it look like a reply (i.e. the first word in the Subject: field should be Re:, without the quotes of course); the -request server does not react to replies. The archive server -- Every submission sent to this list is archived. The size of the archive depends on the limits set by the list maintainer (it is very well possible that only, say, the last two mails sent to the list are still archived, the rest might have expired). You can look at the header of every mail coming from this list to see under what name it has been archived. The X-Mailing-List: field contains the mailaddress of the list and the file in which this submission was archived. If you want to access this archive, you have to send mails to the -request address with the word archive as the first word of your Subject:. To get you started try sending a mail to the -request address with the following: Subject: archive help The listmaster -- To reach a human being answering your mail you may contact the address [EMAIL PROTECTED] We will process your request as soon as we can. Mail sent to this address is pre-parsed, a little mail robot will automatically answer all mails sent with the following Subject lines: help sends this help lists sends information on how to get a list of mailing lists -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] Proposal for installs without network connection
Quoting Frans Pop ([EMAIL PROTECTED]): Template: apt-setup/use_mirror Type: boolean Default: true Description: Use network mirror? The next step of the installation will be to install additional packages based on tasks. As you are installing from CD-ROM, you have the option to from a CD-ROM use a network mirror as source to retrieve packages in addition to those available on the CD-ROM. . If you are installing from a netinst CD and you choose not to use a mirror, you will end up with only a very minimal base system. . If you choose to also use a mirror and a package is available both on the CD-ROM and on the mirror, the installer will only retrieve it from the it will be retrieved from the mirror I find the template a bit verbose and maybe hard to translate and fit in one screenmaybe simplify the entire last paragraph. signature.asc Description: Digital signature
Re: [G-I] Udeb dependency resolution issue resolved!
On 5/14/06, Davide Viti [EMAIL PROTECTED] wrote: - as far as fonts are concerned, current g-i covers all the languages supported by the installer, including the latest Thai and Dzongkha. I haved finally tried the daily image, after I found an alternative machine, since the g-i failed to start framebuffer on my i830 video card. Thai looks very nice on the installer. I imagine this new installer will introduce Debian to Thai users in a most friendly way ever. Thank you for your great jobs! Regards, -- Theppitak Karoonboonyanan http://linux.thai.net/~thep/
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
Hello Frans, could you stop using debian-release for the purpose of bashing Sven Luther ? As far as my understanding goes, Frans is not the one who expanded the CC list. In short, faudrait peut-être pas trop déconner, quand même. signature.asc Description: Digital signature
Processed: patch for partman_server
Processing commands for [EMAIL PROTECTED]: reassign 270136 partman-base Bug#270136: aparted_server.pid handling is not robust Bug reassigned from package `partman' to `partman-base'. tag 270136 + patch Bug#270136: aparted_server.pid handling is not robust There were no tags set. Tags added: patch 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#270136: patch for partman_server
reassign 270136 partman-base
tag 270136 + patch
thanks
Patch attached to make this behaviour a bit more robust (I hope).
Mark
--
Mark Hymers [EMAIL PROTECTED]
But Yossarian *still* didn't understand either how Milo could buy eggs
in Malta for seven cents apiece and sell them at a profit in Pianosa
for five cents.
Catch 22, Joseph Heller
Index: debian/changelog
===
--- debian/changelog(revision 37382)
+++ debian/changelog(working copy)
@@ -1,3 +1,9 @@
+partman-base (83) unstable; urgency=low
+
+ * Add more robust pid file and fifo handling. Closes: #270136.
+
+ -- Mark Hymers [EMAIL PROTECTED] Thu, 18 May 2006 03:37:26 +0100
+
partman-base (82) unstable; urgency=low
[ Frans Pop ]
Index: definitions.sh
===
--- definitions.sh (revision 37382)
+++ definitions.sh (working copy)
@@ -255,8 +255,6 @@
open_infifo
write_line QUIT
close_infifo
-
-rm /var/run/parted_server.pid
}
# Must call stop_parted_server before calling this.
Index: init.d/parted
===
--- init.d/parted (revision 37382)
+++ init.d/parted (working copy)
@@ -5,12 +5,13 @@
. /lib/partman/definitions.sh
if [ ! -f /var/run/parted_server.pid ]; then
-mknod /var/lib/partman/infifo p /dev/null 2/dev/null || true
-mknod /var/lib/partman/outfifo p /dev/null 2/dev/null || true
-mknod /var/lib/partman/stopfifo p /dev/null 2/dev/null || true
[ -d /var/run ] || mkdir /var/run
-parted_server
-echo $! /var/run/parted_server.pid
+parted_server
+RET=$?
+if [ $RET != 0 ]; then
+# TODO: How do we signal we couldn't start partman_server properly?
+exit $RET
+fi
if [ -d /var/lib/partman/old_devices ]; then
rm -rf /var/lib/partman/old_devices
Index: parted_server.c
===
--- parted_server.c (revision 37382)
+++ parted_server.c (working copy)
@@ -8,11 +8,20 @@
#include errno.h
#include stdbool.h
#include ctype.h
+#include signal.h
/**
Logging
**/
+/* This file is used as pid-file. */
+char pidfile_name[] = /var/run/parted_server.pid;
+
+/* These are the communication fifos */
+char infifo_name[] = /var/lib/partman/infifo;
+char outfifo_name[] = /var/lib/partman/outfifo;
+char stopfifo_name[] = /var/lib/partman/stopfifo;
+
/* This file is used as log-file. */
char logfile_name[] = /var/log/partman;
@@ -2053,6 +2062,91 @@
activate_exception_handler();
}
+void
+make_fifo(char* name)
+{
+int status;
+status = mkfifo(name, 0x644);
+if ((status != 0))
+if (errno != EEXIST) {
+perror(Cannot create FIFO);
+exit(252);
+}
+}
+
+void
+make_fifos()
+{
+make_fifo(infifo_name);
+make_fifo(outfifo_name);
+make_fifo(stopfifo_name);
+}
+
+int
+write_pid_file()
+{
+FILE *fd;
+int status;
+pid_t oldpid;
+if ((fd = fopen(pidfile_name, a+)) == NULL)
+return -1;
+
+if (!feof(fd)) {
+status = fscanf(fd, %d, oldpid);
+if (status != 0) {
+// If kill(oldpid, 0) == 0 the process is still alive
+// so we abort
+if (kill(oldpid, 0) == 0) {
+fprintf(stderr, Not starting: process %d
still exists\n, oldpid);
+fclose(fd);
+exit(250);
+}
+}
+// Truncate the pid file and continue
+freopen(pidfile_name, w, fd);
+}
+
+fprintf(fd, %d, (int)(getpid()));
+fclose(fd);
+return 0;
+}
+
+void
+cleanup_and_die()
+{
+if (unlink(pidfile_name) != 0)
+perror(Cannot unlink pid file);
+if (unlink(infifo_name) != 0)
+perror(Cannot unlink input FIFO);
+if (unlink(outfifo_name) != 0)
+perror(Cannot unlink output FIFO);
+if (unlink(stopfifo_name) != 0)
+perror(Cannot unlink stop FIFO);
+}
+
+void
+prnt_sig_hdlr(int signal)
+{
+int status;
+switch(signal) {
+// SIGUSR1 signals that child is ready to take
+// requests (i.e. has finished initialisation)
+case SIGUSR1:
+exit(0);
+break;
+// We'll only get SIGCHLD if our child has pre-deceased us
+// In this case we should exit with its error code
+case SIGCHLD:
+if (waitpid(-1, status, WNOHANG) 0)
Bug#367798: installation-reports
Package: installation-reports
INSTALL REPORT
Debian-installer-version: 15-05-2006
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
uname -a: Linux ms4tr3 2.6.16-1-amd64-generic #2 Thu May 4 18:19:05
CEST 2006 x86_64 GNU/Linux Date: 15 May 2006
Method: How did you install? What did you boot off? If network
install, from where? Proxied?
Machine: Self-builded machine. ASUS K8N-E Deluxe NVIDIA nForce3.
Processor: AMD64 3000+
Memory: 512MB
Root Device: Western Digital 40GB UDMA100
Root Size/partition table:
% df -h /dev/hda*
FilesystemSize Used Avail Use% Mounted on
/dev/hda5 7.1G 1.6G 5.2G 24% /
/dev/hda6 9.2G 5.4G 3.4G 63% /home
NB: I reinstalled my desktop environment + my servers from i686 to AMD64
Output of lspci and lspci -n:
# lspci
:00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge
(rev a1) :00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC
Bridge (rev a2) :00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI
System Management (rev a1) :00:02.0 USB Controller: nVidia
Corporation CK8S USB Controller (rev a1) :00:02.1 USB Controller:
nVidia Corporation CK8S USB Controller (rev a1) :00:02.2 USB
Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev a2)
:00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev
a2) :00:06.0 Multimedia audio controller: nVidia Corporation
nForce3 250Gb AC'97 Audio Controller (rev a1) :00:08.0 IDE
interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5) (rev
a2) :00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA
Controller (v2.5) (rev a2) :00:0b.0 PCI bridge: nVidia Corporation
nForce3 250Gb AGP Host to PCI Bridge (rev a2) :00:0e.0 PCI bridge:
nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)
:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration :00:18.1
Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address
Map :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller :00:18.3 Host bridge: Advanced
Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
:01:00.0 VGA compatible controller: ATI Technologies Inc RV280
[Radeon 9200] (rev 01) :01:00.1 Display controller: ATI
Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01) :02:09.0
Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10) :02:0b.0 FireWire (IEEE 1394): VIA
Technologies, Inc. IEEE 1394 Host Controller (rev 80) :02:0c.0 RAID
bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial
ATA Controller (rev 02) # lspci -n :00:00.0 0600: 10de:00e1 (rev
a1) :00:01.0 0601: 10de:00e0 (rev a2) :00:01.1 0c05: 10de:00e4
(rev a1) :00:02.0 0c03: 10de:00e7 (rev a1) :00:02.1 0c03:
10de:00e7 (rev a1) :00:02.2 0c03: 10de:00e8 (rev a2) :00:05.0
0680: 10de:00df (rev a2) :00:06.0 0401: 10de:00ea (rev a1)
:00:08.0 0101: 10de:00e5 (rev a2) :00:0a.0 0101: 10de:00e3 (rev
a2) :00:0b.0 0604: 10de:00e2 (rev a2) :00:0e.0 0604: 10de:00ed
(rev a2) :00:18.0 0600: 1022:1100 :00:18.1 0600: 1022:1101
:00:18.2 0600: 1022:1102
:00:18.3 0600: 1022:1103
:01:00.0 0300: 1002:5961 (rev 01)
:01:00.1 0380: 1002:5941 (rev 01)
:02:09.0 0200: 10ec:8139 (rev 10)
:02:0b.0 0c00: 1106:3044 (rev 80)
:02:0c.0 0104: 1095:3114 (rev 02)
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot worked:[O]
Configure network HW: [O]
Config network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives: [O]
Create file systems:[O]
Mount partitions: [O]
Install base system:[O]
Install boot loader:[O]
Reboot: [O]
Comments/Problems:
It was fine ;)
--
http://massonnet.org/ Mike Massonnet (mmassonnet) ,-.
, ( {o\
GnuPG 0-- 0xF8C80F97 {`=,___) (`~
C4DA 431D 52F9 F930 3E5B 3E3D 546C 89D9 F8C8 0F97 \ ,_.- )
signature.asc
Description: PGP signature
Re: Write Access to repository for translate
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Frans and Nozomu, At 18 May 06 01:53:02 GMT, Frans Pop wrote: On Thursday 18 May 2006 03:27, [EMAIL PROTECTED] wrote: I'm translating D-I manual to Japanese. The translated files had been committed to kmuto up to now. (Thanks kmuto!) I have no problems with that, but would like to receive an OK on the request from Kenshi. Yes, Nozomu has already worked as a dedicated translator. Please add him. Thanks, - -- Kenshi Muto [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) Comment: Processed by Mailcrypt 3.5.8+ http://mailcrypt.sourceforge.net/ iEYEARECAAYFAkRr6csACgkQQKW+7XLQPLEvjACeOMTuSFocNZ8NLmJEcWftT5yh FXkAoJmr2zZXJVlM+yBg/VpsLr8J/R/l =/wyY -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#367798: marked as done (installation-reports)
Your message dated Thu, 18 May 2006 06:05:10 +0200
with message-id [EMAIL PROTECTED]
and subject line Bug#367798: installation-reports
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
INSTALL REPORT
Debian-installer-version: 15-05-2006
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
uname -a: Linux ms4tr3 2.6.16-1-amd64-generic #2 Thu May 4 18:19:05
CEST 2006 x86_64 GNU/Linux Date: 15 May 2006
Method: How did you install? What did you boot off? If network
install, from where? Proxied?
Machine: Self-builded machine. ASUS K8N-E Deluxe NVIDIA nForce3.
Processor: AMD64 3000+
Memory: 512MB
Root Device: Western Digital 40GB UDMA100
Root Size/partition table:
% df -h /dev/hda*
FilesystemSize Used Avail Use% Mounted on
/dev/hda5 7.1G 1.6G 5.2G 24% /
/dev/hda6 9.2G 5.4G 3.4G 63% /home
NB: I reinstalled my desktop environment + my servers from i686 to AMD64
Output of lspci and lspci -n:
# lspci
:00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge
(rev a1) :00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC
Bridge (rev a2) :00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI
System Management (rev a1) :00:02.0 USB Controller: nVidia
Corporation CK8S USB Controller (rev a1) :00:02.1 USB Controller:
nVidia Corporation CK8S USB Controller (rev a1) :00:02.2 USB
Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev a2)
:00:05.0 Bridge: nVidia Corporation CK8S Ethernet Controller (rev
a2) :00:06.0 Multimedia audio controller: nVidia Corporation
nForce3 250Gb AC'97 Audio Controller (rev a1) :00:08.0 IDE
interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5) (rev
a2) :00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA
Controller (v2.5) (rev a2) :00:0b.0 PCI bridge: nVidia Corporation
nForce3 250Gb AGP Host to PCI Bridge (rev a2) :00:0e.0 PCI bridge:
nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)
:00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration :00:18.1
Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address
Map :00:18.2 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] DRAM Controller :00:18.3 Host bridge: Advanced
Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
:01:00.0 VGA compatible controller: ATI Technologies Inc RV280
[Radeon 9200] (rev 01) :01:00.1 Display controller: ATI
Technologies Inc RV280 [Radeon 9200] (Secondary) (rev 01) :02:09.0
Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10) :02:0b.0 FireWire (IEEE 1394): VIA
Technologies, Inc. IEEE 1394 Host Controller (rev 80) :02:0c.0 RAID
bus controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial
ATA Controller (rev 02) # lspci -n :00:00.0 0600: 10de:00e1 (rev
a1) :00:01.0 0601: 10de:00e0 (rev a2) :00:01.1 0c05: 10de:00e4
(rev a1) :00:02.0 0c03: 10de:00e7 (rev a1) :00:02.1 0c03:
10de:00e7 (rev a1) :00:02.2 0c03: 10de:00e8 (rev a2) :00:05.0
0680: 10de:00df (rev a2) :00:06.0 0401: 10de:00ea (rev a1)
:00:08.0 0101: 10de:00e5 (rev a2) :00:0a.0 0101: 10de:00e3 (rev
a2) :00:0b.0 0604: 10de:00e2 (rev a2) :00:0e.0 0604: 10de:00ed
(rev a2) :00:18.0 0600: 1022:1100 :00:18.1 0600: 1022:1101
:00:18.2 0600: 1022:1102
:00:18.3 0600: 1022:1103
:01:00.0 0300: 1002:5961 (rev 01)
:01:00.1 0380: 1002:5941 (rev 01)
:02:09.0 0200: 10ec:8139 (rev 10)
:02:0b.0 0c00: 1106:3044 (rev 80)
:02:0c.0 0104: 1095:3114 (rev 02)
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot worked:[O]
Configure network HW: [O]
Config network: [O]
Detect CD: [O]
Load installer modules: [O]
Detect hard drives: [O]
Partition hard drives: [O]
Create file systems:[O]
Mount partitions: [O]
Install base system:[O]
Install boot loader:[O]
Reboot: [O]
Comments/Problems:
It was fine ;)
--
http://massonnet.org/ Mike Massonnet (mmassonnet) ,-.
, ( {o\
GnuPG 0-- 0xF8C80F97 {`=,___) (`~
C4DA 431D 52F9 F930 3E5B 3E3D 546C 89D9 F8C8 0F97 \ ,_.- )
signature.asc
Description: PGP signature
Bug#64570: respect of all
Hey buddy, Are you stuck in a job that is leading you on the path to no where? Do you wish you could better your financial situtation? We can help you obtain a College Degree with classes, books, and exams from a reputable Univ, transcripts included. Call me anytime at 1 - 206 - 350 - 3737 for detailed information. Regards, Trina Admission Office -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: r37385 - in trunk/packages/apt-setup: .
Frans Pop wrote: Modified: trunk/packages/apt-setup/apt-setup == --- trunk/packages/apt-setup/apt-setup(original) +++ trunk/packages/apt-setup/apt-setupWed May 17 22:44:39 2006 @@ -25,6 +25,39 @@ log warning: $@ } +if [ -e /cdrom/.disk/base_installable ]; then + if db_get cdrom/codename [ $RET ]; then + db_set mirror/codename $RET + fi + if db_get cdrom/suite [ $RET ]; then + db_set mirror/suite $RET + fi + + db_input high apt-setup/use_mirror + db_go + if [ $? -eq 10 ]; then + exit 30 + fi + + db_get apt-setup/use_mirror + if db_get mirror/protocol [ $RET ]; then + protocol=$RET + fi + if [ $RET = false ]; then + if [ $protocol ]; then + db_set mirror/$protocol/hostname + db_set mirror/$protocol/directory + fi + else + if [ $protocol ]; then + if db_get mirror/$protocol/directory [ -z $RET ]; then + db_reset mirror/$protocol/directory + fi + fi + choose-mirror + fi +fi + Shouldn't this be in 50mirror so it only asks about using a mirror if using a mirror is something it can really do? (Similarly the template should move to apt-mirror-setup.templates) I'm also not really sure why we need to ask this, at least at high priority, for a netinst install, when using a mirror is a fine default. -- see shy jo signature.asc Description: Digital signature
Re: [RFR] Proposal for installs without network connection
Christian Perrier wrote: I find the template a bit verbose and maybe hard to translate and fit in one screenmaybe simplify the entire last paragraph. I've rewritten it fairly heavily: Description: Use a network mirror? A network mirror can be used to supplement the software that is included on the CD-ROM. This may also make newer versions of software available. . If you are installing from a netinst CD and you choose not to use a mirror, you will end up with only a very minimal base system. I'd like to remove that second paragraph too once there's a way to detect whether the CD is a netinst. -- see shy jo signature.asc Description: Digital signature
Re: gtk 2.0.x or 2.9+ for etch g-i ? (Was: graphics or text as default)
On Wed, May 17, 2006 at 10:27:38PM -0500, Christian Perrier wrote: Hello Frans, could you stop using debian-release for the purpose of bashing Sven Luther ? As far as my understanding goes, Frans is not the one who expanded the CC list. In short, faudrait peut-être pas trop déconner, quand même. Ah, but the original CC expanding had a reason and technical content, while frans reply had none. That said, it was not my intention to in any way try to take Frans place as d-i RM. I just wanted that we had the right information, so we could discuss this issue in good knowledge of facts, and not with random suppositions, like we did previously. I really fail to see how this could be interpreted as a problem, and if i am supposed to ask permission for writing this kind of emails, or ask frans to write it, things will very quickly turn very tedious. Frans, there is enough bureaucrazy in debian as is, no need to add another set of unnecessary layer. This is just discussion and planning, and everyone should be free to do that, as long as it doesn't indulge in insults and agressive bashing, but i believe my emails where devoid of that. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFR] Proposal for installs without network connection
On Thursday 18 May 2006 07:08, Joey Hess wrote: Description: Use a network mirror? A network mirror can be used to supplement the software that is included on the CD-ROM. This may also make newer versions of software available. . If you are installing from a netinst CD and you choose not to use a mirror, you will end up with only a very minimal base system. Yes, is better. Thanks. Maybe s/available/available for installation/ ? I'd like to remove that second paragraph too once there's a way to detect whether the CD is a netinst. Agree. Or maybe do a separate dialog as a warning if no mirror is selected for a netinst install. Should I upload? Testing here may be tricky as downloading a netinst can take a while... pgpLg4x7xuSEb.pgp Description: PGP signature
Bug#270136: patch for partman_server
On Thu, 18, May, 2006 at 12:13:23AM -0500, Joey Hess spoke thus.. Mark Hymers wrote: Patch attached to make this behaviour a bit more robust (I hope). Sweet. Patch looks correct, did you get a chance to test it? Yeah, Steve Gran booted it on his thinkpad qemu session and it seems to work fine. Buyer beware :-) Mark -- Mark Hymers [EMAIL PROTECTED] That's why the good die young; it's because Death can't be bothered to check the paperwork. Andy Hamilton, Old Harry's Game signature.asc Description: Digital signature
Bug#270136: patch for partman_server
Mark Hymers wrote: Patch attached to make this behaviour a bit more robust (I hope). Sweet. Patch looks correct, did you get a chance to test it? -- see shy jo signature.asc Description: Digital signature
Re: Write Access to repository for translate
On Thursday 18 May 2006 03:27, [EMAIL PROTECTED] wrote: Could you add me to commiter for translating D-I manual? I have added you to the project. You should have commit access sometime tomorrow. Please make sure that you are subscribed to the debian-i18n list for announcements about the manual. Thanks for your work, FJP pgpUfAxZWXWoX.pgp Description: PGP signature
Re: r37385 - in trunk/packages/apt-setup: .
On Thursday 18 May 2006 06:57, Joey Hess wrote: Shouldn't this be in 50mirror so it only asks about using a mirror if using a mirror is something it can really do? Maybe, although this was my last proposal. I'd like to leave it like this for now though as this has been tested. I'd like to see this in before my holiday. We can always move it later when there is a bit more time. I'm also not really sure why we need to ask this, at least at high priority, for a netinst install, when using a mirror is a fine default. As long as we can't tell the difference between netinst and full CDs... pgp1Oi0U1mkqr.pgp Description: PGP signature
Re: r37385 - in trunk/packages/apt-setup: .
On Thursday 18 May 2006 06:57, Joey Hess wrote: Shouldn't this be in 50mirror so it only asks about using a mirror if using a mirror is something it can really do? Hmm. Probably yes. That is basically why I added the test for existence of choose-mirror later. pgpCs5HQyN3Iv.pgp Description: PGP signature
Bug#367803: Installation report
Package: installation-reports Boot method: CD for network installation Image version: 2006-05-13 Date: 2006-05-17 Machine: Pentium 400 Processor: Memory: 256 Partitions: Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked:[O] Configure network HW: [O] Config network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Create file systems:[E] Mount partitions: [ ] Install base system:[ ] Install boot loader:[ ] Reboot: [ ] Comments/Problems: It's difficult to install Debian on a RAID only system (in that case software RAID1). The partitioning completes with the creation of the filesystem. The partitions itself are created at a later step during RAID setup. The installation stops with the error no / defined. Thats true because all partitions are marked as software RAID partition. Creating the RAID is only possible after completion of the partitioning process which can only be completed after creating the RAID. Workaround: I selected one partition as / and was able to complete the partitioning. Then I created the RAID and was now able to create file system structure on it. Solution: it should be possible to complete the partitioning task without / when the partitions created are marked for use by software RAID. Additional the order is confusing. Creation of RAID is sorted after the creation of LVM. But I think it would be done always in the reversed order: first create RAID then the LVM on it. The last steps are not completed because the kernel traps turing file system creation. If I read correctly this should be fixed meanwhile. Dierk Hentrich -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
