[00:56] <persia> Any core-dev's about?  bug #568736 would benefit from being approved for lucid, and milestoned.
[00:56] <ubot4> Launchpad bug 568736 in netbook-meta (Ubuntu) "Having Evolution installed along with Desktop-Email is pointlessly redundant (affects: 1) (heat: 10)" [High,Triaged] https://launchpad.net/bugs/568736
[01:45] <cwillu_at_work> persia, this is an arm specific bug? :p
[01:45] <persia> Yes, because desktop-webmail is only installed for armel by default.
[01:46] <persia> One could safely argue that it makes sense for it to be default on all architectures, but that's a different discussion.
[06:03] <DanaG> weird... neither networkmanager nor wicd will connect with my rtl8187.
[06:03] <persia> That's unexpected.
[06:10] <DanaG> X11 connection rejected because of wrong authentication.
[06:10] <DanaG> Trying to run ssh-with-X.
[06:11] <persia> Hrm.  It generally works for me if I ssh out of my X session into somewhere else, with the appropriate .ssh/config bits to pass X, and then run an X app.
[06:11] <persia> Dunno if that's precisely how you're doing it.
[06:13] <DanaG> I have forwardx11 and forwardx11trusted in .ssh/config
[06:13] <DanaG> (capitalized properly there.)
[06:17] <persia> Ought do it, really.
[06:19] <DanaG> hmm, it's not working for me.  Weird.
[06:20] <persia> Indeed.
[06:22] <DanaG> oh, "no space left on device"
[06:22] <DanaG> No wonder.
[06:22] <DanaG> Would've been nice if ssh had told me that.
[06:23] <persia> Heh.  That explains it.
[06:25] <DanaG> Need bigger SD card -- 2 gigs is tiny.
[06:25] <persia> We recommend 4G of available storage for a running system.
[06:25] <persia> (or more).
[06:26] <persia> It can (barely) fit in 2G, but one usually runs into issues.
[06:30] <DanaG> hmm, what read and write speeds is the beagle itself capable of?
[06:31] <DanaG> For example, why bother with a "class-10" card if it can't do class 10 speeds?... =þ
[06:39] <DanaG> weird... blueman won't let me use the pulseaudio plugin.
[06:40] <DanaG> ValueError: invalid literal for int() with base 10: '21-63-gd3efa-dirty'
[06:41] <persia> File a bug.
[06:41] <persia> That *should* just work.
[06:41] <persia> (and not working is a clear port failure)
[06:43] <DanaG> https://bugs.launchpad.net/ubuntu/+source/blueman/+bug/535446
[06:43] <ubot4> Launchpad bug 535446 in blueman (Ubuntu) "[lucid] Blueman Pulseaudio plugin cannot be loaded (affects: 4) (heat: 24)" [Undecided,Confirmed]
[06:44] <persia> Does the patch work for you?
[06:45] <persia> Nifty.  Looks like I can upload that.  Tell me the patch works, and I'll put it in lucid.
[06:54] <DanaG> I just edited the file manually, rather than patching it.
[06:55] <DanaG> The patch seems to be for something different.
[06:55] <DanaG> Now I just need to remember which audio port was line-out on the beagle.
[06:57] <DanaG> I'm getting no audio on either port.
[06:58] <persia> But your traceback matches the one in that bug?
[06:59] <DanaG> Yes, the invalid literal for int()
[06:59] <persia> Oh, xax200's traceback?
[06:59] <persia> I think the patch is for mmbossoni's traceback
[07:00] <persia> No, I'm confused
[07:00]  * persia reads the bug again
[07:01] <DanaG> Looks like the bug partly got highjacked?
[07:02] <persia> By the original reporter, which makes it complicated.
[07:02] <persia> "I noticed another problem" is the key phrase one never wants to see in a bug report.
[07:03] <persia> xax200 seems to recommend small changes to lines 115 and 218 (comments 3&4).  Does that work for you?
[07:03] <DanaG> I just changed the first one mentioned.
[07:04] <DanaG> 115.
[07:05] <persia> Right, which is a bit different than the patch in comment #5, which seems to be a different bug.
[07:07] <DanaG> hmm, is there any way to get blueman to run without an X server?  Or a dummy X server?
[07:09] <persia> xvfb?
[07:09] <persia> Mind you, it might be tricky to press the buttons that way :)
[07:10] <DanaG> Or I suppose I could run a real X server with just a blueman-applet.
[07:12] <DanaG> argh, too dang many mixer controls...
[07:12] <DanaG> now is it headset, or earpiece?
[07:20] <DanaG> ah, maybe I do need that other bit of "int" change.
[07:31] <DanaG> argh, pavucontrol over ssh controls the client's pulseaudio, not the server's.
[07:32] <persia> heh.  pavucontrol is too smart :)
[07:33] <DanaG> Dag-blast it, I need this PPA in armel:
[07:33] <DanaG> https://launchpad.net/~blueman/+archive/blueman-dailies/+packages
[07:34] <persia> apt-get source, sbuild -d lucid source.dsc
[07:34] <persia> If that doesn't just work: `mk-sbuild lucid` should get you a nice clean buildd chroot.
[07:34] <persia> And since we never managed to fix the command-not-found bug, install ubuntu-dev-tools to get mk-sbuild.
[07:37] <DanaG> great, I'm tight on space as it is..
[07:37] <persia> Well, you could build with qemu.
[07:37] <persia> Do you have a lucid x86 system available?
[07:37] <persia> (or can you make one)
[07:40] <DanaG> I do have lucid (amd64, rather).
[07:40] <DanaG> It's easier just to go out and get a bigger SD card.
[07:40] <DanaG> =þ
[07:40] <persia> IF you like.
[07:41] <persia> Installing ubuntu-dev-tools, sbuild, and qemu-extras-static on your amd64 machine lets you run `mk-sbuid --arch=armel lucid` which generates an emulated lucid chroot for building stuff.
[07:41] <persia> You can then run `sbuild -d lucid-armel foo.dsc` to generate lucid armel binaries on your host.
[07:41] <persia> I've had a couple issues with some mono packages, but most stuff seems to just work.
[07:50] <DanaG> oooh, I got bluez to segfault.
[07:51] <DanaG> what's a really, really tiny window manager (just needs to be able to change focus and move windows)?
[07:51] <DanaG> tinywm
[08:12] <DanaG> oh guawd, bluetooth audio streamed to the beagleboard works hilariously poorly.
[08:12] <DanaG> Picture taking an audio stream, chopping it into tiny bits, then chipmunkifying and looping those bits.
[08:12] <DanaG> Changing the resampler to speex-fixed-0 seems to have worked.
[08:13] <persia> Oh my.
[08:14] <DanaG> Interesting... changing it to speex-fixed-0 worked so well, in fact, that it works better than when I try to do the same between two x86 systems.
[08:14] <DanaG> On those, I get an assertion failure, and pulseaudio aborts.
[08:14] <persia> file a bug :)
[08:14] <DanaG> Can't do it with apport. =þ
[08:15] <persia> Why not?
[08:17] <DanaG> Upstream ticket, by the way: http://www.mail-archive.com/pulseaudio-tickets@mail.0pointer.de/msg02912.html
[08:18] <DanaG> Apport "does not support" reporting assertion failures.
[08:24] <persia> Ugh!
[08:25] <DanaG> oh yeah, better than speex-fixed-0 is src-linear
[08:26] <DanaG> ...maybe.
[08:26] <persia> You'll find it eventually :)
[08:32] <DanaG> Okay, linear is the only usable one.
[08:32] <DanaG> well, that, and fixed-0.
[08:33] <DanaG> https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/358831
[08:33] <DanaG> old
[08:33] <ubot4> Launchpad bug 358831 in pulseaudio (Ubuntu) (and 1 other project) "[ARM] Pulse Audio eating up to much CPU" [High,Invalid]
[08:36] <persia> Are you running a distro kernel?  If so, please file a new bug.
[08:36] <DanaG> interesting... speex-float-1 works.
[08:36] <DanaG> Surprisingly well.
[08:36] <persia> That old bug got marked invalid because someone filed with with random vendor HW and random vendor kernel, and it's not clear if the issue can be replicated in Ubuntu.
[08:36] <DanaG> Yeah, I figured as such.
[08:37] <DanaG> Wow, float-1 works really well.
[08:37] <DanaG> 55% CPU usage, though.
[08:37] <DanaG> And granted, bluetooth is an extreme use case. =þ
[08:37] <persia> That needs a bug.  Might or might not get a fix, but if it's replicable on known HW/kernel there's a chance that someone can work on it.
[08:37] <DanaG> Network streaming with pulseaudio native works really well with the default resampler.
[08:38] <persia> Not really.  Lots of folk have made noises about running Ubuntu on an N900 or similar, where bluetooth is a common function.
[08:38] <cwillu_at_work> those resamplers would benefits from being rewritten for neon if they aren't already
[08:38] <persia> cwillu_at_work: Feeling bored today?  Want to dig in?
[08:38] <persia> :)
[08:38] <cwillu_at_work> persia, I've been at work for 20 hours today :p
[08:39] <persia> That would be "no" then :)
[08:39] <cwillu_at_work> on the other hand, my sd cards _almost_ boot on c3, c4 beagles and overos :p
[08:39] <persia> What bit doesn't work?
[08:39] <cwillu_at_work> the bit where it boots :p
[08:39]  * persia thought the standard images just worked on C3/C4
[08:40] <cwillu_at_work> I'm not using standard images
[08:40] <persia> Oh, what are you changing?
[08:40]  * persia is wondering how much of the standard-image-build-stuff can be leveraged
[08:40] <cwillu_at_work> the overo is the source of my grief, and it looks like I fried something on the serial level shifter
[08:40] <persia> Ouch!
[08:40] <DanaG> persia: my use case is not streaming from ARM to a headset... but the other way around...
[08:40] <DanaG> streaming from one computer to the beagle over BT.
[08:40] <cwillu_at_work> I've got a hacked up rootstock, so it's basically just a standard deboostrap + extra scripts
[08:41] <persia> DanaG: Do you expect that pulse performance differs based on the direction of the stream?
[08:41] <cwillu_at_work> I can see the uboot prompts, but it sends garbage constantly, so I can't get _past_ the uboot while serial is plugged in
[08:42] <DanaG> I'm not sure... my only regular non-PC headset device is my FreePulse headset... and the power button on it has failed.
[08:42] <persia> And you can't see what you're doing when serial isn't attached.  Yeah.  That makes it hard.
[08:42] <cwillu_at_work> and I only have two sd card readers, and they're both tied up writing out btrfs images at ~50kb/s
[08:42] <DanaG> icantbelieveitsnotbtr?
[08:43] <cwillu_at_work> DanaG, already saved my ass a couple times; I really really hate sd cards, and I really really hate driving four hours to replace one
[08:43] <cwillu_at_work> checksumming + metadata mirroring ftw!
[08:43] <DanaG> Hmm, how stable is the on-disk format for btrfs?
[08:43] <cwillu_at_work> pretty much completely
[08:43] <DanaG> Can you convert from ext4 with extents?
[08:44] <cwillu_at_work> the occasional forward transition, but they're not mucking with it
[08:44] <cwillu_at_work> yep
[08:44] <cwillu_at_work> there's still a bunch of corner cases you have to be aware of though
[08:44] <DanaG> For now, I've been using ext4 with data=journal, since I value data integrity and the ability to recover from just plain unplugging... over the lifespan of SD cards.  At least, that's true of this 2-gig card.
[08:45] <cwillu_at_work> i.e., determining how much free space is non-trivial, and it behaves fairly badly if you run out
[08:45] <cwillu_at_work> see, journalling doesn't get along with sd cards
[08:45] <DanaG> Hmm, I may stick with ext4 for now... though a good point: I should make a DD image, if nothing else, of the card.
[08:46] <cwillu_at_work> and let me assure you that fsck does more harm than good if the journal goes kabloiee
[08:47] <DanaG> hmm.
[08:47] <DanaG> So am I better off with no journal?
[08:47] <cwillu_at_work> you're better off with a keen understanding of how filesystems work and how crappy sd cards handle corner cases :)
[08:48] <cwillu_at_work> but yes, no journal is preferable
[08:48] <cwillu_at_work> At least, unless you're sure that your particular card behaves reasonably well regarding wear levelling (although they're all crappy, these aren't ssd drives) and power loss
[08:49] <DanaG> Ah.  Hmm, then I need to find what tune2fs option to set...
[08:49] <cwillu_at_work> specifically, most/many/some cards handle things _really_ badly if they lose power while they were writing; it's not the clean case that a journal handles, you can lose data that you weren't even writing to
[08:50] <DanaG> Ugh.
[08:50] <cwillu_at_work> hence my current love of btrfs:  it can tell you if things are corrupted and exactly how corrupted they are
[08:53] <DanaG> Login incorrect.
[08:53] <DanaG> Give root password for maintenance
[08:53] <DanaG> (or type Control-D to continue):
[08:53] <DanaG> I press ANYTHING ... even ctrl-d, it loops back to there.
[08:53] <persia> How did you get there?
[08:53] <ogra> did you have an fsck ?
[08:53] <persia> Yeah, you have to have a password.
[08:53] <DanaG> I think I did have one.
[08:54] <cwillu_at_work> you guys haven't fixed that yet?
[08:54] <ogra> cwillu_at_work, release managers are hard to convince sometimes :)
[08:54] <DanaG> I'd been trying to get the udisks-over-ssh working... but it kept giving "stdin: is not a tty"
[08:54] <persia> cwillu_at_work: Fixed which?
[08:54] <ogra> still working on it
[08:54] <ogra> persia, bug 563618
[08:54] <ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[08:54] <persia> Oh, that one.  Yeah.
[08:54] <cwillu_at_work> persia, the arm images having the root account locked rather than simply a deleted password like the rest of ubuntu's archs
[08:54] <cwillu_at_work> passwd -d root
[08:54] <ogra> (it doesnt always result in reboots)
[08:54] <ogra> cwillu_at_work, they dont
[08:55] <cwillu_at_work> DanaG, passwd -d root the next time you're in to make it work right :p
[08:55] <DanaG> Thanks.  I'm just doing fsck on my host, for now. =þ
[08:55] <ogra> cwillu_at_work, dont mix up "arm images" with rootstock built rootfses
[08:55] <persia> cwillu_at_work: I have disabled password on amd64/powerpc.  Are you sure?
[08:55] <cwillu_at_work> ogra, my bad;
[08:55] <ogra> ;)
[08:55] <cwillu_at_work> hence my hacked up rootstock :p
[08:55] <ogra> cwillu_at_work, and you still havent filed a bug :)
[08:56] <persia> Take care with that: there's no guarantee that rootstock generates a policy-compliant install.
[08:56]  * ogra will happily pull that into an SRU
[08:56] <cwillu_at_work> pretty sure I did actually :p
[08:57] <ogra> https://bugs.edge.launchpad.net/project-rootstock/+bugs https://bugs.edge.launchpad.net/ubuntu/+source/rootstock ... neither has it
[08:57] <DanaG> http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareDescription.jsp?lang=en&cc=us&prodTypeId=12454&prodSeriesId=4063703&prodNameId=4063704&swEnvOID=4030&swLang=13&mode=2&taskId=135&swItem=vc-78398-1
[08:57] <DanaG> HP actually uses Debian on some Marvell thingy.
[08:57]  * cwillu_at_work checks his bug list
[08:58] <persia> Doesn't surprise me much.  HP used to ship a live Debian CD as their rescue environment back when I did server farm management.
[09:05] <DanaG> https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap/+bug/566238
[09:05] <ubot4> Launchpad bug 566238 in linux-ti-omap (Ubuntu) "wlan0 "Interface doesn't support scanning." -- CONFIG_CFG80211_WEXT is not set (affects: 1) (heat: 6)" [Undecided,New]
[09:06] <DanaG> Heat?
[09:09] <cwillu_at_work> hawt
[09:19] <persia> It's a new metric the LP guys added to help identify which bugs are interesting.  So far, I haven't seen it provide interesting information, but I understand they are tuning the algorithm.
[09:22] <lool> It's the number of times the page is loaded
[09:22] <lool> It's a very often used metric amongst web developers
[09:22] <lool> The number of heats of a page gives a good idea of its popularity
[09:23] <persia> It's more complex than that.  It takes into account *who* loads it, etc.
[09:23] <persia> And who files it, what status it is, etc.
[09:24] <persia> (or else someone gave me wrong information)
[09:25] <lool> persia: I was kidding actually  :)
[09:25] <lool> hit versus heat
[09:25] <lool> I did fail at making it sound like a joke it seems!
[09:25] <persia> But it's one of those rare jokes that's funny *after* it's explained :)
[09:26] <persia> (but I'm in end-of-day mode, and so a bit humour impaired just now)
[09:29]  * ogra_beagle waves from a successful netbook install 
[09:29] <persia> \o/
[09:29] <ogra_beagle> only the clock issue left
[09:30] <ogra_beagle> and htop shows a moderate 174M being used
[09:30] <ogra_beagle> (only xchat, one terminal and desktop up though)
[09:31] <cwillu_at_work> which clock issue?
[09:31]  * cwillu_at_work strongly recommends buying the lithium battery for the beagle
[09:32] <ogra> cwillu_at_work, bug 563618
[09:32] <ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 3 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[09:32] <cwillu_at_work> ogra, keep your computer plugged into the network :)
[09:33] <ogra> cwillu_at_work, by default the board comes without, i want the images to work on a default config ... fsck needs fixing and will get fixed but that wont happen for lucid
[09:33] <cwillu_at_work> or do what I do (on the boards that don't yet have lithium batteries):
[09:33] <ogra> network wont help
[09:33] <cwillu_at_work> use a filesystem that doesn't have a working fsck :)
[09:33] <ogra> network isnt up when fsck is run
[09:34] <ogra> nah, we will fix it properly
[09:34] <ogra> for now it has to be a workaround though
[09:34] <ogra> but i'm still waiting for release manager approval
[09:35] <ogra> ted tso already agreed on fixing it right in fsck
[09:36]  * ogra thinks he earned some breakfast before setting up the installation wikipages 
[09:36] <ogra> bbl
[10:00] <amitk> ogra_cmpc: what address in the nand do you write the boot.scr, kernel, initrd to? (sd install)
[10:13]  * cwillu_at_work jumps
[10:13] <cwillu_at_work> first image finished umounting!
[10:14] <cwillu_at_work> now if only I knew which reader was sdh and which was sdd so I don't panic the kernel removing the wrong one :p
[10:31] <ogra> amitk, ??
[10:32] <ogra> amitk, i write to mtdblock devices
[10:32] <ogra> no special addressing
[10:32] <amitk> ogra: if i wanted to change the boot.scr, how would I do that?
[10:32] <ogra> after install ?
[10:32] <amitk> yes
[10:33] <amitk> to get rid of the POS splash and get back serial console
[10:33] <ogra> sudo fw_printenv and fw_setenv
[10:33] <amitk> ogra: ah, nice
[10:33] <ogra> sudo fw_setenv bootargs "your boot args"
[10:33] <ogra> similar to redboot-cmdline
[10:34] <amitk> nice integration! perhaps too simple :)
[10:40] <ogra> heh
[10:41] <ogra> asac, welcome to the "league of old farts" and ******** H A P P Y   B I R T H D A Y ! ! ! ! ! ! ! ! ! ! *********
[10:41] <DanaG1>  /dev/disk/by-id is useful.
[10:41] <DanaG1> or /dev/disk/by-path
[10:43] <NCommander> eggonlea: you around?
[10:47] <dmart> ogra: hi there
[10:48] <ogra> hey
[10:48] <dmart> Just saw your comment in https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/563618
[10:48] <ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 5 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged]
[10:48] <ogra> yup
[10:48] <ogra> its still not approved :/
[10:48] <dmart> How would I set up a branch with the extra code to test?
[10:48] <ogra> and the longer it takes the less likely it will be we'll get it in
[10:49] <ogra> branch from my branch, edit the script file i added, copy hook and script in place on your board, run update initramfs and try it
[10:50] <ogra> (and indeed make sure the clock is wrong and mount time of the disk is in the future :) )
[10:50] <dmart> Er, what's a branch?  Are we talking bzr or launchpad here, or something else?
[10:50] <ogra> i linked a bzr branch to the bug
[10:50] <ogra> lp:~ogra/initramfs-tools/initramfs-tools-fixrtc
[10:51] <dmart> Unfortunately, I don't really know how to use bzr yet...
[10:51] <dmart> My suggestions were "nice to have"— we could skip those if it's a problem.
[10:51] <ogra> https://code.edge.launchpad.net/~ogra/initramfs-tools/initramfs-tools-fixrtc says at the top what to do
[10:51] <ogra> bzr branch lp:~ogra/initramfs-tools/initramfs-tools-fixrtc
[10:52] <ogra> cd into the newly created dir ... cd to scripts/local-premount ... edit fixrtc
[10:53] <ogra> if the change is good: bzr commit -m 'your commit message'; bzr push lp:~dmart/initramfs-tools/initramfs-tools-fixrtc and add the branch to the bug
[10:54] <dmart> Does the bzr push create a new branch owned by me?
[10:54] <persia> If you push to that location, yes.
[10:54] <persia> IF you push to an existing branch (to which you have write permission), no.
[10:54] <dmart> so lp:~dmart/initramfs-tools/initramfs-tools-fixrtc gets made if it doesn't exist yet?
[10:54] <ogra> the hook needs to go into /usr/share/initramfs-tools/hooks and the script into /usr/share/initramfs-tools/scripts/local-premount before calling update-initramfs -u (make sure both are executable)
[10:54] <persia> RIght.
[10:55] <ogra> right
[10:55] <dmart> ok... I will have a go
[10:56] <ogra> oh, indeed ~dmart needs to be your LP id
[10:56]  * ogra just noticed its not dmart :)
[10:57] <dmart> I should maybe change it sometime, but yeah.  I can probably work that one out :)
[10:57] <ogra> :)
[10:57] <persia> No need to change it: just make sure your nick is registered on LP, and folks can find you from launchpad.net/people
[10:58] <persia> Also, once you start publishing branches and having a PPA, changing the name is hard.
[11:07] <dmart> ogra: is scripts/local-premount/fixrtc sourced or exec'd ?
[11:07] <ogra> exec'd
[11:07] <ogra> (thats why it has a shebang)
[11:07] <dmart> (doesn't always follow)
[11:08] <dmart> Is it worth quitting the script if we didn't find root= ?
[11:08] <ogra> heh
[11:08] <dmart> (though it's unlikely)
[11:08] <ogra> if we dont find root= we have bigger probs
[11:09] <dmart> true - probably not worth it yet
[11:14] <dmart> ogra: Do we have e2fsck.conf in the initramfs?
[11:14] <ogra> nope
[11:14] <ogra> and it wouldnt help anyway
[11:15] <dmart> Just wondered if we could default to the fixrtc behaviour if the broken rtc option is set.
[11:15] <ogra> no
[11:15] <dmart> But this is a hack anyway...
[11:15] <dmart> so it doesn't matter too much
[11:15] <ogra> right, you would need to create an e2fsck.conf and set the parameter etc
[11:16] <ogra> well, its the right fix once we have an actual option in fsck
[11:16] <ogra> if thats there in maverick i'll make the installer create an e2fsck.conf
[11:16] <ogra> but with the existing option not working its moot
[11:17] <dmart> Can the e2fsck.conf be grabbed from /etc when making the initramfs?  That way whatever the admin configures would be used
[11:17] <ogra> i think thats happening already
[11:17] <ogra> if not i'll make sure it happens in maverick
[11:18] <ogra> in any case the option needs to be fixed first
[11:18] <ogra> we'll have to wait for upstream to fix that
[11:23] <dmart> What happens if this script terminates with non-zero exit status?
[11:23] <persia> Make it not do that.  Use ||true if necessary.
[11:24] <dmart> I want to use set -e, since if dumpe2fs fails or something else goes wrong, we may accidentally set the clock to junk...
[11:24] <persia> I believe it dumps when it fails.
[11:25] <persia> Is it possible to do sanity checking and set the clock to the epoch if we can't get useful data?
[11:25] <ogra> depends what you mean by epoch :)
[11:25] <dmart> What kind of sanity-check do you suggest?
[11:26] <ogra> the beagle epoch is 01-01-2000 ... i'm not sure if you could even set the clock to an earlier date
[11:26] <persia> dmart: e.g. make sure the date is set to something between 1970 and 2038.
[11:26] <ogra> dont put so much effort into that hack
[11:26] <ogra> and dont make it to big
[11:27]  * persia doesn't want set -e + the hack to make systems unbootable
[11:27] <ogra> s/big/complex/
[11:27] <dmart> date --set will barf if the supplied textual date won't fit in time_t
[11:27] <ogra> persia, they are unbootable already
[11:27] <dmart> so we just give up (which may be the best thing)
[11:28] <dmart> We shouldn't make any otherwise bootable cases unbootable
[11:28] <ogra> and if you want to not use the fix, just drop fixrtc from the cmdline
[11:28] <persia> Fine.  I don't like it because it's not elegant, but I agree it makes sense to do it right later.
[11:28] <ogra> right, the hack is temporary anyway
[11:28] <dmart> This is a bodge in advence of the real fix (which is to make e2fsck less picky about the clock)
[11:28] <ogra> exactly
[11:28] <ogra> and upstream is aware and agreed to fix it already
[11:28] <dmart> The other way to work round the issues is mount -o remount,rw / ; mount -o remount,ro /
[11:29] <dmart> (but this is obviously not a great idea if the root fs might be damaged)
[11:29] <ogra> i think that will slow down your boot significantly
[11:29] <persia> Not "less picky", but rather "handle the case where the clock has been reset"
[11:30] <ogra> i was already hitting a race with setting the date to the proper time and needed to add a minute if you mount and remount you will likely have to add sleeps
[11:30] <ogra> or at least wait until mount is done
[11:30] <dmart> iiuc, ext[2-4] fs filesystem integrity does not depend on the integrity of the clock.  I think e2fsck has some clock-based heuristics for sorting out filesystem errors, but that's only an issue if the filesystem is actually broken
[11:31] <ogra> right, the prob is that fsck doesnt handle the case properly
[11:31] <dmart> dmart: but we should let upstream have the final say, of course
[11:31]  * dmart is talking to himself now...
[11:31] <ogra> heh
[11:39] <ogra> dpkg-buildpackage: host architecture armel
[11:39] <ogra>  /usr/bin/fakeroot debian/rules clean
[11:39] <ogra> debian/rules:39: *** atlas doesn't build on arm, not terminating on the buildd.  Stop.
[11:39] <ogra> dpkg-buildpackage: error: /usr/bin/fakeroot debian/rules clean gave error exit status 2
[11:39]  * ogra shakes his head
[11:39] <ogra> i wonder if the packager every heard of the Yrchitecture field :P
[11:40] <ogra> *Architecture
[11:40] <dmart> ogra: can you take a look at http://pastebin.ubuntu.com/420963/
[11:42] <ogra> dmart, looks fine, tested already ?
[11:42] <dmart> I have tested "by diff" -- replacing $(cat /proc/cmdline) with $(echo) and prefixing the date and hwclock commands with echo to check that they are run at the right times and with the expected arguments
[11:42] <dmart> is that enough?
[11:43] <dmart> otherwise, how to I set up the initramfs?
[11:43] <ogra> well, i'd like to hear that a boot succeeds with different root= cmdline options on a system that exposes the issue
 the hook needs to go into /usr/share/initramfs-tools/hooks and the script into /usr/share/initramfs-tools/scripts/local-premount before calling update-initramfs -u (make sure both are executable)
[11:44] <dmart> OK, I'll try it
[11:44] <ogra> (and you need to set fixrtc on the cmdline indeed)
[11:44] <dmart> yeah
[11:44] <dmart> thanks, I probably would have forgotten ;)
[11:44] <ogra> heh
[11:52] <dmart> blaargh, guess what?
[11:53] <dmart> (forgot fixrtc)
[11:57] <ogra> lol
[12:22] <dmart> ogra: hi there
[12:22] <ogra> hey
[12:22] <ogra> works ?
[12:22] <dmart> I think it mostly works
[12:22] <ogra> mostly ?
[12:22] <dmart> But dumpe2fs and its libraries appear to be missing from the initramfs
[12:22] <ogra> did you copy the hook in place before running update-initramfs -u ?
[12:23] <ogra> needs to go to /usr/share/initramfs-tools/hooks and needs to be executable
[12:23] <dmart> Ah, hold on a minute --- what is "the hook"?
[12:24] <ogra> http://bazaar.launchpad.net/~ogra/initramfs-tools/initramfs-tools-fixrtc/revision/182
[12:24] <ogra> hooks/fixrtc
[12:25] <dmart> ah, oops
[12:25]  * ogra kicks the wiki
[12:26] <dmart> right, updating the initramfs again...
[12:28] <dmart> ah, better
[12:30] <dmart> Well, we still have the issue that if the clock is only intermittently corrupted across boot, we always break it (by resetting it based on the last mount time)
[12:30] <dmart> But since this is only for broken systems anyway, that's probably OK
[12:30] <dmart> The clock should never be seen to go backwards
[12:30] <dmart> And ntp should patch things up
[12:32] <ogra> right
[12:32] <ogra> and you wont need it at all if you never pull the power plug :)
[12:33] <ogra> ok, if it works fine, please note that on the bug and point to your branch (and link the branch to the bug (top right there is an option))
[12:37] <dmart> When bzr committing, how to I get the committer name and email right?
[12:37] <dmart> I'm working on a dev board, so those are garbage
[12:37] <dmart> ...or will launchpad patch it up?
[12:39] <persia> bzr launchpad-login will help
[12:39] <persia> bzr whoami will do the rest of it
[12:39] <persia> LP won't get it right based on your ssh keys, for complex reasons (you might be pushing someone else's commits, etc.)
[12:53] <dmart> ok, done
[12:54]  * dmart 's ignorance has decreased
[12:54] <dmart> (slightly)
[12:54] <dmart> thanks for the pointers
[12:59] <persia> That's why we're here.  Thanks for helping work on the bug.
[13:01] <dmart> I'll know for next time... lp+bzr is still rather a mystery for me ;)  Are there any good docs floating aroung?
[13:01] <dmart> around
[13:01] <dmart> ogra: done (in case you didn't see)
[13:01] <ogra> i did
[13:01] <persia> Docs?
[13:02]  * persia digs some up
[13:02] <ogra> thanks a lot !
[13:02] <persia> dmart: https://help.launchpad.net/Code isn't a bad place to start.
[13:03] <dmart> cool, thanks
[13:08] <ogra> https://wiki.ubuntu.com/ARM/Beagle
[13:08] <ogra> finished :)
[13:08] <ogra> anyone who wants, feel free to improve/enhance
[13:09] <persia> You know we have a Qt/plasma variant as well, right?
[13:09] <persia> Has anyone installed that?  Does it work OK on the Beagle?
[13:10] <ogra> no idea
[13:10] <ogra> i dont think we build it
[13:10] <rcn-ee> quick, glance it looks good ogra...
[13:10] <persia> http://cdimage.ubuntu.com/kubuntu-netbook/ports/daily-live/current/lucid-netbook-armel+omap.img
[13:10] <ogra> oh, we do build it
[13:10] <ogra> yeah, just saw that
[13:10] <ogra> no idea, i wont have the time
[13:11] <ogra> s/have/take/
[13:11]  * persia tries to find out if it passed RC testing
[13:11] <ogra> i'll put info that it exists in the blog post i'll write soon
[13:11] <ogra> probably someone in the community wants to test it
[13:12] <ogra> (if the KDE ubiquity doesnt OOM anyway that is :) )
[13:12] <persia> Yeah, didn't get into the RC testing, so there's no record if anyone tried it.
[13:12] <persia> That's my thought.
[13:12] <ogra> omap didnt get into the RC testing at all
[13:12] <persia> I know it works for dove/imx51 (it passed RC testing)
[13:12] <persia> But those have more RAM.
[13:13] <ogra> its fully voluntary even for release for 10.04
[13:13] <persia> I didn't think it was even schedued for formal release, but just that we'd have cdimages.
[13:13] <ogra> right
[13:14] <persia> Anyway, I don't have a Beagle, so I can't know.  Anyone with a Beagle up for seeing if that image boots?
[13:14] <ogra> given there is no EFL launcher for kubuntu-netbook i really doubt it will work
[13:14] <ogra> qt-ubiquity will probably run though
[13:15] <persia> plasma-netbook is designed to be lightweight though.
[13:15] <ogra> not as light as efl though
[13:15] <ogra> and even that is close to the edge on beagle
[13:15]  * persia refuses to argue about toolkits
[13:16] <ogra> heh, that wasnt my intention :)
[13:16] <suihkulokki> xaw3d xaw3d!
[13:16] <ogra> yeah !
[13:16] <ogra> thats a 3d toolkit that works everywhere at least !
[13:17] <persia> Isn't Beagle specs similar to n810?
[13:17] <ogra> persia, well, kubuntu is still at 20.1 that wont work anyway
[13:17] <suihkulokki> beagle is more powerful than n810
[13:17] <ogra> it needs a build from 22
[13:17] <ogra> else the flash-kernel fixes are missing
[13:18] <persia> Oh.
[13:18] <persia> Are image builders still on manual?  They should probably get turned on for the weekend.
[13:18] <ogra> i think they might stay on manual
[13:19] <ogra> ask steve
[13:23] <NCommander> lool: why'd you upload kexec-tools to ~canonical-arm-dev/marvell-dove-public?
[13:23] <lool> NCommander: for testing
[13:24] <lool> NCommander: Because I needed public armel builds before pushing to the arcihve
[13:24] <lool> NCommander: can be dropped now
[13:24] <NCommander> lool: fair enough. I just didn't expect to see it there
[13:24] <lool> NCommander: I checked with other people before doing it -- note that it affected dove too
[13:24] <NCommander> lool: not a problem, was just curious
[13:25] <lool> removed
[13:25] <ogra> lool, https://wiki.ubuntu.com/ARM/Beagle
[13:25] <ogra> feel free to test :)
[13:26] <lool> Favoriten
[13:26] <lool> lol
[13:26] <lool> Büro!
[13:26] <ogra> yeah, i need to add an english screenie once i have an english install :)
[13:26] <ogra> will do that before final :)
[13:26] <lool> Should be Software-Zentrum!
[13:26] <ogra> LOL !
[13:27] <lool> ogra: You want the bootloaders links I guess
[13:27] <ogra> i havent written that yet
[13:27] <ogra> you mean how to install uboot to nand etc, right ?
[13:28] <ogra> or put MLO on your fat
[13:28] <ogra> i'll do that over the weekend, for now i wanted to have the general pages ready
[13:28] <ogra> since i want to blog it to get some attention
[13:28] <lool> ogra: I mean links to working bootloaders
[13:28] <lool> ogra: how to flash them etc.
[13:28] <ogra> yes
[13:28] <lool> ogra: because people might be stuck if they don't load boot.scr
[13:28] <ogra> havent got that yet
[13:29] <ogra> its all on the elinux wiki and i assume beagle users know that
[13:29] <ogra> they will survive over the weekend :)
[13:29] <ogra> or come here and complain ;)
[13:29] <rcn-ee> lool, boot.scr's are pretty much the default on the beagle elinux land .. ;)
[13:30] <lool> ogra: netbook install points at server image
[13:30] <lool> "Get the lucid-server-armel+omap.img image"
[13:30] <ogra> rcn-ee, but you could have changed your uboot setup (which is why i have the "how to load a boot.scr from serial prompt" part in all the installation pages)
[13:30] <lool> fixed
[13:31] <ogra> thanks :)
[13:31] <ogra> oops
[13:31] <ogra> luckily the link was ok
[13:31] <rcn-ee> yeap..  as long as you go over how to flash u-boot and change things, that'll cover those issues...
[13:31] <ogra> right
[13:31] <ogra> i still have a week to shake out all the docs
[13:31] <lool> ogra: Ideally, but together a SD card image with just x-loader + u-boot and a default config which just flashes the board
[13:32] <lool> So that people basically boot with it, and it flashes their NAND as appropriate
[13:32] <ogra> thats just a start, i'm sure questions will come up that show wheer we need additional documentation
[13:32] <rcn-ee> lool, like https://code.launchpad.net/~beagleboard-kernel/+junk/omap-flasher ;)
[13:32] <ogra> haha
[13:32] <ogra> rcn-ee, i'll link that on the flasher page :)
[13:33] <lool> ogra: https://wiki.ubuntu.com/ARM/BeagleEditBootscr is awful
[13:33] <rcn-ee> oh great... i got tired of doing the commands my self.. so i scripted it..
[13:33] <lool> ogra: can't we just ship boot.script in the image?
[13:33] <ogra> lool, what dont you like about it ?
[13:33] <lool> the dd
[13:33] <ogra> lool, i wont change debian-cd anymore now
[13:33] <rcn-ee> yeah the dd is different.. i never thought about doing that.. but it works...
[13:33] <ogra> we can ship it in 10.++
[13:34] <ogra> lool, there is a lot of awful stuff about that image that needs to improve
[13:34] <ogra> its a first hit
[13:34] <ogra> created in a week
[13:34] <ogra> dont expect shiny :)
[13:35] <persia> Rather, expect shiny, because that's interface, and shared, but don't peer under the sleek shiny cover too much.
[13:35] <rcn-ee> It look's fine and will work for most people...  the others always do what they want anyways..
[13:36] <ogra> rcn-ee, there are a lot of things i could have done better and i know lool will die if he looks into details :)
[13:36] <ogra> but there is always 10.++
[13:36] <ogra> which will fix that
[13:36] <rcn-ee> laughs, i just hope he doesn't look into my Netinstall hack..  Probally cringe and never look at any of patches.. ;)
[14:04] <rcn-ee> and we'll have the XM for 10.10 ;)
[14:05] <persia> Don't get too excited: that just means we have that much more work to do to create a boot script that can somehow boot on more platforms.
[14:07] <rcn-ee> well my script, currently boots Bx, Cx and my proto Xm.. ;)  if only the kenrel didn't bomb on the xm... I'm hoping enough kernel bits for the Xm hit mainline that omap can share the ubuntu kernel..
[14:07] <persia> Well, there's currently a special omap kernel in Ubuntu, but yeah, extra points for getting into the "normal" ports kernels.
[14:09] <rcn-ee> just for reference, the XM uses a new omap3 similar core, DM3730 but the kernel bits are in a ti staging repo...
[14:09] <lool> rcn-ee: public?
[14:10] <rcn-ee> yeap.. as i dig for the link...
[14:10] <lool> rcn-ee: it's good
[14:10] <lool> just knowing it's public is enough
[14:10] <rcn-ee> http://arago-project.org/git/people/sriram/ti-psp-omap.git?p=people/sriram/ti-psp-omap.git
[14:11] <rcn-ee> *okay heads to work, but will be back, i enjoy half fridays.. ;)
[14:22] <ogra> http://ograblog.wordpress.com/2010/04/23/unleash-the-beagles/
[14:22]  * ogra had some issues to get the utf-8 right on lool's name :)
[14:52] <lool> rcn-ee: Do you know what comes with the digikey beagleboard?  cant figure whether it has power adapter
[15:04] <ogra> ndec, http://ograblog.wordpress.com/2010/04/23/unleash-the-beagles/
[15:30] <gduarte> hello ogra
[15:30] <ogra> gduarte, hey
[15:31] <gduarte> :D ogra, do you know where i can download (if exist) a pre-compiled qemu-arm image to use directly with qemu
[15:31] <gduarte> ?
[15:31] <gduarte> I'm trying for 3 days without success
[15:32] <ogra> nope, but if you follow the https://wiki.ubuntu.com/ARM/RootfsFromScratch page you can create one
[15:32] <gduarte> yep
[15:32] <gduarte> I've tried it, no success
[15:32] <ogra> what was the issue ?
[15:32] <gduarte> I'm trying it right now http://people.canonical.com/~ogra/arm/qemu/README
[15:33] <ogra> oh, thats ancient
[15:33] <gduarte> but don't know if it is the same thing
[15:33] <ogra> dont use that
[15:33] <gduarte> ahhh
[15:33]  * ogra needs to clean up his homedir
[15:33] <ogra> what did not work with https://wiki.ubuntu.com/ARM/RootfsFromScratch ?
[15:33] <gduarte> my problem is when I try to log in into my emulated system
[15:34] <gduarte> i type my login, but it's no recognized
[15:34] <gduarte> never
[15:34] <gduarte> and followed by filesystem issues
[15:34] <ogra> what is your host system ?
[15:34] <gduarte> Ubuntu 9.10 amd64
[15:35] <ogra> hmm, ok
[15:35] <ogra> you can install qemu-arm-static there and chroot into your image to fix it up
[15:35] <gduarte> ok :D I'll be able to compile my programs there?
[15:36] <ogra> yes, but it is as slow as a VM
[15:36] <gduarte> no problem ;) thank you ogra
[15:37] <ogra> after you installed qemu-arm-static, loop mount the image and cp the qemu-arm-static binary into <mountpoint>/usr/bin/
[15:37] <ogra> then you can just chroot
[15:37] <gduarte> ok ok,  I'll do it
[15:40] <persia> GrueMaster: Did you get a chance to test kubuntu-netbook on imx51/dove?
[15:41] <GrueMaster> I'm just now loading it on imx51.  Already hit a few minor issues.
[15:44] <asac> ogra: plars: GrueMaster: persia: NCommander: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
[15:44] <asac> dyfet: ^
[15:44] <persia> OK.  freeflying and Riddell were wondering if it got tested in #kubuntu-devel, and I misread "netboot" as "netbook" on the kubuntu page before, so had the wrong information :(
[15:44] <asac> maybe check out if i missed something in the summary that you want to have there
[15:44] <gduarte> ian_brasil : are a ARM developer from Brasil?
[15:44] <gduarte> **are you
[15:44] <NCommander> asac: looks good.
[15:44] <persia> fpc moved to SRU :(
[15:44] <ian_brasil> well i am from Brasil :)
[15:44] <NCommander> persia: sorry, I didn't get to that >.<;
[15:45] <ian_brasil> well strictly speaking I am not Brazilian but i live in Brazil
[15:45] <asac> persia: thats a really old bug. no progress. if we had a fix today we can resurrect it for final maybe
[15:45] <persia> NCommander: No worries.  THe issue is that it only doesn't work for the folks that are able to bootstrap.  Works for the folks that wanted it to happen :)
[15:45] <ian_brasil> ah, he left
[15:45] <persia> asac: It's an old bug because doko decided to hijack the powerpc bootstrap bug to bootstrap armel.
[15:46] <persia> (not that I'm complaining, because it made powerpc get bootstrapped, but ... )
[15:46] <ogra> asac, looks all good to me
[15:46] <persia> asac: You might want to beg again for bug #538736 if you don't like the current answer
[15:46] <ubot4> Launchpad bug 538736 in vm "Filename encoding for external viewer inconsistent (affects: 1) (heat: 6)" [Undecided,Incomplete] https://launchpad.net/bugs/538736
[15:47] <persia> NO.
[15:47] <persia> bug #568736
[15:47] <ubot4> Launchpad bug 568736 in netbook-meta (Ubuntu Lucid) (and 1 other project) "Having Evolution installed along with Desktop-Email is pointlessly redundant (affects: 1) (heat: 12)" [High,Won't fix] https://launchpad.net/bugs/568736
[15:47] <ogra> asac, slangasek promised to review bug 563618 right after the meeting, we should make sure to tickle him so he doesnt forget again :)
[15:47] <ubot4> Launchpad bug 563618 in util-linux (Ubuntu Lucid) (and 5 other projects) "Ignoring a broken clock results in infinite reboots; not ignoring results in fsck failure; no solution to this problem (affects: 1) (heat: 14)" [High,Triaged] https://launchpad.net/bugs/563618
[15:51] <asac> ogra: its on the list
[15:51] <asac> ogra: e.g. on the list of still final targetted bugs
[15:52] <ogra> yeah, saw that
[16:07] <cwillu_at_work> rcn-ee, poke poek
[16:07] <cwillu_at_work> question for ya :)
[16:08] <cwillu_at_work> http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/revision/57
[16:08] <cwillu_at_work> which of your kernels is that patch in?
[16:14] <gduarte> ogra: sorry for annoying you again
[16:14] <gduarte> but
[16:14] <ogra> shoot
[16:14] <gduarte> I'm having this problem
[16:15] <gduarte> I: Creating temporary Image
[16:15] <gduarte> I: Mounting temporary Image
[16:15] <gduarte> I: Running first stage
[16:15] <gduarte> sudo: unable to cache gid, already exists
[16:15] <gduarte> I: First stage install done
[16:15] <gduarte> /usr/bin/rootstock: 572: cannot create /tmp/tmp.x3pBJdpxDE/tmpmount/etc/fstab: Directory nonexistent
[16:15] <gduarte> in another machine
[16:15] <ogra> can you pastebin the logfile somewhere ?
[16:15] <ogra> it should have cerated one on exit and tell you where that lives
[16:16] <gduarte> ok
[16:17] <ogra> and the version of rootstock to use as well as the complete command you call to run it would also help
[16:17] <gduarte> it's not creating a log file
[16:17] <ogra> s/to use/you use/
[16:18] <gduarte> sudo rootstock --fqdn ubuntu-arm-dev --login ubuntu --password ubuntu --imagesize 2G --seed xubuntu-desktop
[16:18] <gduarte> this is the command
[16:18] <ogra> that should be fine
[16:19] <ogra> could it be that your disk is full ?
[16:19] <gduarte> yes, but isn't working
[16:19] <gduarte> no, i'ts not full
[16:19] <cwillu_at_work> gduarte, do you have a million loop mounts showing up if you type "mount"?
[16:19] <ogra> right, that was my next question
[16:19] <gduarte> I'll check
[16:20] <gduarte> no, no loop devices mounted
[16:21] <ogra> and its directly going from "I: Running first stage" to "I: First stage install done" just with that one line inbetween ?
[16:22] <gduarte> no
[16:23] <gduarte> I'ill past at pastbin
[16:23] <gduarte> I'll*
[16:24] <gduarte> **paste
[16:26] <gduarte> http://pastebin.com/Su3gmYEB
[16:26] <gduarte> there
[16:30] <gduarte> saw?
[16:30] <ogra> gduarte, so how did you install rootstock
[16:30] <gduarte> apt-get
[16:30] <gduarte> sudo apt-get install rootstock
[16:30] <ogra> hmm, weird
[16:30] <gduarte> this way
[16:32] <gduarte> :(
[16:32] <ogra> is debootstrap installed ?
[16:33] <ogra> i dont get why it doesnt seem to run it at all
[16:33] <gduarte> ye, it's installed, is downloaded together with rootstock when run apt-get
[16:33] <ogra> right
[16:33] <ogra> but it isnt executed at all
[16:34] <ogra> thast very weird
[16:34] <ogra> *that's
[16:34] <gduarte> unlucky
[16:35] <ogra> qemu-kvm is installed as well ?
[16:35] <gduarte> yes, it's also installed together with rootstock
[16:36] <ogra> right, and qemu-img seems to run fine since it shows I: Mounting temporary Image
[16:37] <ogra> but your first stage does definately not run
[16:37] <ogra> (which is debootstrap)
[16:37] <gduarte> :S
[16:37] <gduarte> I really need it, because I need to compile and package to ARM
[16:37] <ogra> might be an amd64 issue in karmic
[16:38] <gduarte> it's my exam to be hired to canonical :(
[16:39] <ogra> try the following: "sudo debootsrap --arch=i386 lucid $HOME/lucid-i386" that will give you a lucid i386 environment
[16:39] <gduarte> ok
[16:40] <ogra> chroot into that and you shopuld be able to install rootstock and run it under i386
[16:41] <gduarte> it's retrieving packages
[16:41] <ogra> yeah
[16:42] <gduarte> would be nice if would exist a default image to everybody download and modify
[16:43] <ogra> we might provide something like that in maverick
[16:43] <ogra> though the tools got a lot better in lucid already
[16:43] <ogra> i know there were qemu related issues in karmic
[16:43] <ogra> on amd64
[16:43] <gduarte> :(
[16:44] <orbarron> hey all... I was thinking about registering a blueprint for a Mobile Ubuntu user interface (mo-buntu). The main idea would be creating a better mobile experience for "phone like" devices. Does anyone know if something like this is in the works for lucid? -- any feedback?
[16:45] <ogra> orbarron, there is some QT based work ian_brasil works on iirc (not sure how much phone based that is)
[16:45] <ogra> might be somewhere between netbook and phone rather
[16:45] <ogra> beyond that i dont know whats planned for UDS
[16:46] <ian_brasil> we will integrate ophono
[16:46] <ian_brasil> so it will be phone based
[16:47] <ian_brasil> obarron..look at https://blueprints.launchpad.net/ubuntu/+spec/mobile-liquid
[16:47] <orbarron> ahh thanks...
[16:49] <ian_brasil> orbarron: there are likely to be some discussions at UDS about this - how to sanely break down kdelibs mainly if you are interested
[16:51] <lool> ian_brasil: ofono :)
[16:51] <ogra> haha
[16:51]  * ogra read that typo somewhere today already
[16:51] <lool> yep, asac
[16:53] <asac> ian_brasil: cool. can we have a call on your ofono experiences etc.?
[16:54] <asac> not today. but next week?
[16:54] <asac> or we can chat, but my hands are getting lamer every day i continue to do that ;)
[16:54] <ogra> asac, thats the raising age :)
[16:55] <ogra> (i wished you a happy b-day this morning in case you havent seen it)
[16:55] <asac> ogra: i saw ... i tried to ignore it for obvious reasons. thanks for spreading it to the world ;)
[16:55] <ogra> lol
[16:56] <asac> but its over soon enough ;)
[16:56] <ian_brasil> asac: let me ping some people then
[16:56] <asac> and /me will get off now for a bit anyway
[16:56] <asac> ian_brasil: cool. lets talk on monday?
[16:56] <ogra> yeah, enjoy your evening
[16:56] <asac> (i am mostly out)
[16:56] <asac> thanks!!!!
[16:56] <ogra> and stay away from the kbd !
[16:56] <asac> i will i will
[16:56] <asac> ogra: remember to submit your blueprints against ubuntu-arm ;)
[16:57] <ogra> if i could rememebr the blueprints i had done it already ... i need to look them up
[16:57] <ian_brasil> asac: cool
[16:57] <ogra> but i'm waiting for slangasek anyway
[17:07] <gduarte> ogra: I got it!!!!!
[17:07] <ogra> wonderful
[17:08] <gduarte> it's basic, no gcc, no X,  some few FS issues but works
[17:08] <ogra> good
[17:08] <gduarte> I can make it avaliable to others?
[17:08] <ogra> you can do what you like with it :)
[17:09] <gduarte> i know
[17:09] <gduarte> but, to other that do not want to download and buid it, get a pre-compiled image
[17:09] <gduarte> we could make it avaliable at that page
[17:10] <ogra> sure, if you have space to host it you can make it available
[17:13] <gduarte> ok
[17:14] <gduarte> I'll improve that, install gcc and some other dev stuff and make it avaliable if i could
[17:14] <ogra> gret
[17:14] <ogra> *great even
[17:14] <gduarte> :D
[17:16] <gduarte> :D
[17:16] <gduarte> thank you for helping me!!!!
[17:17] <ogra> welcome, if you have other issues, dont hesitate to ask here (even if i'm not around there are surely people who can help)
[17:18] <gduarte> surely ;)
[17:19] <gduarte> thank you again!
[17:30] <DanaG> http://www.bit-tech.net/news/hardware/2010/04/23/samsung-plans-own-netbook-chips/1
[17:52] <samuel_Sayag> hi, I need to add FireWire support to the Ubuntu-ARM linux kernel. do i must recompile the whole kernel for that ?
[18:02] <tractor> No doubt this has been asked before so apologies in advance. I am looking at the arm9 and wondering if Ubuntu is available for it.
[18:17] <tractor> Anybody there?
[18:23] <Meizirkki> tractor,
[18:23] <Meizirkki> http://wiki.ubuntu.com/
[18:23] <tractor> Excellent, thanks. Let me check that.
[18:23] <Meizirkki> err..
[18:24] <Meizirkki> wth is wrong with my clipboard -.-
[18:24] <tractor> I only know it is an arm9 processor, I don't have any further details than that unfortunately
[18:24] <Meizirkki> I meant https://wiki.ubuntu.com/ARM
[18:24] <tractor> Oh, I see, thanks for the correction
[18:25] <Meizirkki> Lucid probably doesn't work on arm9 machines
[18:25] <Meizirkki> hmm, not Karmic either is seems
[18:26] <samuel_Sayag> I have error while loading shared libraries libraw1394.so.8: cannot open shared object file problem ... though all my lib files are linked correctly
[18:26] <samuel_Sayag> any ideals?
[18:29] <samuel_Sayag> should I link them to usr/include ?
[18:34] <tractor> Thanks Meizirkki, just looking through it now.
[19:22] <rcn-ee> cwillu_at_work, pong.... rev 57 would be anything 2.6.32.10-l10.0 ++++
[19:23] <cwillu_at_work> and in the karmic kernels as well?
[19:23] <cwillu_at_work> [    1.412597] omapfb omapfb: no displays
[19:23] <cwillu_at_work> [    1.416442] omapfb omapfb: failed to setup omapfb
[19:23] <cwillu_at_work> [    1.421203] omapfb: probe of omapfb failed with error -22
[19:24] <rcn-ee> yeah, exactly...  one user said it worked on their overo... looks like it's broken...
[19:25] <cwillu_at_work> does it have an associated config item?  I'd like to prove to myself that it's actually included
[19:26] <rcn-ee> it relies on a combined defconfig, so the same defconfig as the beagle..
[19:28] <rcn-ee> cwillu_at_work, i'd actually test the lasted in the 2.6.32 series, as i had to tweak that patch in rev 65
[19:29] <rcn-ee> which would be 2.6.32.11-x13
[19:29] <cwillu_at_work> http://rcn-ee.net/deb/kernel/beagle/karmic/v2.6.32.11-x13/
[19:30] <rcn-ee> exactly..
[19:31] <rcn-ee> in that diff, look for: diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c is the dss2 patch
[19:31] <rcn-ee> basicly pulled from sakoman's overo tree
[19:42] <cwillu_at_work> I see a penguin
[19:48] <cwillu_at_work> should I see that change in http://rcn-ee.net/deb/karmic/v2.6.33.2-d8/patch-*.diff, for example?
[19:55] <rcn-ee> Nope, two different patchsets... 2.6.33 is still only in my 2.6-dev tree, (that's what the 'd' is)  I've been stress testing it on my gcc test farm, I'm thinking of moving 2.6.33.3 to stable after esc...
[19:56] <cwillu_at_work> ah, that's my problem then
[19:56] <cwillu_at_work> I'm on 2.6.33 as btrfs is significant more stable there
[19:57] <cwillu_at_work> so now that I know what to beg for
[19:57]  * cwillu_at_work begs for a 2.6.33 with the overo dss2 patches :p
[19:57] <cwillu_at_work> I could just build it myself, but where's the fun in that?
[19:57] <rcn-ee> actually it's rcn-ee, get your ass in gear and move 2.6.33 to stable. ;)
[20:17] <cwillu_at_work> rcn-ee, indeed, and while you're at it, start getting 2.6.34 ready too :p\
[20:18] <rcn-ee> hehe.. actually it's in pretty good shape... (other then dss2 on overo..) ;)
[20:19] <cwillu_at_work> yep, I've been on .33 for a long'ish while now
[20:19] <rcn-ee> i know.. i moved my x86's to 2.6.34-rc's as 2.6.33 just fells too old.. ;)
[20:19] <cwillu_at_work> just got some old overo boards back that I want to get running more up-to-date images, and boom, no video :p
[20:20] <cwillu_at_work> I'm anxiously waiting 2.6.35, as there's a bunch of btrfs stability stuff that should be landing there
[21:02] <EvaLuaTe> hello
[21:03] <EvaLuaTe> I have a mobile phone with a ARM processor. Is there any way I can find out if it supports ubuntu?
[21:03] <rcn-ee> EvaLuaTe, maybe... which phone?
[21:04] <EvaLuaTe> rcn-ee: it's an LG GT500. It's originale OS sucks, so I'm just looking to see if there's an alternative :p
[21:06] <samuel_Sayag> can I compile the ubuntu arm kernel on the beagleboard ?
[21:06] <rcn-ee> samuel_Sayag, yes i do it all the time... with alll modules 5 hours.. ;)
[21:07] <samuel_Sayag> okay ... can you plase help me :) rcn-ee
[21:07] <samuel_Sayag> I'm looking for the right kernel to download
[21:08] <rcn-ee> define: right?  are you looking for a specific feature? or just something that works?
[21:08] <samuel_Sayag> due the fact that the offical http://www.kernel.org/ doesnot get compiled :(
[21:08] <samuel_Sayag> I just need a kernel with firewire support
[21:09] <samuel_Sayag> to do it I need to compile a preprepared kernel for the arm ( i guess )
[21:09] <rcn-ee> 2.6.32 works just fine if you build omap3_beagleboard_defconfig..
[21:09] <rcn-ee> dss2 support needs patches...
[21:10] <samuel_Sayag> okay ... how do i begin ? how can i find the first foot grip in all this ?
[21:10] <rcn-ee> btw... how are you adding firewire to the beagle?
[21:10] <samuel_Sayag> thank you very much by the way rcn-ee
[21:11] <samuel_Sayag> I don't, I have a wird cemra interface that need it
[21:11] <samuel_Sayag> http://tldp.org/HOWTO/libdc1394-HOWTO/install.html
[21:12] <samuel_Sayag> the cemra name is FireFly MV by PG
[21:12] <samuel_Sayag> very nice pice of hardware
[21:12] <rcn-ee> interesting... well the problem, the beagle only has usb2.0, that's why i ask...  but to build something that just works, take a look at: https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-stable  it's my stable branch with scripts to build a stable workign kernel..
[21:13] <samuel_Sayag> I been there :) (BTW) I didn't find how to add this flags    1.
[21:13] <samuel_Sayag>       OHCI-1394 support
[21:13] <samuel_Sayag>    2.
[21:13] <samuel_Sayag>       OHCI-1394 Video Support
[21:13] <samuel_Sayag>    3.
[21:13] <samuel_Sayag>       OHCI-1394 DVI/O Support
[21:13] <samuel_Sayag>    4.
[21:13] <samuel_Sayag>       RAW IEEE1394 I/O Support
[21:14] <rcn-ee> they require hardware firewire... the beagle doesn't have it, so it never shows up on the menuconfig..
[21:14] <samuel_Sayag> :(
[21:15] <samuel_Sayag> So I'm just lost :(
[21:15] <EvaLuaTe> rcn-ee: so, do you have any idea if my device might support ubuntu? :) I've read that it sports a 93 Mhz ARM processor with 128MB or RAM memory btw...
[21:16] <rcn-ee> EvaLuaTe, i've been searching for it.. I think it's an armv5 core which woudl mean jaunty only...  it's kinda too slow, you might not like the experience..
[21:17] <alextisserant> hi all
[21:17] <EvaLuaTe> ohh. Seeing as the 'reflash' with the original firmware isn't a pain in the ass though, I might think about trying it out. Is it hard to install?
[21:18] <alextisserant> I'm trying to get an arm ubuntu image working thanks to the rootstock script
[21:18] <rcn-ee> EvaLuaTe, it's not so much as reflash the rom with an ubuntu install, you need a Kernel for your device, the blob for your phone interface and tehn the rootfs...
[21:18] <alextisserant> it works well with default settings, but I can't get the --seed option to work correctly
[21:19] <rcn-ee> alextisserant, what are you sending to '--seed'
[21:19] <alextisserant> (with lucid dist)
[21:19] <alextisserant> a file with a list of packages
[21:19] <alextisserant> at first I had a bunch of them, but now I'm just trying with mousepad
[21:19] <EvaLuaTe> rcn-ee: so, if there isn't a kernel for my device, i'd have to compile one myself, right? also, I've no idea what a blob is :p
[21:20] <alextisserant> then I do --seed `cat packages | tr '\n' ','
[21:20] <alextisserant> so actually the script is just "stuck" while "Unpacking ttf-dejavu-core"
[21:21] <alextisserant> when I had my long list of additional packages, it was actually stuck on Unpacking libc6-dev
[21:21] <rcn-ee> EvaLuaTe, exactly, and a lot of these 3rd party phones it's almost impossible to find...
[21:21] <alextisserant> my CPU is still working, but after a whole night of unpacking, I guess this is not totally normal :-)
[21:22] <rcn-ee> alextisserant, lucid?
[21:22] <alextisserant> so the script does not die, but it just seems to loop on this unpacking...
[21:22] <alextisserant> yes
[21:22] <rcn-ee> welcome to bug 56639
[21:22] <ubot4> Launchpad bug 56639 in acpi-support (Ubuntu) "Thinkpad R40 Fn-F7 should switch active display in software" [Undecided,Invalid] https://launchpad.net/bugs/56639
[21:22] <rcn-ee> crap, bug 566639
[21:22] <ubot4> Launchpad bug 566639 in apt-setup (Ubuntu) "omap install ends up with security.ubuntu.com urls in sources.list after install (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/566639
[21:22] <alextisserant> hmm
[21:22] <rcn-ee> I give up: this bug: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/532733
[21:22] <ubot4> Launchpad bug 532733 in qemu-kvm (Ubuntu Lucid) (and 2 other projects) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 4) (dups: 1) (heat: 34)" [High,Incomplete]
[21:23] <EvaLuaTe> rcn-ee: ohh, ok then. You know any other nice OS for such a mobile device that might be easier to install/try?
[21:29] <alextisserant> rcn-ee: did anyone try with other versions of qemu?
[21:30] <rcn-ee> I've tried Debian Squeeze & Sid's...
[21:31] <rcn-ee> Dustin and Loci are the ubuntu qemu guys..
[21:31] <alextisserant> ok
[21:32] <rcn-ee> It's one of those disapointing things...  If you have a beagle, the best method to build an SD card is the NetInstall..  I'm planning to make that work for the overo and igepv2, but after ESC...
[21:35] <alextisserant>  yes, but I'm trying to get a ready-to-use final image for the Touch Book
[21:35] <alextisserant> at least I can indeed do a netinst and pack the image afterwards
[21:37] <samuel_Sayag> okay, I see my camera under the lsusb :)
[21:37] <rcn-ee> alextisserant, that's exactly what i'm planning for my x11 images on rcn-ee.net for the beagle.. build native, copy...
[21:38] <alextisserant> yup
[21:38] <alextisserant> just need more time :)
[21:38] <samuel_Sayag> But still when I'm trying to take a photo I get "err libdc1394: Failed to initialize libdc1394" odd...