[00:09] hi all [00:11] what are tha lpia compiler flags? === ALo is now known as ALoGeNo === foka_ is now known as foka [02:18] chuck: A couple people have tried it on the EeePC : general consensus is the 1) It takes a *long* time to install without feedback, and 2) the EeePC is not a MID. Look for Ubuntu Mobile in intrepid. [02:18] ian_brasil: -monitor stdio puts the KVM monitor in the shell from which you launched KVM, which can give you useful metacontrol of your instance. [02:21] persia: ok thanks [03:11] re-rolling the squashfs makes the hd work for its money ;) [03:11] ian_brasil: /tmp on tmpfs can help with that. [03:12] Also, the 20080913 image appears to have suffered a mishap, so one still can't install (although it's usable as a live image). [03:12] i don't understand [03:13] I added the following to /etc/fstab: [03:13] tmpfs /tmp tmpfs nodev,nosuid 0 0 [03:14] ah,ok [03:14] What that does it create a /tmp that is half the size of physical RAM, and anything stored in /tmp goes to RAM. In practice, much of it ends up being committed to swap, but it means that it only gets written to disk when the space in /tmp exceeds the cache buffers, rather than immediately, which can speed up operations on temporary files for machines with slower access to secondary storage (not SSD) [03:15] (or even not 10K drives - just having a 7200, 5400, or slower drive makes this a win) [03:15] Of course, the downside is that one wants to clean up /tmp to hibernate, and it's in RAM, so if one is short RAM, it may limit the size of what one can put in /tmp. [03:19] i will try that for sure. its a good job you are always here and don't sleep much persia ;) [03:19] ian_brasil: I do sleep. That's why it took me so long to answer your question about -monitor. [03:23] ok..well thanks anyway [03:26] damn, out of space again [03:27] it is annoying that it gets right to the end before this error [03:28] It's hard to know how well the chroot will compress in advance, and when it copies the squashfs, there might just not be enough room. [03:29] Also, still out of space after running apt-get clean? Is this a different issue? [03:29] Lastly, do you have firefox installed? Some of the earlier images did, and you might be able to remove it to regain space. [03:31] i will try and remove firefox [03:33] You might also install deborphan and see what else can be dropped. Alternately pull a new image :) [03:48] i think the space issue is going to cause a lot of confusion/questions..i think i will write a wiki page about this at some point [03:54] Probably best if you just mention it as a warning on the current wiki page. I think you are the primary user of this now: ogra and I have used it some, but not to the extent you use it. [03:56] OK..space is a concern in order that the image fits on a 512MB pen drive , right? [03:56] just want to clarify this [03:59] Well, it's of interest to me, as I only have one pen drive > 512M, but they sell them at the corner store here, so it's not essential or anything. [04:00] Anyway, the current images are well over 512M, so since that criteria hasn't been met, it's not worth trying to enforce it unless you have a good idea about which packages we would do better without, and we can try to find out why they are being installed. [04:04] i am asking why is there the 20MB additional size limit when you are working inside the chroot...i missed that part of the conversation earlier [04:05] ian_brasil: It's just an arbitrary number. [04:05] Essentially, the VFAT image needs enough extra space to hold the kernel, the manifests, the preseeding, and the boot configuration files. [04:06] 20M was determined as a number that would probably handle all that without much fuss. [04:06] After the images were available, ogra put together the image-editing script, which opened new possibilities. [04:06] At this point, it's a matter of debate whether the image should contain more empty space (longer downloads, but more flexible) or stay small. [04:07] Personally, I think it's better to stay small, and upgrade an installed system, but that's currently blocked on https://launchpad.net/ubuntu/+source/debian-installer/20080522ubuntu14/+build/715838 [04:07] ah i understand now [04:08] With luck, the image generated in ~21 hours will work for installs. If not, I'm 100% certain the image generated in ~69 hours will allow installs. [04:09] (I very much suspect the image generated in ~45 hours will be identical to the one in ~21 hours) [04:13] i am in the camp of longer downloads with more space...with this you can make a larger theme and customize more for an OEM [04:14] ian_brasil: I guess, but I'd suspect most OEMs would prefer the even greater flexibility of generating the images themselves. [04:15] To do that, just use the squashfs-editing portion of the image-editor script, and then create a VFAT image of sufficient size, and stuff in the squashfs, kernel, preseeds (likely different for OEMs anyway), manifests (also likely different for replicable installs), and boot hints. [04:16] syslinux the VFAT image, and you're done. [04:16] The key part here is that the OEM likely wants to change the preseeds and manifests to change the way the install works. [04:17] For someone just playing around, adding a couple packages to the image works. This is also very important when testing changes to enable new hardware. [04:17] For hardware enablement, once it's complete, I'd hope to get support into the official images. [04:18] For installing a couple fun packages that someone always uses, 20M (or maybe 30M) ought be enough. Too much size makes latency *very* painful for those of us with long-haul connections to cdimage.ubuntu.com [04:18] Also, for folk with download caps, an extra 100M every few days can add up quickly to a 2G or 3G ceiling. [04:31] I suppose this depends to a certain extent on the OEM. In my experience some do not want to get involved in this level of customization...they just ask can I put my own applications and my own theme on ume...a quick and easy way to do enable this to happen could give this sector a good kickstart...maybe a community maintained larger vfat image might work for this? [04:33] ian_brasil: Could be, although I'd think putting together a script to expand the VFAT is probably easier, both to maintain, and to get hosted. [04:33] I'm thinking just something that takes an existing .img as an argument, and a second argument that says how much space to add. It then creates a VFAT that is the desired amount larger, and copies in the contents, for later use with the image editor. [04:34] Does that sound useful to you> [04:34] s/>/?/ [04:36] that sounds extremely useful to me [04:37] It's also not that big, and reusable. [04:37] and a much better idea than big downloads [04:38] I'm chasing a few other things today, but if you've time to put something together, I'm happy to test, or act as a sounding board if you want to talk through something. [04:38] ok...i will try to hack something up this weekend for that [04:40] ian_brasil: Oh, right, it's still Friday night for you :) [04:42] yes, talking of which it is time to sleep! thanks again for the advice [04:44] Have a good night. === asac_ is now known as asac [16:43] hey people [16:43] just a dumb question, bluez 4 is not targeted for intrepid? === Snookie is now known as Guest83413 === foka_ is now known as foka === Snookie is now known as Guest83869 === Guest83869 is now known as snookie === snookie is now known as Guest82291 === Guest82291 is now known as snookie === snookie is now known as Guest94106 === Snookie is now known as Guest96899 === Guest96899 is now known as snookie === snookie is now known as Guest11420 === Guest11420 is now known as snookie2