[03:15] <ian_brasil> i just updated to the intrepid version of kvm and when i run it it gives
[03:15] <ian_brasil> kvm
[03:15] <ian_brasil> QEMU PC emulator version 0.9.1 (kvm-72), Copyright (c) 2003-2008 Fabrice Bellard
[03:15] <ian_brasil> usage: qemu [options] [disk_image]
[03:15] <ian_brasil> why is itusing qemu?
[04:20] <persia> ian_brasil: hppa is the Hewlett Packard Precision Architecture (http://en.wikipedia.org/wiki/PA-RISC_family).  I don't know of any portable devices that use it, but it's supported for Ubuntu and we try to be relatively architecture-independent.
[04:20] <ian_brasil> persia: ok
[04:21] <sgeorge> could someone point me to a touchscreen driver for jax-10?
[04:21] <persia> sgeorge: Celtiore is probably your best guide for the Aigo MID.  I'm not sure who can help with the Jax10
[04:21] <sgeorge> i have an aigo
[04:22] <persia> ian_brasil: Also, KVM is based heavily on qemu: it's basically a branch of qemu that uses the processor shortcuts, rather than either true emulation or the kqemu modules.
[04:24] <ian_brasil> ok..before when it executes in the title pane it said kvm/qemu but now just qemu so maybe i am using just the software emulation
[04:24] <ian_brasil> all the kvm checks look ok
[04:24] <persia> sgeorge: Then you're the second person here who does.  From reading traffic, I remember there being issues with touchscreen calibration, but I don't know if they are solved.  I don't remember seeing traffic about the WiFi modules: http://www.umpcportal.com/modules/newbb/viewtopic.php?topic_id=3672&forum=31 might have some useful pointers.
[04:25] <persia> ian_brasil: Is it incredibly painfully slow?  If not, it may just be that the qemu team and KVM team are moving more towards a common codebase.
[04:25] <sgeorge> yes I have been following that thread. And Yes I saw a bug listed for calibration not working. But I think that the actual driver isnt packaged in the distribution due to licensing....
[04:25] <ian_brasil> well i dunno..it is quite difficult to judge latency!..i will have a play tomorrow anyway
[04:26] <sgeorge> i did install a 7.01 build that worked but it had to many other issues to be usable
[04:27] <ian_brasil> i backported the kvm in intrepid to hardy
[04:27] <persia> ian_brasil: heh.  Yeah.  My experience with running non-KM qemu on an A110@800MHz was that it took about 15 minutes for the image to boot.  If you're not seeing that level of latency, you're probably using the accelleration.
[04:27] <ian_brasil> ah cool...then it is using kvm
[04:30] <persia> Good.  It's probably just closer merging with qemu then, which is good, because then there's fewer lines of code to maintain, and we'll likely see more improvements.
[04:32] <ian_brasil> i wish they nad not change the window title though..ijust spent a couple of hours thinking that 1. my backport had not worked 2. I was completely dumb for not working out why kvm was not running
[04:33] <persia> Yeah, that's a little confusing.  You might file a bug: if nothing else, the change ought be listed in the release notes.
[04:33]  * ian_brasil looks for release notes
[04:47] <persia> They aren't written yet :)  But filing a bug ought get the ubuntu-virt team to either add it to the release notes or to change the user-visible behaviour.
[04:47] <persia> There could possibly be something in /usr/share/doc/kvm/ but that's not very visible.
[07:12] <Celtiore> hi
[07:13] <persia> Celtiore: Hey.  You just missed sgeorge who also has the Aigo.
[07:14] <Celtiore> yep i see
[07:14] <Celtiore> 05:21:15 :p
 sgeorge: Celtiore is probably your best guide for the Aigo MID.  I'm not sure who can help with the Jax10
[07:14] <persia> Heh.  Oops.
[09:54] <crevette> hello
[09:54] <crevette> persia: hey
[10:48] <persia> crevette: Hey.
[10:51] <crevette> persia: I did some review of the patches
[10:51] <persia> crevette: Anything useful there?
[10:53] <crevette> so from F-9 I took bluez-gnome-0.26-handle-error because it display a message on tranfer error a,d nit could help on other bug to know what happen when it fails
[10:54] <persia> Cool.  Were you able to prepare a candidate for testing?
[10:54] <crevette> I didn't took bluez-gnome-remove-class-file-sharing because it disable file sharing over bluuetooth; because fedora installs gnome-user-share and it does the same function
[10:55] <crevette> so they conflict
[10:55] <crevette> I put bluez-gnome-0.28-services-running but I didn't understand what it solves, I see it was had to avoid a crash on pairing
[10:56] <crevette> s/had/added/
[10:57] <crevette> persia: I don't know if I have to take the patch 000_bluetooth-applet-xfce.patch from debian
[10:57]  * persia looks
[10:57] <crevette> I updated the patch 99_automake
[10:59] <crevette> persia: you can find the package at https://launchpad.net/~bmillemathias/+archive
[11:00] <persia> I'd probably grab 000_bluetooth-applet-xfce.patch.  It looks minimal, but useful.
[11:01] <crevette> I kept it in the package
[11:01] <persia> Cool.  I'm grabbing the merge now.
[11:02] <crevette> I'd need to change the changelog format
[11:02] <crevette> I'm not sure I use the rightone
[11:02] <persia> Yeah, and collapse the last couple entries, but the current stuff is good for testing.
[11:03] <crevette> persia: you'll try it
[11:03] <crevette> I didn't have a lot to try
[11:03] <persia> I'll test it for audio and comms.  We need someone to test keyboard and mouse.
[11:04] <crevette> I can only test it for file transfert
[11:04] <crevette> I don't have input device
[11:04] <persia> I'll look in a shop tomorrow and see if I can find an inexpensive bluetooth keyboard or mouse, but I don't really want to spend too much just to test it :)
[11:04] <crevette> :)
[11:05] <persia> For debian/rules, it would be nice to add --enable-hildon to DEB_CONFIGURE_EXTRA_FLAGS for lpia.  That would make it work better with the hildon framework for Ubuntu MID.
[11:06] <persia> (yes, this isn't the right way to do it, but nobody runs Desktop on lpia anyway)
[11:06] <crevette> I don't know :/
[11:07] <persia> changelog looks pretty good, but you'll want to add the old Ubuntu changelog entries, and mention that you've merged with Debian.
[11:11] <crevette> persia: where I had the ubuntu changelog, as the latest in 0.25 for ubuntu and 0.27 for debian
[11:11] <persia> crevette: Right.  It's considered best practice to extract each of the changelog entries that show Ubuntu variation and insert them in the Debian changelog when merging.
[11:12] <persia> I can probably do that within the next hour, if the above doesn't make sense.
[11:19] <crevette> persia: http://dpaste.com/79311/
[11:19] <crevette> you want the changelog like that
[11:20] <persia> No: for the new entry, what you did is perfect.
[11:21] <crevette> okay
[11:21] <persia> Take a look at 0.11-0ubuntu1 ... 0.13-1 ... 0.13-1ubuntu1 at http://changelogs.ubuntu.com/changelogs/pool/main/b/bluez-gnome/bluez-gnome_0.25-0ubuntu2/changelog
[11:21] <persia> See how the Debian and Ubuntu entries are interleaved?
[11:29] <crevette> persia: not sure, but I forgot to modified the maintainer field also
[11:30] <persia> Oops.  Yeah, that too :)
[11:38] <persia> crevette: I've got to run off for a bit, but I'll take another look (and put together the changelog if you need) as soon as I get back.
[11:39] <crevette> okay
[13:25] <xsacha> hi
[13:29] <xsacha> hey, any progress on ubuntu MID on ARM? also, how is the touchscreen support?
[13:29] <persia> xsacha: Ubuntu MID on ARM won't happen until Ubuntu generally supports ARM.  No MID-specific progress.
[13:30] <xsacha> k thx
[13:30] <persia> Touchscreen support is fairly good for some devices, and there's a reasonable framework to provide hints for anything using evdev, although the number of hints files isn't particularly large right now.
[13:31] <persia> https://launchpad.net/+builds is probably a good page to watch if you are curious about architecture support, although I suspect there will be some sort of announcement if/when ARM is properly supported.
[13:32] <xsacha> also, will it ever be supporting radios? (phone)
[13:34] <persia> xsacha: That's really a kernel thing, rather than specific to Ubuntu MID.
[13:34] <persia> Personally, I expect to see good support for embedded 3G modems well before there is proper support for phones.
[13:35] <persia> Mind you, there's no reason there couldn't be an Ubuntu Phone flavour, but I suspect it's likely to be different.  Ubuntu MID targets 4-6" screens, and is more for the PDA/MID/pocket tablet sort of use case.
[13:37] <persia> I suppose it might work for a phone, but having a MID that is even smaller (3.5" screen and not running Ubuntu) that also works as a phone, I'll say that generally the UI for phones is really different than the UI for MIDs, and that trying to have one thing that works for both is probably not ideal.
[13:37] <persia> GIven the recent news of Debian on the OpenMoko, I wouldn't expect it to be too hard to get something working on a phone-like device for Ubuntu 9.04 (assuming processor support), but it's not likely to be Ubuntu MID (unless more manufacuturers decide to make ~400g "phones")
[13:39] <ach> oh ok, i read this on xda: http://forum.xda-developers.com/showpost.php?p=2346047&postcount=5
[13:40] <persia> ach: There are a number of community efforts currently underway to port Ubuntu to ARM, including a few people who run it on the Zaurus.
[13:40] <persia> Ubuntu MID is a fairly good flavour for the Zaurus (although I really need to fix mine and test that).
[13:40] <ach> k
[13:41] <persia> But a Zaurus is *not* a phone.  There are some phones that are that big, but most of them don't make for very good phones.
[13:41] <persia> Sharp's most recent significantly oversized phone (the D4) comes with a separate bluetooth handset with a dial-pad because Sharp knows it's not a very good phone :)
[13:42] <persia> Some of the HTC devices are about the right size, but again, aren't very good phones.
[13:43] <persia> Ubuntu MID is really targeted at things like the Nokia n810 or the Zaurus (except using lpia processors, so it doesn't work on these).
[13:44] <ach> the new sharp ones are winmob tho, right?
[13:44] <ach> is it still easy to change ROM to a linux distro like ubuntu?
[13:44] <persia> Yeah, but Ubuntu MID will support them (although maybe not the phone).  Some people have been testing with the Aigo MID.
[13:44] <ach> oo ok
[13:45] <persia> I suspect there are some other devices that work, but the Sharp D4 and the Aigo MID are the only two that I know people are using that match the intended spec.
[13:45] <persia> You could probably use it on the little Fujitsu devices as well, but I've not yet heard any reports about success/failure.
[13:46] <lool> persia: Not sure you should mention non-lpia devices as examples of what Ubuntu MID is targetting :-P
[13:47] <persia> lool: Well, most people have never heard of the D4 or the Aigo.  It's the use-case I'm trying to describe.
[13:47] <persia> The Gigabyte M528 might be the right size.
[13:48] <persia> Or the BenQ S6
[13:48] <ach> is lpia for specific devices or does it work with any i386?
[13:49] <persia> ach: It's targeted for the A100, A110, and Atom processors, but it also works on many other newer i386 processors (but may not take full advantage of those processors).
[13:52] <ach> ok
[13:55]  * ach dreams of a day when this fully locked-up winmob samsung i780 runs linux
[13:56] <persia> ach: What kind of bootloader does that have?  One of the reasons it's easy to load something different for lpia devices is that they tend to have a fairly normal PC BIOS, and let you boot off USB.
[13:58] <ach> hardSPL i think?
[13:59] <ach> "The good thing about SGH i780 is that the bootloader seems to run on a very sturdy HardSPL which makes it very resilient to rom changes"
[14:00] <persia> heh.  That's not very promising.
[14:01] <persia> It's well off topic here, but it seems some of the xda-dev folk have a linux hack for HardSPL.  Might try there.
[14:01] <ach> k
[14:02] <persia> Probably several steps to get Ubuntu, but linux might be possible (mind you, I have no idea how this might affect the use of the device as a phone)
[14:07] <ach> o well im satisfied with the winmo (this device is fast!) so i might just upgrade to 6.1 :)
[14:07] <ach> one day..
[17:30] <crevette> hello
[17:42] <persia> crevette: Hey.  Did you get the changelog sorted out?  Shall I post my version?
[17:43] <crevette> persia: post your
[17:43] <crevette> yours
[17:43] <crevette> I was away
[17:43] <persia> No problem.  Hold on a minute whist I collect it.
[17:46] <crevette> persia: in the log you can say the new upstream fixes https://bugs.launchpad.net/ubuntu/+source/bluez-gnome/+bug/258738
[17:48] <persia> http://paste.ubuntu.com/48624/ should include everything.
[17:48] <persia> Let me just check a couple things...
[17:49] <persia> Yep.  Just remember to set XSBC-Original-Maintainer: in your control file.
[17:50] <persia> You'll need to bump to 0.28-0ubuntu1~ppa3 if you upload to the PPA again, and if it looks good, change to 0.28-0ubuntu1 when attaching a debdiff to 258738
[17:50] <crevette> okay
[17:50] <crevette> thanks persia
[17:51] <crevette> I seen what was missing in the changelog
[17:51] <persia> crevette: Thank you *very* much.  This is something I've wanted to do for a couple months, but it's never risen to the top of my TODO list.  I really appreciate your help to get it all merged and the latest available patches applied.
[17:52] <crevette> :)
[17:52] <crevette> thanks it could help you
[17:52] <crevette> persia: who should I set as maintainer ? you N
[17:52] <crevette> ?
[17:53] <persia> No.  " Ubuntu Core Developers <ubuntu-devel-discuss@lists.ubuntu.com>"
[17:53] <persia> I'm not actually one of them :)
[17:53] <crevette> okay
[17:54] <persia> We'll have to get one to upload it, but if the three of us who are most interested all report good test results, I suspect we ought be able to do that.
[18:11] <crevette> persia: it's build on tmy ppa
[18:12] <persia> crevette: Excellent.  It's late for me here, but I'll be testing it in 16 or 17 hours.  slytherin has said he will try to test it sooner.
[18:12] <persia> I presume it's working perfectly for you?
[18:13] <crevette> I need to do further testing
[18:14] <persia> heh.  We probably can't get it uploaded until Monday anyway so there's a bit of time.
[18:17] <crevette> persia: I can put a comment on bluez-gnome bugs to ask for testing for those using intrepid ?
[18:29] <persia> crevette: At least for 258738.  Are you expecting it to close any other bugs?
[18:30] <persia> I think it also closes 256994
[18:32] <persia> crevette: In fact, it appears I'm still assigned to 256994.  I'll assign that to you :)
[18:37] <crevette> hey
[18:39] <persia> You're doing all the work :)  If anyone has questions about the status, you're a better person to ask.  I'm happy to help you, but I don't think I should get credit for working on it when you are actually doing it.
[18:39] <crevette> bah I did nothing
[18:40] <crevette> vredits goes upstream, fedora and debian
[18:41] <persia> If you think that's nothing, ask me in November: there's a lot of nothing needs doing :), but yes, credit for it actually working belongs indeed to those who are solving the problems, and not those who are preparing the solution for the Ubuntu users.
[18:41] <persia> Anyway, good luck with the tests: I must be away
[18:42] <crevette> persia: good night
[18:44] <ian_brasil> persia: i found this link http://www.linuxquestions.org/questions/linux-general-1/use-squashfs-as-647320/  to install the ume image/squashfs etc by hand it looks more or less like this? 
[18:46] <ian_brasil> ah sorry ..it must be late there in japan
[18:46] <persia> ian_brasil: Well, for hardy, kinda.  Personally, I think that's not a very good way to do it because of how updates apply to a system.  A system constructed that way is a poor choice for developers, and can be awkward for end users if there are a number of updates.
[18:46] <persia> (yes, well past my bedtime)
[18:47] <persia> For intrepid, the plan is to not use the squashfs on the installed system.  The majority of devices available these days have at least 4GB of storage, which is sufficient to not use a squashfs (including space for user data).  Many devices have significantly more (30GB is not too hard).
[18:48] <persia> Depending on how the device market develops, and what devices people tend to have, I'd be open to revisiting this for jaunty, but only if there is significant market penetration of devices with less than 4G available secondary storage.
[18:48] <ian_brasil> ah cool ...but what about a device without that luxury?
[18:49] <persia> Of course, I'm not the only person with an opinion, so it may be that we'll definitely do squashfs for jaunty if enough others feel strongly about it.
[18:49] <persia> Do you know of any currently available devices that don't have 4G secondary storage?
[18:50] <persia> Also, for an equipment manufacturer use-case, there's no reason one couldn't build an image for flashing on the device that included a squashfs.
[18:51] <persia> (mind you, this would involve some effort on the part of the OEM or IHV, but not so much: it's just a change to the initrd and a different way of formatting the disks)
[18:52] <ian_brasil> not offhand but maybe some kiosk type devices?
[18:53] <ian_brasil> and manufactures look to have less space in order to reduce costs
[18:53] <persia> I could see that, but 4G is rapidly dropping in price, and if one is building a kiosk, I'd guess that using a full flavour is probably overkill anyway: be better to just pull some smaller subset of packages.
[18:54] <persia> (for example, the kiosk probably doesn't need all the different networking tools, or all of open office, or a full Java stack, etc.)
[18:54] <ian_brasil> yes, that makes sense
[18:55] <ian_brasil> and the viewpoint is more valid in the first world than here in the third ;)
[18:55] <persia> Mind you, part of this is because it's tricky to figure out how much storage is available, and whether to optimise for user data with few updates or an updatable system :)
[18:55] <ian_brasil> especially in  Brazil where we pay 90% tax on hardware which is imported
[18:55] <persia> That's probably true.  I'm biased based on where I live, and it shows.
[18:56] <persia> I thought it was only 80%.  Did it go up?
[18:56] <ian_brasil> it is 84% if i remember correctly
[18:56] <persia> Ah.  Then 80% and 90% are both accurate within the limits of their precision :)
[18:57]  * persia hasn't lived in Brasil, only heard stories
[18:57] <persia> And there is no local manufacture of flash?
[18:57] <ian_brasil> no
[18:57] <ian_brasil> unless local == china
[18:58] <persia> Yeah, that makes it more awkward.
[18:58] <persia> No :)  China isn't that local to Brasil
[18:59] <ian_brasil> so if you had to do it the way shown in the link is probably the thing to do or is there some better way?
[19:00] <persia> Well, some of the hardcoding is variable.
[19:00] <persia> Essentially, create some filesystem layout somewhere, run mksquashfs to create your squashfs, dd that to your target / partition.
[19:00] <persia> Make sure you have a different boot partition.
[19:01] <persia> It's a good idea to use aufs or unionfs to merge an empty partition with your squashfs partition to handle file changes.
[19:01] <persia> If you're using squashfs for /, this is especially critical to support changes in /etc and /var
[19:01] <persia> (and software updates).
[19:02] <persia> I'd recommend having /home be a separate partition from either of those, and if you use swap, that also needs to be separate (although you may want to look into a compressed swap solution if you're really that limited in secondary storage)
[19:03] <persia> squashfs and unionfs/aufs need to be enabled in the initrd for this to work.
[19:04] <ian_brasil> ah, this is cool...so mount some dirs like tmp , var and run as tmpfs
[19:05] <persia> If you want to see an example of a working configuration, install the hardy image to a KVM drive constructed with `qemu-img -f raw ${file} ${size}`. mount the resulting image, and take a look at the configuration.
[19:05] <ian_brasil> very nice persia
[19:06] <persia> Well, /var as tmpfs gets a little risky: you *really* want /var/lib to persist over reboots.  It's probably safe to lose /var/cache /var/lock, and /var/run.
[19:06] <persia> /var/spool depends on what you are doing on the system: you may want to persist it.  /var/log is handy to keep so you don't lose your logs on an unexpected reset, and can track it down.
[19:07] <persia>  /tmp should *definitely* be /tmpfs if you are limited in secondary storage.  If you have a use case for a large /tmp, I think it's probably better to have a large swap, and use tmpfs anyway, as that way you only allocate disk space as it is used, rather than all the time.
[19:08] <persia> (I use that even on systems with ~100G secondary storage, just because /tmp is wiped on reboot anyway, and I typically want RAM access times for stuff in /tmp)
[19:09] <persia> For the hardy image, I think /home is partially in the squashfs (standard user data), and partially in the overlay.  The reason I suggest this is dangerous is that if you change the squashfs, it may corrupt the overlay, which could result in a loss of user data.
[19:11] <persia> Anyway: any quick questions about squashfs, or are you planning to go test and play for a while?
[19:13] <ian_brasil> just one ...about fstab ...to mount squashfs as root...there is something special to do
[19:13] <ian_brasil> i will play on a device with @2GB of staorage
[19:13] <persia> For the kiosk case you might want this.  For a personal system, I still think most people would want to pay an additional ~15 reais to have a MID with enough storage.
[19:14] <persia> You have a 2G device?  Oh, that changes things.  I thought this was a theoretical discussion.
[19:16] <ian_brasil> no, we are trying to lend one to make these  tests
[19:16] <persia> I actually don't remember what you need in fstab.  I think you just define the union fs there, and the unionfs definition is where you put the compressed and overlay details.
[19:17] <persia> The hardy installer image installs a system with a layout as described, and looking there is likely your best example.
[19:17] <ian_brasil> excellent
[19:18] <persia> OK.  I've not seen any for sale anywhere, despite persistent rumors that one might exist, so I've someone assumed they were fictional.  If you can test on an actual device, then they exist, and it's probably worth at least putting together a wiki page explaining how to do it.
[19:19] <ian_brasil> right...that would help
[19:20] <persia> It's probably also not that hard to construct a script that would extract the squashfs from the live images, delete the installer, and tweak a couple things to turn it into something that would be suitable for direct copy to such a device.
[19:21] <ian_brasil> ah, so this is what we want to do here!
[19:22] <ian_brasil> exactly what we were think about
[19:22] <persia> I ultimately think the introduction of any such devices will be a market failure, even in Brasil, because of the rapidly falling cost of flash, and the increasingly common availability of 1" rotary drives, but that doesn't mean some people won't end up with them.
[19:22] <persia> Yeah, that's probably the easiest method.  The other would be to construct a debootstrap chroot, install the ubuntu-mid package, and use that as a base for a squashfs.
[19:23] <persia> In either case, I still think that it makes more sense to pick some subset of ubuntu-mid than try to use the whole thing (OO.o and OpenJRE are prime candidates to be dropped), but it really depends on the expected ultimate use case for the device.
[19:24] <persia> In that case, you'd debootstrap up a base chroot, install ubuntu-minimal, and then add packages as you need.  Clean up the apt-cache (apt-get clean), and construct the squashfs.
[19:25] <ian_brasil> yes, this is what we are doing 
[19:25] <persia> With judicious trimming, and some attention to use cases when selecting the software, I expect you could get the squashfs down to about 350M.
[19:27] <ian_brasil> this is interesting and to quickly change the subject ..is there some public info somewhere about use cases and selecting software for UME or is that just common sense?
[19:27] <persia> I've had trouble with /boot of only 256M previously, but that is only an issue when there are two kernels installed simultaneously.  150M is probably sufficient if you don't expect a kernel upgrade (or can reflash the device on kernel upgrade), which should get the base system in ~512M.
[19:27] <persia> I don't know of anything.  I think cgregan was working on documenting some, but I believe it's a work-in-progress.
[19:28] <persia> For the most part it's been about supporting what seem like common use cases (including arguing about what is actually common).
[19:28] <persia> And then trying to find applications that work with a smaller screen, and can be adjusted to support finger navigation and the like.
[19:29] <persia> Anyway, too many of my words are malapropisms for me to stay confident any longer.  Good luck with your project, and ask me about it again in ~15 hours if you like.
[19:29] <ian_brasil> excellent info ..thanks a lot..i will poke you when the scriptis ready
[19:30] <ian_brasil> in python
[19:30] <persia> If you do get something working, please also post instructions to the wiki.  While I hope they will be completely useless for everyone else, this may not be true if you have access to actual 2G devices.
[19:31] <ian_brasil> ok, will do
[19:58] <ethana2> http://i38.tinypic.com/11hxdgl.png
[21:21] <sgeorge> any Aigo owners around?