[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<EMAIL_ADDRESS>[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 <IP_ADDRESS>-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 <IP_ADDRESS>-x13
[19:29] <cwillu_at_work> http://rcn-ee.net/deb/kernel/beagle/karmic/v<IP_ADDRESS>-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/v<IP_ADDRESS>-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 <IP_ADDRESS> 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.  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...


[00:19] <ScottK> ev: Speaking of jockey, how crackful would it be to run jockey-text -a when the live session starts up?  If I do that by hand I get working wifi in the live session on my broadcom based netbook.
[05:56] <superm1> ScottK, without a user agreeing to do it, probably not the best thing to do on the live session
[08:53] <CIA-87> ubiquity: superm1 * r4307 ubiquity/ (debian/changelog ubiquity/frontend/noninteractive.py): Restore the functionality of the noninteractive frontend.
[09:12] <cjwatson> ev: I don't know if you *can* dpkg-divert away a trigger
[09:12] <cjwatson> ev: I'm not entirely averse to introducing a way to suppress it via an environment variable
[09:13] <ev> can dpkg-divert> ah, I hadn't considered that possibility :)
[09:13] <ev> cjwatson: in the trigger itself?
[09:13] <ev> sounds reasonable to me if all else fails
[09:49] <erupter> hi all ppl
[09:50] <erupter> anybody not afk?
[09:51] <erupter> i have a problem, probably you could help, i need the installer to leave alone one of the MBRs in my system
[09:51] <erupter> but it persists on messing up with it
[09:51] <ev> erupter: is this Maverick?
[09:53] <erupter> dunno, kubuntu 10.04
[09:53] <erupter> if you have time, i would explain more clearly
[09:54] <ev> erupter: oh, there's an advanced button on the summary page, before you click the final install button
[09:54] <ev> in the dialog that appears is a checkbox to either install or not install the bootloader
[09:54] <ev> if you uncheck it, the bootloader wont be installed
[09:55] <erupter> ok but if i don't do that then how can i access the linux install?
[09:55] <erupter> my problems aroused because i have a software raid array (intel ich9) and a spare disc
[09:56] <erupter> i set up the bios to use the spare as boot disc (this usually works for windows installations)
[09:56] <erupter> but after installing the distro i ended up with the bootloader on my raid array
[09:56] <erupter> and neighter oses booting
[09:57] <ev> in that dialog you can also pick which disk or partition you want to install the bootloader to
[09:58] <erupter> ok i'll try then thaks
[09:58] <erupter> hope this helps me :p
[09:58] <ev> sure thing
[09:58] <erupter> have a nice day
[10:13] <ev> you too
[10:18] <cjwatson> ev: yeah
[10:20] <erupter> looks like it hangs on loading...
[10:20] <erupter> it has installed and has started as it should but now it has hang with the kubuntu loading screen...
[10:21] <CIA-87> ubiquity: evand * r4308 trunk/ (4 files in 3 dirs): Add back the hostname entry (LP: #628087).
[10:23] <ev> I still have to do the dmidecode dance, just wanted to get things back to a sane state first.
[10:23] <ev> oh and fix the KDE hostname bug.
[10:24] <erupter> ok looks like it's now starting...
[10:28] <persia> ev, So, which value from dmidecode are you using?
[10:29] <ev> persia: I'm not sure.  Is there a field that is more often set than not? Family?
[10:31] <persia> Values for Family for a couple machines that support dmidecode here are "To Be Filled By O.E.M." and "Other"
[10:32] <ev> We could filter those out, or are you making the point that there are lots of bogus values?
[10:32] <persia> I think Chassis/Type is closest, but I have one machine with the value "Lunch Box" there, so I'm not sure it's well standardised.  Also seems an even mix of "Desktop" and "Desktop Case"
[10:33] <ev> the idea is to use something somewhat unique
[10:33] <persia> I take it as a given there are lots of bogus values for every dmidecode entry.  That said, having irregular hardware, I'd like to help you find one that is more sensible, and make sure we can support it (e.g. contains spaces)
[10:33] <ev> so if I install Ubuntu on several devices, I don't end up with the same hostname
[10:33] <ev> unique but still attractive*
[10:33] <persia> Right.  I think Chassis/Type is probably cleanest, as long as we can support spaces (swich to more hypens, maybe?)
[10:34] <ev> indeed, spaces would be subbed with hyphens
[10:34] <ev> I have "Notebook" for Chassis Type though.
[10:34] <persia> I'd recommend limiting to ~15 characters, to avoid matching "To Be Filled By O.E.M."
[10:34] <ev> fairly generic
[10:34] <ev> 15 characters> good idea
[10:34] <persia> Yeah, but "ev-notebook" vs. "ev-desktop" vs. "ev-lunch-box" allows some differentiation.
[10:35] <ev> sure, but is there no field that would give us something like ev-thinkpad-x61
[10:35] <ev> Is version often not set?
[10:35] <persia> Chassis/Version?
[10:35] <ev> not set here
[10:35] <ev> system version is
[10:36] <ev> (mind you I haven't read through the spec, I'm just going off how dmidecode the binary prints this)
[10:37] <persia> System/version is "001", "To Be Filled by O.E.M", "1.0" on the dmidecode capable machines on my desk.
[10:37]  * persia also
[10:37] <persia> System/Family looks better here "CFY7-1", "To Be Filled By O.E.M", "Macmini"
[10:38] <ev> ah, system family works
[10:38] <ev> as that's thinkpad x61 as well
[10:38] <ev> I'll do a quick survey of Millbank
[10:38] <persia> Good plan.
[10:38] <ev> to make sure at least the major have it set
[10:38] <persia> Next bit: what about machines that don't have dmidecode?
[10:39] <ev> we fall back to username-{desktop,laptop}
[10:39] <ev> where desktop/laptop is determined by laptop-detect
[10:39] <persia> How do we make that determination?
[10:39] <persia> Ah, OK.
[10:40] <persia> Hrm.  Seems that relies on either having a battery interface *OR* having dmidecode.
[10:41] <ev> Anyone know if there's a reliable way to get the used blocks on any supported linux filesystem without actually mounting it?  Something in the superblock perhaps?
[10:41] <ev> persia: battery interface?  The path is try dmidecode, if that fails or doesn't exist, try running laptop-detect (which we've always run to determine the hostname).
[10:42] <persia> Right.  laptop-detect checks for batteries, and runs dmidecode.
[10:43] <ev> ah, so then your argument is to not try laptop-detect at all and simply go straight to ubuntu-desktop?
[10:43] <persia> No.  I've no argument at all.
[10:43] <ev> :)
[10:43] <persia> I have an unsolved issue of what to do with devices with unused battery interfaces (e.g. the ARM boards folks are using)
[10:43] <persia> Not supporting them cleanly is *not* a regression, but now that I understand the path, there's a chance of possibly supporting them in the future.
[10:44] <ev> gotcha
[10:44] <persia> Might also affect small home-built whatevers.  Or some NAS boxes that have built-in batteries as internal semi-UPS, etc.
[10:45] <cjwatson> FWIW on my Dell Latitude D830, System/Family is blank, System/Manufacturer is "Dell Inc.", System/Product Name is "Latitude D830", Chassis/Type is "Portable"
[10:46] <cjwatson> I imagine you'll want fallbacks or something
[10:47] <persia> System/Product Name looks good here: "CF-Y7AW1AXS", "Macmini3,1", "To Be Filled By O.E.M." (the last would be too long, and fall back to "desktop")
[10:47] <ev> good call
[10:47] <persia> Base Board/Product Name also has full support here "MacF22C86C8", "CFY7-1", "MCP7A-ION"
[10:48] <cjwatson> "0HN341"
[10:48] <persia> That's not very informative.
[10:48] <cjwatson> and on my server, "i440BX-W83977 (BH6 V1.1)"
[10:48] <persia> Do servers get the same logic applied?
[10:49] <ev> Either of you have any thoughts on the filesystem question, or is that a lost cause?
[10:49] <cjwatson> which also has blank System/Product Name and System/Manufacturer, no System/Family at all, and Chassis/Type "Desktop", so that's probably a bit of a loss
[10:49] <soren> ev: Why the "without mounting it" requirement?
[10:49] <cjwatson> well, it was originally a desktop :-)
[10:49] <ev> I'm not too concerned about servers ;)
[10:49] <persia> Ah :)
[10:49]  * persia thinks most server folk set hostname via DNS in advance anyway
[10:49] <cjwatson> you want to avoid mounting filesystems so that you don't replay journals
[10:49] <cjwatson> if possible
[10:49] <ev> soren: don't we have issues with replaying journals on hibernated systems?
[10:49] <ev> ah, beat me to it
[10:50] <cjwatson> libparted might be able to tell you?
[10:50] <ev> for what it's worth, this is for the resize widget in the partitioner, saying "Files, X GB used" instead of "Unknown operating system"
[10:50] <soren> Just use blockdev to set it to read-only?
[10:50] <cjwatson> ev: I thought partman already had an interface for that
[10:50] <ev> I thought the d-i team tried that and it failed spectacularly
[10:50] <ev> blockdev --setro, that is
[10:51] <cjwatson> d-i should use blockdev, there were just some tedious things to deal with
[10:51] <soren> ev: Exactly.
[10:51] <cjwatson> but anyway, I don't think you need to go down that route
[10:51] <cjwatson> this is what the resize range stuff in partman is for
[10:51] <cjwatson> and I thought that ubiquity already interpreted that
[10:51] <ev> ah, I thought it just shelled out to resize2fs for that
[10:52] <ev> or are you saying, use the lower bound as the size used
[10:52] <ev> err upper bound
[10:52] <cjwatson> that's what I'm saying, yes
[10:52] <ev> errr partition size - upper bound
[10:52] <ev> coffee, need cofee
[10:52] <ev> awesome
[10:52] <ev> thanks everyone
[10:52] <cjwatson> the value you get as the minimum resizable size of the filesystem is as near as damnit the size used
[10:53] <cjwatson> I mean, it does shell out to tune2fs in the case of ext[234], but that's the information you want anyway
[10:53] <cjwatson> and best to avoid ext2-specific code in ubiquity IMO
[10:53] <ev> indeed
[10:53] <ev> brilliant
[11:09] <ogra> ev, please dont forget that dmidecode only works on systems with a BIOS
[11:09] <ev> ogra: indeed, that's why we have the fallback
[11:10] <ogra> and thanks so much for adding the hostname feature back :)
[11:13] <ev> sure thing.  I still want to ultimately get rid of it, but clearly we're not ready yet
[11:14] <ogra> yeah
[11:14] <ev> sabdfl wants this as part of the solution: https://bugs.edge.launchpad.net/ubuntu/+source/ubiquity/+bug/634187
[11:14] <ubot2> Launchpad bug 634187 in ubiquity (Ubuntu) "Detect hostname collisions using avahi (affects: 1) (heat: 6)" [High,Triaged]
[11:14] <persia> ogra, If you have any bright ideas on how to make laptop-detect more robust to do more than just check for batteries or Chassis/Type=="Notebook"|"Portable" or to try to differentiate phone/handheld/netbook/laptop/desktop or just differentiate dev boards, it may be interesting.
[11:15] <ogra> we could have a BOF at UDS ;)
[11:15] <ogra> i dont have bright ideas beyond either a database or parsing additional info from i.e. /proc/cpuinfo (on arm for example)
[11:16] <persia> ev, Do you think you'd have time at UDS to participate in such a thing, or would you not care, as long as we can produce useful strings?
[11:17] <ev> I'm most concerned about having useful strings, but if you think it would be helpful for me to be there, put me as required and I'll make the time.l
[11:18] <persia> Up to you :)  If we have such a spec, I'll definitely at least subscribe you (and let you select whether you are required)
[11:20] <ev> okay
[11:22] <ogra> well, on arm the useful strings live in the hardware line of /proc/cpuinfo usually (thats also where all other tools look)
[11:23] <ogra> i guess its up to the arm team to develop and supply such a püatch once the function is there :)
[11:24] <persia> The same kind of thing ought work for powerpc as well, although there may be better sources of information.
[11:24] <ogra> yes, ppc has nvram to read from iirc
[11:25] <ogra> on arm cpuinfo is the only common thing among all boards
[11:26] <persia> At least on my powerpc machines, cat /proc/cpuinfo is likely to have more human-readable information on the device that the output of nvsetenv.
[11:26] <persia> Anyway, let's save this discussion until *after* release :)
[11:46] <CIA-87> ubiquity: evand * r4309 trunk/ (debian/changelog ubiquity/plugins/ubi-partman.py):
[11:46] <CIA-87> ubiquity: * Use a block device icon for cases where we cannot detect the
[11:46] <CIA-87> ubiquity:  operating system on a partition.
[11:46] <CIA-87> ubiquity: * Set the amount of used space on a partition that we presume contains
[11:46] <CIA-87> ubiquity:  no operating system (LP: #626299).
[12:11] <ScottK> superm1: You're probably right (re restricted drivers in live session).  Something to consider for the next UDS for design.
[13:51] <ev> :q
[13:51] <ev> whoops
[14:16] <CIA-41> ubiquity: evand * r4310 trunk/ (debian/changelog gui/gtk/stepUserInfo.ui):
[14:16] <CIA-41> ubiquity: Make requiring a password to log in the default again, matching the
[14:16] <CIA-41> ubiquity: behavior in the previous version of Ubuntu.
[14:19] <CIA-41> ubiquity: evand * r4311 trunk/debian/ (changelog ubiquity.templates): Use the correct string for the resize partition option.
[15:33] <CIA-41> ubiquity: evand * r4312 trunk/ (3 files in 3 dirs):
[15:33] <CIA-41> ubiquity: Set the size of the disk on the automatic partitioning page
[15:33] <CIA-41> ubiquity: (LP: #626299).
[16:01] <superm1> ev, re dpkg-diverting the trigger, its a live filesystem - you can probably just rm it can't you?
[16:01] <ev> well, I wanted to undo the change afterwards
[16:01] <superm1> it's not like you are making that change in /target though
[16:01] <superm1> but if you want to undo it, just mv it to trigger.old to run jockey, and move it back?
[16:02] <ev> sure, though I'm going to try Colin's suggestion of adding a flag to man-db
[16:02] <ev> just as soon as I finish with building a big table of common locations for the product name in DMI
[16:02] <ev> superm1: I don't suppose you know where they occur on all of your systems?
[16:03] <superm1>  /sys/class/dmi/id/product_name
[16:03] <ev> is it always system product name?
[16:03] <superm1> it should always be that directory, first half is line of business (eg vostro, inspiron, etc) and second half is model number
[16:04] <ev> I'm assuming you mean file
[16:04] <ev> but noted
[16:04] <ev> thanks!
[16:05] <superm1> yeah i mean that file
[16:05] <superm1> re persia's recommendation to only cover up to 15 characters long names, i'm not sure that would continue to work.  if you go an look at something like Latitude E6410XFR, that would be too long
[16:06] <superm1> so probably better to just filter out those bad ones like To Be Filled by O.E.M
[16:06] <ev> indeed, will do
[16:17] <superm1> ScottK, well as you saw that for the newer generation of broadcom cards they've been open sourced, hopefully it becomes less of something that needs to be worried about over time
[16:17] <ScottK> superm1: True.
[16:17] <ScottK> OTOH, all the hard work is done now, it's a shame not to take advantage of it.
[16:33] <ev> I had a chat with the kernel team about this.  The new driver doesn't work with 42XX and non-SSB adapters as I understand it, equally it will be a post-release thing, so we couldn't take advantage of it in the installer anyway.
[17:01] <CIA-41> debian-installer: cjwatson * r1358 ubuntu/ (build/config/armel/dove.cfg debian/changelog): Move dove to 2.6.32-410 kernels.
[17:35] <CIA-41> ubiquity: evand * r4313 trunk/ (3 files in 3 dirs):
[17:35] <CIA-41> ubiquity: Use dmidecode to get a more unique suffix for the hostname
[17:35] <CIA-41> ubiquity: (LP: #628087).
[17:53] <CIA-41> debian-installer: cjwatson * r1359 ubuntu/debian/changelog: releasing version 20100211ubuntu25
[17:54] <CIA-41> ubiquity: evand * r4314 trunk/ (debian/changelog ubiquity/plugins/ubi-usersetup.py):
[17:54] <CIA-41> ubiquity: Also generate a sample hostname when generating a sample username
[17:54] <CIA-41> ubiquity: (LP: #634279).
[18:00] <ev> cjwatson: given bug #635040, what are your thoughts on not raising that exception anymore?
[18:00] <ubot2> Launchpad bug 635040 in ubiquity (Ubuntu) "ubiquity crashed during install - no bootloader (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/635040
[18:00] <ev> the "oh bother, no bootloader" one, that is.
[18:05] <cjwatson> I guess we could demote it to a log message, yes.  But why's it happening here?  armel/dove is supposed to be handled by the flash_kernel component.
[18:06] <cjwatson> we're hitting an else that suggests that archdetect is producing the wrong output?
[18:08] <ev> indeed, followed up in the bug
[18:45] <CIA-41> ubiquity: evand * r4315 trunk/ (3 files in 3 dirs):
[18:45] <CIA-41> ubiquity: Only set the next button to 'Install Now' when not on the first
[18:45] <CIA-41> ubiquity: partitioning page.
[23:18] <persia> ev, Thought on data source validation: checkbox runs dmidecode: it may be that there's thousands of values stored in the checkbox DB in LP (helps find bad values to filter, strong candidates, etc.)


[04:28] <pangolin> identified!
[04:32] <bazhang> oh lawd
[10:54] <vibhav> 16:21 < k-rAd> kiss pangolin he's ubuntu's slut
[10:55] <vibhav> 16:23 < k-rAd> i'm not muslim and neither are most ubuntu ops
[10:55] <ikonia> what are you doing ?
[10:55] <vibhav> ikonia: Please tell k-rAd to behave
[10:56] <ikonia> vibhav: a.) you can tell him yourself b.) if you have a problem, can you explain it rather than just cutting and pasting random lines
[10:56] <vibhav> Thats not random
[10:56] <ikonia> vibhav: it is - what is going on? it's not in context
[10:56] <ikonia> I'm looking at -offtopic now
[10:57] <vibhav> I was reporting un-family friendly stuff
[10:57] <vibhav> But anyways
[10:57] <ikonia> it depends on the conte....
[10:57] <ikonia> ooh,
[10:57] <ikonia> the muslim line is not unfriendly
[11:02] <LjL> @mark #ubuntu-offtopic k-rad Some rants I didn't understand about kissing ops and how he's not gay, followed by calling a user a slut.
[13:00] <bazhang> what does being a C programmer have to do with knowing how to build things from source in Ubuntu
[13:14] <bazhang> why is Lint still on that
[13:15] <ikonia> it won't last longer than my last comment
[13:15] <bazhang> he wants to just slam apt some more
[13:16] <ikonia> he won't on this occasion
[13:23] <jpds> Why would anyone want to slam APT?
[13:23] <bazhang> it's Lint
[13:23] <bazhang> he was saying earlier how rhythmbox developers are idiots
[13:24] <ikonia> shock horror, I have a similar impression of his contribution
[13:25] <bazhang> it's all he does. ask for the impossible, then slam Ubuntu for not doing it the standard rpm way
[13:25] <ikonia> he doesn't seem to know rpm very well either though
[13:25] <bazhang> true
[13:27] <jpds> Well, it looks like he's in Siberia, so I imagine there's 50 feet of snow outside his door.
[14:33] <mneptok> if you were using RPM that would only be 20 feet.
[14:33] <bazhang> hehe
[15:06] <Myrtti> oh man, Cinnamon PPA :-|
[15:07] <Myrtti> well I suppose people are allowed to play with their Ubuntu as much as they like.
[15:23] <AlanBell> !wubi
[15:23] <AlanBell> Unit193: what should it say?
[15:23] <Unit193> Oneiric.
[15:23] <AlanBell> oh, I guess not the maverick thing
[15:26] <AlanBell> !wubi is <sed> /Maverick/Oneiric/
[15:26] <AlanBell> hmm, maybe that doesn't work like that
[15:27] <Unit193> wubi =~ s/Maverick/Oneiric/  does, if it knows you. Try @login?
[15:27] <AlanBell> !no Wubi is an Ubuntu installer for Windows users that allows you to install and uninstall Ubuntu like a Windows application, in a simple and safe way. http://wubi-installer.org/support.php and https://wiki.ubuntu.com/WubiGuide for troubleshooting. Please  file bugs at http://launchpad.net/wubi/+filebug. For Ubuntu Oneiric/11.10 http://releases.ubuntu.com/oneiric/wubi.exe
[15:28] <AlanBell> @login
[15:28] <AlanBell> !no Wubi is an Ubuntu installer for Windows users that allows you to install and uninstall Ubuntu like a Windows application, in a simple and safe way. http://wubi-installer.org/support.php and https://wiki.ubuntu.com/WubiGuide for troubleshooting. Please  file bugs at http://launchpad.net/wubi/+filebug. For Ubuntu Oneiric/11.10 http://releases.ubuntu.com/oneiric/wubi.exe
[15:28] <AlanBell> !wubi
[15:29] <Myrtti> !foo
[15:29] <Myrtti> !foo ~= s/wiggle/wibble/
[15:29] <bazhang> hehe
[15:30] <Myrtti> !foo ~= s/wiggle/wibble/
[15:30] <Myrtti> !foo ~= s/wibble/wiggle/
[15:33] <AlanBell> so does it not like me?
[15:33] <AlanBell> !wubu ~= s/Maverick/Oneiric/
[15:33] <AlanBell> !wubi ~= s/Maverick/Oneiric/
[15:33] <AlanBell> !wubi
[15:33] <AlanBell> !wubi ~= s/maverick/oneiric/
[15:34] <AlanBell> !wubi ~= s/10.10/11.04/
[15:34] <AlanBell> !wubi
[15:34] <AlanBell> yay
[15:34] <Unit193> 11.10* ;)
[15:35] <AlanBell> !wubi ~= s/11.04/11.10/
[15:36] <AlanBell> !firewall
[15:36] <AlanBell> !firewall ~= s/Lucid and Maverick/from Lucid onwards/
[15:38] <Unit193> Cool.
[15:57] <bazhang> since when is +1 the debate design decisions channel
[16:07] <mneptok> bazhang: i don't use +1 and i won't until they change the fonts and the most icons.
[16:08] <bazhang> mneptok, hehe
[17:21] <popey> +1
[20:28] <theadmin> Can someone take care of "Herman_" in #ubuntu ? Obvious troll
[20:28] <theadmin> Oh, pardon, didn't notice. Thank you Pici
[21:16] <h00k> !away > bhunt|afk
[21:16] <h00k> !away > iqpi|on
[21:23] <h00k> !away > bhunt


[07:44] <artnay> morning all
[07:45] <artnay> anyone aware of ubuntu tour's situation and especially its translation situation?
[07:46] <artnay> http://www.ubuntu.com/tour/ vs. https://translations.launchpad.net/ubuntu-tour/ doesn't match. so is the tour translatable and if yes, where is it hosted?
[08:56] <sagaci> do translations need to go offline again when you do the precise openings?
[09:00] <artnay> sagaci: I don't think so as the imports have been done (afaik)
[09:01] <sagaci> righteo then
[09:02] <artnay> dpm: hi
[09:02] <artnay> dpm: is ubuntu tour translatable somewhere? http://www.ubuntu.com/tour/ I found https://translations.launchpad.net/ubuntu-tour/ but it seems to be a different project.
[09:03] <artnay> having that tour translated would be a huge thing on LoCo sites
[09:03] <artnay> and as most of the strings are already translated, it shouldn't be much work
[09:04] <dpm> artnay, we're working on making it translatable (the code needs to be more i18n-friendly), but I don't know the current status. I'll post an update on the mailing list as soon as I know more
[09:05] <artnay> dpm: ok, having that translated for LTS would be great.
[09:05] <kelemengabor> artnay: the precise import queue is currently stopped, copying the translations from oneiric is done
[09:06] <kelemengabor> dpm: I guess it is okay to re-enable the imports now, is it?
[09:06] <dpm> kelemengabor, yeah
[09:07] <kelemengabor> okay, import queue is active
[09:08] <dpm> cool
[10:18] <kelemengabor> dpm: I see the there are still a lot of templates with 0 priority, is that priority setting project progressing?
[10:23] <dpm> I haven't started yet


[10:41] <soyboyxavier> hi
[10:43] <soyboyxavier> i dont know how to view messages with telnet lol
[10:44] <soyboyxavier> well cya


[06:47] <ivve> anyone else experiencing sporadic pxe booting working/not working?
[08:05] <mup> Bug #1839860 opened: cloud-init error while MAAS commissioning (PXE phase) P9 Witherspoon <ppc64el> <cloud-init:New> <MAAS:New> <The Ubuntu-power-systems project:New for maas> <https://launchpad.net/bugs/1839860>
[12:24] <mup> Bug #1840029 opened: Prettify "Conflict" error message shown in MAAS when using external authentication <MAAS:New> <https://launchpad.net/bugs/1840029>
[14:03] <mup> Bug #1840041 opened: Add ability to add brief notes and a method to display them when a machine is marked broken <MAAS:New> <https://launchpad.net/bugs/1840041>
[14:39] <mup> Bug #1840049 opened: [UI] When changing configuration of an Interface, one has to enter the config twice <hwcert-server> <ui> <MAAS:Triaged> <https://launchpad.net/bugs/1840049>
[15:45] <mup> Bug #1840058 opened: Events sent during commissioning/deploy may be recorded as 'node status' events <MAAS:Triaged> <https://launchpad.net/bugs/1840058>
[16:48] <mup> Bug #1837903 changed: [2.6] preseed uses region controller as http_proxy where rack controller proxy should be used <http> <preseed> <proxy> <rack> <region> <MAAS:Won't Fix> <https://launchpad.net/bugs/1837903>
[21:21] <mup> Bug #1840084 opened: [2.6] Redfish interface to BMC controller fails with stack trace in rackd.log <MAAS:New> <https://launchpad.net/bugs/1840084>


[10:27] <owend> Hello world.  I asked my question of cjwatson but he sent me here, so I'll try here...
[10:27] <owend> Is there a way of finding out which events of an Upstart job's start on A and B clause the job has yet received?
[13:49] <jodh> owend: The easiest thing to do is just enable verbose logging (http://upstart.ubuntu.com/cookbook/#obtaining-a-list-of-events) before the job starts. If that's not possible, there is a more precise way of establishing which events a job has already received, but note that this latter method isn't via a command - you can infact inspect upstarts inner state (assuming upstart 1.6.1+).
[22:00] <cschneid> I have an upstart job that seems to track the pid correctly, but hangs when I do `service myjob start` and `service myjob stop` even though if I ctrl-c it has the right pid during a status call
[22:02] <cschneid> This is the script & the behavior I'm seeing. https://gist.github.com/cschneid/4fb0757f7e71bf7cb745
[23:23] <postmodern> what is the correct way to set a custom PATH for an upstart script?