[00:09] <matteo> hi all
[00:11] <matteo> what are tha lpia compiler flags?
[02:18] <persia> 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] <persia> 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] <ian_brasil> persia: ok thanks
[03:11] <ian_brasil> re-rolling the squashfs makes the hd work for its money ;)
[03:11] <persia> ian_brasil: /tmp on tmpfs can help with that.
[03:12] <persia> 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] <ian_brasil> i don't understand
[03:13] <persia> I added the following to /etc/fstab:
[03:13] <persia> tmpfs /tmp tmpfs nodev,nosuid 0 0
[03:14] <ian_brasil> ah,ok
[03:14] <persia> 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] <persia> (or even not 10K drives - just having a 7200, 5400, or slower drive makes this a win)
[03:15] <persia> 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] <ian_brasil> i will try that for sure. its a good job you are always here and don't sleep much persia ;)
[03:19] <persia> ian_brasil: I do sleep.  That's why it took me so long to answer your question about -monitor.
[03:23] <ian_brasil> ok..well thanks anyway
[03:26] <ian_brasil> damn, out of space again
[03:27] <ian_brasil> it is annoying that it gets right to the end before this error
[03:28] <persia> 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] <persia> Also, still out of space after running apt-get clean?  Is this a different issue?
[03:29] <persia> 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] <ian_brasil> i will try and remove firefox
[03:33] <persia> You might also install deborphan and see what else can be dropped.  Alternately pull a new image :)
[03:48] <ian_brasil> 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] <persia> 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] <ian_brasil> OK..space is a concern in order that the image fits on a 512MB pen drive , right?
[03:56] <ian_brasil> just want to clarify this
[03:59] <persia> 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] <persia> 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] <ian_brasil> 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] <persia> ian_brasil: It's just an arbitrary number.
[04:05] <persia> Essentially, the VFAT image needs enough extra space to hold the kernel, the manifests, the preseeding, and the boot configuration files.
[04:06] <persia> 20M was determined as a number that would probably handle all that without much fuss.
[04:06] <persia> After the images were available, ogra put together the image-editing script, which opened new possibilities.
[04:06] <persia> 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] <persia> 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] <ian_brasil> ah i understand now
[04:08] <persia> 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] <persia> (I very much suspect the image generated in ~45 hours will be identical to the one in ~21 hours)
[04:13] <ian_brasil> 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] <persia> ian_brasil: I guess, but I'd suspect most OEMs would prefer the even greater flexibility of generating the images themselves.
[04:15] <persia> 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] <persia> syslinux the VFAT image, and you're done.
[04:16] <persia> 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] <persia> 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] <persia> For hardware enablement, once it's complete, I'd hope to get support into the official images.
[04:18] <persia> 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] <persia> Also, for folk with download caps, an extra 100M every few days can add up quickly to a 2G or 3G ceiling.
[04:31] <ian_brasil> 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] <persia> 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] <persia> 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] <persia> Does that sound useful to you>
[04:34] <persia> s/>/?/
[04:36] <ian_brasil> that sounds extremely useful to me
[04:37] <persia> It's also not that big, and reusable.
[04:37] <ian_brasil> and a much better idea than big downloads
[04:38] <persia> 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] <ian_brasil> ok...i will try to hack something up this weekend for that
[04:40] <persia> ian_brasil: Oh, right, it's still Friday night for you :)
[04:42] <ian_brasil> yes, talking of which it is time to sleep! thanks again for the advice
[04:44] <persia> Have a good night.
[16:43] <crevette> hey people
[16:43] <crevette> just a dumb question, bluez 4 is not targeted for intrepid?