Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
* Emanuele Rocca [EMAIL PROTECTED] [2006-11-23 00:57]: Probably it's worth changing the partman-auto recipes only for the potentially affected systems. I think all systems are potentially affected, but I can add a new recipe for arm/ixp4xx if that's preferred. Which version of the patch should I apply? One changing 64 MB minimum swap to 96 MB on all systems or one that only does it on arm/ixp4xx? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch to handle touchpads in g-i available
Holger Wansing wrote: On Wed, 22 Nov 2006 16:44:39 +0100 Attilio Fiandrotti [EMAIL PROTECTED] wrote: I prepared an iso image [2] which includes the fix: i'm asking testers who previously reported their synaptics touchpad not working within g-i to test this iso and report results and feelings about how the touchpad works. [2] https://debian.polito.it/downloads/mini_synaptics.iso Works great for me. (Synaptics Touchpad on a Gericom Laptop; touchpad didn't work in g-i before) cool! i tried o my father's laptop too and it worked well, even if the cursor moves slower slower than on my laptop (i guess because different input dynamics). hope new reports will come cheers Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving to 2.6.18
* Martin Michlmayr [EMAIL PROTECTED] [2006-11-19 21:41]:
- cobalt: RTC not working but checking 2.6.17 I see it's a problem
there too. Will investigate.
So this isn't as bad to what I initially thought. What happens is
that the time in d-i is set to Jan 1 2000 but the installation itself
works fine. The only problem is that e2fsck is run on the root and it
will reboot once, but then it will boot properly.
I'm not quite sure why it's 2000 though because the hardware has the
right time. From within d-i, I went into the chroot and issues the
following commands:
sh-3.1# hwclock -r
Tue Nov 21 14:51:21 2006 -0.344000 seconds
sh-3.1# date -R
Sat, 01 Jan 2000 01:01:17 +0100
sh-3.1# hwclock --hctosys
sh-3.1# date -R
Tue, 21 Nov 2006 14:51:49 +0100
sh-3.1#
Does anyone know why date and hwclock disagree? Thiemo?
--
Martin Michlmayr
http://www.cyrius.com/
[d-i]
The system is going down NOW !!
Sending SIGTERM to all processes.
Sending SIGKILL to all processes.
Please stand by while rebooting the system.
Restarting system.
.
Cobalt Microserver Diagnostics - 'We serve it, you surf it'
Built Tue May 25 15:58:41 PDT 1999
1.LCD TestPASS
2.Controller Test.PASS
5.Bank 0:.64M
6.Bank 1:.64M
7.Bank 2:.0M
8.Bank 3:.0M
9.Serial Test.PASS
10.PCI Expansion Slot**EMPTY**
12.IDE TestPASS
13.Ethernet Test...PASS
16.RTC TestPASS
BOOTLOADER ramcode: selected partition /dev/hda1
Decompressing -\|/-\|/-\|/-\| done
Executing bootloader kernel...
Decompressing -/-\ done.
[ CoLo v1.22 ]
stage2: 87fa-8800
cpu: clock 250.000MHz
pci: unit type RaQ2
tulip: #0 device 21143
tulip: #1 device 21143
tulip: {00:10:e0:00:eb:8d}
ide: resetting
boot: running boot menu
1 lcd 'Booting...'
1 mount
ide: {SAMSUNG WN321620A (2.16 GB)}
ide: LBA 4219488
ide: supports PIO mode 4
ide: mode 4 timing
ide: partition 1
ext2: revision 0
1 lcd 'Booting...' /dev/{mounted-volume}
1 -load /boot/default.colo
ext2: {boot/default.colo} -- {./default.colo}
00bf 191t
1 -script
2 mount hda1
ext2: revision 0
2 load /vmlinux
ext2: {vmlinux} -- {vmlinux-2.6.17-2-r5k-cobalt}
0033561c 3364380t
2 lcd Booting Debian
2 var cons_opts ''
2 -var cons_opts console=ttyS0,{console-speed}
2 execute root=/dev/hda2 {cons_opts}
elf32: 0008 - 0032301f (802df000) (.8000)
elf32: 8008 (8008) 2605190t + 159642t
Linux version 2.6.17-2-r5k-cobalt (Debian 2.6.17-9) ([EMAIL PROTECTED]) (gcc
version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 Wed Sep 13 17:01:10
UTC 2006
CPU revision is: 28a0
FPU revision is: 28a0
Cobalt board ID: 6
Cobalt: early console registered
Determined physical RAM map:
memory: 0800 @ (usable)
Built 1 zonelists
Kernel command line: root=/dev/hda2 console=ttyS0,115200
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB, 2-way, linesize 32 bytes.
Synthesized TLB refill handler (21 instructions).
Synthesized TLB load handler fastpath (34 instructions).
Synthesized TLB store handler fastpath (34 instructions).
Synthesized TLB modify handler fastpath (33 instructions).
PID hash table entries: 1024 (order: 10, 4096 bytes)
Linux version 2.6.17-2-r5k-cobalt (Debian 2.6.17-9) ([EMAIL PROTECTED]) (gcc
version 4.1.2 20060901 (prerelease) (Debian 4.1.1-13)) #1 Wed Sep 13 17:01:10
UTC 2006
CPU revision is: 28a0
FPU revision is: 28a0
Cobalt board ID: 6
Cobalt: early console registered
Determined physical RAM map:
memory: 0800 @ (usable)
Built 1 zonelists
Kernel command line: root=/dev/hda2 console=ttyS0,115200
Primary instruction cache 32kB, physically tagged, 2-way, linesize 32 bytes.
Primary data cache 32kB, 2-way, linesize 32 bytes.
Synthesized TLB refill handler (21 instructions).
Synthesized TLB load handler fastpath (34 instructions).
Synthesized TLB store handler fastpath (34 instructions).
Synthesized TLB modify handler fastpath (33 instructions).
PID hash table entries: 1024 (order: 10, 4096 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 126592k/131072k available (1985k kernel code, 4348k reserved, 439k
data, 120k init, 0k highmem)
Security Framework v1.0.0 initialized
SELinux: Disabled at boot.
Capability LSM initialized
Mount-cache hash table entries: 512
Checking for 'wait' instruction... available.
NET: Registered protocol family 16
Galileo: fixed bridge class
Galileo: revision 17
NET: Registered protocol family 2
IP route cache hash table entries: 1024 (order: 0, 4096 bytes)
TCP established hash table entries: 4096 (order: 2, 16384 bytes)
TCP bind hash table entries: 2048 (order: 1,
Processing of glantank_1.2_arm.changes
glantank_1.2_arm.changes uploaded successfully to localhost along with the files: glantank_1.2.dsc glantank_1.2.tar.gz glantank-utils_1.2_arm.deb glantank-installer_1.2_arm.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch to handle touchpads in g-i available
On Wednesday 22 November 2006 16:44, Attilio Fiandrotti wrote: I recently wrote a patch against DFB 0.9.25 which adds to linux_input the capability to translate absolute x,y coordinates generated by touchpads into relative ones: this allows using Synaptic touchpads with the g-i. Works on my laptop with alps touchpad. Cursor movement is a bit slow. Tapping does not work correctly: - deliberate tapping sometimes works, but mostly not - very quick mouse movement will always end in a tap However, it is a lot better than the current situation, so I'd very much like to try to get this patch in before Etch. Could you file a BR against the directfb package and discuss an upload for it with the maintainer? It would be nice to also get some testing of this patch on powerpc with the directfb input module enabled. Cheers, FJP pgpli85pxZD6m.pgp Description: PGP signature
glantank_1.2_arm.changes ACCEPTED
Accepted: glantank-installer_1.2_arm.udeb to pool/main/g/glantank/glantank-installer_1.2_arm.udeb glantank-utils_1.2_arm.deb to pool/main/g/glantank/glantank-utils_1.2_arm.deb glantank_1.2.dsc to pool/main/g/glantank/glantank_1.2.dsc glantank_1.2.tar.gz to pool/main/g/glantank/glantank_1.2.tar.gz Override entries for your package: glantank-installer_1.2_arm.udeb - standard debian-installer glantank-utils_1.2_arm.deb - optional admin glantank_1.2.dsc - source admin 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]
Re: Patch to handle touchpads in g-i available
Frans Pop wrote: On Wednesday 22 November 2006 16:44, Attilio Fiandrotti wrote: I recently wrote a patch against DFB 0.9.25 which adds to linux_input the capability to translate absolute x,y coordinates generated by touchpads into relative ones: this allows using Synaptic touchpads with the g-i. Works on my laptop with alps touchpad. Cursor movement is a bit slow. Tapping does not work correctly: - deliberate tapping sometimes works, but mostly not - very quick mouse movement will always end in a tap experienced something similar on my father's laptop: cursor moves much slower than on my touchpad, i guess because different touchpads provide different X,Y ranges. This could be fixed lowering the speed scaling factor, but this may result in too fast motion on other touchpads like mine (i own an hp pavillon laptop ). I also experienced tap not working on my father's latop: this may be because of different Z input values and could be adjusted by lowering the pressure treshold over which the tap is reported, but there are drawback there too (luckily the user can use the normal buttons) However, it is a lot better than the current situation, so I'd very much like to try to get this patch in before Etch. Could you file a BR against the directfb package and discuss an upload for it with the maintainer? alright, i'll open a new bug for directfb tagging it patch; i'd just like to wait a couple of days still for more reports to come ( i sent a call for testing to d-italian and responses are generally positive ATM ) It would be nice to also get some testing of this patch on powerpc with the directfb input module enabled. Uhm, does the Macintosh touchpads are recognized as ps2 mices? in this case the patch shouldn't be even necessary (ps2mouse input module would be used instead), but as i own no mac powerbook i cannot check. cheers attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch to handle touchpads in g-i available
On Thu, 23 Nov 2006 10:25:02 +0100 Attilio Fiandrotti [EMAIL PROTECTED] wrote: i tried o my father's laptop too and it worked well, even if the cursor moves slower slower than on my laptop (i guess because different input dynamics). Well, as I don't use the touchpad in normal work (use usb mouse instead), I have no experience about the speed and that. Holger -- Created with Sylpheed 2.0.4 under Debian GNU/LINUX 3.1 Sarge Registered LinuxUser #311290 Spam filtering by bogofilter.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
On Thu, 23 Nov 2006 10:03:26 +0100 Martin Michlmayr [EMAIL PROTECTED] wrote: * Emanuele Rocca [EMAIL PROTECTED] [2006-11-23 00:57]: Probably it's worth changing the partman-auto recipes only for the potentially affected systems. I think all systems are potentially affected, but I can add a new Does it make a difference, that the drive to partition is on an usb stick? (In other words: does creating filesystem on an usb stick consum more ram than creating on ide hard disc?) I have an Toshiba laptop with 32MB, on which d-i runs in low memory mode, and I have no problems to create ext2 filesystem of 4 GB on ide hard disc (64MB swap is created, too). Ahh, or is the difference, that I create ext2, not ext3? (ext3 is not available in low memory mode here) Holger -- Created with Sylpheed 2.0.4 under Debian GNU/LINUX 3.1 Sarge Registered LinuxUser #311290 Spam filtering by bogofilter.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
* Holger Wansing [EMAIL PROTECTED] [2006-11-23 12:18]: Does it make a difference, that the drive to partition is on an usb stick? (In other words: does creating filesystem on an usb stick consum more ram than creating on ide hard disc?) No, it has been reproduced in qemu too. I have an Toshiba laptop with 32MB, on which d-i runs in low memory mode, and I have no problems to create ext2 filesystem of 4 GB on ide hard disc (64MB swap is created, too). You have a 4 GB disk, not a 1 GB disk. That's the difference. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
On Thursday 23 November 2006 10:03, Martin Michlmayr wrote: I think all systems are potentially affected, but I can add a new recipe for arm/ixp4xx if that's preferred. Which version of the patch should I apply? One changing 64 MB minimum swap to 96 MB on all systems or one that only does it on arm/ixp4xx? I don't see any problem with making the change globally. It should not have any effect anyway except when using really small target media. pgpIC3em2AXlm.pgp Description: PGP signature
Bug#399737: Installation Report - Etch RC1 DVD does not install Desktop
On Wednesday 22 November 2006 15:58, Clyde E. Kunkel wrote: I am sure the Desktop and Base system were selected. I have also seen this behavior with the netinst CD (previously reported, bz #397036). Perhaps it is something to do with the fact that I am using a 20GB LV for /, but also configure a small (100MB) ordinary linux 0x83 partition for boot? Is there something I can check before leaving the installer and rebooting? If the desktop task is selected X and Gnome should be installed, a separate boot partition makes no difference and 20GB is plenty for a desktop installation. Please send us (gzipped) the syslog for the installation, which can be found in /var/log/installer on the installed system. pgpx6UeJjmZQl.pgp Description: PGP signature
Bug#399687: installation report: low memory install: grub missing
On Thursday 23 November 2006 00:45, Holger Wansing wrote: So everything is commented out! And that is the cause of the problem. I suspect that the cause is just a minor error recognizing the CD, which happens quite often with older machines. Trying a reinstallation may fix it, especially as there were no problems using the CD during base installation. If you can reproduce the error, try adding a 'set -x' line in /usr/lib/apt-setop/generators/50cdrom before running apt-setup. Or maybe try 'chroot /target' and running 'apt-cdrom add' manually. Maybe this is related to the wrong date of the cd, too? Looking for a cd ... (20061121)..., but find ... (20061102)... ? No, I doubt that as the initial line was created for the same CD. pgpmbUCpbymZ4.pgp Description: PGP signature
Bug#399956: installation-reports etch RC1 and serveraid 8i
On Thursday 23 November 2006 03:08, Martin Foster wrote: 04:00:0 RAID bus controller [0104]: Adaptec AAC-RAID (Rocket) [9005:0286] (rev 2) Comments/Problems: IBM serveraid 8i not detected. Suspect ips.ko is too old. These serveraid cards are rather popular now, the 8 series support SAS and SATA disk. Why ips.ko? The kernel lists aacraid as the correct driver for the Adaptec AAC-RAID controller. We expect to have a 2.6.18 based installer available some time next week using the daily built images. It would be great if you could try again with that. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [RFC] Detecting type of CD image and using that to make apt-setup smarter
On Tuesday 21 November 2006 18:14, Steve McIntyre wrote: H. I've been working on a slightly different setup in my devel branch - specifying the type of media up-front instead of the size, then setting the size from there. Same overall effect, just slightly different code. Mine in CONF.sh looks like: Looks like a good idea for the long run and probably allows to avoid having to set all the individual variables as is currently needed. However, any objection to implementing my proposed code in the current trunk for RC2? pgpwnp1roVLkh.pgp Description: PGP signature
Bug#394971: This bugs affects the official powerpc port as well.
On Thursday 23 November 2006 01:55, Charles Plessy wrote: If it is not possible to integrate fan support to the installer, I would like to suggest the following addition to the installer errata: I expect fan control to be present in RC2. Cheers, FJP pgpbx39rsI2dD.pgp Description: PGP signature
Bug#394971: [powerpc64] load the fan control modules
The provided patch is broken: standard error is redirected to a file named 1 instead of file handle 1. Suggest to use the following syntax instead: modprobe -q module || true Also, I wonder if all listed modules really need to be modprobed individually: modprobe will after all load modules that other modules depend on automatically. I would expect that i2c-powermac and windfarm_core can safely be dropped. So please only modprobe those modules that are strictly needed to enable the fan control. Finally, why was S50directfb-linux-powerpc added in the Makefile? This seems unrelated to this patch. Colin suggested that when we apply this patch in the installer, a similar patch should added in initramfs-tools to make sure that the modules are loaded too on the installed system. Has that already been coordinated? P.S. The main reason (beside the fact that the patch was broken) that I reverted the upload was that normal NMU procedure was not followed: - an NMUer never adds himself to Uploaders - an NMU uses a different version number from normal uploads - bug closure was missing - there was no mail to the open BR with a final patch based on the debdiff for the upload pgpuKp15xaTTx.pgp Description: PGP signature
Processed: Re: Bug#342756: I think that the standard jp106 keymap can be used with japanese macintoshes.
Processing commands for [EMAIL PROTECTED]: reassign 342756 console-data Bug#342756: debian-installer: Japanese mac usb keyboard is missing Bug reassigned from package `kbd-chooser' to `console-data'. tags 342756 - moreinfo Bug#342756: debian-installer: Japanese mac usb keyboard is missing Tags were: moreinfo Tags removed: moreinfo 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#340980: marked as done (installation-reports: unable to install yaboot on a iMac G5)
Your message dated Thu, 23 Nov 2006 14:13:13 +0100 with message-id [EMAIL PROTECTED] and subject line Closing as requested 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: http://people.debian.org/~luther/d-i/ppc64/2005-11-27/powerpc64/netboot64/mini.iso uname -a: install failed Date: 2005-11-27 Method: burn the iso on CD-RW, and reboot pressing 'c'. had to boot with video=ofonly Machine: iMac G5 1.8 Ghz Processor: PPC970FX, altivec supported Memory: 751976 Root Device: discover: ;;;ATA;ST3160023AS;/dev/sda Root Size/partition table: Model: ATA ST3160023AS Path: /dev/scsi/host0/bus0/target0/lun0/disc Sector size: 512 Sectors: 312581808 Sectors/track: 63 Heads: 255 Cylinders: 19457 Partition table: yes Type: mac Partitions: # id length typefs pathname (0,0,0) (0,0,0) -1 0-511 512 primary label /dev/scsi/host0/bus0/target0/lun0/part-1 (0,0,1) (0,1,0) 1 512-32767 32256 primary unknown /dev/scsi/host0/bus0/target0/lun0/part1 Apple (0,1,1) (65,78,20) 2 32768-537169919 537137152 primary hfs+ /dev/scsi/host0/bus0/target0/lun0/part2 Apple_HFS_Untitled_1 (65,78,21) (130,147,24)3 537169920-1074040831536870912 primary ext2/dev/scsi/host0/bus0/target0/lun0/part3 bootux (130,147,25)(373,186,23)4 1074040832-3074041343 200512 primary linux-swap /dev/scsi/host0/bus0/target0/lun0/part4 swap (373,186,24)(1589,126,14) 6 3074041344-13074041855 1000512 primary ext3/dev/scsi/host0/bus0/target0/lun0/part6 debian (1589,126,15) (2805,66,5) 8 13074041856-23074042367 1000512 primary ext3/dev/scsi/host0/bus0/target0/lun0/part8 autre (2805,66,6) (4021,5,59) 9 23074042368-33074042879 1000512 primary fat32 /dev/scsi/host0/bus0/target0/lun0/part9 exchange (4021,5,60) (11690,188,57) 10 33074042880-96159617023 63085574144 primary ext3/dev/scsi/host0/bus0/target0/lun0/part10home (11690,188,58) (14285,65,27) 5 96159617024-117500235775 21340618752 primary hfs+/dev/scsi/host0/bus0/target0/lun0/part5 Apple_HFS_Untitled_3 (14285,65,28) (14301,146,28) -1 117500235776-117634453503 134217728 primary free/dev/scsi/host0/bus0/target0/lun0/part-1 (14301,146,29) (19457,80,46) 7 117634453504-160041877503 42407424000 primary hfs+/dev/scsi/host0/bus0/target0/lun0/part7 Apple_HFS_Untitled_4 (19457,80,47) (19457,80,62) -1 160041877504-160041885695 8192 primary free/dev/scsi/host0/bus0/target0/lun0/part-1 Output of lspci and lspci -n: hardware-summary:/proc/pci: PCI devices found: hardware-summary:/proc/pci: Bus 240, device 11, function 0: hardware-summary:/proc/pci: Class 0600: PCI device 106b:0058 (rev 0). hardware-summary:/proc/pci: Master Capable. Latency=16. hardware-summary:/proc/pci: Bus 240, device 16, function 0: hardware-summary:/proc/pci: Class 0300: PCI device 10de:0329 (rev 161). hardware-summary:/proc/pci: IRQ 59. hardware-summary:/proc/pci: Master Capable. Latency=16. Min Gnt=5.Max Lat=1. hardware-summary:/proc/pci: Non-prefetchable 32 bit memory at 0x9100 [0x91ff]. hardware-summary:/proc/pci: Prefetchable 32 bit memory at 0xa000 [0xa7ff]. hardware-summary:/proc/pci: Bus 0, device 1, function 0: hardware-summary:/proc/pci: Class 0604: PCI device 106b:0053 (rev 0). hardware-summary:/proc/pci: Bus 0, device 2, function 0: hardware-summary:/proc/pci: Class 0604: PCI device 106b:0054 (rev 0). hardware-summary:/proc/pci: Bus 0, device 3, function 0: hardware-summary:/proc/pci: Class 0604: PCI device 106b:0055 (rev 0). hardware-summary:/proc/pci: Bus 3, device 15, function 0: hardware-summary:/proc/pci: Class 0200: PCI device 106b:0051 (rev 0). hardware-summary:/proc/pci: IRQ 40. hardware-summary:/proc/pci: Master Capable. Latency=16. Min Gnt=64.Max Lat=64. hardware-summary:/proc/pci: Non-prefetchable 32 bit memory at 0x8040 [0x805f]. hardware-summary:/proc/pci: Bus 1, device 7, function 0: hardware-summary:/proc/pci: Class ff00: PCI device 106b:004f (rev 0). hardware-summary:/proc/pci: IRQ -1. hardware-summary:/proc/pci: Master Capable. Latency=16. hardware-summary:/proc/pci:
Re: Patch to handle touchpads in g-i available
Holger Wansing wrote: On Thu, 23 Nov 2006 10:25:02 +0100 Attilio Fiandrotti [EMAIL PROTECTED] wrote: i tried o my father's laptop too and it worked well, even if the cursor moves slower slower than on my laptop (i guess because different input dynamics). Well, as I don't use the touchpad in normal work (use usb mouse instead), I have no experience about the speed and that. Holger, could you please check if cursor speed and touchpad sensitivity is similar to that in X? do you see any big difference between the g-i and Xorg ? Attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
Hello Holger, * Holger Wansing [EMAIL PROTECTED], [2006-11-23 12:18 +0100]: Ahh, or is the difference, that I create ext2, not ext3? Yeah, another difference is that I created an ext3 fs, and ssh died during the journal creation. (ext3 is not available in low memory mode here) You should be able to choose the udeb for ext3 in the screen that allows to select which components of the installer you want to use. ciao, ema -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
IMPORTANT: Significant changes to CD/DVD build setup
As of late last night, there's a couple of things that have changed: 1) The machine doing daily builds is now farbror rather than bla. That won't mean much to most people, as the output will still appear in the same place at cdimage.debian.org. However, farbror is a faster machine than bla and is situated much closer to cdimage. This means that the build process should be much faster (yay!) I haven't (yet) moved the weekly builds across to run on farbror, but I expect to do that in the next couple of days, before the next scheduled build on Monday. This will *really* help in terms of build performance. 2) dinstall and the mirror pulse are now happening twice daily, which means we will get two daily build runs. *Right* now the second daily build will automatically overwrite the first each day, but I'm going to change the scripts on farbror and bla to keep both, as date-1 and date-2. The arch-latest links will still be kept up-to-date to keep external links pointing at the latest build. Any comments, please let me know... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] You lock the door And throw away the key There's someone in my head but it's not me signature.asc Description: Digital signature
Bug#398333: Automatic partition/disk selection
On Friday 17 November 2006 13:36, Olaf van der Spek wrote: Frans Pop wrote: That is probably not supported. Please see the example in the development version of the manual: http://d-i.alioth.debian.org/manual/en.i386/apbs04.html#preseed-partman Why not? The technical reason is probably that to preseed your way you'd need the translated _description_ of the disk instead of its device name. pgpEmfPNuuvlB.pgp Description: PGP signature
Bug#398333: Automatic partition/disk selection
On Friday 17 November 2006 11:28, David Härdeman wrote: On Fri, November 17, 2006 10:21, Frans Pop said: Because the method is not a question as such when using preseeding. We should handle the situation where partman-auto/disk is preseeded but partman-auto/method is not more gracefully though. How would you like it to work? I think we have two options: 1) Default to method regular If partman-auto/disk=/dev/* and partman-auto/method is not set, then default partman-auto/method to regular. 2) Error out if no method set If partman-auto/disk=/dev/* and partman-auto/method is not set, then show an error message and unset partman-auto/disk. I somewhat prefer 1) as it gives some backwards compatibility and 2) probably would mean adding a new error message which is undesirable for RC2. pgp5TLLWabUD5.pgp Description: PGP signature
Bug#399053: post install error
On Friday 17 November 2006 12:33, Joao Eugenio Marynowski wrote:
Comments/Problems:
...
After install it broken at recongnize the hd SATA printing:
ata1: handling error/timeout
ata1: port reset, p_is 0 is 0 pis 0 cmd 47048007 tf 7f ss 0 se 0
ata1: status=0x50 {DriveReady SeekComplete}
sda: Current: sense key: No Sense
Additional sense: No additional sense information
...
To be honest, this looks like a hardware problem rather than an
installation issue.
Especially as the same kernel kernel version was used for the installation
and the installed system (although probably not the same kernel flavor:
the installer uses the -486 flavor while I suspect the -686 flavor was
installed for the new system).
Cheers,
FJP
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IMPORTANT: Significant changes to CD/DVD build setup
On Thursday 23 November 2006 14:58, Steve McIntyre wrote: 2) dinstall and the mirror pulse are now happening twice daily, which means we will get two daily build runs. *Right* now the second daily build will automatically overwrite the first each day, but I'm going to change the scripts on farbror and bla to keep both, as date-1 and date-2. The arch-latest links will still be kept up-to-date to keep external links pointing at the latest build. I'm not so sure that having two builds is really that good an idea. In almost all cases the images will be virtually identical, especially with regard to d-i. And as we're only talking about small images, the number of debs included is relatively small. However, if there are problems with an image, having new images created so quickly may cause confusion when trying to reproduce a problem: when we download an image ourselves the chance will be much bigger that it won't be the same image. If there is mirror space to spare, I'd much rather have the previous day's images available than having two sets from the same day. Just my first reaction. FJP pgpQj4MBrd1H6.pgp Description: PGP signature
Bug#400020: installation-reports
Package: installation-reports Boot method: Cd Image version: http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso Date: 23.11.2006 15:22 Machine: desktop pc no brand Processor: Athlon K7 700Mhz Memory: 384 MB Partitions: df -Tl will do; the raw partition table is preferred Output of lspci -nn and lspci -vnn: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [E] Detect CD: [O] Load installer modules: [O] Detect hard drives: [ ] Partition hard drives: [ ] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: We tried to install debian testing on 3 different machines all known working. The base system installation works and sometimes also the network card detection but there is no way to make the networking working not even with manual configuration. we booted from a linux live distro and everything works fine with the machines, also the network! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IMPORTANT: Significant changes to CD/DVD build setup
On Thu, Nov 23, 2006 at 03:27:03PM +0100, Frans Pop wrote: On Thursday 23 November 2006 14:58, Steve McIntyre wrote: 2) dinstall and the mirror pulse are now happening twice daily, which means we will get two daily build runs. *Right* now the second daily build will automatically overwrite the first each day, but I'm going to change the scripts on farbror and bla to keep both, as date-1 and date-2. The arch-latest links will still be kept up-to-date to keep external links pointing at the latest build. I'm not so sure that having two builds is really that good an idea. In almost all cases the images will be virtually identical, especially with regard to d-i. And as we're only talking about small images, the number of debs included is relatively small. However, if there are problems with an image, having new images created so quickly may cause confusion when trying to reproduce a problem: when we download an image ourselves the chance will be much bigger that it won't be the same image. If there is mirror space to spare, I'd much rather have the previous day's images available than having two sets from the same day. There should be plenty of space to keep 6 sets rather than the current 3, so I've changed the setup to do that. Alternatively, if you only want one set built per day that's also entirely possible. You'll just need to let me know which of the 2 possible builds you want. :-) -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Into the distance, a ribbon of black Stretched to the point of no turning back signature.asc Description: Digital signature
Bug#399956: installation-reports etch RC1 and serveraid 8i
Thanks, I noticed the ips vs aacraid thing after filing the bug. Been using ServerRAID 7 and 4 series for too long. However, aacraid was loaded on the current Etch RC1 2.6.17 kernel. Will try again when the 2.6.18 kernel when it becomes available. Documentation/scsi/aacraid.txt has it listed 9005:0285:9005:0290 IBM ServeRAID 7t (Jaguar) 9005:0285:1014:02F2 IBM ServeRAID 8i (AvonPark) 9005:0285:1014:0312 IBM ServeRAID 8i (AvonParkLite) 9005:0286:1014:9580 IBM ServeRAID 8k/8k-l8 (Aurora) 9005:0286:1014:9540 IBM ServeRAID 8k/8k-l4 (AuroraLite) Cheers! -Martin Foster Frans Pop a écrit : On Thursday 23 November 2006 03:08, Martin Foster wrote: 04:00:0 RAID bus controller [0104]: Adaptec AAC-RAID (Rocket) [9005:0286] (rev 2) Comments/Problems: IBM serveraid 8i not detected. Suspect ips.ko is too old. These serveraid cards are rather popular now, the 8 series support SAS and SATA disk. Why ips.ko? The kernel lists aacraid as the correct driver for the Adaptec AAC-RAID controller. We expect to have a 2.6.18 based installer available some time next week using the daily built images. It would be great if you could try again with that. Cheers, FJP
Re: Patch to handle touchpads in g-i available
El mié, 22-11-2006 a las 16:44 +0100, Attilio Fiandrotti escribió: Hi I recently wrote a patch against DFB 0.9.25 which adds to linux_input the capability to translate absolute x,y coordinates generated by touchpads into relative ones: this allows using Synaptic touchpads with the g-i. The patch was sent for review to directfb-dev [1] and was said to be ok, updated patch is attached to this mail. I prepared an iso image [2] which includes the fix: i'm asking testers who previously reported their synaptics touchpad not working within g-i to test this iso and report results and feelings about how the touchpad works. I just tested the image and the touchpad works fine :) The only thing that doesn't work is the scrolling side of the touchpad, but I guess most users of the installer could live without it for now. cheers Attilio Thanks for the fix! [1] http://mail.directfb.org/pipermail/directfb-dev/2006-November/002414.html [2] https://debian.polito.it/downloads/mini_synaptics.iso -- Alejandro Rios Peña signature.asc Description: Esta parte del mensaje está firmada digitalmente
Re: Re: RC1 with auto-RAID and graphical preseeding
Sorry for perhaps breaking the thread. I forgot to mention I'm not subscribed to this list. Please keep me Cc:'ed until then. Otavio Salvador: Looks like there's something broken or your image or on the install itself. Have you rebuild the installer? If yes, you could have lose the preseed behaviour change that had some package splitting or like. Would be nice to check it. I didn't it (and don't plan to). I just: - fetched the .iso - extracted the initrd.gz - added the preseed.cfg to it - rebuild the initrd.gz - updated the md5sums - rebuilt the .iso Everything guided by instructions I've found in the wiki :-) About Attilio's message: despite some weirds error values I'm using (that seems null for what I want, anyway), the file syntax is right? -- caio[1982] begotti http://caio.ueberalles.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dictionaries-common prompts users FIVE times during a default French desktop install
Quoting Christian Perrier ([EMAIL PROTECTED]): While testing D-I with the install of the desktop task in French language, I have noticed that there are several successive prompts for dictionaries settings: -first choose between American English and handle symlinks youself -then choose between American English, francais and handle symlinks youself -then choose between francais, francais GUTenberg and handle symlinks youself -then choose between ameriucan English, francais, francais GUTenberg and handle symlinks youself -finally choose between american English, british, francais, francais GUTenberg and handle symlinks youself I just installed a fresh system today, with D-I RC1 businesscard. The install was a testing install, choosing desktop system and standard system. The install was done in French with all default settings. D-I *does not* use localization config. And I still got prompted five times about dictionaries. This problem will undoubtfully lead to very bad reviews of D-I by French users if not solved. signature.asc Description: Digital signature
Bug#394971: [powerpc64] load the fan control modules
On Thu, Nov 23, 2006 at 01:51:59PM +0100, Frans Pop wrote: The provided patch is broken: standard error is redirected to a file named 1 instead of file handle 1. Suggest to use the following syntax instead: modprobe -q module || true Ok, will be done, i wonder why you didn't start by telling us this instead of reverting the patch ? Furthermore, the patch was in the BTS since almost a month, without any comment on your part, and at the latest, i would have expected from you to investigate it and comment when you did the 1.42 upload. Also, I wonder if all listed modules really need to be modprobed individually: modprobe will after all load modules that other modules depend on automatically. Well, this is not how things are, after investigation and discussion with Benjamin Herrenschmidt, the powerpc/powermac linux kernel maintainer. The current way of doing this is the best compromise for within the 2.6.18 and etch timeframe. I would expect that i2c-powermac and windfarm_core can safely be dropped. And you would expect wrong. When are you going to stop to try to second guess the work and investigation i do, and try by all mean to show me as incapable ? They cannot be dropped, especially i2c-powermac cannot be dropped, since it will not be pulled in by the other modules. There are numerous comments about this fact on both debian-kernel and debian-powerpc, as well as numerous irc conversations on debian-kernel, where you are also present. So, either you chose to get involved, and try to stay informed about the different powerpc developments, or you don't, but then it is only fair to ask you to trust my knowledge and competence, as well as the interaction with the upstream linux/powerpc community such as Benjamin Herrenschmidt. Your current attitude is quite insulting to them and me, please modify it. So please only modprobe those modules that are strictly needed to enable the fan control. Well, given that your premises are wrong, this conclusion is obviously not valid. Finally, why was S50directfb-linux-powerpc added in the Makefile? This seems unrelated to this patch. It was not. Or should not have been. If it was, it is uniquely a result of a bad manipulation caused by me not having the svn commit right, and you are as thus solely to blame for it. But seriously, find attached my svn diff, there is no trace of a S50directfb-linux-powerpc in my diff, if it was there, it most probably did come from an older commit. I did in fact do an apt-get source of rootskel, and then applied the svn diff output, so i have no idea where this S50directfb-linux-powerpc file came from. I guess it came from earlier experiments done while me and attilio and a few others tried to investigate the g-i breakage. Colin suggested that when we apply this patch in the installer, a similar patch should added in initramfs-tools to make sure that the modules are loaded too on the installed system. Has that already been coordinated? A similar patch for therm_pm72 is already in the installer, and i have regularly been pushing maks to apply the whole stuff, but without success upto now. We even have some material from benjamin herrenschmidt for doing much more fine-grained checking in the initramfs-tools, based on actual model information and a static mapping from them to the actual needed modules. But in the context of the d-i, this is hardly worth it, which is why i didn't go into such a detailed and more error prone patch. P.S. The main reason (beside the fact that the patch was broken) that I reverted the upload was that normal NMU procedure was not followed: Indeed, it was not an NMU. I am the defacto d-i powerpc porter, even though manipulated me into resigning back in march while my mother was dying, for which i don't think i will ever forgive you, unless you are very sincere when you present your excuses for such unpardonable behavior. Your inability to find anyone able to replace me and do the work that needs dooing, and this more than 6 months after the fact, fully supports me in this. I reject your or anyone's right to expulse me from d-i, i am doing the powerpc port work, so i am the lead powerpc porter, that you want it or not. Debian has always been a community where the only thing that counted was the work you did, and as thus it is my full right to do this upload, despite your dillusions of power or whatever. Furthermore, by uploading 1.42 without even investigating the fancontrol patch, you furthermore failed in your responsabilities, and furthermore lose all right to revert that maintainer upload. - an NMUer never adds himself to Uploaders Indeed, which is why it was not an NMU. - an NMU uses a different version number from normal uploads Indeed, but as it was a maintainer upload. - bug closure was missing Indeed, since the bug was holding the patch, and since you are refusing me the right to commit to the svn repo normally, the patch should not be closed before
Bug#394970: finish-install: [powerpc64] Add support for IBM serial consoles (hvc and hvsi)
On Monday 23 October 2006 22:19, Sven Luther wrote:
This patch is currently untested, but i don't want to lose it again, so
i submit it. I expect to test it nextly, but i can only do so for hvc
as i have no longer access to a non-virtualized pserver, and can only
do so within the constraints of my free time.
The patch had an error in the sed on /etc/inittab. Please test the
attached patch, which also avoids the code duplication.
Index: finish-install.d/90console
===
--- finish-install.d/90console (revision 42772)
+++ finish-install.d/90console (working copy)
@@ -16,16 +16,18 @@
console=${console#/dev/}
case $console in
-ttyS*)
+ttyS*|hvc*|hvsi*)
log Configuring /etc/inittab for serial console
+ consoletype=${console%%[0-9]*}
+ ttyline=${console#$consoletype}
ttyspeed=$(chroot /target stty --file /dev/$console speed)
- ttyline=${console#ttyS}
ttyterm=$TERM
if [ -z $ttyterm ]; then ttyterm=vt100; fi
if [ -z $ttyspeed ]; then ttyspeed=9600; fi
+
sed -i -e s/^\([1-6]\):/#\1:/ \
- -e s/^#T0\(.*ttyS\).*/T$ttyline\1$ttyline $ttyspeed $ttyterm/ \
+ -e s/^#T0\(.*\)ttyS.*/T$ttyline\1$console $ttyspeed $ttyterm/ \
/target/etc/inittab
echo # serial console added by debian-installer /target/etc/securetty
echo $rawconsole /target/etc/securetty
pgpODHinIv2cP.pgp
Description: PGP signature
Bug#394971: This bugs affects the official powerpc port as well.
On Thu, Nov 23, 2006 at 01:53:11PM +0100, Frans Pop wrote: On Thursday 23 November 2006 01:55, Charles Plessy wrote: If it is not possible to integrate fan support to the installer, I would like to suggest the following addition to the installer errata: I expect fan control to be present in RC2. It would be very nice if you could give some details about the brokeness you found in the patchs i submitted, so i could try to fix them. I am surprised though, since i tested them multiple times, and didn't find any such brokeness. So, if you could lift the mystery and partake your knowledge and wisdom, if would be greatly appreciated. That said, this does not justify why you chose to revert the patch, instead of informing me on the breakage, and uploading a fixed package, as i believe you would have done with any other d-i team member. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400034: partman-auto-crypto: please allow waiving erase operation during guided partitioning
Package: partman-auto-crypto Severity: wishlist Hi, when using d-i RC1, and doing guided partitioning (LVM with crypto), there does not seem to be a possibility to prevent the erase data operation from happening. This is bad when installing to a vmware, since the virtual disk file is going to expand to its maximum size during that operation. The only workaround seems to be manual partitioning, which is a pain due to the complexity of the desired setup. Please consider adding a possibility to have an extra confirmation step before the erase operation starts. Greetings Marc -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18.3-zgsrv Locale: LANG=C, LC_CTYPE=de_DE (charmap=ISO-8859-1) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC1 with auto-RAID and graphical preseeding
Caio Begotti [EMAIL PROTECTED] writes: Looks like there's something broken or your image or on the install itself. Have you rebuild the installer? If yes, you could have lose the preseed behaviour change that had some package splitting or like. Would be nice to check it. I didn't it (and don't plan to). I just: - fetched the .iso - extracted the initrd.gz - added the preseed.cfg to it - rebuild the initrd.gz - updated the md5sums - rebuilt the .iso Which iso? Would be nice if you can include a syslog of both installations on the mail so we can check what's happening. I'm using preseeding almost every day on both g-i and d-i without problems so it can be a hidden bug or a small mistake. Everything guided by instructions I've found in the wiki :-) About Attilio's message: despite some weirds error values I'm using (that seems null for what I want, anyway), the file syntax is right? It looks like. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394970: finish-install: [powerpc64] Add support for IBM serial consoles (hvc and hvsi)
On Thu, Nov 23, 2006 at 04:24:34PM +0100, Frans Pop wrote:
On Monday 23 October 2006 22:19, Sven Luther wrote:
This patch is currently untested, but i don't want to lose it again, so
i submit it. I expect to test it nextly, but i can only do so for hvc
as i have no longer access to a non-virtualized pserver, and can only
do so within the constraints of my free time.
The patch had an error in the sed on /etc/inittab. Please test the
attached patch, which also avoids the code duplication.
Ok, cool, will do this this WE, since i have no access to the box.
Index: finish-install.d/90console
===
--- finish-install.d/90console(revision 42772)
+++ finish-install.d/90console(working copy)
@@ -16,16 +16,18 @@
console=${console#/dev/}
case $console in
-ttyS*)
+ttyS*|hvc*|hvsi*)
BTW, the new genesi efika board will use /dev/ttyPSC*, and i guess there are a
bunch of other serial ports out there.
Would it not be better to use the variable in rootskel to detect that the
terminal is a serial terminal, namely those who delcare themselves to be :
TERM_TYPE=serial in rootskel/src/lib/debian-installer/detect-console-linux
The code there is :
/dev/console|/dev/tts/*|/dev/tty[A-Z]*|/dev/hvc*|/dev/hvsi*)
Furthermore, i have personally found out that it is interesting to enable
a serial console in /etc/inittab even in non-serial installs, Maybe a debconf
question of low priority would allow this to be preseeded or set in expert
installs ? Maybe too late for etch now, but still something to keep in mind.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
Sven Luther [EMAIL PROTECTED] writes: Also, I wonder if all listed modules really need to be modprobed individually: modprobe will after all load modules that other modules depend on automatically. Well, this is not how things are, after investigation and discussion with Benjamin Herrenschmidt, the powerpc/powermac linux kernel maintainer. The current way of doing this is the best compromise for within the 2.6.18 and etch timeframe. What's the plan for lenny? Is it going to change on 2.6.19 or so? I would expect that i2c-powermac and windfarm_core can safely be dropped. And you would expect wrong. When are you going to stop to try to second guess the work and investigation i do, and try by all mean to show me as incapable ? Hold on Sven... I need to agree here with Frans. We always should try to reduce the amount of code and looks like there's a lot of dependent module being loaded by hand in your patch. If it has a reason, it's ok but you need to tell us about it. It's impossible to you, Frans or everyone to know about everything on every arch so as a D-I RM Frans did a question and I think you can just reply to it as I usually do and many others does too. There's no try to show you as incapable person. They cannot be dropped, especially i2c-powermac cannot be dropped, since it will not be pulled in by the other modules. There are numerous comments about this fact on both debian-kernel and debian-powerpc, as well as numerous irc conversations on debian-kernel, where you are also present. Isn't it a bug that could be solve on kernel itself? So, either you chose to get involved, and try to stay informed about the different powerpc developments, or you don't, but then it is only fair to ask you to trust my knowledge and competence, as well as the interaction with the upstream linux/powerpc community such as Benjamin Herrenschmidt. Your current attitude is quite insulting to them and me, please modify it. Please modify your action too. As you know I worry about ppc status and try to be updated about it. I'm still lacking the need hardware to work on it but it should change in near future and I'll get more involviment on it as I did before when I had an iBook. Besides, we all do mistake and you aren't different. We should try to review our code and patches to ensure a high quality on d-i and it should be done when the patches are pending to be commited as Frans is doing now. Please calm down and just reply for the questions and then I'm sure Frans will commit the patch also because it's really need for a proper ppc support from d-i side. Finally, why was S50directfb-linux-powerpc added in the Makefile? This seems unrelated to this patch. It was not. Or should not have been. If it was, it is uniquely a result of a bad manipulation caused by me not having the svn commit right, and you are as thus solely to blame for it. But seriously, find attached my svn diff, there is no trace of a S50directfb-linux-powerpc in my diff, if it was there, it most probably did come from an older commit. I did in fact do an apt-get source of rootskel, and then applied the svn diff output, so i have no idea where this S50directfb-linux-powerpc file came from. I guess it came from earlier experiments done while me and attilio and a few others tried to investigate the g-i breakage. Yes, it was include in your patch and might be useful if you can send a revised patch fixing the modprobe syntax and removing this hook from it. Colin suggested that when we apply this patch in the installer, a similar patch should added in initramfs-tools to make sure that the modules are loaded too on the installed system. Has that already been coordinated? A similar patch for therm_pm72 is already in the installer, and i have regularly been pushing maks to apply the whole stuff, but without success upto now. Let me ask it here again. Doesn't the right place to fix it be the kernel? Is too difficult to fix it there? Friendly ;-) Otavio Salvador -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394970: finish-install: [powerpc64] Add support for IBM serial consoles (hvc and hvsi)
Sven Luther [EMAIL PROTECTED] writes: Would it not be better to use the variable in rootskel to detect that the terminal is a serial terminal, namely those who delcare themselves to be : TERM_TYPE=serial in rootskel/src/lib/debian-installer/detect-console-linux I think it can be an interesting option to investigate. How deeply would be the patch to do that? Furthermore, i have personally found out that it is interesting to enable a serial console in /etc/inittab even in non-serial installs, Maybe a debconf question of low priority would allow this to be preseeded or set in expert installs ? Maybe too late for etch now, but still something to keep in mind. Interesting. That would help indeed. But maybe instead of enabling it by default or using a debconf question would be eaiser to use a command line param to enable it. What do you think? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC1 install successful on Pentium II, comments on tasks
On Friday 17 November 2006 15:59, Mikel Ward wrote: At one point I had to change the controller my hard disk was attached to, which caused the pivot_root to fail. I'm pretty sure the root file system can be specified using an ext2 label rather than a device path, which would have made things a little smoother there. This is something we are considering, but will probably only be implemented after Etch as the risk of subtle breakage is too great so short before the release. The other thing was the package group selections (tasks). Installing Database server gave me Postgresql, but I was expecting MySQL. It could at least have mentioned that I would get Postgresql before downloading packages I didn't want. I also selected Mail server and got Exim4 rather than Postfix, but this was to be expected due to Exim4's status as preferred mail transport agent. I have a patch pending to better document this in the installation guide. However, I don't expect major changes regarding this in tasksel as its maintainer does not agree with your view. I also didn't see a Development group. Now I've been using Debian for years, I know to apt-get install build-essential, but a development task would be great for new users. Tasksel is not targeted at developers, but at users. What packages should be installed for packaging work is explained in the developers reference. (I realize that developers can be considered a type of user and also that build-essential has a wider usage than just packaging, but I hope you get my drift.) (I'm hoping you want to hear feedback about tasks as well. If not, let me know where to direct it.) You can always file bugs against tasksel if you like. However, its maintainer has quite strong ideas as to what tasksel should and should not support. Thank you for your mail. Next time, please consider filing an installation report [1]. Cheers, FJP [1] http://d-i.alioth.debian.org/manual/en.i386/ch05s03.html#submit-bug pgpk4eoPxd96b.pgp Description: PGP signature
Re: Deactivated languages
പ്രവീണ്|Praveen wrote: 2006/11/20, Eddy Petrișor [EMAIL PROTECTED]: As I said, the problem is the actual space on the initrd and having a latin languages image/CD and a asian languages image is not such a good idea since you might end up downloading the wrong image and will be faced with a semi-useless cd since you don't know any of the other languages. Can't we give a option to choose a set of languages at the beginning say ASIAN languages, European languages, AFRICAN languages ... We can ship a set of initrd images for each laguage groups and it can be selected from grub menu at boot. (like we used to ship linux 2.4 and linux 2.6 at the same time we could have 5 initrds each for a continent). I think this would solve the problem of initrd image size in a considerable way and would not be tough to implement I think. Thanks for reminding me about that idea. I wanted to raise that option in the discution, but I managed to forget it. Implementing this would mean changing/stripping the udebs before putting them in the image. Meaning that the debian-installer build system should be changed. I don't know what impact multiple initrd images would have on debian-cd. About the stripping, isn't this already done in the installer via white listing? Christian? -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#395040: Check that ywrap,mtrr options for the vesafb device on i386 are harmless
I have tested during one install that g-i works without these parameters. However, the directfb README still says that they are needed: http://www.directfb.org/index.php?path=Documentation%2FUser+Manuals%2FREADME Could you please check with upstream whether or not the parameters are still needed or if the documentation is outdated? In any case, I think it is probably smart to delay changing this until after Etch as we currently have no indication that they break anything. Cheers, FJP pgpmIart4aGL1.pgp Description: PGP signature
Re: Deactivated languages
About the stripping, isn't this already done in the installer via white listing? Christian? Not sure what you're talking about so it's hard for me to answer. signature.asc Description: Digital signature
Re: Dictionaries-common prompts users FIVE times during a default French desktop install
On Thursday 23 November 2006 18:05, Agustin Martin wrote: More things, I remember to have been prompted when apt-utils was not installed and so, no pre-configuration was possible or, when due to space limitation in the /var partition some sort of debconf database corruption happened. So, does the problem appear at the pre-configure or at the postinst stage? Do other questions appear at the pre-configure stage? Can you provide us with a version of the relevant package(s) (probably only dictionaries-common) that dump some debugging output somewhere (stderr will work)? I feel we are going around in circles on this issue and having a version for testing that _shows_ what is happening would probably allow us to do some real tracing instead of speculating. Cheers, FJP pgprpobbahbh8.pgp Description: PGP signature
Bug#400064: autopartkit: FTBFS: No rule to make target `mapdevfs.o'
Package: autopartkit Version: 1.21 Severity: serious Hello, There was a problem while autobuilding your package: At 1164265143 time_t, [EMAIL PROTECTED] wrote: Automatic build of autopartkit_1.21 on avidan by sbuild/i386 98 Build started at 20061123-0758 ** ... checking for ped_disk_write... no checking for ped_partition_get_path... yes configure: creating ./config.status /bin/sh ./config.status config.status: creating Makefile config.status: creating autopartkit.d/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: Entering directory `/build/buildd/autopartkit-1.21' cd . /bin/sh /build/buildd/autopartkit-1.21/missing --run autoheader /build/buildd/autopartkit-1.21/missing: line 52: autoheader: command not found WARNING: `autoheader' is missing on your system. You should only need it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. rm -f stamp-h1 touch config.h.in /usr/bin/make all-recursive make[2]: Entering directory `/build/buildd/autopartkit-1.21' Making all in autopartkit.d make[3]: Entering directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Entering directory `/build/buildd/autopartkit-1.21' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT distribute.o -MD -MP -MF .deps/distribute.Tpo -c -o distribute.o distribute.c; \ then mv -f .deps/distribute.Tpo .deps/distribute.Po; else rm -f .deps/distribute.Tpo; exit 1; fi distribute.c: In function 'distribute_partitions': distribute.c:167: warning: ISO C90 does not support 'long long' distribute.c:167: warning: ISO C90 does not support 'long long' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT loadpartitions.o -MD -MP -MF .deps/loadpartitions.Tpo -c -o loadpartitions.o loadpartitions.c; \ then mv -f .deps/loadpartitions.Tpo .deps/loadpartitions.Po; else rm -f .deps/loadpartitions.Tpo; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT lvm.o -MD -MP -MF .deps/lvm.Tpo -c -o lvm.o lvm.c; \ then mv -f .deps/lvm.Tpo .deps/lvm.Po; else rm -f .deps/lvm.Tpo; exit 1; fi lvm.c: In function 'vg_exists': lvm.c:87: warning: unused variable 'devpath' lvm.c:86: warning: unused variable 'statbuf' make[3]: *** No rule to make target `mapdevfs.o', needed by `autopartkit'. Stop. make[3]: Leaving directory `/build/buildd/autopartkit-1.21' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make: *** [build-stamp] Error 2 ** Build finished at 20061123-0759 FAILED [dpkg-buildpackage died] -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD pgpRjXKIBpeIL.pgp Description: PGP signature
Bug#399096: marked as done (user doesn't yet trust the UI)
Your message dated Thu, 23 Nov 2006 18:20:00 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#399096: user doesn't yet trust the UI 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 Boot method: CD Image version: debian-testing-i386-netinst.iso Date: 11-17-2006 Machine: Custom Processor: AMD Athlon +2100 Memory: 1GB Partitions: n/a Output of lspci -nn and lspci -vnn: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [E] Install base system:[ ] Clock/timezone setup: [ ] User/password setup:[ ] Install tasks: [ ] Install boot loader:[ ] Overall install:[ ] Comments/Problems: My hard drive is all ready partitioned the way I want it. I could not figure out how to get past your partitioner to install Debian where I wanted it without the possibility of destroying existing data. Your partitioner seems to insist on creating a swap file, why do I need this with 1GB of RAM, other distros don't require a swap partition. ---End Message--- ---BeginMessage--- On Sunday 19 November 2006 02:49, W Talley wrote: When I boot off the CD and the main partitioner screen comes up, both hda1 and hdb1 have a B showing. However, only hda1 is bootable, hdb1 is just data. I would think that hda1, hda2, hdb2, and hda5 (where I want Debian) should all be bootable. If I try to set a bootable flag on hda5, then all the B's disappear except for one at hda5. I need four bootable partitions, but the partitioner will only allow for one. Maybe I don't understand what bootable means in your partitioner. It would be nice if your help file explained what to do for a multi-boot system. No, this is not how boot flags work. The boot flag indicates to the BIOS please look for a bootloader on this partition. There can only be one bootflag per harddisk. Which harddisk is used for booting, is a setting in your BIOS. Note also that the partitioner will always show a confirmation dialog that shows what changes will be made. Also, you should always allow the partitioner to format the partition you want to use as your / partition. You can skip creating a swap partition; the partitioner will warn about that, but you can ignore the warning. I'm sorry I don't get all this. This is the first time I've ever used your installer. Up until now, every Linux distro I tried had a graphical installer and they were all very easy to use. I hate to say this, but your installer's help file leaves me just a little helpless. The help file is just a very short explanatory text. If you want more detailed information, read the installation guide [1]. I'm closing your report as basically there is nothing that you want to do that cannot be done with the Debian installer/partitioner. And a lot of people have used it successfully for both simple and very complex setups. We are aware that the partitioner is not the most simple to use, but it _is_ one of the most versatile partitioners in any distribution. The setup you want is not all that complex, but does require manual partitioning and requires you to be careful so you don't damage existing partitions. It also requires a bit more knowledge about how a system boots and how to configure a system for multiboot. But hey, you are the one that wants to create something more than a simple setup... How you want to boot Debian is completely up to you. You can let the installer set up grub, and it will do its very best to also support any existing operating systems you have. You can also choose not to set up a bootloader (use go back when you get the first grub question and choose the no bootloader option in the menu. Note that even though your report is closed, you can still reply to this mail. Cheers, FJP [1] http://d-i.alioth.debian.org/manual/ ---End Message---
Re: Bug#394970: finish-install: [powerpc64] Add support for IBM serial consoles (hvc and hvsi)
On Thu, Nov 23, 2006 at 02:32:53PM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Would it not be better to use the variable in rootskel to detect that the terminal is a serial terminal, namely those who delcare themselves to be : TERM_TYPE=serial in rootskel/src/lib/debian-installer/detect-console-linux I think it can be an interesting option to investigate. How deeply would be the patch to do that? I am not sure. There may be some trick, since the TERM_TYPE case has more serial devices than the finish-install one. That said, i think we could check for TERM_TYPE=serial, and if so, guess the console from $console, with a few heuristic for the less evident cases. I would like comments from Bastian, and others with knowledge of the less evident detect-console-linux serial cases to go further here. Furthermore, i have personally found out that it is interesting to enable a serial console in /etc/inittab even in non-serial installs, Maybe a debconf question of low priority would allow this to be preseeded or set in expert installs ? Maybe too late for etch now, but still something to keep in mind. Interesting. That would help indeed. But maybe instead of enabling it by default or using a debconf question would be eaiser to use a command line param to enable it. What do you think? The best would be a defaulting to no debconf question, maybe even a n invisible one, so you can preseed it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dictionaries-common prompts users FIVE times during a default French desktop install
How do you manage to install both at the same time? triggerred by tasksel as it seems More things, I remember to have been prompted when apt-utils was not installed and so, no pre-configuration was possible or, when due to space limitation in the /var partition some sort of debconf database corruption happened. No way this can be a limitation in /var. This install was done in a 6GB partition and I was only using one partition. signature.asc Description: Digital signature
Re: d-i runs out of RAM on 32 MB machine with 1 GB hard drive
* Frans Pop [EMAIL PROTECTED] [2006-11-23 12:33]: recipe for arm/ixp4xx if that's preferred. Which version of the patch should I apply? One changing 64 MB minimum swap to 96 MB on all systems or one that only does it on arm/ixp4xx? I don't see any problem with making the change globally. It should not have any effect anyway except when using really small target media. I've commited to this CVS now. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#399951: RC1 on a NSLU2, 1GB usb drive
Processing commands for [EMAIL PROTECTED]: clone 399951 -1 Bug#399951: RC1 on a NSLU2, 1GB usb drive Bug 399951 cloned as bug 400074. reassign -1 partman Bug#400074: RC1 on a NSLU2, 1GB usb drive Bug reassigned from package `installation-reports' to `partman'. retitle -1 hangs at 50% - cd /var/lib/partman/devices/=dev=mtdblock0 / open_dialog DUMP Bug#400074: RC1 on a NSLU2, 1GB usb drive Changed Bug title. 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#399951: RC1 on a NSLU2, 1GB usb drive
clone 399951 -1 reassign -1 partman retitle -1 hangs at 50% - cd /var/lib/partman/devices/=dev=mtdblock0 / open_dialog DUMP thanks * Emanuele Rocca [EMAIL PROTECTED] [2006-11-23 00:37]: There's a known issue [0] installing over ssh on a 1GB hard drive in low mem. Without a big enough swap partition the ssh daemon goes out of memory creating the root fs, disconnecting the user. Moreover, trying to login again to resume the installation, partman hangs doing: cd /var/lib/partman/devices/=dev=mtdblock0 open_dialog DUMP (from /lib/partman/init.d/35dump) I've seen this too. BTW, besides from this issue, the installation was perfect, congrats for the really fine job. I've been able to complete the installation twice, the first time with a 128M swap partition, and now even with a smaller one, as suggested by Otavio [1], just 96M. The partman-auto reciepe for put everything in one partition creates a swap area of around 80M, which are not enough; I'd suggest to raise the default size, maybe only if in low-mem. I've commited a fix for this to SVN. -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RC1 with auto-RAID and graphical preseeding
Otavio, I just noticed that after installing RC1 with partman-auto- raid preseed and then using the installgui option (which didn't work well using preseed), my GRUB menu got the following [rough] structure: Debian GNU/Linux 2.6.17 (the newest entry, using installgui) Debian GNU/Linux 2.6.17 ... (from the old installation that failed to boot GRUB!) Amazing! So I tried to boot the second one (after checking kernel parameters - all of them were ok) It worked, and now I'm investigating what the hell is going on with the my preseed. Somehow, GRUB isn't being installed correctly in both disks, although the same config is being used in both methods (GUI and text) :-( I'll save the logs and post them as soon as I get them. Thanks for helping! -- caio[1982] begotti http://caio.ueberalles.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deactivated languages
Christian Perrier wrote: About the stripping, isn't this already done in the installer via white listing? Christian? Not sure what you're talking about so it's hard for me to answer. The udebs are downloaded/fetched during the build, but how are deactivated languages' translations away from the installer? Do they not enter the packages in the first place (before udeb build time)? Or are the translations for the activated languages *selected* from the udeb to enter the image and the rest of the translation are dropped. If is the first case (not entering in the first place) we could change to the second scheme and thus be able to create more initrd images which could be placed on the same ISO image and could be selected individually from the same media at boot time. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
On Thu, Nov 23, 2006 at 02:29:25PM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Also, I wonder if all listed modules really need to be modprobed individually: modprobe will after all load modules that other modules depend on automatically. Well, this is not how things are, after investigation and discussion with Benjamin Herrenschmidt, the powerpc/powermac linux kernel maintainer. The current way of doing this is the best compromise for within the 2.6.18 and etch timeframe. What's the plan for lenny? Is it going to change on 2.6.19 or so? lenny is etch +1. If lenny take the same time as etch, 18 months, we could have 2.6.24 for lenny. I hope that this would be fixed by then. I would expect that i2c-powermac and windfarm_core can safely be dropped. And you would expect wrong. When are you going to stop to try to second guess the work and investigation i do, and try by all mean to show me as incapable ? Hold on Sven... I need to agree here with Frans. We always should try to reduce the amount of code and looks like there's a lot of dependent module being loaded by hand in your patch. If it has a reason, it's ok but you need to tell us about it. Ok, fine, i guess benh will wlecome your patches. If upstream tells me we need to work on this, but right now it is not possible otherwise, i tend to believe him. It is also upstream work, and i don't really have time for it, and in any case, we don't have the time for etch to get those patches migrated upstream, which is needed accordying to the debian/kernel team policy, and it will be available at the earliest in 2.6.20 if we submit it today. It's impossible to you, Frans or everyone to know about everything on every arch so as a D-I RM Frans did a question and I think you can just reply to it as I usually do and many others does too. There's no try to show you as incapable person. This would be the case if : 1) he had commented on the bug during the month it had been open. 2) he had considered including the pacth last week when he did the 1.42 upload. 3) he had asked me about the breakage and we had uploaded a fixed package instead of reverting it. This being not the case, and he keeping me in a unfair and humiliating position since over 6 months, i am very justified to critic him on this. And yes, in case you didn't notice, i am angry about the way i have been handled, and now, so many months after the fact, i am rightly angered. They cannot be dropped, especially i2c-powermac cannot be dropped, since it will not be pulled in by the other modules. There are numerous comments about this fact on both debian-kernel and debian-powerpc, as well as numerous irc conversations on debian-kernel, where you are also present. Isn't it a bug that could be solve on kernel itself? Sure, but see above. So, either you chose to get involved, and try to stay informed about the different powerpc developments, or you don't, but then it is only fair to ask you to trust my knowledge and competence, as well as the interaction with the upstream linux/powerpc community such as Benjamin Herrenschmidt. Your current attitude is quite insulting to them and me, please modify it. Please modify your action too. Maybe, but it has been since late april, so ... As you know I worry about ppc status and try to be updated about it. I'm still lacking the need hardware to work on it but it should change in near future and I'll get more involviment on it as I did before when I had an iBook. Besides, we all do mistake and you aren't different. Sure, i am different, i am the only one who is outcast and humiliated like i am. We should try to review our code and patches to ensure a high quality on d-i and it should be done when the patches are pending to be commited as Frans is doing now. Please calm down and just reply for He is only commiting and comenting on them because i did the upload on sunday, and because i raised a fuss over the revert upload from him. If he had come to me, and commented about the bug in question, this would be something else, but given the way this happened, added to the humiliating handling i am getting from frans and a few others, ... the questions and then I'm sure Frans will commit the patch also because it's really need for a proper ppc support from d-i side. Indeed, but the patch was commited a whole month ago, and frans did an upload of rootskel a week ago, and didn't even bother considering the patch in question, even though i told him repeteadly that doing d-i test installation on the XServe without it is really health damaging. I always end up with a headache and if i work at night, i wake the kids. That is how loud it is. Finally, why was S50directfb-linux-powerpc added in the Makefile? This seems unrelated to this patch. It was not. Or should not have been. If it was, it is uniquely a result of a bad
Re: IMPORTANT: Significant changes to CD/DVD build setup
On Nov 23, 2006, at 8:58 AM, Steve McIntyre wrote: 2) dinstall and the mirror pulse are now happening twice daily, which means we will get two daily build runs. *Right* now the second daily build will automatically overwrite the first each day, but I'm going to change the scripts on farbror and bla to keep both, as date-1 and date-2. The arch-latest links will still be kept up-to-date to keep external links pointing at the latest build. Any comments, please let me know... Occasionally, in the past, it has happened by accident that there were two daily builds done on the same day. As you note, the second one overwrote the first. This caused some confusion as the two were significantly different in their behavior (at least the one time I'm thinking of particularly) and it took me a while to figure out that they were different builds, and I wasn't going crazy! So, I ask that you code it is a way that if three or more daily builds just happen to get done in one day, it won't overwrite anything. Maybe a name scheme based on the date, hour, and minute of the build? Thanks! Rick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400064: marked as done (autopartkit: FTBFS: No rule to make target `mapdevfs.o')
Your message dated Thu, 23 Nov 2006 19:25:32 +0100 with message-id [EMAIL PROTECTED] and subject line Bug#400064: autopartkit: FTBFS: No rule to make target `mapdevfs.o' 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: autopartkit Version: 1.21 Severity: serious Hello, There was a problem while autobuilding your package: At 1164265143 time_t, [EMAIL PROTECTED] wrote: Automatic build of autopartkit_1.21 on avidan by sbuild/i386 98 Build started at 20061123-0758 ** ... checking for ped_disk_write... no checking for ped_partition_get_path... yes configure: creating ./config.status /bin/sh ./config.status config.status: creating Makefile config.status: creating autopartkit.d/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: Entering directory `/build/buildd/autopartkit-1.21' cd . /bin/sh /build/buildd/autopartkit-1.21/missing --run autoheader /build/buildd/autopartkit-1.21/missing: line 52: autoheader: command not found WARNING: `autoheader' is missing on your system. You should only need it if you modified `acconfig.h' or `configure.ac'. You might want to install the `Autoconf' and `GNU m4' packages. Grab them from any GNU archive site. rm -f stamp-h1 touch config.h.in /usr/bin/make all-recursive make[2]: Entering directory `/build/buildd/autopartkit-1.21' Making all in autopartkit.d make[3]: Entering directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/build/buildd/autopartkit-1.21/autopartkit.d' make[3]: Entering directory `/build/buildd/autopartkit-1.21' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT distribute.o -MD -MP -MF .deps/distribute.Tpo -c -o distribute.o distribute.c; \ then mv -f .deps/distribute.Tpo .deps/distribute.Po; else rm -f .deps/distribute.Tpo; exit 1; fi distribute.c: In function 'distribute_partitions': distribute.c:167: warning: ISO C90 does not support 'long long' distribute.c:167: warning: ISO C90 does not support 'long long' if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT loadpartitions.o -MD -MP -MF .deps/loadpartitions.Tpo -c -o loadpartitions.o loadpartitions.c; \ then mv -f .deps/loadpartitions.Tpo .deps/loadpartitions.Po; else rm -f .deps/loadpartitions.Tpo; exit 1; fi if gcc -DHAVE_CONFIG_H -I. -I. -I. -Wall -W -Os -pedantic -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -Os -fomit-frame-pointer -MT lvm.o -MD -MP -MF .deps/lvm.Tpo -c -o lvm.o lvm.c; \ then mv -f .deps/lvm.Tpo .deps/lvm.Po; else rm -f .deps/lvm.Tpo; exit 1; fi lvm.c: In function 'vg_exists': lvm.c:87: warning: unused variable 'devpath' lvm.c:86: warning: unused variable 'statbuf' make[3]: *** No rule to make target `mapdevfs.o', needed by `autopartkit'. Stop. make[3]: Leaving directory `/build/buildd/autopartkit-1.21' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/buildd/autopartkit-1.21' make[1]: *** [all] Error 2 make[1]: Leaving directory `/build/buildd/autopartkit-1.21' make: *** [build-stamp] Error 2 ** Build finished at 20061123-0759 FAILED [dpkg-buildpackage died] -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD pgprmwqlyo6Ps.pgp Description: PGP signature ---End Message--- ---BeginMessage--- On Thursday 23 November 2006 18:28, Julien Danjou wrote: There was a problem while autobuilding your package: Already fixed with an upload (1.22) a bit later yesterday. ---End Message---
Re: RC1 with auto-RAID and graphical preseeding
Caio Begotti [EMAIL PROTECTED] writes: Otavio, I just noticed that after installing RC1 with partman-auto- raid preseed and then using the installgui option (which didn't work well using preseed), my GRUB menu got the following [rough] structure: Debian GNU/Linux 2.6.17 (the newest entry, using installgui) Debian GNU/Linux 2.6.17 ... (from the old installation that failed to boot GRUB!) what's the difference of resulting menu? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IMPORTANT: Significant changes to CD/DVD build setup
On Thu, Nov 23, 2006 at 01:22:58PM -0500, Rick Thomas wrote: On Nov 23, 2006, at 8:58 AM, Steve McIntyre wrote: 2) dinstall and the mirror pulse are now happening twice daily, which means we will get two daily build runs. *Right* now the second daily build will automatically overwrite the first each day, but I'm going to change the scripts on farbror and bla to keep both, as date-1 and date-2. The arch-latest links will still be kept up-to-date to keep external links pointing at the latest build. Any comments, please let me know... Occasionally, in the past, it has happened by accident that there were two daily builds done on the same day. As you note, the second one overwrote the first. This caused some confusion as the two were significantly different in their behavior (at least the one time I'm thinking of particularly) and it took me a while to figure out that they were different builds, and I wasn't going crazy! So, I ask that you code it is a way that if three or more daily builds just happen to get done in one day, it won't overwrite anything. Maybe a name scheme based on the date, hour, and minute of the build? The system as it's set up now will increment a build number for each build it does, resetting to 1 again as the day changes. Hopefully that will suffice for you...? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Is there anybody out there? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Dictionaries-common prompts users FIVE times during a default French desktop install
On Thu, Nov 23, 2006 at 06:37:01PM +0100, Frans Pop wrote: On Thursday 23 November 2006 18:05, Agustin Martin wrote: More things, I remember to have been prompted when apt-utils was not installed and so, no pre-configuration was possible or, when due to space limitation in the /var partition some sort of debconf database corruption happened. So, does the problem appear at the pre-configure or at the postinst stage? Do other questions appear at the pre-configure stage? Can you provide us with a version of the relevant package(s) (probably only dictionaries-common) that dump some debugging output somewhere (stderr will work)? I feel we are going around in circles on this issue and having a version for testing that _shows_ what is happening would probably allow us to do some real tracing instead of speculating. Current dictionaries-common package already provides info to STDERR during the first installation (and preconfiguration) if envvar DICT_COMMON_DEBUG is set. It is however only about the process of default dict selection, but if no preconfiguration is happenning, that info will not be shown. No info is currently shown for individual dicts install, but I can try adding some details about old and new choices if needed. Cheers, -- Agustin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC1 with auto-RAID and graphical preseeding
On 23/11/2006, at 16:51, Otavio Salvador wrote: what's the difference of resulting menu? The second (to boot the array) works and was right generated, but the MBR recording seems to have failed. -- caio[1982] begotti http://caio.ueberalles.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
Sven Luther [EMAIL PROTECTED] writes: Well, this is not how things are, after investigation and discussion with Benjamin Herrenschmidt, the powerpc/powermac linux kernel maintainer. The current way of doing this is the best compromise for within the 2.6.18 and etch timeframe. What's the plan for lenny? Is it going to change on 2.6.19 or so? lenny is etch +1. If lenny take the same time as etch, 18 months, we could have 2.6.24 for lenny. I hope that this would be fixed by then. Ok :-D I would expect that i2c-powermac and windfarm_core can safely be dropped. And you would expect wrong. When are you going to stop to try to second guess the work and investigation i do, and try by all mean to show me as incapable ? Hold on Sven... I need to agree here with Frans. We always should try to reduce the amount of code and looks like there's a lot of dependent module being loaded by hand in your patch. If it has a reason, it's ok but you need to tell us about it. Ok, fine, i guess benh will wlecome your patches. If upstream tells me we need to work on this, but right now it is not possible otherwise, i tend to believe him. It is also upstream work, and i don't really have time for it, and in any case, we don't have the time for etch to get those patches migrated upstream, which is needed accordying to the debian/kernel team policy, and it will be available at the earliest in 2.6.20 if we submit it today. Even if the patch is simple? (I mean for inclusion on Debian patch queue). It's impossible to you, Frans or everyone to know about everything on every arch so as a D-I RM Frans did a question and I think you can just reply to it as I usually do and many others does too. There's no try to show you as incapable person. This would be the case if : 1) he had commented on the bug during the month it had been open. 2) he had considered including the pacth last week when he did the 1.42 upload. 3) he had asked me about the breakage and we had uploaded a fixed package instead of reverting it. I more or less agree with you here. I agree that would have another ways to handle things but also I don't think if he doesn't do what I or you think is the right thing todo he's completely wrong. He has the right to think different from us and follow his thoughts about it. This being not the case, and he keeping me in a unfair and humiliating position since over 6 months, i am very justified to critic him on this. And yes, in case you didn't notice, i am angry about the way i have been handled, and now, so many months after the fact, i am rightly angered. Please ... you're humiliating yourself. It's not he who's humiliating you. Just do a great patch, prove that you're a good and trustable porter and he won't have options but allow you back. As you know I worry about ppc status and try to be updated about it. I'm still lacking the need hardware to work on it but it should change in near future and I'll get more involviment on it as I did before when I had an iBook. Besides, we all do mistake and you aren't different. Sure, i am different, i am the only one who is outcast and humiliated like i am. Read above... We should try to review our code and patches to ensure a high quality on d-i and it should be done when the patches are pending to be commited as Frans is doing now. Please calm down and just reply for He is only commiting and comenting on them because i did the upload on sunday, and because i raised a fuss over the revert upload from him. If he had come to me, and commented about the bug in question, this would be something else, but given the way this happened, added to the humiliating handling i am getting from frans and a few others, ... Let's have a deal. When you don't receive a comment on a bug, please ping me. There're a lot of reason to it happen not only disagreements with you. There're a bunch of bugs to handle on d-i and sometimes those bugs are forgotten. Just bring my attention to them and I can try to coordenate it. Indeed, but the patch was commited a whole month ago, and frans did an upload of rootskel a week ago, and didn't even bother considering the patch in question, even though i told him repeteadly that doing d-i test installation on the XServe without it is really health damaging. I always end up with a headache and if i work at night, i wake the kids. That is how loud it is. Read above... Finally, why was S50directfb-linux-powerpc added in the Makefile? This seems unrelated to this patch. It was not. Or should not have been. If it was, it is uniquely a result of a bad manipulation caused by me not having the svn commit right, and you are as thus solely to blame for it. But seriously, find attached my svn diff, there is no trace of a S50directfb-linux-powerpc in my diff, if it was there, it most probably did come from an older commit. I did in fact do an apt-get
Re: RC1 with auto-RAID and graphical preseeding
Caio Begotti [EMAIL PROTECTED] writes: On 23/11/2006, at 16:51, Otavio Salvador wrote: what's the difference of resulting menu? The second (to boot the array) works and was right generated, but the MBR recording seems to have failed. Paste them, please. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RC1 with auto-RAID and graphical preseeding
Caio Begotti [EMAIL PROTECTED] writes: On 23/11/2006, at 16:51, Otavio Salvador wrote: what's the difference of resulting menu? The second (to boot the array) works and was right generated, but the MBR recording seems to have failed. Paste them please ... -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
On Thu, Nov 23, 2006 at 05:19:44PM -0200, Otavio Salvador wrote: Even if the patch is simple? (I mean for inclusion on Debian patch queue). Well, i have not looked into it. If the patch is scheduled for upstreamn inclusion at a later point, and thus of upstream quality, then we can include it. It's impossible to you, Frans or everyone to know about everything on every arch so as a D-I RM Frans did a question and I think you can just reply to it as I usually do and many others does too. There's no try to show you as incapable person. This would be the case if : 1) he had commented on the bug during the month it had been open. 2) he had considered including the pacth last week when he did the 1.42 upload. 3) he had asked me about the breakage and we had uploaded a fixed package instead of reverting it. I more or less agree with you here. I agree that would have another ways to handle things but also I don't think if he doesn't do what I or you think is the right thing todo he's completely wrong. He has the right to think different from us and follow his thoughts about it. He has the right to think anything he want, as long as he doesn't hurt others by doing so. By virtue of the power over d-i he wields, and since he is apparently not able to separate a personal dispute from his d-i responsabilities, his thoughts in this issue are hurting both me and our users. This being not the case, and he keeping me in a unfair and humiliating position since over 6 months, i am very justified to critic him on this. And yes, in case you didn't notice, i am angry about the way i have been handled, and now, so many months after the fact, i am rightly angered. Please ... you're humiliating yourself. It's not he who's humiliating you. Right. Especially as the main complaint against me seems to be that i am not respectful enough of him, exact ? Just do a great patch, prove that you're a good and trustable porter and he won't have options but allow you back. This would be the case if we where facing someone reasonable and honest. But go look at the wiki patches where i list all my contributions since june or so, and even so, it if not enough, and my contributions are : the biggest load of self-satisfied and self-centered crap [he has] ever seen. http://wiki.debian.org/DebianInstaller/FransPopAndOthersVs.SvenLutherIssue/SvenLuther#head-69bb71fe3ef5766e46624ff746cd888a4591a6c6 Let's have a deal. When you don't receive a comment on a bug, please ping me. There're a lot of reason to it happen not only disagreements with you. There're a bunch of bugs to handle on d-i and sometimes those bugs are forgotten. Just bring my attention to them and I can try to coordenate it. Yeah, fine, and when will i no more be an outcast, and will get back all the right normally attributed to everyone who is contributing to d-i ? I don't know from where it comes, it is not in my local svn checkout, so ... So please send another reviewed patch that I can apply :-D I will, but i have no access to the box to test it until this WE. The patch is so trivial you can just as well fix it yourself. I attached the modified version of the patch with frans suggestion. The original proposal was coming either from code copied from elsewhere on d-i or from a suggestion from someone on #debian-boot, i don't remember exactly the details, it is over a month ago now. Again this would not have happened if frans was more reasonable, and let people work while he is vacationing all over the world. Friendly, Sven Luther Index: debian/changelog === --- debian/changelog(revision 42042) +++ debian/changelog(working copy) @@ -1,3 +1,12 @@ +rootskel (1.42) UNRELEASED; urgency=low + + [ Sven Luther ] + * Added S05fancontrol-linux-powerpc, in order to actually load the +fancontrol modules, in order to not have G5 apple box go into aircraft +noise level a few minutes after the start of the installation. + + -- Sven Luther [EMAIL PROTECTED] Mon, 23 Oct 2006 20:13:59 +0200 + rootskel (1.41) unstable; urgency=low * Rebuild against klibc 1.4.29-1 to make cpio in rootskel-bootfloppy work Index: src/lib/debian-installer-startup.d/S05fancontrol-linux-powerpc === --- src/lib/debian-installer-startup.d/S05fancontrol-linux-powerpc (revision 0) +++ src/lib/debian-installer-startup.d/S05fancontrol-linux-powerpc (revision 0) @@ -0,0 +1,13 @@ +# Load fan control modules, to stop the fans to go into aircraft-db levels +modprobe i2c-powermac || true +modprobe therm_pm72 || true +modprobe windfarm_core || true +modprobe windfarm_cpufreq_clamp || true +modprobe windfarm_lm75_sensor || true +modprobe windfarm_max6690_sensor || true +modprobe windfarm_pid || true +modprobe windfarm_pm81 || true +modprobe windfarm_pm91 || true +modprobe windfarm_smu_sat
linux-kernel-di-arm-2.6_1.5_arm.changes ACCEPTED
Accepted: cdrom-core-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/cdrom-core-modules-2.6.18-3-footbridge-di_1.5_arm.udeb cdrom-core-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/cdrom-core-modules-2.6.18-3-iop32x-di_1.5_arm.udeb crc-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/crc-modules-2.6.18-3-footbridge-di_1.5_arm.udeb crc-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/crc-modules-2.6.18-3-iop32x-di_1.5_arm.udeb crc-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/crc-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb ext3-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/ext3-modules-2.6.18-3-iop32x-di_1.5_arm.udeb ext3-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/ext3-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb fat-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/fat-modules-2.6.18-3-footbridge-di_1.5_arm.udeb fat-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/fat-modules-2.6.18-3-iop32x-di_1.5_arm.udeb fat-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/fat-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb fat-modules-2.6.18-3-rpc-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/fat-modules-2.6.18-3-rpc-di_1.5_arm.udeb ide-core-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/ide-core-modules-2.6.18-3-iop32x-di_1.5_arm.udeb ide-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/ide-modules-2.6.18-3-footbridge-di_1.5_arm.udeb ide-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/ide-modules-2.6.18-3-iop32x-di_1.5_arm.udeb input-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/input-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb kernel-image-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/kernel-image-2.6.18-3-footbridge-di_1.5_arm.udeb kernel-image-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/kernel-image-2.6.18-3-iop32x-di_1.5_arm.udeb kernel-image-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/kernel-image-2.6.18-3-ixp4xx-di_1.5_arm.udeb kernel-image-2.6.18-3-rpc-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/kernel-image-2.6.18-3-rpc-di_1.5_arm.udeb linux-kernel-di-arm-2.6_1.5.dsc to pool/main/l/linux-kernel-di-arm-2.6/linux-kernel-di-arm-2.6_1.5.dsc linux-kernel-di-arm-2.6_1.5.tar.gz to pool/main/l/linux-kernel-di-arm-2.6/linux-kernel-di-arm-2.6_1.5.tar.gz loop-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/loop-modules-2.6.18-3-footbridge-di_1.5_arm.udeb loop-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/loop-modules-2.6.18-3-iop32x-di_1.5_arm.udeb loop-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/loop-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb loop-modules-2.6.18-3-rpc-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/loop-modules-2.6.18-3-rpc-di_1.5_arm.udeb md-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/md-modules-2.6.18-3-footbridge-di_1.5_arm.udeb md-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/md-modules-2.6.18-3-iop32x-di_1.5_arm.udeb md-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/md-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb nic-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/nic-modules-2.6.18-3-footbridge-di_1.5_arm.udeb nic-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/nic-modules-2.6.18-3-iop32x-di_1.5_arm.udeb nic-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/nic-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb nic-shared-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/nic-shared-modules-2.6.18-3-footbridge-di_1.5_arm.udeb nic-usb-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/nic-usb-modules-2.6.18-3-iop32x-di_1.5_arm.udeb nic-usb-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/nic-usb-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb reiserfs-modules-2.6.18-3-footbridge-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/reiserfs-modules-2.6.18-3-footbridge-di_1.5_arm.udeb reiserfs-modules-2.6.18-3-iop32x-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/reiserfs-modules-2.6.18-3-iop32x-di_1.5_arm.udeb reiserfs-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb to pool/main/l/linux-kernel-di-arm-2.6/reiserfs-modules-2.6.18-3-ixp4xx-di_1.5_arm.udeb
Re: RC1 with auto-RAID and graphical preseeding
On 23/11/2006, at 17:22, Otavio Salvador wrote: The second (to boot the array) works and was right generated, but the MBR recording seems to have failed. Paste them please ... I forgot to save it... here it is now, attached. This menu.lst was generated by installgui without much preseeding, as I said. The other operating systems entry was created 'cause I installed it with partman-auto-raid before that, which failed when recording the MBR. -- caio[1982] begotti http://caio.ueberalles.net menu.lst Description: Binary data
Processed: Re: Bug#400079: [INTL:tlh] Wolof debconf templates translation
Processing commands for [EMAIL PROTECTED]: reassign 400079 tasksel Bug#400079: [INTL:tlh] Wolof debconf templates translation Bug reassigned from package `debconf' to `tasksel'. tags 400079 pending Bug#400079: [INTL:tlh] Wolof debconf templates translation Tags were: l10n 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]
Re: Bug#394971: [powerpc64] load the fan control modules
Sven Luther [EMAIL PROTECTED] writes: Let's have a deal. When you don't receive a comment on a bug, please ping me. There're a lot of reason to it happen not only disagreements with you. There're a bunch of bugs to handle on d-i and sometimes those bugs are forgotten. Just bring my attention to them and I can try to coordenate it. Yeah, fine, and when will i no more be an outcast, and will get back all the right normally attributed to everyone who is contributing to d-i ? I wouldn't remove your credit. Of course. I'm not interested on credit but work done. I don't know from where it comes, it is not in my local svn checkout, so ... So please send another reviewed patch that I can apply :-D I will, but i have no access to the box to test it until this WE. The patch is so trivial you can just as well fix it yourself. I attached the modified version of the patch with frans suggestion. The original proposal was coming either from code copied from elsewhere on d-i or from a suggestion from someone on #debian-boot, i don't remember exactly the details, it is over a month ago now. Again this would not have happened if frans was more reasonable, and let people work while he is vacationing all over the world. AFAIK he wasn't on vacation but working. Besides it's not our business. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
Sven Luther [EMAIL PROTECTED] writes: Index: src/lib/debian-installer-startup.d/Makefile === --- src/lib/debian-installer-startup.d/Makefile (revision 42042) +++ src/lib/debian-installer-startup.d/Makefile (working copy) @@ -32,7 +32,9 @@ ifeq ($(DEB_HOST_ARCH_CPU),powerpc) files += \ - S45keyboard-linux-powerpc + S05fancontrol-linux-powerpc \ + S45keyboard-linux-powerpc \ + S50directfb-linux-powerpc endif ifneq (,$(filter mips mipsel,$(DEB_HOST_ARCH_CPU))) Same error as before. Please, review the patch and remove the directfb change since it's unrelated to this patch. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: other fallback languages Re: Deactivated languages
Jens Seidel wrote: On Wed, Nov 22, 2006 at 12:29:49PM -0500, Matthias Julius wrote: Christian Perrier [EMAIL PROTECTED] writes: Quoting Matthias Julius ([EMAIL PROTECTED]): This could be avoided if the user gets to decide: Not all messages have been translated into the language you have chosen. Please select a fallback language. Indeed, this was what I thought. Theoretically, yes, but how would the installer know in advance that debconf templates are not translated competely? D-I is modular by nature so, at the moment localechooser is run, there is no possible way to know whether udebs are fully translated, or not, for the chosen language. Right, I first assumed that the udebs are created at the same time so that the translation status of all packages can be put into localechooser. Probably this approach works at least roughly, especially for official releases and release candidates. But I agree that putting these information into localechooser is not good idea. This information would need to be stored somewhere in a file created by the build process. No, not necessarily. I can imagine at least two solutions: * Let localechooser scan all udebs found in the initrd. The list of found udebs could probably provided by a debian-installer component itself (there must be already a component of d-i which scans all/most udebs to create the main menu). The contained templates file could be analysed on the fly ... This would miss all incomplete translations loaded from outside the initrd, such as via network. And the gain is where? You still need the translations of the languages from which you choose. So no space gain there. Also, your choice of available languages is based on the available languages in the translation of the following packages: anna, base-installer, (countrychooser,) cdebconf, debian-installer, di-utils-reboot, ethdetect, hw-detect, (languagechooser,) kbd-chooser, lowmem, mirror, netcfg, localechooser, preseed, retriever and save-logs (and probably some other arch specific packs). i am not sure if this is such a good idea. * Let debconf handle the alternative language approach and ask for an alternative if one debconf string is not translated! Of course not This must be first implemented :-) directly, but it would be possible to provide a hook script to debconf which is called once a translation is missing. This script needs to be provided by localechooser. Sounds nice. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Deactivated languages
The udebs are downloaded/fetched during the build, but how are deactivated languages' translations away from the installer? By removing the PO files from the packages in the SVN signature.asc Description: Digital signature
Re: Bug#397649: install-report: NTP sync missing by default
On Wed, Nov 22, 2006 at 04:10:40PM -0500, Rick Thomas wrote: On Nov 22, 2006, at 1:05 PM, Olaf van der Spek wrote: reopen 397649 thanks Could we have NTP by default? But it would be a problem for the minority who have no or only intermittent (e.g. dial-up) network access. Why would it be a problem? No network mean the Network Time Protocol won't work. Intermittent network (e.g. dial-up) means that NTP goes for long periods with no connection to the external time servers. The ntpd daemon is (mostly) OK with that, but some auto-dialers may see it's occasional polls as a reason to dial the ISP, which is probably not what the user expected. Instead of NTP you could use chrony which gets put offline with poff. Doug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch to handle touchpads in g-i available
Alejandro Rios Peña wrote: El mié, 22-11-2006 a las 16:44 +0100, Attilio Fiandrotti escribió: Hi I recently wrote a patch against DFB 0.9.25 which adds to linux_input the capability to translate absolute x,y coordinates generated by touchpads into relative ones: this allows using Synaptic touchpads with the g-i. The patch was sent for review to directfb-dev [1] and was said to be ok, updated patch is attached to this mail. I prepared an iso image [2] which includes the fix: i'm asking testers who previously reported their synaptics touchpad not working within g-i to test this iso and report results and feelings about how the touchpad works. I just tested the image and the touchpad works fine :) The only thing that doesn't work is the scrolling side of the touchpad, but I guess most users of the installer could live without it for now. on your pavillon dv1117 the patch should perform almost as X synaptics driver does (i developed the driver on a pavillon laptop) thanks for testing again cheers attilio -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#398333: Automatic partition/disk selection
On Thu, Nov 23, 2006 at 02:48:13PM +0100, Frans Pop wrote: On Friday 17 November 2006 11:28, David Härdeman wrote: On Fri, November 17, 2006 10:21, Frans Pop said: Because the method is not a question as such when using preseeding. We should handle the situation where partman-auto/disk is preseeded but partman-auto/method is not more gracefully though. How would you like it to work? I think we have two options: 1) Default to method regular If partman-auto/disk=/dev/* and partman-auto/method is not set, then default partman-auto/method to regular. 2) Error out if no method set If partman-auto/disk=/dev/* and partman-auto/method is not set, then show an error message and unset partman-auto/disk. I somewhat prefer 1) as it gives some backwards compatibility and 2) probably would mean adding a new error message which is undesirable for RC2. Said and done, patch attached for review. -- David Härdeman Index: debian/changelog === --- debian/changelog(revision 42849) +++ debian/changelog(working copy) @@ -5,8 +5,12 @@ is needed for installations on systems with 32 MB RAM and only a 1 GB drive. Closes: #399951. - -- Martin Michlmayr [EMAIL PROTECTED] Thu, 23 Nov 2006 18:51:38 +0100 + [ David Härdeman ] + * Use regular autopartition method if partman-auto/method has not been +set but partman-auto/disk has. Closes: #398333. + -- David Härdeman [EMAIL PROTECTED] Thu, 23 Nov 2006 22:29:54 +0100 + partman-auto (60) unstable; urgency=low [ Updated translations ] Index: init.d/initial_auto === --- init.d/initial_auto (revision 42849) +++ init.d/initial_auto (working copy) @@ -38,6 +38,9 @@ if db_get partman-auto/method [ -n $RET ]; then method=$RET fi +if [ -n $method ]; then + method=regular +fi # See if any autopartition disks have been set disks=
Please review #393728
It would be nice to have crypto-on-md working before the next RC release, so I'd appreciate it if someone could review the patch attached to bug report #393728. -- David Härdeman
Re: Debian Archive Automatic Signing Key (4.0/etch)?
On Wed, Nov 22, 2006 at 07:22:35AM +0100, Andreas Tille wrote: But Hendrik Sattler is perfectly right and this knowledge has to be stored at prominant places like: a) installation manual b) apt-key.8 c) perhaps somewhere else It is already at the Securing Debian Manual, see section 7.4 'Package signing in Debian': http://www.debian.org/doc/manuals/securing-debian-howto/ch7.en.html#s-deb-pack-sign I guess that qualifies for c). Of course, it could be improved, that's what patches are for. /me goes to waiting mode :) Regards Javier signature.asc Description: Digital signature
Bug#400107: installation-reports
Package: installation-reports please note that this is the identical machine as Bug#399882, however this time with debian testing. Boot method: business card install Image version: debian etch, beta 3, testing + selected testing distribution from German mirror Date: 2006-11-23 Machine: Motherboard Gigabyte GA-M55plus-S3G Processor: AMD Athlon 64 X3 3800+ AM2 Memory: 2GB Partitions: FilesystemType 1K-blocks Used Available Use% Mounted on /dev/hda3 ext338448304 2424148 34071056 7% / udev tmpfs 1024052 10188 1% /dev devshm tmpfs 1038148 0 1038148 0% /dev/shm Output of lspci -nn [EMAIL PROTECTED]:~$ lspci -nn 00:00.0 RAM memory [0500]: nVidia Corporation C51 Host Bridge [10de:02f5] (rev a2) 00:00.1 RAM memory [0500]: nVidia Corporation C51 Memory Controller 0 [10de:02fa] (rev a2) 00:00.2 RAM memory [0500]: nVidia Corporation C51 Memory Controller 1 [10de:02fe] (rev a2) 00:00.3 RAM memory [0500]: nVidia Corporation C51 Memory Controller 5 [10de:02f8] (rev a2) 00:00.4 RAM memory [0500]: nVidia Corporation C51 Memory Controller 4 [10de:02f9] (rev a2) 00:00.5 RAM memory [0500]: nVidia Corporation C51 Host Bridge [10de:02ff] (rev a2) 00:00.6 RAM memory [0500]: nVidia Corporation C51 Memory Controller 3 [10de:027f] (rev a2) 00:00.7 RAM memory [0500]: nVidia Corporation C51 Memory Controller 2 [10de:027e] (rev a2) 00:02.0 PCI bridge [0604]: nVidia Corporation C51 PCI Express Bridge [10de:02fc] (rev a1) 00:03.0 PCI bridge [0604]: nVidia Corporation C51 PCI Express Bridge [10de:02fd] (rev a1) 00:04.0 PCI bridge [0604]: nVidia Corporation C51 PCI Express Bridge [10de:02fb] (rev a1) 00:09.0 RAM memory [0500]: nVidia Corporation MCP51 Host Bridge [10de:0270] (rev a2) 00:0a.0 ISA bridge [0601]: nVidia Corporation MCP51 LPC Bridge [10de:0260] (rev a3) 00:0a.1 SMBus [0c05]: nVidia Corporation MCP51 SMBus [10de:0264] (rev a3) 00:0a.2 RAM memory [0500]: nVidia Corporation MCP51 Memory Controller 0 [10de:0272] (rev a3) 00:0b.0 USB Controller [0c03]: nVidia Corporation MCP51 USB Controller [10de:026d] (rev a3) 00:0b.1 USB Controller [0c03]: nVidia Corporation MCP51 USB Controller [10de:026e] (rev a3) 00:0d.0 IDE interface [0101]: nVidia Corporation MCP51 IDE [10de:0265] (rev a1) 00:0e.0 IDE interface [0101]: nVidia Corporation MCP51 Serial ATA Controller [10de:0266] (rev a1) 00:0f.0 IDE interface [0101]: nVidia Corporation MCP51 Serial ATA Controller [10de:0267] (rev a1) 00:10.0 PCI bridge [0604]: nVidia Corporation MCP51 PCI Bridge [10de:026f] (rev a2) 00:10.1 Audio device [0403]: nVidia Corporation MCP51 High Definition Audio [10de:026c] (rev a2) 00:14.0 Bridge [0680]: nVidia Corporation MCP51 Ethernet Controller [10de:0269] (rev a3) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:0e.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] 02:00.0 VGA compatible controller [0300]: nVidia Corporation NV44 [GeForce 6200 LE] [10de:0163] (rev a1) and lspci -vnn: lspci -vnn 00:00.0 RAM memory [0500]: nVidia Corporation C51 Host Bridge [10de:02f5] (rev a2) Subsystem: Giga-byte Technology Unknown device [1458:5000] Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: access denied 00:00.1 RAM memory [0500]: nVidia Corporation C51 Memory Controller 0 [10de:02fa] (rev a2) Subsystem: Giga-byte Technology Unknown device [1458:5000] Flags: 66MHz, fast devsel 00:00.2 RAM memory [0500]: nVidia Corporation C51 Memory Controller 1 [10de:02fe] (rev a2) Subsystem: Giga-byte Technology Unknown device [1458:5000] Flags: 66MHz, fast devsel 00:00.3 RAM memory [0500]: nVidia Corporation C51 Memory Controller 5 [10de:02f8] (rev a2) Subsystem: Giga-byte Technology Unknown device [1458:5000] Flags: 66MHz, fast devsel 00:00.4 RAM memory [0500]: nVidia Corporation C51 Memory Controller 4 [10de:02f9] (rev a2) Subsystem: Giga-byte Technology Unknown device [1458:5000] Flags: bus master, 66MHz, fast devsel, latency 0 00:00.5 RAM memory [0500]: nVidia Corporation C51 Host Bridge [10de:02ff] (rev a2) Subsystem: Giga-byte Technology Unknown device [1458:5000] Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: access denied 00:00.6 RAM memory [0500]: nVidia Corporation C51 Memory Controller 3 [10de:027f] (rev a2) Subsystem: Giga-byte Technology Unknown device [1458:5000] Flags: 66MHz, fast devsel 00:00.7 RAM memory [0500]: nVidia
Bug#399882: Package: installation-reports
find the /boot/grub/grub.conf attached. Please be aware that I have filed for the same machine another installation report some minutes ago. That time with debain etch (testing). I do not have the bug # ID yet. -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Gesendet: 22.11.06 19:59:39 An: [EMAIL PROTECTED] Betreff: Re: Bug#399882: Package: installation-reports reassign 399882 os-prober retitle 399882 Broken grub entries for multibooting Fedora thanks On Wednesday 22 November 2006 17:35, Michael Josenhans wrote: Comments/Problems: Bootloader did recognize Fedora Core 6 Partition already on the disk, however did not set boot parameters of that partition OK. FC6 Grub configuration should look as following: kernel /boot/vmlinuz-2.6.8-1.2798.fc6 ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.18-1.2798.fc6.img and for Xen configuration: kernel /boot/vmlinuz-2.6.8-1.2798.fc6 ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.18-1.2798.fc6xen.img I see four differences; somewhat in order of severity: - no initrd line - root should be set to LABEL=/ instead of /dev/hda1 - missing rhgb option What does this option do? Is it required or optional? - missing quiet option Not all of those were required. I had tried those seperately. I will come back to answer these questions. What bootloader are you using on the Fedora partition? on both, Debain and FC6 I used grub. Could you send us its configuration file? attached. Br, Michael __ Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! grub.conf Description: Binary data
Bug#400114: enable a serial console in /etc/inittab even in non-serial installs
Package: rootskel Severity: wishlist Op 23-11-2006 om 18:44 schreef Sven Luther: On Thu, Nov 23, 2006 at 02:32:53PM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Furthermore, i have personally found out that it is interesting to enable a serial console in /etc/inittab even in non-serial installs, Maybe a debconf question of low priority would allow this to be preseeded or set in expert installs ? Maybe too late for etch now, but still something to keep in mind. Interesting. That would help indeed. But maybe instead of enabling it by default or using a debconf question would be eaiser to use a command line param to enable it. What do you think? The best would be a defaulting to no debconf question, maybe even a n invisible one, so you can preseed it. Rewording the previous paragraph: A debconf question that is not show on normal installs, but will be visible at expert a.k.a. detailed install. Being a debconf question allows preseeding. Hey, that is like first paragraph. Anyway: enabling serial console is good thing. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Re: RC1 with auto-RAID and graphical preseeding
Otavio, I've sent the menu.lst to the list but seems that my previous message with both syslog files attached were rejected or something. Anyway, I uploaded them to my website... Using installgui, GRUB got installed right: http://caio.ueberalles.net/wip/syslog_gui.txt Using only install, not a bootable system: http://caio.ueberalles.net/wip/syslog_raid.txt Cheers, -- caio[1982] begotti http://caio.ueberalles.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397649: install-report: NTP sync missing by default
Op 22-11-2006 om 23:02 schreef Olaf van der Spek: There's a checkbox in the Gnome clock applet to enable NTP. But that doesn't work if it's not installed and I doubt the average user is easily able to install NTP. Then (ab)use the Gnome clock applet to get NTP installed. Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400107: installation-reports
Op 23-11-2006 om 22:31 schreef Michael Josenhans: [EMAIL PROTECTED]:~$ lspci -nn 01:0e.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB23 IEEE-1394a-2000 Controller (PHY/Link) [104c:8024] My motherboard has a build-in network card. during install, the debian installer provided me the following options: eth0: Ethernet or Fast Ethernet eth1: nVidia Corporation MCP51 Ethernet Controller I had selected 'eth1'. the eth0 is the fire-wire card, it is a known bug. Cheers Geert Stappers (only commenting on the dual eth issue) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: IMPORTANT: Significant changes to CD/DVD build setup
Op 23-11-2006 om 14:42 schreef Steve McIntyre: On Thu, Nov 23, 2006 at 03:27:03PM +0100, Frans Pop wrote: On Thursday 23 November 2006 14:58, Steve McIntyre wrote: I'm going to change the scripts on farbror and bla to keep both, as date-1 and date-2. The arch-latest links will still be kept I'm not so sure that having two builds is really that good an idea. In almost all cases the images will be virtually identical, especially with regard to d-i. And as we're only talking about small images, the number of debs included is relatively small. There should be plenty of space to keep 6 sets rather than the current 3, so I've changed the setup to do that. Alternatively, if you only want one set built per day that's also entirely possible. You'll just need to let me know which of the 2 possible builds you want. :-) Another reason for one set built each day, is that no one will see date-1 and date-2 as part-1 and part-2. Please stick to _one_ daily build. Schedule the build start 00:05 UTC or another time that might be recognised world wide as begin of a day Cheers Geert Stappers Yes, infact I ask to _not_ burn all the CPU power that you have. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Patch to handle touchpads in g-i available
On Thu, 23 Nov 2006 14:37:28 +0100 Attilio Fiandrotti [EMAIL PROTECTED] wrote: Holger, could you please check if cursor speed and touchpad sensitivity is similar to that in X? do you see any big difference between the g-i and Xorg ? Sensitivity: no difference detectable Speed: while others (Frans and you?) mentioned very slow speed, I have higher speed compared with XFree86 (I have Sarge running, so I can only compare with XFree86, not X.org, if this makes a difference (different version of synaptics driver in X?)) Speed is faster as in X, but not so fast, that it would be unusable. I can position the cursor on everything I want without any problems. So it's ok here. Holger -- Created with Sylpheed 2.0.4 under Debian GNU/LINUX 3.1 Sarge Registered LinuxUser #311290 Spam filtering by bogofilter.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#398333: Automatic partition/disk selection
David Härdeman [EMAIL PROTECTED] writes: Index: init.d/initial_auto === --- init.d/initial_auto (revision 42849) +++ init.d/initial_auto (working copy) @@ -38,6 +38,9 @@ if db_get partman-auto/method [ -n $RET ]; then method=$RET fi +if [ -n $method ]; then + method=regular +fi # See if any autopartition disks have been set disks= Can't it be done using an else block? Looks sanner to me. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house.
Bug#400124: Buttons in the GTK frontend are not properly setup
package: cdebconf-gtk-udeb
severity: minor
tags: patch
Currently the screenshot and cancel buttons are setup sensitive in
gtk_initialize(), so if a long time should pass between
frontend_intialize()
and frontend_go(), the user may be able to click them.
As the gtk_main() loop is already running there should be no risk of
crashing anything, but anyway this patch disables those buttons in
gtk_initialize(), like it's already done for back and cancel buttons.
Hiding them, as it's done now, has no effect, and this should be fixed
because it's wrong.
The attached patch also takes care of hiding ok, back and screenshot
buttons while the progressbar is running and CAPB progresscancel is not
set (it makes no sense, IMHO, displaying disabled buttons)
cheers
Attilio
Index: gtk.c
===
--- gtk.c (revisione 42838)
+++ gtk.c (copia locale)
@@ -1315,11 +1315,12 @@
gtk_button_box_set_layout (GTK_BUTTON_BOX(actionbox), GTK_BUTTONBOX_END);
gtk_box_set_spacing (GTK_BOX(actionbox), DEFAULT_PADDING);
-/* button to take screenshots of the frontend */
+/* Screenshot button is set insensitive by default */
button_screenshot = gtk_button_new_with_label (get_text(obj, debconf/gtk-button-screenshot, Screenshot));
g_signal_connect (G_OBJECT (button_screenshot), clicked, G_CALLBACK (screenshot_button_callback), obj );
gtk_box_pack_start (GTK_BOX(actionbox), button_screenshot, TRUE, TRUE, DEFAULT_PADDING);
((struct frontend_data*) obj-data)-button_screenshot = button_screenshot;
+gtk_widget_set_sensitive (button_screenshot, FALSE);
/* Here are the back and forward buttons */
button_prev = gtk_button_new_with_label (get_text(obj, debconf/button-goback, Go Back));
@@ -1344,7 +1345,7 @@
gtk_widget_set_sensitive (button_prev, FALSE);
gtk_widget_set_sensitive (button_next, FALSE);
-/* Cancel button is not displayed by default */
+/* Cancel button is set insensitive by default */
button_cancel = gtk_button_new_with_label (get_text(obj, debconf/button-cancel, Cancel));
ret_val = NEW(int);
*ret_val = DC_GOBACK;
@@ -1353,7 +1354,7 @@
G_CALLBACK(cancel_button_callback), obj);
gtk_box_pack_start (GTK_BOX(actionbox), button_cancel, TRUE, TRUE, DEFAULT_PADDING);
((struct frontend_data*) obj-data)-button_cancel = button_cancel;
-gtk_widget_hide(button_cancel);
+gtk_widget_set_sensitive (button_cancel, FALSE);
/* focus order inside actionbox */
focus_chain = g_list_append(focus_chain, button_next);
@@ -1679,13 +1680,14 @@
gtk_widget_hide(data-button_prev);
gtk_widget_hide(data-button_next);
gtk_widget_show(data-button_cancel);
+gtk_widget_set_sensitive (data-button_cancel, TRUE);
GTK_WIDGET_SET_FLAGS (GTK_WIDGET(data-button_cancel), GTK_CAN_DEFAULT);
gtk_widget_grab_default (GTK_WIDGET(data-button_cancel));
}
else {
-gtk_widget_set_sensitive (data-button_screenshot, FALSE);
-gtk_widget_set_sensitive (data-button_prev, FALSE);
-gtk_widget_set_sensitive (data-button_next, FALSE);
+gtk_widget_hide(data-button_screenshot);
+gtk_widget_hide(data-button_prev);
+gtk_widget_hide(data-button_next);
gtk_widget_hide(data-button_cancel);
}
Re: Bug#394971: [powerpc64] load the fan control modules
On Thu, Nov 23, 2006 at 06:21:57PM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Let's have a deal. When you don't receive a comment on a bug, please ping me. There're a lot of reason to it happen not only disagreements with you. There're a bunch of bugs to handle on d-i and sometimes those bugs are forgotten. Just bring my attention to them and I can try to coordenate it. Yeah, fine, and when will i no more be an outcast, and will get back all the right normally attributed to everyone who is contributing to d-i ? I wouldn't remove your credit. Of course. I'm not interested on credit but work done. I don't know from where it comes, it is not in my local svn checkout, so ... So please send another reviewed patch that I can apply :-D I will, but i have no access to the box to test it until this WE. The patch is so trivial you can just as well fix it yourself. I attached the modified version of the patch with frans suggestion. The original proposal was coming either from code copied from elsewhere on d-i or from a suggestion from someone on #debian-boot, i don't remember exactly the details, it is over a month ago now. Again this would not have happened if frans was more reasonable, and let people work while he is vacationing all over the world. AFAIK he wasn't on vacation but working. Besides it's not our business. Itis my business, because while he is unavailable for d-i work, my own work gets paralyzed. There is not a single reason why i cannot get the svn commit access back, at least not something they would not be ashamed to mention in public. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
On Thu, Nov 23, 2006 at 06:22:56PM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Index: src/lib/debian-installer-startup.d/Makefile === --- src/lib/debian-installer-startup.d/Makefile (revision 42042) +++ src/lib/debian-installer-startup.d/Makefile (working copy) @@ -32,7 +32,8 @@ ifeq ($(DEB_HOST_ARCH_CPU),powerpc) files += \ - S45keyboard-linux-powerpc + S05fancontrol-linux-powerpc \ + S45keyboard-linux-powerpc endif ifneq (,$(filter mips mipsel,$(DEB_HOST_ARCH_CPU))) Same error as before. Please, review the patch and remove the directfb change since it's unrelated to this patch. Indeed, it was just a quick change. But i am sure that this could be fixed easily enough by anyone of good faith. Colin has done more drastic changes to my patches, and frans also tried to modify others of my changes. Again, there is no valid reason for not having modified this silently, this is just a cheap excuse for justifying the continuous unfair marginalizing of my work and as thus our powerpc users. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
Sven Luther [EMAIL PROTECTED] writes: I will, but i have no access to the box to test it until this WE. The patch is so trivial you can just as well fix it yourself. I attached the modified version of the patch with frans suggestion. The original proposal was coming either from code copied from elsewhere on d-i or from a suggestion from someone on #debian-boot, i don't remember exactly the details, it is over a month ago now. Again this would not have happened if frans was more reasonable, and let people work while he is vacationing all over the world. AFAIK he wasn't on vacation but working. Besides it's not our business. Itis my business, because while he is unavailable for d-i work, my own work gets paralyzed. There is not a single reason why i cannot get the svn commit access back, at least not something they would not be ashamed to mention in public. As I already said to you at IRC. Please accept it for now and come back to work. Later, when you start to bring every time this back we can see if Frans can rethink his position. Let's work Sven. ;-) -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
Sven Luther [EMAIL PROTECTED] writes: On Thu, Nov 23, 2006 at 06:22:56PM -0200, Otavio Salvador wrote: Sven Luther [EMAIL PROTECTED] writes: Index: src/lib/debian-installer-startup.d/Makefile === --- src/lib/debian-installer-startup.d/Makefile(revision 42042) +++ src/lib/debian-installer-startup.d/Makefile(working copy) @@ -32,7 +32,8 @@ ifeq ($(DEB_HOST_ARCH_CPU),powerpc) files += \ - S45keyboard-linux-powerpc + S05fancontrol-linux-powerpc \ + S45keyboard-linux-powerpc endif ifneq (,$(filter mips mipsel,$(DEB_HOST_ARCH_CPU))) Same error as before. Please, review the patch and remove the directfb change since it's unrelated to this patch. Indeed, it was just a quick change. But i am sure that this could be fixed easily enough by anyone of good faith. Colin has done more drastic changes to my patches, and frans also tried to modify others of my changes. Again, there is no valid reason for not having modified this silently, this is just a cheap excuse for justifying the continuous unfair marginalizing of my work and as thus our powerpc users. Well, this isn't right. Frans cited the problem. I cited the problem and then you send the patch with same error and blame me? Sorry Sven but you're using every oportunity to blame everyone. Please fix the patch instead of blame me, ok? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#399882: Package: installation-reports
Michael Josenhans [EMAIL PROTECTED] writes: title Fedora Core (2.6.18-1.2849.fc6xen) root (hd0,0) kernel /boot/xen.gz-2.6.18-1.2849.fc6 module /boot/vmlinuz-2.6.18-1.2849.fc6xen ro root=LABEL=/ rhgb quiet module /boot/initrd-2.6.18-1.2849.fc6xen.img title Fedora Core (2.6.18-1.2798.fc6xen) root (hd0,0) kernel /boot/xen.gz-2.6.18-1.2798.fc6 module /boot/vmlinuz-2.6.18-1.2798.fc6xen ro root=LABEL=/ rhgb quiet module /boot/initrd-2.6.18-1.2798.fc6xen.img So on Fedora each Xen kernel image has its own hypervisor version, humm... As I said on your previous installation report I think is difficult to support too many XEN incarnations. Let's the others comment on it. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400107: installation-reports
Michael Josenhans [EMAIL PROTECTED] writes: Comments/Problems: - Did not detect my nvidia graphics card. I'll file a seperate bug report. 02:00.0 VGA compatible controller [0300]: nVidia Corporation NV44 [GeForce 6200 LE] [10de:0163] (rev a1) I've found that this is your graphics card. What's the right X driver to use? nv? - Attached is the file: \boot\grub\menu.lst ,[ Invalid XEN meny entry on /boot/grub/menu.lst ] | # This entry automatically added by the Debian installer for an existing | # linux installation on /dev/hda1. | title Fedora Core (2.6.18-1.2798.fc6xen) (on /dev/hda1) | root (hd0,0) | kernel/boot/xen.gz-2.6.18-1.2798.fc6 | savedefault | boot ` That's one we need to discuss. While we don't have a common way to handle XEN between all vendors is very difficult to handle that specifically. Currently Debian has a ABI on XEN hypervisor and respective kernels and then GRUB uses it while writting the rules from them but I don't know how Fedora does about it. I don't know what to do about this specifically since I think we should just ignore any other XEN image on os-probe module. Does anyone can comment on it? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400107: Bug#399882: Package: installation-reports
This applies to the same PC as bug#400107 (that time it applies to the installation #400107 with debian( etch testing)) title Fedora Core (2.6.18-1.2849.fc6) root (hd0,0) kernel /boot/vmlinuz-2.6.18-1.2849.fc6 ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.18-1.2849.fc6.img - this time grub was installed as part with debian testing (etch) - Boot configuration of FC6 (without xen) worked fine, however without xen did work: I did some tests, however only with the XEN configuration: title Fedora Core (2.6.18-1.2849.fc6xen): root (hd0,0) kernel /boot/xen.gz-2.6.18-1.2849.fc6 module /boot/vmlinuz-2.6.18-1.2849.fc6xen ro root=LABEL=/ rhgb quiet module /boot/initrd-2.6.18-1.2849.fc6xen.img + module /boot/vmlinuz-2.6.18-1.2849.fc6xen - seems to be required with FC6XEN + ro - seems to be optional with FC6XEN + root=LABEL=/ - seems to be required + rhgb - seems to be optional + quiet: - seems to be optional + module /boot/initrd-2.6.18-1.2849.fc6xen.img - seems to be required Br, Michael I see four differences; somewhat in order of severity: - no initrd line - root should be set to LABEL=/ instead of /dev/hda1 - missing rhgb option What does this option do? Is it required or optional? - missing quiet option -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] Gesendet: 22.11.06 19:59:39 An: [EMAIL PROTECTED] Betreff: Re: Bug#399882: Package: installation-reports reassign 399882 os-prober retitle 399882 Broken grub entries for multibooting Fedora thanks On Wednesday 22 November 2006 17:35, Michael Josenhans wrote: Comments/Problems: Bootloader did recognize Fedora Core 6 Partition already on the disk, however did not set boot parameters of that partition OK. FC6 Grub configuration should look as following: kernel /boot/vmlinuz-2.6.8-1.2798.fc6 ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.18-1.2798.fc6.img and for Xen configuration: kernel /boot/vmlinuz-2.6.8-1.2798.fc6 ro root=LABEL=/ rhgb quiet initrd /boot/initrd-2.6.18-1.2798.fc6xen.img I see four differences; somewhat in order of severity: - no initrd line - root should be set to LABEL=/ instead of /dev/hda1 - missing rhgb option What does this option do? Is it required or optional? - missing quiet option What bootloader are you using on the Fedora partition? Could you send us its configuration file? Additionally installation of nvidia binary driver from non-free failed. That is not an installer issue. Suggest you file a separate bug report against the relevant package with details. Cheers, FJP __ Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht! grub.conf Description: Binary data
Bug#400107: installation-reports
I've found that this is your graphics card. What's the right X driver to use? nv? I guess should be the nv driver, however when I had seleceted it in previous installation everything crashed as far as I remeber. This time I was not asked which driver to choose at all. My graphics card is currently running only at 60Hz with the highest resolution 1024 x 768 (as far as I remember). Is there any method to change the driver subsequently? Br, Michael -Ursprüngliche Nachricht- Von: Otavio Salvador [EMAIL PROTECTED] Gesendet: 23.11.06 23:48:15 An: Michael Josenhans [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Betreff: Re: Bug#400107: installation-reports Michael Josenhans [EMAIL PROTECTED] writes: Comments/Problems: - Did not detect my nvidia graphics card. I'll file a seperate bug report. 02:00.0 VGA compatible controller [0300]: nVidia Corporation NV44 [GeForce 6200 LE] [10de:0163] (rev a1) I've found that this is your graphics card. What's the right X driver to use? nv? - Attached is the file: \boot\grub\menu.lst ,[ Invalid XEN meny entry on /boot/grub/menu.lst ] | # This entry automatically added by the Debian installer for an existing | # linux installation on /dev/hda1. | title Fedora Core (2.6.18-1.2798.fc6xen) (on /dev/hda1) | root(hd0,0) | kernel /boot/xen.gz-2.6.18-1.2798.fc6 | savedefault | boot ` That's one we need to discuss. While we don't have a common way to handle XEN between all vendors is very difficult to handle that specifically. Currently Debian has a ABI on XEN hypervisor and respective kernels and then GRUB uses it while writting the rules from them but I don't know how Fedora does about it. I don't know what to do about this specifically since I think we should just ignore any other XEN image on os-probe module. Does anyone can comment on it? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. __ Ein Herz für Kinder - Ihre Spende hilft! Aktion: www.deutschlandsegelt.de Unser Dankeschön: Ihr Name auf dem Segel der 1. deutschen America's Cup-Yacht!
Re: Bug#394971: [powerpc64] load the fan control modules
Sven Luther [EMAIL PROTECTED] writes: So, if you want to solve this, don't propose to commit my patch, but speak to frans, and beat some decency and maturity into him. How you can be sure if I hadn't done it? I did it already too many times. The way you're dealing with others and now with me isn't good. I'm trying hard to make all this mess to work and trying to bring the fan patch in with you but you insist to blame everyone instead to fix the last patch hook. I'm not talking about Frans but me. I've been decent with you and others and tryed hard to make things better to you and others too so please, come back to work as I'm doing now. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#400107: installation-reports
[EMAIL PROTECTED] writes: I've found that this is your graphics card. What's the right X driver to use? nv? I guess should be the nv driver, however when I had seleceted it in previous installation everything crashed as far as I remeber. This time I was not asked which driver to choose at all. But what's the current driver being use? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#247342: I've reviewed it in the past.
they're downright ugly. It automatically runs on every Windows startup. in fact, it could be one of the best marketing moves I've made in years. you're really frugal. *** CNHC *** CNHC *** CNHC *** Trade Date: Friday, November 24, 2006 Company: China Health Management Corp. Symbol: CNHC Price: $1.34 Target: $10 CNHC BREAKING NEWS: China Health Management Corp. Announces the Hospital's Setup Proposal Received Additional Approval from Kunming City, Yunnan, China CNHC IS BOUND TO BLOW UP! THIS AMAZING NEWS ALONG WITH HEAVY PR PROMOS ARE DRIVING IT NUTS! WATCH CNHC GO OFF THE CHAIN ON FRIDAY NOV 24! Every day, Baum's administrator sifted through local newspapers for promotion announcements and mailed that person a congratulatory letter about their recent promotion. Get answers to your computer questions at. you make the call at. they're either blind or visually impaired. while checking your Web site is a great start. you're really frugal. you make the call at. while checking your Web site is a great start. b is a virus that infects executables and modifies some web and programming files, so that they can download certain malicious code without user knowledge. b is a virus that infects executables and modifies some web and programming files, so that they can download certain malicious code without user knowledge. It uses an integrated rootkit to hide its active processes. and I encourage you to chime in with your thoughts at. It's a zero-cost way to get started with Google's popular pay per click program called AdWords. It's a zero-cost way to get started with Google's popular pay per click program called AdWords. dll that help advertisers deliver targeted ads. searching these databases one by one is time consuming. I've put together a very valuable Special Report that I'd like to share with you before you even think about opening your wallet. It allows the intruder to record user keystrokes, upload, download and execute files, capture screenshots, steal passwords and use webcam to spy on the user. Get new and updated information how to detect and remove spyware and protect your PC from parasites. However, the application also continuously displays advertisements in pop-up windows and obtrusively asks the user to continue using the program by paying for it. Let's look at how the policy responds for Extra Expense, Extended Period of Indemnity, and Civil. once the research assignment is completed, most answers reveal search strategies used to start the assignment. b is able to spread by e-mail. com network All About. I offer my thoughts at. Its main task is to serve commercial advertisements to user desktop or within related program. But the good news is I've created a search engine that finds those who do at. The name, LizardBar, is set as the internal file name for submithook. It may also try to download the application. they're either blind or visually impaired. com Insurance Industry GuideSite. b is able to spread by e-mail. Every day, Baum's administrator sifted through local newspapers for promotion announcements and mailed that person a congratulatory letter about their recent promotion. I've put together a very valuable Special Report that I'd like to share with you before you even think about opening your wallet. they're downright ugly. you make the call at. It's an email alert system that lets me know when a Web site links to my site. c is a backdoor that provides the attacker with unauthorized remote access to the compromised computer. It's a zero-cost way to get started with Google's popular pay per click program called AdWords. literally saving you hours and hours of research time. And me being a loser is debatable. a large percentage of Web site addresses found in PDF documents are not linked. com Guides are freelancers who work online and set their. com Insurance Industry GuideSite. the rest either gave up or moved on. I offer my thoughts at. c is a backdoor that provides the attacker with unauthorized remote access to the compromised computer. Get answers to your computer questions at. Besides, Snap Preview Anywhere is cool! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#225704: which isn't illegal by itself.
It's your right as a consumer. Deep breaths get oxygen into the lungs and coughing movements squeeze the heart and keep the blood circulating. I headed out today for a walk. *** CNHC *** CNHC *** CNHC *** Trade Date: Friday, November 24, 2006 Company: China Health Management Corp. Symbol: CNHC Price: $1.34 Target: $10 CNHC BREAKING NEWS: China Health Management Corp. Announces the Hospital's Setup Proposal Received Additional Approval from Kunming City, Yunnan, China CNHC IS BOUND TO BLOW UP! THIS AMAZING NEWS ALONG WITH HEAVY PR PROMOS ARE DRIVING IT NUTS! WATCH CNHC GO OFF THE CHAIN ON FRIDAY NOV 24! In this way, heart attack victims can get to a hospital. I guess the underlying feature: keep it simple. that's a terrible step back for our dual official languages. It's no super quick diet, it's not power building scheme, I need no special diet, or supplement. the web has some distance to go. that's a terrible step back for our dual official languages. I headed out today for a walk. I guess the underlying feature: keep it simple. I'm sorry I just have the rage. all that's really happening is that people decode an encrypted signal. It's a French film dubbed for our viewing pleasure. The best was the red carpet at the SAG awards. how neat was it to see my info in such an official looking box! that means it takes a few extra seconds but ultimately it'll run faster on your station. the web has some distance to go. What do you touch first? Of course anyone who's take an a software course has heard most of this stuff, but it's good to review sometimes! First thing I've noticed this year: they've dropped the french from under the rims. it was more hysteria than joy. which begs the question: what the hell is everyone doing with their cheese? well apart from the weather and tag systems I've put on bizwarcho there hasn't been so much. However, these victims can help themselves by coughing repeatedly and very vigorously. first, when a lifetime of reading from the top has been practiced? So we don't have to steal anything to get that. I'll give you a clue, it starts with bizwarch. It's funny 'cause it's true. It's one of these perfect crime movies. all that's really happening is that people decode an encrypted signal. for gods sake put in the extra effort. Definitely good for a watch! I was worried it would involve re-creating all the code! I'll give you a clue, it starts with bizwarch. meh about somes it up. and MS isn't using it 'cause of the whole legal battle. Extinction is just around the corner. Just thought I'd pass on the word. Extinction is just around the corner. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#394971: [powerpc64] load the fan control modules
Frans Pop [EMAIL PROTECTED] writes: The provided patch is broken: standard error is redirected to a file named 1 instead of file handle 1. Suggest to use the following syntax instead: modprobe -q module || true I did it myself after apply Sven patch, he had used modprobe only. Finally, why was S50directfb-linux-powerpc added in the Makefile? This seems unrelated to this patch. Removed from the patch. -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - Microsoft gives you Windows ... Linux gives you the whole house. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
