[01:31] <bspencer> anyone know why mplayer wouldn't be installable in target image?
[01:31] <bspencer> I get:
[01:31] <bspencer> Package mplayer is not available, but is referred to by another package.
[01:31] <bspencer> This may mean that the package is missing, has been obsoleted, or
[01:31] <bspencer> is only available from another source
[01:31] <bspencer> E: Package mplayer has no installation candidate
[01:37] <rustyl> doesn't look like there is a package called 'mplayer'
[01:38] <bspencer> hm, curious.
[01:38] <rustyl> at least on the in lpia repository
[01:38] <bspencer> apt-get install gnome-mplayer
[01:38] <bspencer> says:
[01:38] <bspencer> The following packages have unmet dependencies:
[01:38] <bspencer>   gnome-mplayer: Depends: mplayer (>= 1.0) but it is not installable
[01:38] <bspencer> E: Broken packages
[01:38] <rustyl> i am guessing that the mplayer package broke for the lpia build, but that would be a guess
[02:03] <bspencer> HappyCamp, you still here?
[04:27] <bspencer> on the current images with broken sudoers and messed up root pswd, is there a way to get root priveleges?
[04:27] <bspencer> It logs in as ume and I'm stuck.  
[04:28] <bspencer> this endless bug is sucking my will to live
[04:29] <bspencer> when booting can I do something to get into single user mode?
[04:30] <mjg59> bspencer: Hit escape at grub, hit e, press down arrow, press e, type " init=/bin/bash"
[04:30] <mjg59> Press b
[04:31] <bspencer> on the kernel line
[04:31] <mjg59> Yup
[04:31] <bspencer> s/on/end of 
[04:32] <mjg59> Oh, delete the splash argument
[04:32] <bspencer> too late :)
[04:32] <bspencer> gracias
[04:33] <mjg59> Remember to sync after editing files
[04:33] <mjg59> reboot doesn't shut down cleanly in that mode
[04:33] <bspencer> good tip
[04:34] <bspencer> when I run "pswd" it only lets me enter 1 char for the pswd before prompting for "repeat pswd"
[04:34] <bspencer> no big deal, just curious
[04:34] <mjg59> You mean passwd?
[04:36] <bspencer> yeah
[04:36] <bspencer> and characters aren't echoed to the screen
[04:36] <mjg59> Weird
[02:40] <DaftDust> hello
[02:40] <DaftDust> some one here and have time for questions?
[02:42] <DaftDust> hello?
[04:08] <xyzzy_bill> Hey, guys.  Apple just borked my iPhone on purpose, which to me was like a kick in the head... I just totally realized the value of Ubuntu Mobile.
[04:11] <xyzzy_bill> So, I'm a skilled and prolific C programmer.  Any significant projects that need C programmers right away?  I've got a few hours/week I can donate.
[04:42] <xyzzy_bill> BTW, the 4.8" minimum screen size spec-ed in the UIStyleGuide is waay too big.  iPhone is 3.5", and quite usable, even as an e-book.
[04:44] <xyzzy_bill> And geeze... the Blueprint doesn't even have a SIP client at any priority?
[07:08] <Mithrandir> xyzzy_bill: we're not trying to build a mobile phone.  If you want to help out by getting support for SIP into moblin-chat; help would be appreciated.  Note that upstream empathy (which moblin-chat is based on) doesn't yet have stable SIP support, AIUI.
[07:19] <wasabi> There's no doubt that what is built gets you part of the way to a mobil phone distro though. Somebody just needs to package openmoko. :)
[07:21] <Mithrandir> openmoko aren't using hildon, so they won't look very good together
[07:25] <wasabi> Sure, I mostly speak about the core system stuff. Good power management, quick boot, etc.
[07:25] <wasabi> Both hildon and openmoko can then be layed on top of that.
[07:26] <mjg59> wasabi: We have that. It's called Ubuntu.
[07:26] <wasabi> Hehe.
[07:41] <xyzzy_bill> But hildon looks very much like a smart phone window manager, doesn't it?  I'd hate to get locked out of most mobile devices, simply because the early specs said to target 4.8" screens instead of 3.5"
[07:43] <xyzzy_bill> I personally think the iPhone shows that the mobile computing devices and mobile phones will mostly merge in the future.  I think it's worth planning for.  Also, just add a SIP client, and you're half-way to a mobile phone.
[07:44] <mjg59> Hildon is currently not really practical on portrait displays
[07:44] <mjg59> It's not designed to work at < 800x480
[07:44] <tko> xyzzy_bill: hildon doesn't have clearly defined range of form factors at the moment. there is a limit somewhere but it needs someone to go poking around to find it
[07:45] <suihkulokki> and now for something completely different
[07:45] <xyzzy_bill> As computing devices continue to shrink, the only reason to keep mobile computing devices large is for the screen.  I think 3.5" is on the small side for practical computing, but on the large side for my pocket...
[07:46] <suihkulokki> how do I make bzr not conflict on debian/changelog everytime I merge
[07:46] <tko> don't commit debian/changelog :)
[07:46] <tko> just like ChangeLog guarantees merge conflicts
[07:47] <suihkulokki> tko: well both hildon upstream and ume commit changelogs..
[07:48] <suihkulokki> ..and since bzr is mostly used exactly for maintaining debian/ubuntu packages, I kinda expect somekind of best practice/solution to exist
[07:48] <mjg59> Merge the changelog by hand?
[07:48] <tko> resolving changelog conflicts is close to trivial anyway
[07:48] <tko> just annoying
[07:49] <mjg59> I don't think there's a trivial way to do it automatically
[07:50] <tko> if you didn't do line based merge but taught bzr to handle changelog entries as a whole, you could easily make it automatic
[07:50] <suihkulokki> for arbitary changelogish files yes, but debian/changelog is formatted enough somekind of automatic solution should be easy
[07:52] <tko> you could also do similar thing for GNU-ish ChangeLogs, just assume ^[a-ZA-Z0-9] begins a new group that should be handled atomically
[08:28] <corevette> are there any screens of UME yet?