[02:19] <tsimonq2> Hello dudz.
[05:12] <Joeky> Hello again
[05:12] <Joeky> https://github.com/lxde/lxqt/issues/1188
[05:12] <Joeky> Status Notifier may cause qt4 software crash
[14:12] <jim53> Hello everybody
[14:13] <jim53> I have a problem with my keyboard because I need to pouch 4 times à letter to show it on screen
[14:13] <jim53> Do you ave a idea of my roblem


[08:36] <mvo> hey, is there a way to get more details from LP if it tells me (for a git merge proposal): "lp:~mvo/+git/cnf-extractor-charm is not mergeable into this repository." - context is that I try to create a PR from https://code.launchpad.net/%7Emvo/+git/cnf-extractor-charm/+ref/master/+register-merge to ~canonical-sysadmins/+git/cnf-extractor-charm - when I do this using the git cli it seems to be just fine
[08:38] <cjwatson> mvo: No personal-namespace (i.e. ~owner/+git/name) repositories are ever mergeable into any other ones
[08:38] <cjwatson> As far as LP is concerned
[08:38] <cjwatson> Somebody in ~canonical-sysadmins needs to move that to a different location if they want to be able to accept MPs
[08:39] <cjwatson> Yes, they're mergeable at the git level, but that isn't enough because we need to be able to do things like efficiently scan for merged MPs when pushes happen
[08:44] <mvo> cjwatson: thank you! so the right way is to create a proper LP project for the cnf-extractor-charm and use that for the PRs I assume
[08:47] <cjwatson> Yeah, that would be best
[08:49]  * mvo nods
[10:11] <rbasak> cjwatson: you mentioned there was something you wanted to check before we attempt to switch the default VCS for the LP "ubuntu" project over to git, IIRC. Does that still need looking at, or are you happy for a TB member to make the API call when ready?
[10:17] <cjwatson> rbasak: It was kind of inchoate memories of possible unimplemented bits.  I can't find anything specific (other than that we don't have push permissions for uploaders set up, which we knew about already), but somebody should really try it out on qastaging first and see what happens there.
[10:17] <rbasak> OK, thanks. slangasek (not here) agreed to make the change on behalf of the TB. I'll ask him to try qastaging first.
[13:08] <coreycb> this comment looks malicious, figured i'd report it: https://bugs.launchpad.net/neutron/+bug/1057558/comments/15
[13:08] <cjwatson> coreycb: Thanks, dealing with it.
[13:09] <coreycb> thanks cjwatson
[13:10] <cjwatson> It's gone.
[20:02] <teward> what SSH key encodings are supported?  I know RSA and ECDSA, I wasn't sure if there were any other key types that were supported?
[20:03] <teward> s/encodings/'types'/
[20:09] <cjwatson> teward: It's documented on https://launchpad.net/~/+editsshkeys.
[20:09] <cjwatson> RSA, DSA, and ECDSA.
[20:10] <teward> cjwatson: not sure where exactly you're looking... but no, that isn't actually listed anywhere
[20:10] <teward> oh wait I see, it only lists the "usually" paths
[20:10] <cjwatson> "Insert the contents of your public key (usually ~/.ssh/id_rsa.pub, ~/.ssh/id_dsa.pub, or ~/.ssh/id_ecdsa.pub)."
[20:10] <teward> that's where the confusion is
[20:10] <cjwatson> Yeah, could be clearer I suppose.
[20:10] <teward> cjwatson: indeed, just realized that I'm a bit blind there :P
[20:10] <teward> side effect of tired too
[20:11] <teward> but if it were a tad clearer that'd be easier.  But also if it were documented in the help docs as well
[20:11] <teward> about importing keys (so that it explicitly states the supported types)
[20:11] <teward> but no matter :)
[20:11] <teward> thanks.
[20:11] <teward> *goes back to updating his SSH keys*
[20:12] <cjwatson> teward: I've documented it in https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair#Creating_the_key
[20:15] <cjwatson> (Personally I'm sticking with RSA until we manage to get Ed25519 support going.)
[20:21] <teward> cjwatson: indeed.
[20:22] <teward> i have keys of each good type - rsa ecdsa and ed25519, i'm just a little annoyed that ed25519 isn't supported yet heh
[20:22] <teward> i'm also insane, it seems - I just generated 8k and 16k bitlength keys
[20:22] <teward> so maybe I should be put in the "Overkill" loony bin for a short while :p
[20:23] <teward> (I'm not a fan of DSA as much...)
[20:23] <cjwatson> That is basically ridiculous, yes.
[20:23] <cjwatson> As it happens I was working on pushing Ed25519 a bit further up the hill this evening.
[20:23] <teward> heh, so, coincidence then :p
[20:24] <cjwatson> But it's still going to need an as-yet-unlanded patch to cryptography before I can get anything into Twisted, and the cryptography branch I'm looking at seems to be buggy ...
[20:24] <cjwatson> Also I have a prerequisite branch in Twisted that's still in review
[20:24] <cjwatson> Yaks, yaks everywhere
[20:26] <teward> cjwatson: ouchies.  well, I wish you luck :)
[20:27] <cjwatson> Oh, and then we need OpenSSL 1.1.1 everywhere relevant, which is kind of a pain
[20:28] <teward> indeed, i've heard some evil rumors about it
[20:29] <cjwatson> Specifically 1.1.1, which is newer than bionic.
[20:29] <teward> mhm.
[20:29] <cjwatson> Not even the general 1.1 issues.
[20:31] <teward> cjwatson: help.launchpad.net finally loaded, thanks for making the edit under "Creating the key" to document the types there :)
[20:31] <teward> should help be a little more clear :)
[20:32] <cjwatson> np


[00:53] <DanaG> Weird... trying to use a pl2303 usb-serial ON the beagleboard... and it's giving me garbage.
[00:53] <DanaG> pl2303_process_read_urb - tty_flag = 0
[00:54] <DanaG> H�H�H
[04:23] <DanaG> say, what's the practical difference between 2.6.35-17 (ubuntu) and 2.6.35-1002 (linaro)
[04:30] <rsalveti> not much for now, I'd say
[04:30] <rsalveti> but need to check the kernel tree
[04:42] <DanaG> hmm, stupid pl2303 gives garbage on my beagleboard.
[05:59] <DanaG> Say, if I'm using an aufs overlay, is there any advantage to having the underlying FS be ext4 instead of ext3?
[06:11] <Baybal> yes
[06:11] <Baybal> it would be faster
[06:29] <persia> DanaG, Depends on what you're accessing.  If you're accessing stuff on the base FS, you'll get the normal advantages of ext3 vs. ext4.  If you're accessing stuff on the overlay, you won't see any difference between the two.  For most uses of union filesystems, actual usage is a mix of both.
[06:31] <DanaG> ah, I don't even remember now what the advantages of the base were. =/
[06:32] <persia> http://en.wikipedia.org/wiki/Ext4 has fairly extensive discussion
[06:34] <DanaG> ah, checksum is a big one.
[06:38] <persia> Note that it *only* provides benefits to files unmodified from the base: anything in the overlay will naturally be handled based on the backing-store mechanism used for the overlay (often RAM, but potentially other things)
[06:41] <DanaG> I've also run into the blockage of hardlinks... http://patchwork.ozlabs.org/patch/52392/
[06:42] <persia> What is this blocking?  I've played with all sorts of layed filesystems, and never ended up finding this painful.
[06:46] <DanaG> It was blocking the "SingletonLock" Chromium links to wherever it links.
[06:48] <persia> With packaged chromium?
[06:48] <DanaG> Yeah.  Though, there was a new update today... maybe that would've helped.
[06:49] <persia> My recommendation would be to try to catch fta: there may be a way to get it to work more easily.
[06:50] <DanaG> Anyway, it only happened when the lock was on the underlying fs.
[06:50] <DanaG> Say, is there any easy way to make ttyS2 start only if console=ttyS2 is present?
[06:50] <persia> You could write a custom upstart job...
[06:50] <DanaG> I need to use that port for other things in 'normal' (read-only) mode -- using the "user" button to boot read-write for servicing.
[06:51] <DanaG> yeah, though I have no idea of the syntax -- start-on?
[06:51]  * persia doesn't know modern upstart syntax, not having worked on upstart jobs since jaunty
[06:52] <persia> My recommendation would be to review already installed jobs for clues, and ask in #upstart once you're sure you know the basics.
[06:52] <DanaG> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/586386
[06:52] <ubot2> Launchpad bug 586386 in linux (Ubuntu Maverick) (and 1 other project) "omap3 kernel should hand over all comdline args to the init environment (affects: 1) (heat: 40)" [Medium,Fix released]
[06:54] <DanaG> Perfect, it's already been done.
[09:17] <hrw> hi
[10:52] <cooloney> lag: morning, man
[10:52] <lag> cooloney: They Bryan
[10:52] <cooloney> i just pinged sebjan who is still working on the 2.6.35 patches.
[10:52] <lag> Hey~*
[10:53] <lag> No problem
[10:53] <cooloney> it will be available soon.
[10:53] <cooloney> he helped a lot to fix coding style and duplicated patches. i think
[10:53] <lag> I'd rather them late and in good order than quickly and in a state
[10:53] <lag> I don't mind that at all
[10:53] <lag> Keep up the good work sebjan
[10:53] <cooloney> after sebjan boots the new kernel on panda, he will send it out.
[10:56] <sebjan> thanks lag :)
[10:57] <lag> :)
[12:41] <ogra> ndec, a ti-team ML for the package maintainer field sounds fine to me
[12:42] <ndec> ogra: ok. so should I use tiomap-dev team on LP and create a ML with same name?
[12:42] <ogra> yeah, i think LP offers that
[12:43] <ndec> ogra: ok. I will do that.
[12:44] <ndec> ogra: Mailing list requested and queued for approval....
[12:44] <ogra> perfect !
[13:42] <ogra> ndec, was there ever a bug filed for your AAC issues ?
[13:45] <ndec> ogra: no. in fact we are looking at using ffmpeg instead of faac by default. so i don't have any information to open a bug for now.
[13:45] <ogra> ok
[13:46] <ndec> ogra: but do you confirm that packages cannot be compiled with neon optimizations by default?
[13:46] <ndec> ogra: do you really support v7 h/w that does not have neon?
[13:46] <ogra> if you do neon on a common package you should roll an additional binary with -neon in the name, yes
[13:47] <ogra> ndec, we support v6 HW that pretends to be v7 and has no NEON, yes :)
[13:47] <ogra> ndec, ask NCommander :)
[13:48] <ogra> he maintains the dove stuff
[13:48] <ndec> ogra: so how do we automatically install these -neon packages in case the hw supports it?
[13:48] <ogra> hmm, thats hard
[13:49] <ogra> i think asac had a different idea of using runtime switches
[13:49] <ogra> so the binary is the same but uses a different codepath if NEON is available
[13:50] <persia> Can we reliably detect the ability to run neon on a given machine?  If so, hwcap might work.
[13:50] <ogra> yes, i think asac's idea involved hwcap
[13:50] <ogra> but he can probably elaborate
[13:51] <persia> I'd hope it involved something similar to what we did for pango vfp for jaunty, rather than actually patching every source to have multiple codepaths.
[13:52] <NCommander> ndec: there was going to be some work i was going to suggest in Natty to work towards solving this issue
[13:53] <ogra> NCommander, the missing NEON on dove ?
[13:53] <NCommander> ogra: no, having a mechanism in APT tohandle packages on a subarchitecture basis :-)
[13:53] <ogra> that wont happen i think
[13:54] <ogra> and it would have to be on dpkg level i think
[13:54] <ogra> iirc we discussed it before
[13:58] <persia> And it doesn't help the neon bit anyway: we don't want that: we want opportunistic use of NEON, if available.
[14:08] <ogra> \o/
[14:08]  * ogra dances
[14:08] <ogra> telepathy-glib builds !
[14:08] <ogra> (when using -O0 :/ )
[14:09] <persia> Um, how did you test that?  Everyone is reporting that it builds locally, and only fails on buildds.
[14:09] <ogra> everyone ?
[14:09]  * persia has yet to actually replicate the test failures.
[14:09] <persia> everyone who told me about it.
[14:09] <ogra> who was that ?
[14:09] <ogra> it doesnt build with -O2 here or on the porter box
[14:10] <ogra> one test fails with "invalid utf-8" the other segfaults
[14:10] <persia> Hrm.  Right then.
[14:11]  * persia suspects irregular hardware and incorrect environments
[14:19] <pcacjr> morning
[14:30]  * ogra files bug 623979 and uploads a telepathy-glib workaround
[14:30] <ubot2> Launchpad bug 623979 in telepathy-glib (Ubuntu) "telepathy-glib fails to build on armel due to two unsuccessfull selftests (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/623979
[14:33] <persia> \o/
[14:35] <ogra> now that were 2 very productive hours to fix that :)
[14:36] <ogra> finally we can start to prepare for beta
[14:37] <devilhorns> mmm betas ... tasty :)
[14:48] <devilhorns> ogra, any news/updates wrt doing the arm work ?
[15:28] <ndec1> ogra: can we setup the PPA to send notification email to the team list for each upload and build success?
[15:28] <persia> I think one only gets notification on build failures.
[15:29] <persia> Or maybe I'm confused.
[15:30] <ndec1> persia: hi! I did receive an email of build failure for something that was uploaded by someone else. so you might be right
[15:30] <ndec1> persia: so there is no option to subscribe the team ML to get more notifications?
[15:30]  * persia is asking
[15:31] <persia> (for reference, #launchpad is a good place to ask questions about LP)
[15:35] <persia> ndec1, At least one other user reports they couldn't find any way to get richer notifications.  If you want it, please file a bug against LP (and subscribe me, please).
[15:35] <ndec1> persia: thx. will do.
[15:43] <ndec1> persia: Bug #624038 entered. you and ogra are subscribed
[15:43] <ubot2> Launchpad bug 624038 in launchpad "Team notifications of package upload and build success for PPA (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/624038
[15:44] <ndec1> persia: cool.. didn't know about the ubot notification ;-)
[15:44] <persia> ndec1, Thanks.  It may take a while to get implemented, but we now have a place to discuss it :)
[15:45] <ogra> yeah
[15:45] <ogra> thanks for that
[15:46] <suihkulokki> lool: there is a rebased qemu branch in gitorious (omap3-rebase) with your and matts changes included
[15:47] <lool> suihkulokki: Thanks
[15:47] <rsalveti> ogra: ndec1: could any of you add me at tiomap-dev?
[15:48] <rsalveti> I'm also interested on this, once we get the notifications
[15:48] <lool> suihkulokki: I'm slowly moving this tree under a Linaro umbrella and we have asked one new Linaro starter to look at upstreaming these OMAP3 patches, amongst other things
[15:49] <ndec1> rsalveti: done
[15:50] <rsalveti> ndec1: cool, thanks :-)
[16:05] <ogra> rsalveti, did you research the "Bad Magic Number" issues on omap4 more ?
[16:05] <prpplague> ogra: it is an issue with the old u-boot
[16:05] <ogra> seems that really bites us badly now i cant even fatls on the panda atm
[16:06] <prpplague> ogra: updated u-boot from sakoman works with no issues
[16:06] <prpplague> ogra: i created a small script to reload the boot partition
[16:06] <rsalveti> ogra: nops, not yet
[16:06] <ogra> prpplague, is there an updated 1.1.4 tree anywhere ?
[16:07] <prpplague> ogra: http://paste.ubuntu.com/483487/   for reloading
[16:07] <ogra> we're way paste feature freeze and i'm not really eager to change to a different u-boot version
[16:07] <ogra> prpplague, thats not an option in release images
[16:07] <prpplague> ogra: no, there isn't a fixed 1.1.4 since the fat driver was re-written
[16:07] <ogra> sigh
[16:08] <rsalveti> yep, our version is *very old*
[16:08] <rsalveti> at least the common u-boot part
[16:08] <prpplague> ogra: the issue only seems to occur when writing to the boot partition frequently
[16:08] <rsalveti> that's why no one likes fixing that
[16:08] <ogra> well, it was the one version that i was told to use
[16:09] <rsalveti> ogra: probably because at the time sakoman's tree wasn't ready
[16:09] <ogra> prpplague, it happens on first reboot for me, after install (which writes the new initrd once to the fat)
[16:09] <ogra> rsalveti, right
[16:09] <prpplague> ogra: ahh interesting
[16:09] <ogra> beta freeze is tomorrow and we have a ton of other issues to fix
[16:09] <ogra> gdm isnt starting either :(
[16:10] <rsalveti> :-(
[16:10] <ogra> GrueMaster, ^^^ do we have a bug for that ?
[16:10] <GrueMaster> Looking.
[16:10] <ogra> i can run startx and get to a desktop session
[16:10] <ogra> well, i could before i tried to reboot
[16:11] <ogra> and do we have a bug for the bad magic number ?
[16:11]  * ogra digs
[16:11] <GrueMaster> I'm missing something here.  What am I looking for?
[16:12] <robclark> ogra: fwiw.. I think the issue updating the fat boot partition with new uImage is actually an issue with linux fat support...  if I write the uImage to an MMC card from macosx I can do it 100's of times and I haven't seen bad magic #
[16:12] <ogra> GrueMaster, for a bug about gdm not starting on the panda
[16:12] <robclark> so I think the best option is to dd an entire raw boot partition, rather than relying on fatfs
[16:12] <GrueMaster> I don't think so, but I might have.
[16:12] <ogra> robclark, why dont we have any issues on omap3 then ?
[16:13] <robclark> I had same issue on omap3
[16:13] <robclark> at least on 3430.. I never tried 36xx
[16:13] <GrueMaster> No, thats what I was working on last week.  Haven't finished narrowing it down yet.
[16:13] <ogra> GrueMaster, we need bugs for the freeze execptions
[16:14] <GrueMaster> Understood.
[16:14] <ogra> please file something generic for each issue you find first, we can do detailed research later
[16:14] <prpplague> ogra: that is a good question, how are you mounting the boot partition? as vfat or just msdos?
[16:14] <ogra> prpplague, vfat
[16:14] <GrueMaster> Ok
[16:14] <ogra> prpplague, well, we dont specify a fs actually we just mount it
[16:15] <rsalveti> ogra: you said we don't have this issue for blaze
[16:15] <rsalveti> that's more interesting
[16:15] <prpplague> ogra: ahh, can you check to see what it is actually reporting after mounting?
[16:15] <ogra>                 echo "Using u-boot partition: ${UBOOT_PART}" >&2
[16:15] <ogra>                 TMPMOUNT=$(mktemp -d)
[16:15] <ogra>                 mount $UBOOT_PART $TMPMOUNT
[16:15] <ogra> thats the code that mounts it
[16:16] <ogra> we rely on the kernel here to determine the fs
[16:16] <ogra> i would, if i could boot :P
[16:17] <ogra> /dev/mmcblk0p1 on /mnt type vfat (rw)
[16:18] <ogra> thats what i get on x86
[16:18] <GrueMaster> ogra: Bug #624059.  I marked it as critical - incomplete to indicate that it is high priority but cause unknown.
[16:19] <ogra> thanks
[16:19] <ubot2> Launchpad bug 624059 in ubuntu "gdm fails to start on armel images updated from Alpha 3. (affects: 1) (heat: 8)" [Critical,Incomplete] https://launchpad.net/bugs/624059
[16:21] <ogra> prpplague, same on panda ... "/dev/mmcblk0p1 on /mnt type vfat (rw)"
[16:22] <ogra> mkdosfs -n "SERVICEV001" -F 32 /dev/mmcblk0p1 is the way we use to create the filesystem btw
[16:23] <rsalveti> yep, creating it as a simple fat 32 partition is enough to get the problem
[16:28] <prpplague> ogra: can you email me a list of items that are of concern for the panda support?
[16:28] <ogra> prpplague, you mean for u-boot ?
[16:29] <prpplague> ogra: any issues that you have for 10.10 release
[16:29] <ogra> the trashed filesystem is the only one atm
[16:29] <ogra> the other ones are rather homemade
[16:29] <prpplague> ahh ok
[16:29] <ogra> i.e. busybox reboot doesnt work and things like that ... all stuff i need to fix in the packages
[16:30] <GrueMaster> I have discovered on this issue that I can reproduce it by just moving/renaming existing files and copying new ones over.
[16:30] <prpplague> robclark and i have seem to nailed down the issues with the hdmi/dvi stuff so we should be getting those merged soon
[16:30] <ogra> GrueMaster, does the system dbus run if you try to start gdm ?
[16:30] <prpplague> robclark has his stuff posted on gitorious
[16:30] <GrueMaster> But if I copy them to a different area, reformat the partition, and recopy them back with the new files first followed by the old ones it works.
[16:30] <ogra> yeah, right thats another issue but we're waiting for the latest kernel
[16:30] <prpplague> GrueMaster: yea that is what my script does
[16:31] <GrueMaster> It appears to be an issue with seeking past a certain pont in the filesystem.
[16:31] <ogra> we cant reformat the whole thing on every initramfs update
[16:31]  * ogra will not release with such hacks
[16:32] <ogra> prpplague, how far is the new u-boot implementation feature wise ? shoudl it be on par with the 1.1.4 version ?
[16:32] <ogra> (we need hush shell and scripting support for our images)
[16:33] <prpplague> ogra: feature wise, it is 10000000 times ahead of 1.1.4
[16:33] <ogra> if it works as good as 1.1.4 we should probably update
[16:33] <ogra> but that would have to happen today
[16:34] <prpplague> ogra: you'd need to get with sakoman to double check the complete status
[16:34] <ogra> his wikipage didnt look like it would be comeplete
[16:34] <ogra> http://omappedia.org/wiki/U-boot_Upstreaming_Project
[16:34] <rsalveti> ogra: as I described at the bug report, it works fine :-)
[16:35] <sakoman> ogra: for panda it should be fine
[16:35] <rsalveti> ogra: even using the current u-boot default tree
[16:35] <prpplague> ogra: i think that just means the upstream items
[16:35] <ogra> rsalveti, would you have time to package it ?
[16:35] <ogra> i think we need to switch for the es2.0 HW anyway
[16:35] <rsalveti> ogra: sure, if you think we're good to update it now
[16:35] <sakoman> for sdp/blaze it is missing final ethernet/spi driver cleanup and emmc environment support
[16:36] <ogra> rsalveti, well, if it saves us from bad hacks like reformatting the fat every update
[16:36] <sakoman> hush shell and scripting are there
[16:36] <ogra> sakoman, do you have an ETA for landing teh blaze features ?
[16:36] <rsalveti> ogra: should I update it now or wait for es2?
[16:36] <prpplague> ogra: if you switch to the mainline u-boot to fixed the magic number issue, it will be a good reason to push for changing support on our end
[16:36] <ogra> rsalveti, well, with the current state we cant roll beta images
[16:37] <rsalveti> ogra: ok, will test the latest one and pack it
[16:37] <rsalveti> *try
[16:37] <sakoman> ogra: probably a month or two since I've had OMAP3 stuff moved up on the priority list by the LInaro folks
[16:37] <ogra> prpplague, right, the thing is that we have time constraints and updating stuff gets harder every day, from tomorrow on each fix requires a ton of paperwork
[16:38] <prpplague> ogra: ahh
[16:38] <ogra> sakoman, bah, thats bad, out omap3 u-boot works fine apparently
[16:38] <sakoman> ogra: not for Beagle xM or C4
[16:38]  * ogra hast seen any such issues on beagles
[16:38] <sakoman> that support is not upstream
[16:38] <ogra> i only have a C4 to test (kernel issues on XM prevent me from testing there atm)
[16:38] <sakoman> my task is to get all support upstream
[16:39] <ogra> sakoman, i dont use upstream, i use your branches ;)
[16:39] <sakoman> ogra: my omap4-exp branch has functional ethernet
[16:39] <sakoman> it is just not cleaned up for upstream
[16:39] <ogra> so we should use that one in the distro ?
[16:40] <ogra> rsalveti, would you update our u-boot-omap4 package from that one ?
[16:40] <sakoman> that is my working branch and I do frequent rebases as I clean things up and submit upstrea
[16:40] <rsalveti> ogra: http://people.canonical.com/~rsalveti/maverick/kernel/linux-image-2.6.35-17-omap_2.6.35-17.23rsalveti1_armel.deb should work for your xM, if you want to test it
[16:40] <rsalveti> ogra: sure
[16:40] <ogra> rsalveti, i will, but i'm currently focusing on panda
[16:41] <ogra> and have a long list of broken stuff still here
[16:41] <rsalveti> i know, I'm pointing the link just in case you want to test it :-)
[16:41] <ogra> yeah, i will
[16:41] <sakoman> the omap4-exp branch should work with panda, blaze, beagle c4, beagle xm, and Overo (both 35xx and 37xx versions)
[16:42] <ogra> sweet
[16:42] <GrueMaster> cool.  One uboot to bind them.
[16:42] <sakoman> the only caveat is that the omap4-exp branch is rebased fairly often as I prepare the patches, submit them upstream, and respong to feedback
[16:42] <rsalveti> as we're not seeing any issue with u-boot-omap3, I'd prefer updating just u-boot-omap4 with your current branch
[16:42] <rsalveti> ogra: what do you think?
[16:43] <sakoman> I try to keep it working at all times though
[16:43] <rsalveti> sure, np
[16:43] <ogra> rsalveti, yeah, it will also be a lot easier to package
[16:43] <rsalveti> ok then
[16:43] <ogra> if you build multiple binaries you need multiple configure and build runs
[16:44] <ogra> i plan to switch to linaro u-boot in N anyway
[16:44] <rsalveti> that's not a problem as linaro's package is probably doing that already
[16:44] <rsalveti> but I'd say it's better to just update omap 4 now
[16:44] <ogra> yeah, linaro uboot is not uploaded yet i think
[16:45] <rsalveti> if we see any blocking issue for omap 3, then we merge both packages in one that's upstream based (or linaro)
[16:45] <ogra> i think slangasek said something like that in yesterdays call
[16:45] <rsalveti> hm, ok
[16:45] <sakoman> ogra: I know jcrigby is testing my branch for the linaro u-boot builds
[16:45] <ogra> well, if the linaro u-boot would work on omap4 we could even switch now
[16:45] <ogra> but i think thats plain upstream
[16:45] <ogra> and i want all the additional sakoman love from the -exp branch ;)
[16:46] <slangasek> hmm, what did I say?
[16:46] <jcrigby> ogra: just uploaded new version to ppa
[16:46] <ogra> slangasek, that u-boot isnt uploaded to the archive yet
[16:46] <ogra> the linaro one
[16:46] <slangasek> correct - I need to work with jcrigby today to get it uploaded in a feature-freeze-compliant manner
[16:47] <ogra> slangasek, we have fat issues with the current omap4 version we use and i was wondering if it wouldnt make sense to switch to your version now instead of waiting for N
[16:47] <slangasek> if it helps you, we're happy to support your use of it
[16:47] <ogra> since i want to do that switch anyway at some point
[16:48] <ogra> but you are building from plain upstream
[16:48] <ogra> which doesnt have everything i'd like to have :)
[16:48] <slangasek> ah
[16:48] <ogra> (we need to support panda and blaze with the omap4 package)
[16:48] <slangasek> well, we can discuss putting some sauce into the packaging
[16:48] <slangasek> oh, that sounds less like sauce and more like a side dish :)
[16:49] <ogra> and as sakoman said above eMMC support for blaze is missing atm
[16:49] <ogra> and eMMC is the main disk on the blaze :)
[16:49] <ogra> ndec1, whats your suggestion from a blaze POV ?
[16:52] <rsalveti> ogra: jcrigby can confirm, but it seems current linaro's tree is using most of current sakoman's patches from omap4-exp
[16:52] <ogra> rsalveti, well, lets do it that way, i trust you on picking the right way and leave it in your hands ;)
[16:53] <rsalveti> ogra: haha, sure :-)
[16:53] <rsalveti> but I'd say at the moment that linaro's tree is enough for us
[16:53] <rsalveti> but still want to look for omap3 related patches
[16:53]  * ogra needs to reasearch busybox, gdm and update the netbook-settings package
[16:54] <rsalveti> as we could be missing patches
[16:54] <ogra> ok
[16:54] <ogra> the busybox breakage smells very much like toolchain :(
[16:55] <GrueMaster> ogra: I'm continuing my Alpha 3 update-to-fail investigation right now.  Should have something by EOD (since I can focus ,more on it & have faster network).
[16:55] <jcrigby> ogra:I have all of sakomans latest patches
[16:55] <jcrigby> on top of upstream
[16:55] <rsalveti> jcrigby: cool, will try your package later
[16:55] <ogra> GrueMaster, i still see no systm dbus on ym images, gdm will not start without that running
[16:55] <rsalveti> and check omap 3 support
[16:56] <rsalveti> if everything is well, than we can just use your package
[16:56] <rsalveti> and drop omap3 and omap4 ones
[16:58] <ogra> yeah
[16:58] <ndec1> ogra: what do you mean by 'eMMC support is missing on blaze'?
[16:58] <ogra> that was my plan for N
[16:58] <ogra> ndec1, in u-boot
[16:58] <ndec1> ogra: eMMC on blaze is working with TI version of uboot
[16:58] <ogra> ndec1, which u-boot would you suggest to use, apparently 1.1.4 has massive issues
[16:59] <ogra> since it seems unlikely that we can get the whole fat driver replaced now, we're discussing which other tree to use
[16:59] <jcrigby> rsalveti, I have tested it on the hw I have which  is C4, xM and mx51 babbage
[17:00]  * jcrigby has no omap4 hw
[17:00] <ogra> jcrigby, yeah, we need omap4 panda :)
[17:00] <ogra> but we have the HW
[17:00] <rsalveti> jcrigby: nice, but our old omap 3 tree had some extra patches, I'd say
[17:00] <rsalveti> initial zippy support and other stuff
[17:00] <rsalveti> jcrigby: I'll test it on my panda
[17:00] <ogra> rsalveti, i think i only made config changes and used sakoman'S omap3 tree as is
[17:01] <jcrigby> rsalveti, I think sakomans next task is expansion board support for mainline
[17:01] <rsalveti> jcrigby: cool, good to know
[17:01] <rsalveti> ogra: yup, but these patches are not at his current branch
[17:02] <ogra> ah
[17:02] <ogra> ok, so downgrading busybox to the last version makes reboot -f work again
[17:03]  * ogra re-adds -marm to debian/rules
[17:03] <rsalveti> who could help testing it on blaze? ndec1, GrueMaster?
[17:03] <ogra> i have a blaze but a) not set up and b) we need a special eMMC setup we dont have yet
[17:04] <ogra> (in flash-kernel)
[17:04] <rsalveti> hm, ok
[17:07] <GrueMaster> ogra: and davidm have the blazes (I don't get cool toys, only guts).
[17:07] <ndec1> rsalveti: we can. I just not available atm to discuss since I am on another meeting. i want to understand more about this. perhaps we can discuss on Fri during our call.
[17:07] <ogra> ndec1, beta freeze is unfortunately tomorrow
[17:08] <rsalveti> it's simply, just to test if the latest u-boot boots at blaze
[17:08] <ogra> rsalveti, well, its more since the blaze should get a special setup later
[17:08] <rsalveti> yeah, but for now, I mean
[17:09] <ogra> it will boot from a raw partiton on the eMMC and the u-boot version we use needs to support that
[17:09] <ogra> or at least be enhancable in a way that we can easily get a freeze exception
[17:11] <davidm> I can send the blaze to GrueMaster if that helps, just got it back from NCommander
[17:12] <ogra> well, to someone who will actually work with it would be good :)
[17:12] <ogra> either GrueMaster or rsalveti i'D say
[17:13] <NCommander> davidm: I think I forgot to send the power cord (i couldn't find it, but its a standard plug)
[17:13] <GrueMaster> Probably faster/easier to send it to me, although rsalveti would be the better choice for long term development.
[17:13] <davidm> GrueMaster, I can't send it to him the duties would be insane
[17:14] <rsalveti> yep, expensive board
[17:14] <rsalveti> send it to GrueMaster, I can work with him on that
[17:14] <ogra> then send it to GrueMaster
[17:14] <rsalveti> at least it'd be good so he could test it when needed
[17:14] <rsalveti> GrueMaster: I can get it directly from you later, if needed
[17:15] <ogra> ok, busybox uploaded, automatic rebooting should work again
[17:15] <rsalveti> ogra: just reverting last commit is enough?
[17:15] <rsalveti> re-adding -marm
[17:15] <ogra> rsalveti, yeah, just building with -marm again
[17:16] <prpplague> just a note, the power management is working on the ES2.0 8-layer panda boards
[17:16] <prpplague> looks like the twl6030 silicon we had on the earlier es2.0 boards has an issue
[17:16] <rsalveti> hm
[17:17] <ogra> tricky
[17:17] <ogra> i dont think we'll get the 8 layer yet
[17:17] <rsalveti> ogra: i'd be good if people could test or ask to test arm specific changes on packages
[17:18] <rsalveti> but don't know how hard was to find this bug
[17:18] <ogra> it was just a look at the changelog and some experience :)
[17:18] <ogra> the gdm issue seems to be rather tricky
[17:19] <ogra> what would be good would be to have enough HW to give it to ara so she could set up automated testing
[17:19] <ogra> i.e. not require the maintainer to test but just have automated tests that send regression alterts
[17:20] <ogra> *alerts
[17:20] <sakoman> jcrigby: correct -- adding the expansion board stuff is on the agenda next
[17:20] <sakoman> should be in by end of this week
[17:20] <GrueMaster> Hopefully I can work with her on this post release.  My systems are idle at night anyways.
[17:21] <rsalveti> sakoman: nice
[17:22] <ogra> GrueMaster, not your systems :) for N we should have huuuuge amounts of HW
[17:22] <ogra> GrueMaster, but its surely worth a spec for N
[17:22] <ogra> hey zul !
[17:23] <ogra> you in -arm ?
[17:23] <zul> hey ogra, yep just lurking
[17:23] <ogra> phew ... i was fearing server breakage :)
[17:23] <ogra> good to see you here :)
[17:25] <GrueMaster> ogra: I've added a task to my list to write up a blueprint for test automation, however I'll need someone to proxy for me as I won't make UDS.
[17:25] <ogra> huh ? you wont ?
[17:25] <ogra> thats bad, but i can proxy for you
[17:26] <zul> ogra: hehe
[17:26] <ogra> GrueMaster, or worst case i'll delegate to NCommander he has nothing to do anyway ... just that little dove thing :)
[17:26] <GrueMaster> I had already booked a cruise that week.  Booked it once we had the release date finalized at the last UDS.
[17:26] <GrueMaster> heh
[17:26] <ogra> ah, year i remember now, you told me at the sprint
[17:27] <GrueMaster> When I told the wife I should go to UDS, she gave me a look that would have given an exorcist pause.
[17:27]  * sakoman has no idea what this N thing is
[17:27]  * NCommander embeds a golf club in ogra's head
[17:27] <GrueMaster> Next Release.
[17:27] <ogra> sakoman, next release after mmmmmaverick :)
[17:27] <NCommander> sakoman: its a letter
[17:27] <NCommander> :-)
[17:27] <sakoman> :-)
[17:28]  * sakoman imagines Sesame Street music in the background
[17:28] <sakoman> "this release brought to you by the letter N"
[17:28] <ogra> lol
[17:29] <ogra> it actually *is* like sesame street :) you learn a lot about adjectives and animals following ubuntu releases
[17:30] <ogra> maverick meerkat :) natty narwahl
[17:31]  * ogra takes a break
[17:32] <GrueMaster> I thought it was narcissistic narwhal.
[17:33] <GrueMaster> Guess I should read the web a little more.
[18:54] <mpoirier> has anyone been able to use the ftrace's "set_ftrace_filter" on OMAP3 ?
[19:24] <prpplague> sebjan: ping
[19:29] <slangasek> ogra: are you guys using the linux-fsl-imx51 kernel at all in maverick?  It was inherited from lucid when the archive opened, hasn't been updated since, and if it's not needed / worked on, it's better to cull it from the archive than to let it drift
[19:30] <slangasek> (it's already missing two security revisions from lucid)
[19:31] <lool> slangasek: it's removed already
[19:31] <lool> in maverick
[19:31] <slangasek> lool: no, it isn't
[19:31] <ogra_cmpc> slangasek, we dont support imx51 at all
[19:32] <ogra_cmpc> in maverick
[19:32] <lool> slangasek: Oh I don't see the source in rmadison output
[19:32] <slangasek> lool: I'm looking straight at the archive; not sure why rmadison doesn't show it for you
[19:32] <slangasek> ogra_cmpc: so you're ok with me nuking it?
[19:32] <lool> slangasek: Uh yes I do, I'm just assuming it's sort alphabetically </slap>
[19:32] <lool> slangasek: I'm just tired, sorry
[19:32] <ogra_cmpc> slangasek, totally
[19:33] <GrueMaster> slangasek: I do get security updates for lucid to test.  And we do still support it on lucid.
[19:33] <slangasek> GrueMaster: yes, we don't remove packages from released versions after the release
[19:33] <GrueMaster> ok, just making sure.
[19:34] <ogra_cmpc> GrueMaster, only maverick
[19:34] <GrueMaster> Might also check with oem to see if they have any strange projects going on that require it.
[19:35] <ogra_cmpc> oh, that might be, but for imx51 they will surely have their own kernel/bootloader
[19:35] <ogra_cmpc> since ours definitely only supports babbage boards
[19:36] <slangasek> and hasn't even been getting security updates
[19:36] <ogra_cmpc> slangasek, lamont or IS might have some interest in having an imx51 kernel since our buildds are currently all babbage 3.0 boards
[19:36] <slangasek> if OEM were using it, I expect they would've interfaced with the kernel team on this before now
[19:36] <slangasek> ogra_cmpc: IS doesn't run non-LTS on the buildds
[19:36] <slangasek> (if they can help it)
[19:36] <ogra_cmpc> well, armel is spethial :)
[19:37] <slangasek> it's nuked already, so anyone who needs it should've spoken up sooner
[19:37] <slangasek> armel isn't *that* special, no
[19:37] <ogra_cmpc> well
[19:37] <ogra_cmpc> we had buildds where IS had no control about the kernel at all for the last few releases
[19:38] <slangasek> which is quite a separate thing from wanting to run a kernel from a *newer* non-LTS release
[19:38] <ogra_cmpc> if we run into HW related probs like we did with the former setup it might require an update
[19:39] <ogra_cmpc> but for that we can indeed have a separate kernel if neede
[19:39] <ogra_cmpc> d
[19:40] <ogra_cmpc> (the pegatron buildds with the binary only kernel had issues building thumb2 for example)
[19:40] <prpplague> ogra_cmpc: have you got a L24.9 repo you guys are using for testing your ubuntu builds from?
[19:40] <ogra_cmpc> prpplague, for kernel ?
[19:40] <prpplague> yea
[19:41] <prpplague> rsalveti: said he was waiting on sebjan to do some testing with L24.9
[19:41] <ogra_cmpc> prpplague, we get a specially merged tree from sebjan where he rebases the TI releases on top of the ubuntu tree
[19:41] <ogra_cmpc> we're waiting for the 2.6.35 rebase, zes
[19:41] <prpplague> ogra_cmpc: ahh ok
[19:41] <ogra_cmpc> s/z/y/
[19:42] <prpplague> ogra_cmpc: ok, i was kinda hope'n to test your builds
[19:42] <ogra_cmpc> well, we should get the rebased tree this week
[19:43] <ogra_cmpc> the only working image we currently have is a few weeks old if you are intrested
[19:43] <ogra_cmpc> http://cdimage.ubuntu.com/ubuntu-netbook/ports/releases/maverick/alpha-3/
[19:43] <GrueMaster> slangasek: I'm not sure why the kernel updates haven't been getting in there.  I know they have released some to proposed fairly recently (July I think).
[19:44] <ogra_cmpc> just gunzip, dd to SD card and boot away
[19:44] <GrueMaster> actually, I am currently running a kernel built on 8/19.
[19:44] <ogra_cmpc> GrueMaster, because the mx51 kernel was in a separate tree
[19:44] <ogra_cmpc> in maverick nobody maintains that tree
[19:44] <slangasek> GrueMaster: because publishing to the current dev release isn't part of the security team's process for kernels; so if nobody's maintaining the kernel in maverick, it would be guaranteed to continue falling farther behind between now and release
[19:45] <GrueMaster> ok.  Starting to understand.
[19:45] <ogra_cmpc> smb updates the lucid tree
[19:45] <ogra_cmpc> but cooloney doesnt update the dev tree anymore
[19:46] <slangasek> if somebody wants imx51 in maverick, they can work on getting support upstreamed and into linux-linaro :-)
[19:46] <ogra_cmpc> i thought linux-linaro has imx51 support already
[19:46] <slangasek> yes, as much support as is present upstream
[19:46] <ogra_cmpc> ah
[19:47] <ogra_cmpc> which is likely sparse :)
[19:47] <slangasek> quite
[20:30] <ogra> sigh, now my panda stopped booting completely
[20:31] <GrueMaster> Is there an easy way to backrev a package with apt?
[20:32] <GrueMaster> Or does it always load the latest.
[20:33] <ogra> you can define a version iirc, but if its only one package i'd just wget and dpkg -i it
[20:38] <GrueMaster> ok
[20:48] <rsalveti> sakoman: does 'reset' at u-boot work with you at beagle xM?
[20:49] <rsalveti> at mine I just get stuck
[20:49] <sakoman> rsalveti: I don't have a "final" xM yet (due tomorrow)
[20:49] <sakoman> rsalveti: let me try on an early prototype I have
[20:50] <sakoman> rsalveti: yes, just hangs
[20:50] <rsalveti> sakoman: mine is a p8, not final too
[20:50] <sakoman> rsalveti: let me try on an Overo 37XX
[20:50] <rsalveti> hm, so, so it seems we got a bug
[20:50] <rsalveti> ok
[20:51] <sakoman> we can at least see then if it is a 37XX related issue, or is xM specific
[20:51] <lool> sakoman: I'd love knowing if the XM comes with a MAC address in eeprom in the final version
[20:52] <sakoman> lool: perhaps we'll find out soon :-)
[20:52] <sakoman> rsalveti: same situation with the Overo 37XX
[20:52] <sakoman> rsalveti: I'll investigate
[20:53] <rsalveti> sakoman: ok, thanks :-)
[21:07] <sakoman> rsalveti: looks like the reset command uses a generic arm library used by all arm processors
[21:08] <rsalveti> hm
[21:08] <sakoman> I'll have to ping some TI folks to see if they know why this code doesn't work on the 37XX
[21:12] <sakoman> rsalveti: found a potential fix.  will test.
[21:12] <rsalveti> cool
[21:13] <sakoman> it is indeed -- in involves doing a "cool" reset
[21:13] <sakoman> so your choice of words was amazingly accurate :-)
[21:16] <rsalveti> haha :-)
[21:16] <rsalveti> lool: so no mac address in eeprom for us
[21:16] <rsalveti> the eeprom pins are  n.c.
[21:16] <sakoman> bummer :-(
[21:17] <rsalveti> maybe for panda, but not for xM
[21:18] <rsalveti> prpplague: do you know if we get an smsc eeprom for panda?
[21:18] <rsalveti> or is it just n.c. as xM?
[21:19] <sakoman> rsalveti: the reset fix worked on my 37XX Overo, let me check for regressions on the 35XX versions
[21:20] <rsalveti> nice
[21:20] <prpplague> rsalveti: one sec
[21:22] <sakoman> rsalveti: worked fine on 35XX also, I'll push to my omap4-exp branch shortly
[21:22] <sakoman> I'll ping you when it is done
[21:22] <rsalveti> sakoman: great!
[21:23] <lool> rsalveti: sadness
[21:23] <lool> rsalveti: So I definitely think it's worth talking to the usbnet maintainer
[21:24] <sakoman> lool: the Overo's have eeproms on their network chips
[21:27] <lool> Good!
[21:27] <GrueMaster> HA.  I found a dependency issue in the pool that slipped by the awesomeness of debian packaging.  gnome-terminal now depends on libvte but libvte failed to upgrade at the same time.
[21:34] <prpplague> rsalveti: the eeprom is no connect on the panda
[21:34] <prpplague> rsalveti: you can do one of two things
[21:34] <prpplague> rsalveti: either have linux driver get a random mac
[21:34] <prpplague> rsalveti: or you can use rob's patch to assign one manually as a boot arg
[21:34] <sakoman> rsalveti: I added the fix to the set of patches I am preparing for submission -- staged in the omap4-exp branch
[21:35] <sakoman> rsalveti: in particular: http://www.sakoman.com/cgi-bin/gitweb.cgi?p=u-boot.git;a=commitdiff;h=ce927c809c6b3a619a2cd712c47563676d79f8f0
[21:36] <rsalveti> prpplague: yep, also saw that patch
[21:36] <rsalveti> just wanted to confirm
[21:36] <prpplague> rsalveti: ahh ok
[21:36] <rsalveti> I'm fine with the random one for the moment
[21:37] <rsalveti> ouch, can't boot my kernel on a b5 (external abort on non-linefetch)
[21:37] <rsalveti> hm... works at my c4
[21:37] <rsalveti> sakoman: nice, thanks
[21:40] <rsalveti> prpplague: but thanks for checking it
[21:40] <prpplague> :)
[21:42] <sakoman> rsalveti: thanks for testing and the bug report
[21:42] <rsalveti> prpplague: ndec: don't know yet, but do we have access to any hardware documentation for panda? (public or canonical)
[21:42] <sakoman> there's a lot of common code, so I need to test on 6 different OMAP3/OMAP4 boards
[21:42] <ndec> rsalveti: jayabharath might know.
[21:42] <rsalveti> sakoman: compiling new u-boot right now :-)
[21:43] <jayabharath> rsalveti: what documentation would you like.. we can load it up on the wiki
[21:43] <sakoman> rsalveti: I'm sure you'll let me know if it doesn't work ;-)
[21:44] <rsalveti> jayabharath: things like the schematics
[21:44] <rsalveti> this sometimes can help debugging kernel issues
[21:45] <rsalveti> mostly gpio, pins and etc
[21:45] <rsalveti> not anything specific at the moment, can ping you if I need anything else
[21:45] <jayabharath> Sure.. will load them up on 'the' wiki
[21:45] <rsalveti> sakoman: sure :-)
[21:45] <rsalveti> jayabharath: cool, thanks :-)
[21:46] <rsalveti> jayabharath: would you mind sharing the doc for es1 and es2?
[21:46] <rsalveti> if not possible, just es2 related is enough
[21:46] <jayabharath> Ok. will load up all the schematics for all revs :)
[21:46] <rsalveti> jayabharath: awesome, thanks a lot
[22:43] <prpplague> rsalveti: i have the lilluput/iMO display working on the panda
[22:47] <rsalveti> prpplague: haha, cool!
[22:48] <rsalveti> argh! another fried sd
[22:49] <rsalveti> sakoman: do you know if reset worked for panda before?
[22:49]  * robclark wants to see it
[22:49]  * rsalveti can't remember
[22:49]  * rsalveti can't see it :-(
[22:49] <robclark> rsalveti: fwiw, the reset button works much better on es2
[22:50] <sakoman> rsalveti: don't recall, will have to check
[22:50] <rsalveti> well, doesn't seems to work at all at my es1 hah
[22:50] <rsalveti> sakoman: at least with your latest patch it doesn't work
[22:50] <rsalveti> but don't remember if it worked or not before
[22:51] <rsalveti> took a while to test because one of my most used sd card got fried :-(
[22:51] <rsalveti> lots of i/o errors
[22:52] <sakoman> rsalveti: OMAP4 uses different reset code -- the arm reset library function calls an architecture dependent assembly language reset function
[22:52] <rsalveti> oh, ok, makes sense
[22:52] <sakoman> just tried sdp -- that hangs too
[22:53] <sakoman> I may need to do a similar patch for OMAP4, will investigate
[22:53] <rsalveti> sakoman: haha, ok
[22:54] <rsalveti> but at least I can confirm that it's working fine for all beagles I have
[22:54] <rsalveti> r5, c4 and xm
[22:54] <rsalveti> with your latest patch
[22:55] <sakoman> rsalveti: oops - I was mistaken OMAP3 and 4 share the reset code.  I tested with a pre-patch u-boot on SDP, so I need to rebuild and retest
[22:55] <rsalveti> hm, ok
[23:05] <sakoman> rsalveti: it hangs with my change, and it hangs with TI's internal u-boot
[23:06] <sakoman> so I suspect that either the HW is bad, or the required reset code has changed for OMAP4 (or perhaps both)
[23:06] <sakoman> I'll ping some TI folks about that
[23:07] <rsalveti> could be both
[23:07] <rsalveti> sakoman: do you have an es2?
[23:07] <rsalveti> hm, needs other stuff
[23:07] <sakoman> rsalveti: no, all my machines are ES1
[23:08] <sakoman> prpplague: does the u-boot 'reset' command work with the latest OMAP4 silicon/boards?
[23:10]  * rsalveti things he is the only one who actually uses this command
[23:10] <rsalveti> *thinks
[23:10]  * rsalveti needs more coffee
[23:11] <sakoman> rsalveti: I used to use it a lot on OMAP3 after changing the u-boot environment in nand
[23:11] <sakoman> rsalveti: I am roasting some coffee, cause I need some too :-)
[23:12] <sakoman> rsalveti: I don't use it some much on newer 37xx/OMAP4 boards because they don't have nand!
[23:12] <rsalveti> hahah, true
[23:12] <sakoman> s/some/so/
[23:12] <sakoman> see I do need coffee!
[23:12] <rsalveti> haha :-)
[23:13] <sakoman> in any event, I'll try to track down why reset command is broken on OMAP4
[23:18] <prpplague> sakoman: not sure i'll have to test
[23:33] <Baybal> mmm
[23:33] <Baybal> are there any omap4 COMs?
[23:49] <Iow> Im booting ubuntu-10.04.1-minimal-armel.tar.7z, it loads up to the language selection but it wont take input from my keyboard
[23:52] <rsalveti> time for dinner, hungry
[23:55] <Iow> Which line is the init for the usb keyboard?


[19:22] <rickspencer3> o/
[19:22] <rickspencer3> forgot to autojoin :)
[20:06] <bcurtiswx> o/
[20:07] <bcurtiswx> rickspencer3, should hud-service be taking up 15% of my 8GB of RAM ?
[20:07] <rickspencer3> uh
[20:07] <rickspencer3> no :)
[20:08] <rickspencer3> bcurtiswx, that sounds like a pretty serious bug
[20:08] <bcurtiswx> how would I restart it ?
[20:09] <bcurtiswx> there's no service for it
[20:09] <bcurtiswx> just kill and it'l autospawn rickspencer3
[20:09] <rickspencer3> bcurtiswx, sorry, I don't really know
[20:09] <bcurtiswx> rickspencer3, OK j/w, thx
[20:09] <rickspencer3> #ubuntu-desktop would probably love to hear from you :)
[20:12] <bcurtiswx> rickspencer3, i'm fairly sure I have a professional annoyer tag in my secret canonical employee profile ;)
[20:12] <rickspencer3> lol
[20:12] <bcurtiswx> bbl, gotta go pick up my wife from WMATA
[20:12] <rickspencer3> bcurtiswx, well, people who help us track down and fix bugs are NOT annoying


[07:28] <dholbach> good morning
[07:32] <nhaines> dholbach: good morning.  :)
[07:32] <dholbach> hey nhaines
[07:34] <nhaines> dholbach: having a good day so far?
[07:48] <dholbach> very much so - how about you?
[08:37] <nhaines> dholbach: not bad!  I did everything on my task list except the server admin stuff.  And that can surely wait until later.  :)
[08:51] <dholbach> :)


[14:57] <rbelem> hello all :-)
[15:16] <mterry> lool, bfiller, forgive my release-ignorance, but what's the moblin freeze policy regarding the beta?  Should I hold off updating packages to 2.1 until after the beta is blessed?
[15:17] <bfiller> mterry: I'm guessing yes
[15:18] <lool> mterry: In theory yes
[15:18] <lool> mterry: In practice what matters is what it's in the image and you could push bug fixes to the PPA in the mean time
[15:18] <lool> Just don't push any complex changes or library transition etc.
[15:19] <mterry> Yar.  But are you saying image is no longer pulling from PPA?  There's at least one new image spin coming before beta, I believe
[15:19] <mterry> And there's that important session fix in the PPA
[15:19] <mterry> lool: ^
[15:23] <lool> mterry: No
[15:23] <lool> mterry: we dont plan to respin anything
[15:23] <lool> unless we need to
[15:23] <mterry> lool: oh.  :(  so no session fix?  ah well
[15:23] <lool> mterry: Well I can respin
[15:23] <lool> mterry: if you tell me you have a fix for it
[15:23] <lool> mterry: We dont plan any right now
[15:24] <lool> mterry: Not for desktop, UNR etc.
[15:24] <lool> mterry: But if you have a beta critical fix such as the session one, go for it and I'll respin and retest
[15:24] <mterry> lool: I have a fix for it, it's in PPA.  However, other fixes are in PPA now too, so you'd end up doing more than a cherry pick
[15:24] <lool> mterry: Are all of these safe?
[15:25] <lool> Problem is that I cant block/review all PPA uploads as we do for main archive  :-(
[15:25] <mterry> lool: I didn't do any but mine.  I can't speak to safety, but I'd like to think they are...  :)
[15:25] <lool> bfiller: What about your changes?
[15:25] <lool> paulliu, StevenK: You guys pushed moblin stuff?
[15:25] <mterry> Oh, I did update moblin-menus.  That's probably pretty safe
[15:26] <mterry> paulliu updated the cursor theme
[15:26] <mterry> If 18 hours ago wasn't represented in the last image, there are more changes too..   gnome-session, gnome-settings-daemon, etc.
[15:27] <mterry> moblin-remix-meta
[15:27] <lool> mterry: Concerning update-a --display x-session-manager, it points to startmoblin
[15:27] <bfiller> lool: lots of packages were changed in the last 12-18 hours, don't really know what's working and what's not
[15:27] <lool> mterry: Is there anything else you wanted from that output?
[15:27] <lool> bfiller: That's a pity, cant tell whether I can respin or not  :-(
[15:27] <mterry> lool: yeah, but turns out that's not enough.  gdm prefers default.desktop, then gnome.desktop.  It only sometimes cares about x-session-manager
[15:28] <lool> mterry: So you fixed the other case?
[15:28] <bfiller> lool: I pushed a new meta packages and fixes for connman yesterday, should be safe
[15:28] <mterry> lool: well, the session thing is pretty bad.  It's like a moblin that's not really a moblin
[15:28] <lool> mterry: Ack
[15:28] <mterry> lool: yeah, I ship a default.desktop that points to moblin.desktop (ala xubuntu-default-settings)
[15:28] <lool> Ok; I'll go for a respin
[15:28] <lool> mterry: excellent thanks
[15:28] <mterry> lool: cool
[15:29]  * mterry crosses fingers
[15:29] <bfiller> can't be more broken then the current image :)
[15:37] <mterry> bfiller: how come the daily builds don't have stuff like gedit anymore?  seems very stripped down
[15:38] <bfiller> mterry: I pushed a new meta package yesterday that should match what we did for moblin jaunty
[15:38] <bfiller> mterry: has more of the utils
[15:39] <mterry> bfiller: ah, cool, I look forward to our new daily build then
[15:39] <bfiller> mterry: +1
[15:45] <lool> bfiller, paulliu, mterry: We will have to be much more careful with final coming up
[15:45] <lool> there's no control to what we can push to PPA, but we need to release a decent image out of it
[15:46] <mterry> agreed
[15:46] <bfiller> lool: I'm guessing things should stablize a lot now, there has been a bunch of pushes necessary for the 2.1 upgrade
[15:46] <bfiller> many changed packages
[15:47] <lool> bfiller: We cant afford risky uploads near the release though, even if there's so much to fix
[15:48] <bfiller> lool: ok, it wasn't clear to me that we shouldn't be pushing the 2.1 packages to the PPA at this point
[15:48] <lool> bfiller: Yeah my bad actually
[15:48] <lool> bfiller: I think I completely forgot to mention that in our call on Monday
[15:49] <lool> It was ok to push stuff, but I needed to release a beta image and I didn't mention the freeze or anythng
[15:49] <lool> selbstschuld
[15:49] <bfiller> lool: np, next time we will be more away
[15:49] <bfiller> more aware I mean
[15:49] <lool> Only one last time: release  ;-)
[15:49] <lool> terranova.buildd finished at Wed Sep 30 15:32:02 BST 2009 (failed)
[15:49] <lool> livefs failed to build
[15:49] <lool>   ubuntu-moblin-remix: Depends: anjal but it is not going to be installed
[15:49] <lool> mterry, bfiller ^
[15:50] <mterry> great...
[15:50] <bfiller> lool: paulliu mentioned problems with anjal which was newly added to the meta package, I can remove it from meta package
[15:51] <bfiller> or wait until paul fixes issues with it
[15:51] <lool> bfiller: Cant wait
[15:51] <lool> is paulliu still around at all?
[15:51] <lool> He usually goes late to bed but still  :)
[15:52] <bfiller> lool: I'll push new meta with anjal removed
[15:52] <lool> bfiller: thanks
[15:53] <lool> So the problem is libnbtk-1.2-0 versus libnbtk-1.0-0
[15:59] <bfiller> lool: pushed new moblin-remix-meta, need to wait till it builds
[15:59] <bfiller> lool: I'll ping you when it's built
[16:06] <lool> thanks
[16:09] <bfiller> lool: moblin-remix-meta published, should be good for build
[16:10] <lool> 16 upgraded, 697 newly installed, 0 to remove and 37 not upgraded.
[16:10] <lool> Need to get 327MB of archives.
[16:10] <lool> looks good indeed
[16:11] <lool> plars, GrueMaster: We'll be having a new moblin remix image soon
[16:11] <plars> lool: ok
[16:25] <plars> GrueMaster: *sigh* usb-creator still giving me fits on and off
[16:26] <GrueMaster> I have found that using gparted to reformat the usb drive first helps immensly.
[16:27] <lool> I use format and then unplug and replug the key
[16:27] <lool> it's quite annoying though
[16:28] <GrueMaster> It's slower than if usb-creator would just wipe the drive first, butit is quicker than having usb-creator open the drive so you can start deleting random things.
[16:28]  * lool tries without unplugging
[16:28] <GrueMaster> with gparted, you don't need to unplug and plug in.  It simulates that step as part of the process.
[16:28] <lool> What annoys me is that it I get a nautilus window on the drive
[16:28] <lool> Despite having automount off
[16:33] <ogra> gparted is sooo yesterday
[16:33] <ogra> use palimpsest#+
[16:33] <ogra> *palimpsest
[16:36] <plars> odd, I just tested oem install, which went pretty well, then remembered something I wanted to check.  When I booted it back up again under vbox it just hangs at a black screen
[16:36] <lool> plars: are you running multiple vboxes?
[16:36] <lool> plars: Do you see grub, usplash, anything?
[16:37] <plars> lool: yes, I get through grub and usplash, then when the resolution change happens (gdm?) it just sits at a black screen
[16:37] <plars> lool: I was running multiple ones briefly, then decided that was a bad idea
[16:38] <GrueMaster> plars: did you install the VBoxAdditions?  There is an issue with their driver and 3D support enabled.
[16:38] <plars> GrueMaster: no, hadn't done that
[16:38] <plars> GrueMaster: and yes, aware of that issue
[16:38] <GrueMaster> What version of VBox are you running?
[16:39] <plars> 3.06
[16:39] <GrueMaster> ok
[16:39] <GrueMaster> same here.
[16:40] <lool> plars: gdm should start xsplash
[16:40] <paulliu> lool: hi. I'm trying to make anjal build by the right way.
[16:40] <lool> plars: I didnt try a vbox install; booting live in vbox doesn't require any addition so I'd be surprized if the installed system would
[16:41] <lool> paulliu: Yeah, what's up?
[16:41] <paulliu> lool: Well. The current anjal is good for Karmic universe. But to use it in Moblin, we have to build it with different configuration. And also it have to be build against evo-dbus things as well.
[16:42] <paulliu> lool: So it needs to migrate to nbtk 1.2. New anerley, and.. evo-dbus and eds-dbus things.
[16:42] <plars> lool: right, worked fine through the user install process and everything, wasn't until the subsequent reboot that I had an issue, so might just be an odd fluke.  Hence why I'm trying to get usb-creator working so I can try it outside of vbox
[16:43] <paulliu> lool: current anjal in unverise is built with --with-anerley=no. It's good but it will look different than what we want with moblin.
[16:46] <plars> brb
[16:46] <lool> paulliu: Ok
[16:47] <lool> paulliu: So there are two things to consider
[16:47] <lool> paulliu: One is what we do on the long term there
[16:47] <lool> paulliu: Is it possible to build --with-anerley=yes in universe or doesn't it make sense?
[16:48] <lool> paulliu: If it doesn't make sense, then we need to build two versions; change the build to have two passes and create a new anjal-anerley binary package to install the second pass
[16:48] <lool> paulliu: check e.g. cheese/cheese-hildon as an example
[16:48] <paulliu> lool: Doesn't make sense. Because anerley is part of moblin. To built with anerley=yes is easy in universe. But without eds-dbus, anjal won't work properly.
[16:48] <lool> new UMR up for grabs
[16:49] <paulliu> lool: anerley is still not in universe today because we didn't have new version of telepathy-mission-control-5 and thus our anerley contains tmc5's source code inside.
[16:49] <GrueMaster> lool: 20090930 or newer?
[16:49] <paulliu> lool: That's a major block of anerley.
[16:49] <lool> StevenK bfiller mterry paulliu GrueMaster: New UMR posted
[16:50] <lool> GrueMaster: 20090930
[16:50] <mterry> lool: hot!
[16:50] <lool> paulliu: Ok; seb12 told me he'd push tmc 0.9.0 after beta
[16:50] <lool> *seb128
[16:50] <GrueMaster> getting it now.
[16:50] <lool> paulliu: So after that's done, we can do it
[16:51] <lool> paulliu: Perhaps you can start preparing the anjal package to be like that in ppa?
[16:51] <paulliu> lool: Yes. But still with TMC5 patch.
[16:51] <lool> paulliu: i.e. two passes
[16:51] <lool> paulliu: We wont need the TMC patch after beta in universe
[16:51] <lool> paulliu: Oh you mean a port of anjal?
[16:51] <lool> paulliu: Ok
[16:51] <lool> paulliu: Hmm is it intrusive?
[16:51] <paulliu> lool: Ah. It's port patch. :) Because TMC5 port patch contains 2 parts. One is to modify anerley. One is to add tmc5 inside anerley
[16:52] <lool> paulliu: Ok; it's fine to push anerley with TMC5 patch to universe
[16:52] <lool> paulliu: But the tmc5 copy wont be needed
[16:52] <paulliu> lool: OK.
[16:52] <lool> paulliu: Because seb128 will include tmc 0.9.0 after beta
[16:52] <paulliu> lool: Yes. It will be removed when we have a good tmc5
[16:53] <lool> paulliu: So if you like, start preparing an anjal which builds in two passes so that we can keep "anjal" what it is (--with-anerley=no) and have a new binary package which is built with anerley support ("anjal-anerley")
[16:53] <lool> paulliu: We will need a new FFE for that change
[16:53] <lool> paulliu: But we can start doing that in PPA already
[16:53] <lool> paulliu: BTW new TMC is in unstable alreayd; you can push anerley there   :-)
[16:53] <paulliu> lool: Wait. How to solve the evolution-dbus dependencies for anjal?
[16:54] <lool> paulliu: We will just rebuild anjal in PPA
[16:54] <lool> But keep most of the source in karmic
[16:54] <paulliu> lool: ok.
[16:54] <paulliu> lool: OK. Agreed.
[16:54] <paulliu> lool: Will do that.
[16:54] <lool> paulliu: Cool; thanks for your work!
[17:10] <lool> mterry: You rock!  :)
[17:10] <mterry> lool: you mean you get moblin?  :)  yay
[17:11] <lool> So the next big thing is that there's no icon to install this stuff
[17:11] <lool> I can launch ubiquity by hand though
[17:11] <mterry> lool: it's in apps->Settings
[17:11] <mterry> lool: but yeah, it should be in favorites or something so it's on the first panel
[17:11] <lool> oh really, great
[17:11] <lool> I was worried
[17:12] <lool> mterry: Would be a nice thing for final
[17:12] <lool> Frankly it's not shiny but if it installs like that I'm happy to release that as the developer preview image we announced for karmic
[17:13] <mterry> lool: it does install like it looks in the live image, thankfully
[17:14] <lool> mterry: Cool
[17:14] <lool> I'll do an install test now
[17:14] <lool> in vbox
[17:27] <plars> lool, GrueMaster: so I just reproduced this again under vbox with oem install, haven't tried with normal install yet but I have that running on my eee right now
[17:28] <plars> at the point we exit usplash ubuntu logo, the screen resolution changes and I get a black screen, where it hangs
[17:28] <bfiller> lool: I'm installing now on a netbook
[17:30] <GrueMaster> plars: what steps have you taken?  I'll see if I can reproduce it here.
[17:30] <plars> GrueMaster: pretty much just a straight oem install, taking all the defaults
[17:31] <plars> GrueMaster: I get through the first reboot, and do the prepare for end user, then I reboot and go through the user setup, all that works fine
[17:31] <plars> GrueMaster: but at that point, if I reboot again, it won't come back up
[17:31] <GrueMaster> Ok, will try here.
[17:39] <GrueMaster> Hey, here's an odd user-scenario bug.  Do a normal install with encrypted home directory.  Reboot and set home directory pass phrase.  Once logged in fully, use the  login screen applet under system administration to change the user to auto-login.  What happens is several apps (icewm, nautilus, etc) complain about creating files in the home directory, and you are left with a blank screen w/ background.  To fix, press power button and a
[17:41] <GrueMaster> I wonder why moblin remix takes so much longer to download than UNR?  UNR xfer rate was bouncing in the 200-700kBps range, and UMR is bouncing between 5-70 kBps.  Using zsync for both from cdimage.ubuntu.com
[18:04] <GrueMaster> plars: I am unable to reproduce the issues you are seeing in Vbox.
[18:06] <plars> GrueMaster: ok, I'm retrying on real hardware... in the meantime, I was able to make it boot finally under vbox, but no rhyme or reason to it.  *could* just be some quirkyness with vbox, which wouldn't surprise me, but I want to be sure
[18:11] <lool> plars: That sounds like it, but best to double check
[18:11] <lool> plars: Thanks for your careful testing :)
[21:56] <physic> hello allll
[21:57] <physic> how i can connect to internet from mobile in ubuntu??????????
[22:01] <playya> what do you want to use? UMTS,WiFi,LAN?
[22:07] <physic> any one can answer?
[22:07] <physic> no ineed to use dial up or anything can connect from mobile
[22:12] <tsoncul> physic: what version of Ubuntu are you using?
[22:13] <physic> hardy heron
[22:14] <tsoncul> physic: I don't know about hardy that well. You might want to try #ubuntu
[22:14] <tsoncul> physic: It's a better-frequented chatroom, and they
[22:14] <tsoncul> -- focus on stable releases
[22:21] <physic> good thanks
[22:21] <physic> i saw this channel called ubuntu-mobile i thoght may be use full
[23:08] <plars> GrueMaster: web browser seems to be broken in the current moblin image
[23:09] <plars> GrueMaster: doesn't ever get anywhere, no error, nothing, just a blank page
[23:09] <plars> GrueMaster: either that, or all web pages have suddenly been replaced with "<html></html>" :)
[23:09] <GrueMaster> There is a bug filed on that.
[23:09] <plars> GrueMaster: oh, was there one already? I didn't see it, what's the #?
[23:09] <GrueMaster> need to chmod 644 /etc/resolve.conf
[23:10] <plars> ah, I remember seeing that
[23:10] <plars> GrueMaster: nope, it's already 644
[23:15] <GrueMaster> Big bug.
[23:15] <GrueMaster> Try moblin-web-browser slashdot.com in a terminal.  Quite impressive.
[23:21] <plars> GrueMaster: what, the clutter-mozheadless errors?
[23:22] <GrueMaster> No, the three tabs that get launched in the browser.
[23:22] <plars> GrueMaster: I don't see that
[23:22] <GrueMaster> all blank of course.
[23:22] <plars> GrueMaster: I don't get any tabs
[23:22] <GrueMaster> weird.
[23:22] <plars> oh
[23:22] <plars> yes I do, but just for that site
[23:24] <plars> GrueMaster: I seem to get additional tabs each time I launch, with any site
[23:43] <GrueMaster> wget pulls a webpage no problem.
[23:43] <GrueMaster> and apt-get works (wget isn't installed by default.
[23:44] <GrueMaster> )
[23:58] <SgtOompa> Hi, i'm trying to install Ubuntu MID on my Samsung Q1U but I can't get the image to boot from my USB drive, can someone help me?