#ubuntu-arm 2010-01-04
<lool> ssvb: Oddly, switching with another pixman and the problem goes away
<lool> cwillu_at_work told me that squeeze/sid/emdebian libpixman doesn't have the issue but lucid pixman (same source, different toolchain) does
<lool> I'm pretty sure he used the same kernel in all tests since we dont provide kernels for beagleboard on ubuntu
<lool> bizkut-offline: This is seriously annoying; you don't even answer when we ask you to stop your verbose away
<armin76> lool: :D
<ssvb> lool: don't know, maybe recompiling pixman (and xserver?) with a different toolchain just hides the bug
<ssvb> lool: but I know for sure that such problem existed with problematic kernels and it resulted in a similar looking artefacts on screen
<lool> Ok
<lool> Hmm right, I didn't think of rebuilding xserver, and it might be a bug in the kernel only triggered in specific conditions
<ssvb> lool: what version of kernel are you using by the way?
<lool> In Ubuntu we track 2.6.32 for the next release, but we don't provide beagleboard kernels; he was running a .32 IIRC
<lool> 11:14 < cwillu_at_work> Linux overo 2.6.32.1-x1.0 #1 PREEMPT Thu Dec 17  02:23:37 UTC 2009 armv7l GNU/Linux
<lool> I'm not sure from which branch
<lool> I suppose -omap, but then it could be any tree derived from that
<ssvb> I see, there is a small testcase which can be easily used to verify whether the kernel has this problem or not, I'll try to find it
<lool> Great
<ssvb> lool: here is a testcase for kernel bug: http://siarhei.siamashka.name/files/20100104/test-sighandler-vfp-corruption-bug.c
<ssvb> lool: looks like the fix did not get upstream yet (just tested it with the latest linux-omap kernel), makes sense to send some ping messages
<lool> cwillu_at_work: ^
<lool> ssvb: thanks!
 * armin76 kicks NCommander 
<ssvb> lool: also just verified that these old patches still apply cleanly and fix the problem
 * NCommander is beaten by armin76 
 * armin76 steals NCommander's dove boards
<NCommander> armin76, :-P
<NCommander> armin76, http://www.engadget.com/2010/01/04/freescale-reveals-7-inch-smartbook-reference-design-hopes-to-se/ - just buy one of these
<armin76> NCommander: i prefer your boards *g*
<armin76> NCommander: gimme Z0!
<NCommander> armin76, I never had a Z0
<armin76> NCommander: get me one!
 * NCommander thinks armin76 didn't get any ARM hardware for the holidays
 * cwillu_at_work is pinged
 * cwillu_at_work pokes lool 
<armin76> NCommander: there's an dove arm buildd that hasn't build something since october, gimme!
<NCommander> armin76, ?
<armin76> NCommander: give it to me if it isn't doing anything :P
 * cwillu_at_work has finished reading the scrollback
 * cwillu_at_work runs ssvb's test-sighandler-vfp-corruption-bug.c
<cwillu_at_work> cwillu@overo:~$ ./a.out
<cwillu_at_work> error: x=1090022160 y=1090022161 d=9434.232100
<cwillu_at_work> Aborted
<ssvb> cwillu_at_work: it's a bit messy, but demonstrates that the signal handler can corrupt floating point registers from the main thread, normally this test should run infinitely without any problems
<cwillu_at_work> ya, that run lasted all of 20 seconds
<ssvb> cwillu_at_work: for pixman it means that the signal handler responsible for input handling may corrupt NEON registers and as these are used for processing pixel data, it results in image artefacts which look as horizontal stripes
<cwillu_at_work> hmm
<cwillu_at_work> only horizontal stripes?
<cwillu_at_work> I only get 45degree stripes
<cwillu_at_work> this is upstreams 2.6.32.2 from git, with some patches applied
<cwillu_at_work> although experienced this under 2.6.32.1, only started playing with libpixman after I switched to that series, so I don't know about earlier kernels
<ssvb> cwillu_at_work: well, any kind of bad things may happen in general, also including xserver crashes on some occasions, so the bug is better to be fixed
<cwillu_at_work> do I only need that one patch, or do I also need patch 1/2?
<ssvb> they depend on each other, so both need to be applied
<cwillu_at_work> okay
<cwillu_at_work> re: input handling, that explains why it was so much worse when dragging a scroll bar than when using the mouse wheel
<cwillu_at_work> ssvb, this is only mildly related, but would you know what is required to gain any benefit from the neon routines in pixman?  Is a new cairo build also required?
<cwillu_at_work> (compiling a new kernel, will ping when it completes and I've tested it)
<ssvb> cwillu_at_work: just neon optimized pixman is enough, cairo upgrade is not required
<ssvb> cwillu_at_work: also pixman version 0.17.2 has more neon optimized functions and they are faster, git master has even more stuff
<cwillu_at_work> yep, I was compiling git master
<cwillu_at_work> among others... :p
<cwillu_at_work> should it be a dramatic improvement?
<cwillu_at_work> I'm mainly concerned with scrolling a firefox window at 1280x1024, and I haven't noticed a whole lot of difference
<ssvb> cwillu_at_work: what is the desktop color depth?
<cwillu_at_work> Which makes me inclined to think that firefox is either ignoring my efforts, or that I'm optimizing something that's only 1% of the problem anyway
<suihkulokki> ssvb: re: pixman and neon, is reading /proc/self/auxv really the best way to find out if the cpu supports neon?
<ssvb> suihkulokki: not sure about this, but it seems to work
<suihkulokki> yes, but it is a slight problem when run under qemu linux-user where that file is x86 auxv of qemu
<cwillu_at_work> ssvb, I've tried 16 and 24
<lool> suihkulokki: You can override glibc's hwcaps perspective though
<cwillu_at_work> sorry, missed the question while I was typing :p
<ssvb> suihkulokki: I see, but ARM CPUs unfortunately do not support any way to identify cpu type from userspace for the 'security reasons'
<lool> Wont help with pixman but can help with shared libs
<lool> suihkulokki: Perhaps qemu should provide an emulated /proc in some way though
<lool> Things like cpuinfo will be bogus as well
<ssvb> cwillu_at_work: firefox browser does all the rendering in 32bpp and converts the results to the desktop color format as the last step
<suihkulokki> lool: yeah, Qemu providing virtual /proc to apps running inside qemu would be the correct fix
<ssvb> cwillu_at_work: 32bpp is slow because memory bandwidth is limiting performance for most operations
<cwillu_at_work> ssvb, I was under the impression that 24 and 32bit were the same memory layout, and hence I didn't mention that I also tried 32 explicitly :p
<cwillu_at_work> ssvb, but should I expect to not see any improvement with the neon routines?
<cwillu_at_work> <cwillu_at_work> my kingdom for a firefox that uses 16bpp internally :(
<cwillu_at_work> ^^ is that basically the answer?
<cwillu_at_work> and if that's the case, would there ever be any chance of ubuntu's armel firefox getting patched?
<ssvb> cwillu_at_work: profiling scrolling in firefox 3.6 beta 5 looks more or less like this for me: http://pastebin.com/m669d1f7f
<ssvb> cwillu_at_work: looks like it is already 16bpp friendly
<cwillu_at_work> ssvb, as of 3.6?
<ssvb> cwillu_at_work: don't know, I just remember that this was not the case for firefox 3.0 and I had a simple patch for it
<cwillu_at_work> I'm on 3.5 right now, I'll install 3.6 and see if that improves things
<cwillu_at_work> ssvb, or do I just need to adjust my expectations?
<cwillu_at_work> i.e., is it fluid for you?
<ssvb> cwillu_at_work: but still arora browser is much faster than firefox for scrolling
<cwillu_at_work> I'm fairly reliant on a streamable xmlhttprequest in the browser, which is something of a gecko only thing
<ogra> suihkulokki, shouldnt that be possible through containers ?
<ssvb> cwillu_at_work: disregard the previous oprofile report, appears that for scrolling distribution of cpu time between graphics output and browser engine overhead heavily depends on how fast you are scrolling the page
<cwillu_at_work> rm /tmp/ssvb/hard_data
<ssvb> cwillu_at_work: this is a comparison of firefox vs. arara for scrolling with arrow down key pressed, firefox: http://pastebin.com/m6f334785 arora: http://pastebin.com/m9f98ed2
<ssvb> cwillu_at_work: arora feels much faster and it also spends almost half of the time in pixman, which firefox has a lot of other overhead
<ssvb> s/which/while
<cwillu_at_work> kernel just finished building, installing and retesting
<ssvb> cwillu_at_work: basically these profile reports show that arora benefits from pixman optimizations a lot more and the effect is much more easily visible
<ssvb> cwillu_at_work: great, let me know about the results
<cwillu_at_work> just rebooting now (wanted to update some other stuff at the same time, nothing like mixing experiments to save time :p)
<cwillu_at_work> for no particularly good reason, I've still got it booting into a 32bit framebuffer; if I understand you correctly, there's still a benefit to using 16, correct?
<cwillu_at_work> (running the test now)
<cwillu_at_work> hasn't stopped yet
<cwillu_at_work> unsurprisingly, scrolling is slow as hell while its running :p
<ssvb> cwillu_at_work: 32bit framebuffer is slower because there is more data to process, also display refresh steals some of the memory bandwidth
<ssvb> cwillu_at_work: what is your screen resolution?
<cwillu_at_work> ssvb, 1280x1024 :p
<ssvb> cwillu_at_work: ok, same here
<cwillu_at_work> the sigalarm testcase looks good, hasn't crashed yet
<cwillu_at_work> ssvb, with an otherwise idle cpu, is firefox smooth on your hardware?
<cwillu_at_work> I get about 3 frames per second
<cwillu_at_work> during full-screen scrolling
<ssvb> cwillu_at_work: it is *much* better for me, probably at least 10 frames per second
<ssvb> cwillu_at_work: but it is subjective impression, I did not run tests with camera
<cwillu_at_work> ssvb, 10 frames is just short of fluid, but still acceptable
<cwillu_at_work> ssvb, would be able to compare against ff-3.5 would you?
<ssvb> cwillu_at_work: it would take time to build ff-3.5
<cwillu_at_work> no apt-get? :p
<cwillu_at_work> rebooting under 16bpp
<ssvb> brb
<cwillu_at_work> <3
<ssvb> cwillu_at_work: any news?
<cwillu_at_work> performance seems to be respectable for a smaller scrolling region, I think I need to do some a/b tests to prove that they're actually better though
<cwillu_at_work> the glitching is definitely fixed by that patch, I've got it sent to my upstream, who grumbled about Russel being up to his usual self such that they were never applied
<cwillu_at_work> oh, hi rcn-ee, you joined :)
<rcn-ee> hey cwillu_at_work, so did the patches help with pixman? i haven't been able to test them myself..
<cwillu_at_work> rcn-ee, yes, I actually sent them after I had verified that they worked this time :)
 * bizkut is away (i am away now)
 * armin76 rofls
<armin76> ah, too bad lool is not here :D
<asac> ogra: you said you had a fix for apex?
<asac> http://launchpadlibrarian.net/36670366/buildlog_ubuntu-lucid-armel.libgd2_2.0.36~rc1~dfsg-3.1ubuntu1_FAILEDTOBUILD.txt.gz
<asac> http://launchpadlibrarian.net/36947837/buildlog_ubuntu-lucid-armel.libgphoto2_2.4.7-0ubuntu1_FAILEDTOBUILD.txt.gz
<asac> NCommander: you have buildd powers?
<asac> e.g. can you give back with good prio?
<asac> last build failure might be just fixed?
<asac> hmm libtool still ftbfs
 * asac kicks off a build
<NCommander> asac, yeah, I can do that
<NCommander> asac, which package needs a nudge
<armin76> NCommander: nageia is the buildd that doesn't do anything :)
<asac> NCommander: nevermind. thought libtool wasnt retried
<asac> NCommander: dove images broken/not booting? or just test builds?
<NCommander> asac, the issue was that I didn't notice that we haven't had an alternate build in almost a month. cjwatson looking at antimony to see what went wrong
<ogra> asac, http://paste.ubuntu.com/351393/
<ogra> (it doesnt respect CFLAGS)
<ogra> but that only fixes the initial build failure, at the end it fails with a cast error in link.cc
<ogra> well, "link.cc:236: error: invalid conversion from 'const char*' to 'char*'"
<ogra> anyway, off again
<asac> ogra: what context?
<ogra> apex
<ogra> you asked for my apex fix
<asac> ogra: kk
<asac> i can check
<asac> ogra: if still there ... why -marm? is that a workaround or the right fix?
<ogra> apex is a bootloader for armv5
<asac> oh ;)
<ogra> and doesnt have any thumb support
<asac> yeah
<asac> makes sense
<asac> ogra: why is it in main?
<ogra> it is used for the nslu2
<ogra> that was our first supported armel arch before wer had any HW
<asac> guess we dont support it anymore?
<asac> e.g. we should unseed/demote it ;)
<ogra> it can happily go to universe, but i feel bad if i demote it in that state
<asac> sure
<asac> should be fixed
<ogra> yeah ... would feel like dumping trash on the MOTU
<asac> ogra: do you know if its seeded or why it didnt get demoted in karmic?
<asac> we want to fix all universe armel only failures too ;)
<asac> just that we start in main as its on top of that webpage ;)
<ogra> it didnt ftbfs and nobody had it on the radar
<ogra> probably my fault since i cared for it in jaunty and didnt look after it later
<asac> ogra: well. but afaik it shows up in component-mismatches unless its pulled in thorugh some mechanism
<asac> just wnat to understand what is that ;)
<asac> but no hurry
<ogra> i think its just seeded in supported
<ogra> that makes it not show up on the mistmatches page
<asac> dyfet: checked chrome?
<asac> kk
<dyfet> asac: not extensivily but it works
<dyfet> asac: and feels fast(er)...
<dyfet> or did you mean chromeos rather than chromium browser?
<asac> nope
<asac> our packages
<asac> good
<armin76> thanks to me *g*
<dyfet> asac: since it imports, I dumped my mozilla directory onto the box and let it try to import my bookmarks and passwords, it did not seem to import my passwords entirely though...
<asac> dyfet: entirely? but parts?
<dyfet> yes
<asac> dyfet: any pattern what got imported and what not?
<asac> maybe compare what you see in show passwords in ffox and chromium
<dyfet> I am not sure, but they were all form based, and it happened to be one site it only filled the email/login id, not the password field
<dyfet> but again I did not go through very many sites with it yet
<asac> ok. if in doubt i would start comparing the show passwords dialog in preferences of firefox/chrome
<asac> maybe its a bug about detecting password/input fields
<asac> or something
<dyfet> asac: it feels like there is more in my firefox saved passwords...in fact, there is some I can already confirm are missing
<asac> JamieBennett: there still?
<JamieBennett> asac: yes
<asac> JamieBennett: someone claimed that n.b.l-efl isnt localized ... e.g. like the applications and categories etc.
<dyfet> asac: never mind, I found the ones I thought were missing :)
<asac> good :)
<asac> JamieBennett: can you confirm that thats the case in our lucid build?
<JamieBennett> asac: ummm, not sure, not something I've looked into but I can check
<asac> that would be great
<asac> JamieBennett: how do one best try the launcher? does it just show up as a session variant in gdm?
<JamieBennett> When I installed it I just ran it from the command line
<JamieBennett> asac: It seems that it is localized, most strings come from the .desktop. lfelipe has tested and can confirm along with k-s
<asac> JamieBennett: ok. is sound recorder localized?
<asac> like in chinese?
<JamieBennett> no idea ;)
<JamieBennett> I use neither :D
<asac> JamieBennett: so you say you confirmed it by starting in a different language?
<asac> (on your own?)
<JamieBennett> asac: I confirmed it by asking the developer, I can play around with the local install I have if you need that but lfelipe says he can provide up-to-date screenshots for anything we need
<JamieBennett> k-s also confirmed
<asac> confirmed by running or by thinking ?
<asac> i am find if they say they run lucid packages and all is there
<asac> its just that we got a report about this ;)
<asac> s/find/fine/
<asac> so developers saying "it should work" ... might not be right approach ;)
<cwillu_at_work> I find your lack of faith disturbing
<asac> faith?
<cwillu_at_work> "it should work"
<cwillu_at_work> therefore:  it should work.
<cwillu_at_work> (I'm done now :p)
<asac> yes. but if there is a complain about it not working, its ok to double check :)
<JamieBennett> I don't have a lucid desktop install at the moment, I'll set one up (its on the todo list for today anyway)
<asac> JamieBennett: no need to if you dont have the infrastructure to check. just thought you had all in place
<JamieBennett> asac: not in a Lucid environment yet, something I will fix tonight
<asac> hehe
<asac> i should upgrade too
<asac> e.g. ~end of jan
 * bizkut is away (i am away now)
<asac> bad away messages ;)
<asac> dyfet: so did you check the moblin media player?
<armin76> haha
<armin76> where's lool!
<armin76> !seen lool
<ubot4> I have no seen command
<asac> armin76: he left this channel
<armin76> bah, useless bot
<armin76> well, he just dissapeared in a net split :)
<asac> yes.... so he left the channel
<asac> because whereever i am is the main channel :-P
<asac> armin76: so did you finally manage to get something usable wrt chromium?
<armin76> asac: nah, segfault when building v8
<armin76> i'll try building on my armv7 board, but i'm busy building other stuff
<armin76> thats what happens when you only have one board :)
<armin76> could be that either something is broken or that doesn't build on armv5te
<armin76> asac: build it on jaunty :)
<NCommander> asac, I thought we had a working chromium on ARM ...
<asac> NCommander: we have ... armin76 doesnt
<armin76> :D
<armin76> NCommander: he's using an ugly patch though!
<NCommander> armin76, ?
<armin76> NCommander: asac is using an ugly patch to make it work :)
<armin76> s/work/build
<asac> hey. i have the right one ... just need to check
<mturquette> could someone point me to the apt repositories for the dove and babbage boards?
 * armin76 points to asac and NCommander 
<armin76> NCommander: btw meet mturquette, he wants ubuntu rocking on omap
<NCommander> mturquette, its just the normal ports repo for bost
<asac> mturquette: http://ports.ubuntu.com/ubuntu-ports/
<asac> deb http://ports.ubuntu.com/ubuntu-ports/ lucid main restricted
<asac> deb-src http://archive.ubuntu.com/ubuntu lucid main restricted
<asac> etc
<mturquette> ah, makes sense.  thanks NCommander / asac.
<armin76> mturquette: yw :)
#ubuntu-arm 2010-01-05
 * bizkut is away (i am away now)
 * persia fantasises about a bot that automatically parts clients from a channel after N repeated verbose away messages without intervening intentional traffic
<brian_> any openmkok owners here?
<brian_> openmoko
<persia> brian_: sometimes, although not often, as most OpenMoko devices need ARMv4
<brian_> ic
<brian_> arm 7 now
<persia> Cool!
 * persia goes off to read all about it
<brian_> :)
<persia> Hrm.  I can't seem to find a good link on the openmoko wiki :(
<armin76> :D
 * armin76 is away (*g*)
 * armin76 kicks zumbi 
<cwillu_at_work> what's new in arm land?
<persia> From the current meeting in #ubuntu-meeting, it looks like .32 kernels should drop soon.
<cwillu_at_work> drop == land?
<persia> Yeah.
 * persia digs up the link
<cwillu_at_work> drop typically means the opposite :p
<persia> http://kernel.ubuntu.com/git?p=marvell/dove-kernel/.git;a=shortlog;h=refs/heads/marvell-dove-2.6.32.2
<persia> It's often worth dropping into #ubuntu-meeting at 13 UTC on Tuesdays, as a bunch of folk working on ARM stuff tend to talk about current status.
 * cwillu_at_work makes a note
<cwillu_at_work> 13utc is a bit on the early side for me, but yep
<ogra> you are here now, no ? :)
<cwillu_at_work> coffee is still flowing in
<cwillu_at_work> my mental capabilities are still sub-html
<cwillu_at_work> I need them to be at kernel in half an hour
<cwillu_at_work> this might be a Documentation Day.
<ogra> heh
<asac> GrueMaster: thanks for pushing the patches up ... is https://code.edge.launchpad.net/~gruemaster/lsb-arm-port/main the latest and greatest?
<NCommander> asac, I think I found the problem with libtool
<NCommander> /usr/bin/ld: .libs/hello.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC :-)
<NCommander> Martyn, ping?
<asac> NCommander: who is Martyn ?
<NCommander> asac, resident ARM guru who can confirm a theory of mine. dmart isn't around or I'd ask him as well
<NCommander> asac, its possible our toolchain simply doesn't support non-PIC shared libraries on ARMv7, and thus libtool needs to be taught that test can fail safely
<asac> NCommander: afaik we need PIC
<NCommander> asac, thats what I thought, but ARMv6 and earlier supported non-PIC shared libraries
<NCommander> asac, the situation is more complicated that debian/rules forces in arm-linux-gnueabi as the compiler triplex
<asac> NCommander: so thats a non-PIC test? meaning: we should disable the test?
<NCommander> asac, yeah, thats the case. I can just modify the test so when it sees ARM, it skips the npic test, although that's not going to be acceptable for upstream
<Martyn> I am around
<Martyn> Sorry, had to step away from the keyboard, was doing some FastModel work
<NCommander> Martyn, what do you know about non-PIC shared libraries on ARMv7?
<Martyn> non-PIC on arm should be supported in v7
<NCommander> Martyn, the toolchain doesn't seem happy about it though
<Martyn> Then there is a bug in the toolchain
<NCommander> Martyn, woo.
<Martyn> In fact it's absolutely required on the snapdragon based cellphone platforms (read: Droid)
<NCommander> Martyn, non-PIC shared libraries?
<Martyn> jump onto an Android dev channel, and see if their prepackaged toolchain fails too
<NCommander> Martyn, non-PIC binary objects work, its just an issue when you build a .so
<Martyn> Hrm
<Martyn> Not good
<NCommander> Martyn, well, most shared libraries are PIC
<NCommander> Martyn, the only issue this came up is because the libtool torture test blew up on armv7 when trying to build a non-pic library
<Martyn> *nod*
<Martyn> Well, I guess I'd have to agree .. drop the test for now
<Martyn> and report it upstream for investigation
<NCommander> asac, debdiff on the way :-)
<NCommander> asac, https://bugs.edge.launchpad.net/ubuntu/+source/gcc-4.4/+bug/503448
<ubot4> Launchpad bug 503448 in gcc-4.4 "[arm] building non-PIC libraries fails under ARMv7 mode" [Undecided,New]
<asac> NCommander: so is libtool blocked on that or do we want to disable that test on armel for now?
<asac> can you check if gcc-snapshot helps?
<NCommander> asac, lets disable for now, and keep our eye on it
<asac> (if there is a build available)
<NCommander> asac, will do
<GrueMaster> asac: Yes, the LP code is the most current (from my stuff) so far.
<asac> cool
<armin76> nice, dove support made it to mainline
<armin76> rabeeh: i want one
<armin76> oh well, its just v6
<lool> armin76: dove can work in v6 and v7 mode
<armin76> lool: yep, but the one in the kernel only is armv6
<NCommander> armin76, link?
<armin76> NCommander: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=edabd38e1a017e922e3e3b485ee3ddb4df433aa4 && http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=arch/arm/mm/Kconfig;h=1549863d7b54564b131d2f415815d51b68c6057b;hp=9264d814cd7a9db1f5a5d0901fc62e81fa921aa0;hb=edabd38e1a017e922e3e3b485ee3ddb4df433aa4;hpb=8d27b2f7988b652dbabf79291a3e2550c06e1af5
<NCommander> That's freaking awesome
<armin76> why?
<NCommander> armin76, having a kernel mainline solves a *lot* of issues
<armin76> whats the point if its not the proc you're interested in? :)
<NCommander> armin76, huh?
<NCommander> armin76, dove is the platform that you were using over IPv6 in my apartment
<armin76> NCommander: yes, but your boards are armv7
<NCommander> All dove boards are ARMv7
<armin76> NCommander: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=arch/arm/configs/dove_defconfig;h=f2d1ea0abb849a7402d03ba688adaacb6f03b5d8;hb=edabd38e1a017e922e3e3b485ee3ddb4df433aa4 <- this board uses v6
<NCommander> armin76, ?
<NCommander> armin76, ah
<NCommander> armin76, *shrug*
<armin76> fail :)
<armin76> NCommander: the commit that added dove support(first link i pasted) only touches armv6
<armin76> and you've seen the defconfig now
<armin76> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=patch;h=edabd38e1a017e922e3e3b485ee3ddb4df433aa4 <- commit
<suihkulokki> new toy for armin76 to whine for ;)  http://www.engadget.com/2010/01/05/marvell-plug-computer-3-0-packs-in-wifi-bluetooth-and-2ghz-arma/
<armin76> *g*
<armin76> suihkulokki: hope it doesn't come with ubuntu :P
<armin76> (and the proc is v5)
<armin76> looks like they left 2.0 on the road *g*
#ubuntu-arm 2010-01-06
<JamieBennett> Anyone around to take a look at a boot chart output from the ARM live-cd? Casper is the obvious cause of major slowness and I've documented it at https://wiki.ubuntu.com/ARM/LiveCDSpeedup#Casper, after Casper I can't see many worth-while wins though. Link - https://wiki.ubuntu.com/ARM/LiveCDSpeedup#BootChart
<ogra> looks like adduser and the keyboard stuff are the worst
<JamieBennett> ogra: yeah, all due to debconf-communicate
<ogra> adduser is taking 10sec !
<ogra> err
<ogra> 30, sorry
<persia> JamieBennett: Did you ever track down precisely why debconf-communicate is acting so slow?
<ogra> JamieBennett, try adding a sscript that calls debconf-coomunicate
<JamieBennett> ogra, persia: done and the findings are on the wiki page I liked to.
<ogra> something that sets only one value and see if that also uses 30sec
<ogra> i suspect thats a fixed value we see there
<persia> JamieBennett: Hrm?  In the "Conclusion" section, or somewhere else?
<ogra> i.e. each call to debconf adds 30sec
<persia> I'm seeing clear indication that it *is* debconf-communicate, but I still don't understand why there is a performance skew when compared to other architectures.
<JamieBennett> ogra: each call to debconf-communicate takes 4 seconds due to loading templates.dat via perl code
<ogra> what about the other 26 ?
<JamieBennett> ogra: where are you getting 30 secs from?
<ogra> oh, i only looked at the kbd stuff, adduser simply calls it multiple times
<JamieBennett> Yes - https://wiki.ubuntu.com/ARM/LiveCDSpeedup#19keyboard
<ogra> well, twice actually
<JamieBennett> ogra - 5 times - casper-preseed calls debconf-communicate
<ogra> i only see it twice in adduser
<ogra> at least in the chart
<persia> ogra: The detailed breakdown of the adduser case is above.
<ogra> above what ?
<persia> a 7-sec call to debconf-communicate, wondering about in user-setup-apply (which talks to debconf a lot), and then a final 4 seconds in another debconf-communicate.
<persia> Above the chart on the wiki page.
<JamieBennett> ogra: are you talking adduser or keyboard?
<ogra> adduser
<ogra> only looking at the bootchart
<JamieBennett> ah, yes thats two calls
<JamieBennett> keyboard is 5
<ogra> the chart shows only one very long one
<persia> JamieBennett: Are you *sure* there's no debconf-communicate in user-setup-apply?  I thought I remembered a fair bit.
<ogra> for kbd
<JamieBennett> persia: maybe, I can investigate.
<asac> ogra: persia: so continuing discussion on the our ACTION to document what needs to be backported from .32
<ogra> right
<asac> to .31 kernel
<ogra> i see aufs and apparmor as critical
<persia> JamieBennett: What I'm most curious about is *why* perl is so slow at reading that cache on armel.  I suspect there's a deeper bug that would be nice to address with lots of improvements all over.
<asac> how should we do this
<asac> ?
<asac> do we already know the areas where we need backports?
<ogra> make a list of kernel features we knoe
<ogra> *know
<asac> akk?
<asac> all?
<asac> that feels bad ;)
<ogra> no
<JamieBennett> persia: lool had some thoughts about perl slowness, I'll talk to him to see if he has investigated it at all
<ogra> all that are developed inhouse
<asac> ok brainstroming :)
<asac> you say aufs and apparmor ...
<persia> Could we simply compare the kernel-generated header files for .31 and .32, and backport stuff where the API has changed?
<asac> i remember persia mentioned ureadahead or something
<ogra> ogra@osiris:~/Desktop/uboot/package/uboot-imx-2009.08$ ls /lib/modules/2.6.31-14-generic-pae/kernel/ubuntu/
<ogra> aufs  compcache  dm-raid4-5  drbd  iscsitarget  lenovo-sl-laptop  lirc  misc  ndiswrapper  rfkill
<persia> Mine were more userspacey, like ALSA and bluetooth.
<ogra> i guess we can ignore the lenovo stuff :)
<ogra> and ndiswrapper
<asac> so why are we looking at kernel/ubuntu only?
<ogra> we dont
<persia> asac: How do you mean?
<ogra> but thats the easy and obvious part
<asac> yeah
<asac> ok
<ogra> we surely need to add stuff that happens inline in the kernel, plus what persia said
<ogra> though i think the alsa HW specific stuff isnt that intresting
<ogra> we dont need intel fixes on arm :)
<persia> What is interesting is keeping sync between userspace and kernelspace interfaces.
<asac> persia: we could check the header approach, and see if we get useful results.
<ogra> right
<persia> I don't care about the individual bits of hardware, but I do care if something moved in ALSA, and sound doesn't work.
<persia> Most ARM hardware should be using ASoC anyway.
<persia> asac: To do that, should we generate linux-headers-2.6.31-foo out of the ARM kernel sources, or do you think there are other sources of API changes?
<asac> hmm. are linux-headers really the headers exported to userspace?
<asac> not linux-libc-dev ?
<persia> Well, both are exposed, actually.
<asac> really?
 * persia goes to read up on stuff
<asac> i thought linux-headers was just for kernel modules
<asac> apt-cache show linux-libc-dev
<ogra> stop ...
<persia> Right.  Sorry.  I was confused by "linux-kernel-headers" which was an old name for linux-libc-dev
<asac>  This package provides headers from the Linux kernel.  These headers
<asac>  are used by the installed headers for GNU glibc and other system
<asac>  libraries. They are NOT meant to be used to build third-party modules for
<asac>  your kernel. Use linux-headers-* packages for that.
<ogra> we had that discussion multiple times
<ogra> thats a kernel team job
<asac> ogra: what do you mean?
 * ogra tries to find the mail with the discussion about linux-headers vs libc-dev
<ogra> asac, armel is a special case
<ogra> and it took us weeks to agree on a specific setup everybody was happy with
 * persia isn't entirely convinced it's safe to special-case headers against which userspace is built.
<ogra> i know apw summarized it, i cant find it atm
<ogra> persia, i think we need to use linux-kernel-headers-*SoC* for our stuff iirc
<ogra> but i need the notes
<apw> the email was titled
<apw> Subject: arm headers issue
<persia> apw: To which list was it sent, and about when?
<persia> Anyway, I thought linux-libc-dev *replaced* linux-kernel-headers some time back.
<apw> it was sent to a few people direct
<persia> Ah, tricky those.
<ogra> apw, gracias, got it
<ogra> asac, forwarding to you
<apw> i don't recall it being contentious, just not interesting to the general reader in the raw form it was
<ogra> yeah
<ogra> but important knowledge if you work on armel
<ogra> and surely important to know for asac who became our fearless tech lead now ;)
<persia> But the summary was that there are linux-kernel-headers-${SoC} packages being built that are just like linux-libc-dev except for the different ARM kernels?
<ogra> persia, forwarded to you too
 * persia likes smart search tools that automatically update
 * persia is still confused
<persia> Is this just about arm-specific headers, or *all* headers?
<ogra> arm
<apw> its presumably about apps needing vile arm specific driver headers
<persia> That's completely different from what I'm looking for.  Let's call that solved for now (for all that I think it's a bit of a mess)
<ogra> right
<persia> I was looking to compare linux-libc-dev from the SoC kernels to linux-libc-dev in the master kernel.
<persia> Where those differ, we have a candidate problem.
<ogra> persia, that counts in SoC specific userspace API libs
<persia> Right, I don't care about backporting any of that stuff.
<ogra> right, you cant
<persia> right :)
<ogra> since linux-libc-dev on armel comes from the main source
<apw> linux-libc-dev for armel ... what he said
<persia> Right, so like I said, shall we have the SoC kernel sources provide linux-libc-dev-${SoC} for comparison purposes?
<ogra> apw, hmm, how do you handle that with the .32 vs .31 issue btw ?
<persia> And then if we find discrepancies, backport what we need.
<ogra> persia, no
<persia> Why not?
<ogra> read the mail :)
<ogra> colin will slay you
<apw> ogra, we don't
<persia> This is *completely* unrelated to the mail.
<persia> The mail is about SoC-specific headers.  I'm talking about general headers.
<persia> I don't expect them to be used by anything: I just want them for reference.
<persia> If anything builds against them, we failed.
<ogra> apw, evil ... what if vendors build stuff based on linux-libc-dev ? it will likely be boroken
<persia> We can put ***DON'T USE THIS***  **YOUR APPLICATION WILL FAIL*** in the description.
<apw> arm is in a world of pain by refusing to be at the same version as the rest of the system
<apw> we are assuming some level of compatibility between releases and literally crossing everything
<persia> apw: Well, we're hoping to avoid some of that with backporting.  For instance, backporting ALSA should be relatively painless.
<apw> its already backported for non-arm so i assume so
<persia> Right :)
<ogra> apw, well, i'm more concerned about things like aufs
<persia> The trick is to determine what needs to be backported to avoid pain.
<ogra> we need it for image builds
<apw> i don't think there is any headers for aufs
<ogra> how about apparmor
<persia> ogra: So, what objection do you have to comparing the generated linux-libc-dev for each kernel type?
<apw> included in the linux-libc-dev package
<ogra> persia, there is no linux-libc-dev for each kernel type
<persia> But there could be :)
<apw> not sure we include those either
<ogra> ther is only one and that comes from the upstream source
<ogra> and the archive admin team is strictly against having more than one
<persia> Fine.
<ogra> read the IRC discussion in the mail
<apw> we can't have more than one, as the archive can only be built for one armel form
<persia> I did.  You aren't understanding what I'm saying.  I'm not talking about the same thing from the mail.
<apw> and its that process that consumes the package
<persia> But I don't care to argue that: I'll find a workaround.
<apw> have we hit an issue with our assumptions here, or are we worryng about the future
<persia> apw: We've lost track of the discussion.
<persia> The agenda item was to try to identify what shoud be backported into .31 kernels to make sure lucid works with them.
<persia> Our inital guess was  aufs  compcache  dm-raid4-5  drbd  iscsitarget  lirc  misc rfkill + alsa + bluetooth
<ogra> whateve misc is
 * ogra takes a look in the dir
<ogra> /lib/modules/2.6.31-14-generic-pae/kernel/ubuntu/misc/fsam7400.ko
<ogra> description:    SW RF kill switch for Fujitsu Siemens Amilo M 7400
<apw> my understanding is that aufs is 'compatible' between the two semantically
<ogra> not for us
<apw> apparmor userspace i believe is aware it may be using two differenet kernels
<persia> apw: We've had a lot of issues with aufs version skew in the past, and have little trust.
<ogra> apw, right, but we need to make sure that all the inhouse developed features the kernel team develops work
<ogra> thats why my main issues are aufs and apparmor ... but you answered for both, so i personally am happy
<ogra> compcache and dmraid are surely also important to have working
<ogra> not sure about lirc rfkill or iscsitarget
<persia> rfkill is likely useful, as lots of devices have wireless.
<ogra> but do they have the HW that supports rfkill ?
<persia> lirc falls into the alsa/bluetooth category for me: if we don't do it, classes of devices won't work.
<ogra> the babbage doesnt have wireless per se
<ogra> and we actually only talk about babbage here
<ogra> dove is on .32
<ogra> did we lose asac ?
 * persia installs wireless-tools to see if rfkill works on at least one i.MX51-based device
<asac> no
<asac> reading thta long mail atm ;)
<asac> so from what i understand comparing headers doesnt make sense
<asac> its supposed to be not broken in that way
<asac> so lets focus on the core ideas we had:
<asac> a) figure out which "ubuntu" features were added in .32/lucid
<asac> -> review and make a list of what parts we want from those
<persia> Erm, what?
<ogra> right
<asac> b) try to find some good targets to look closer:
<asac>  e.g. what kernel improvements were done for boot perf.
<ogra> which of them didnt go upstream
<asac>  -> and check if we need those ->
<ogra> we surely do
<ogra> unless we stop caring about bootspeed suddenly
<asac> ogra: didnt go upstream in .31 ... given that we had .31 in karmic, nothing went upstream for us (fsl)
<asac> that was done in lucid
<ogra> right
<asac> i double checked with dtchen back at UDS ... he said, that sound wont be a problem in that we will see regressions over karmic experience
<asac> ...however, we might not see improvements obviously ...
<asac> but i think we can live with that
<ogra> yeah
<ogra> as long as noise still comes out of the speakers :)
<asac> so lets scratch sound from the backporrting candidates unless we find real bugs
<asac> right
<asac> QA would hopefully catch that
<persia> Note that he has already backported the latest ALSA stuff to .31 in a PPA, so it should be fairly painless to integrate.
<asac> if fixes are available we are probably happy to pull them in
<asac> -> lets note that as an option/action
<asac> do we know anything besides boot performance kernel changes and sound?
<ogra> apw, what looks important to me wrt bootspeed are the patches from csurbhi
<ogra> apw, do you see any issues with these to go into a .31 tree ?
<asac> cooloney: there?
<asac> cooloney: what ubuntu specific kernel stuff that is in .32 wont be in our .31 kernel?
<asac> maybe we automatically get everything?
<apw> ogra, those were pretty simple patches, but do we have a bootspeed issue on arm?
<ogra> apw, bootspeed is always an issue, yes
<persia> Well, looking at the bootchart we were discussing earlier, we're running at somewhere under 195 seconds right now.
<ogra> apw, if we have any improvement in the main distro they should definately go into arm
<ogra> persia, thats livefs :)
<persia> ogra: So? :)
<ogra> my babbage boots lucid in about 50sec
<persia> Still, a fairly long time.
<ogra> or 45
<ogra> yes, but not 195 :)
<ogra> lets stay with apples vs apples
<persia> But yeah, we'd like that faster.
<asac> i agree that the kernel tweakage currently done for i386 is not really our major concenr
<asac> but i hope we get the big time consumers removed and then it might be more important
<ogra> asac, even if it gains us several seconds in bootspeed ?
<asac> so being prepared is good
<persia> My concern is things not working because of kernel/userspace interface changes, more than small improvements.
<ogra> bootspeed is definately a vendor concern we har all the time
<persia> Small improvements are nice, but the kernel is outdated, and deserves to suffer a bit.
<ogra> *hear
<asac> persia: i dont think we can understand that up-front fully.
<asac> we can only figure that out through bugs later on
<asac> ogra: yes. but we have 195 secdons. most of that is probably not related to anything done in the .32 kernel
<asac> which is tuning it to get the last few seconds removed from i386
<ogra> asac, yes, but the 195sec are live images
<ogra> asac, has nothing to do with this discussion
<persia> asac: Well, hrm.  I have suspicions about stuff like bt, alsa, lirc, ieee1394, etc.  We had lots of issues with intrepid when the version skewed unexpectedly.
<persia> But I'm not sure our test coverage is broad enough to catch all that (because it wasn't for i386 for intrepid)
<asac> persia: dtchen said alsa isnt a problem for older kernels
<ogra> asac, the 45-50 sec for instealled systems *are* an issue for this discussion though
<asac> ogra: yes. but live image is similarly important. thats the first impression users get
<persia> asac: Does that presume a separate alsa-modules package?
<asac> ogra: not really sure where the problem is. i am all for looking at what was done and what can be pulled into .31 for bootspeed
<ogra> asac, but they are no kernel related issues
<ogra> asac, right ... i'm only talking about the installed system here ... the live issues are all casper related
<asac> ogra: right. but did we analyze our 45 seconds on installed images yet?
<ogra> nope
<asac> maybe its half of the time in something similar
<ogra> nope
<persia> Um, those two "nope"s are mutually exclusive: without analysis there's not enough information for the second answer.
<asac> you say that userspace is well tuned?
<ogra> we dont call things like debconf-communicate anywhere in installed systems
<asac> ogra: still. for me its currently a blackbox
<asac> also on liveimages only 50 seconds or so are deconf-communicate
<ogra> http://people.canonical.com/~ogra/babbage2-karmic-20090916-3.png
<ogra> there is a karmic bootchart
<persia> Well, more than that.  there's about 35 seconds in just 10adduser and 19keyboard
<ogra> speed issues there are totally unrelated to the speed issues on the live boot
<asac> anyway. thats not the point
<persia> No.
<ogra> right
<ogra> but what i say is that we want kernel improvements backported if they can gain us a few secs
<asac> ogra: how can you say that its unrelated without having analysed it
<asac> anyway, as you might know JamieBennett is our boot speed master this cycle ;)
<persia> I think we should be focusing on SoC-specific performance enhancements with SoC-specific kernels, rather than worrying about backporting.
<ogra> i.e. if we can get from 41 to 31 secs through them ... plus gain another 5 secs through ureadahead that is definately something we want
<JamieBennett> :)
<asac> so maybe he should take the action to work on it ... including figuring what kernel parts would be beneficial
<ogra> asac, ++
<asac> ok. lets do that then. doesnt make sense to speculate
<persia> Indeed.
<ogra> asac, i have analyzed it in so far that i took bootcharts every release
<ogra> but didnt have any time to look for possible improvements or to dig deeper
<persia> Do we run any perl during boot?
<asac> so bootspeed is covered ;) ... JamieBennett will work with whoever want to peer on that on a) identifying kernel patches to backport, b) identifying userspace bottlenecks in both: install and live image
<JamieBennett> OK
<JamieBennett> /me scrambles to read backchat to see what I have volunteered to do
<ogra> JamieBennett, so please talk to csurbhi, if it makes sense to backport their patches to us
<asac> JamieBennett: basically the last line i said ;)
<ogra> s/their/her/
<JamieBennett> ogra: OK
<asac> 11:57 < asac> so bootspeed is covered ;) ... JamieBennett will work with whoever want to peer on that on a) identifying kernel patches to backport, b) identifying  userspace bottlenecks in both: install and live image
<persia> JamieBennett: IN summary: analyse bootspeed of installed armel systems, compare against other architectures, and optimise.
<JamieBennett> yep
<ogra> thats a tough comparison :)
<persia> Yep :)
<ogra> given your HW is likely slowing it down
<ogra> like disk etc
<ogra> but well
<persia> Well, but simple HW issues scale, but if most stuff is 2x and one thing is 10x, that thing needs attention.
<ogra> lets go back to the actual discussion
<asac> i dont think we can really compare it
<asac> maybe to identify stuff that takes relatively long
<asac> ok ... so lets move on ... bootspeed is covered ;)
<persia> Right.  That's the extent of the potential for comparison.
<asac> now ... areas of potential userspace breakage:
<asac> mentioned were:
<persia> For *-modules, we just have to make sure that it can be built properly.
<ogra> as apw said, aufs and apparmor should just work
<asac> alsa, bt,  lirc, ieee1394
<ogra> dmraid
<asac> i can take the action to sync with jdstrand on what innovation we might want for apparmor
<asac> (and whoever does that on kernel side )
<ogra> compcache (very important)
<asac> whats your concerna bout compcache?
<persia> rfkill drdb ?
<asac> general breakage i presume?
<ogra> yes
<asac> we are currently at "user space brekage";)
<ogra> we should have the same upstream version in .31 lucid as in .32 lucid x86
<asac> isnt compcache covered by kernel/ubuntu investigation?
<ogra> since the live images 100% rely on it working
<ogra> yes, its in kernel/ubuntu
<asac> which i had hpoed we could put on cooloney's plate ... mission: get as many goodies for ubuntu specific stuff from .32 to .31 as possibe
<ogra> right
<asac> ok .... so lets assign this action to him.
<asac> a) make a list of stuff that changed for kernel/ubuntu in .32
<ogra> ok, that only leaves sound and apparmor
<asac> apparmor i took the action to check what innovation we might want
<ogra> right
<persia> sound is likely mostly safe to leave alone.  People who *really* care can get modules separately.
<asac> sound was already covered imo, but i can also check with dtchen directly what he thinks should be done
<asac> if he has patches ready for consumption that are safe, i dont see why we should not pick them
<persia> Heh.  590 headers files differ between linux and linux-fsl-imx51
<asac> ;)
<ogra> right, so: bootspeed->Jamie, kernel/ubuntu -> cooloney, sound-> dtchen, apparmor -> asac ...
<ogra> anything we forgot ?
<persia> Lots of drm changes: we don't care about any of that, right?
<ogra> unlikely
<persia> bt, lirc
<ogra> lirc is in kernel/ubuntu
<asac> ogra: sound -> asac (with dtchen)
<ogra> right
<ogra> persia, so do yu take bt ?
<persia> Sure, although I'm going to be limited to source-inspection.  I may have to lean on others to help with any testing.
<ogra> well, grab a kernel guy for help :)
<asac> for now we want to investigate
<asac> and then we meet after alpha-2 to discuss the final actions i guess
<asac> and present results
<ogra> yep
<ogra> well, some bits need to happen pre A2
<asac> is there any area that we know is currently breaking us?
<ogra> at least aufs needs to work
<ogra> no, we dont
<asac> e.g. is anthing of the above urgent for a2
<ogra> since we havent seen te3h .31 kernel yet
<asac> ok... aufs is kernel/ubuntu
<asac> anything else?
<ogra> we can do definitive stuff only if we actually have the new kernel
<asac> ogra: why arent we seeing issues with aufs now if its needed for a2?
<ogra> well, as apw said, it shouldnt have issues
<asac> for now, lets hope that stuff that works atm, will work with the new kernel
<asac> right
<ogra> but you cant say until you see the real thing :)
<asac> we are talking about actions and urgencies, so fixing aufs is not urgent until we know its broken :)
<asac> sure
<ogra> we are talking about hypothetical stuff atm
<persia> Seems that linux-fsl-imx51 headers are rather different for bluetooth :(
<asac> but i would hope that all stuff urgent enough for a2 target would be breakage of images
<asac> and would be covered by all other mechanims
<asac> ogra: yes. thats why i dont think that anything of the stuff we talked about has to happen for a2 atm
<persia> I'd agree that urgent stuff would be covered in other ways.
<asac> until we get to know of breakage ;)
<ogra> right
<persia> This is more that we need to be solid pre-beta, and need a head start.
<asac> what we are doing here is an proactive effort to improve the overall quality of our final release
<asac> yep
<asac> persia: want to send out actions we deferred from this with me/ogra/jamie CCed?
<asac> and colooney
<persia> Why CC, rather than addressee?
<asac> hehe
<asac> yes. TOed
<persia> Sure, although I want to dig out of my current stack of stuff first.
 * asac wonders what that is ;)
 * ogra hands persia a ladder
<asac> my current stack of stuff == all the clothes that wait for a laundry here ;)
<asac> or rather: my board buried under heaps of dirty socks ;)
 * persia has ~20 windows opened during this discussion that need to be closed after extracting the key bits while knowledge is fresh: actions are logged in lots of places to grab in some minutes.
 * ogra fights with uboot
<asac> most likely those 20 windows opened on the sharp thing ;)
<ogra> lol
<persia> No, only 4 windows on the Netwalker during the past hour discussion :p
<persia> (mostly terminals to check stuff)
<asac> anyone running lucid already?
<asac> on main desktop?
<asac> is sound working?
 * asac scared that voip/softphone will be completely brokenish when i upgrade now ;)
<persia> Should be: lots of people report that it is.
<persia> Try a liveCD first :)
<ogra> asac, cjwatson upgraded on monday i think
<ogra> no idea if he uses any VoIP though
<asac> most likely not. i have the feeling i am the only one, given how broken all softphones are ;)
<asac> at least for real callout voip
<asac> most apps seems to close the sound stream and open quickly when the call gets dispatched ... this yields random on/off for output/input for the final connection
<asac> if you use pulse
<persia> ogra: Am I reading backscroll correctly that you're not researching anything?
<asac> ogra will be peer for boot performance and the kernel/ubuntu stuff
<ogra> i said i didnt
<persia> asac: pulse and ekiga always work nicely together for me.  Dunno which softphone you use.
<ogra> simply because it was to late in the former releases to do anything about it anyway
<JamieBennett> asac: lucid killed my laptop yesterday
<asac> persia: ekiga is really really busted ;)
<JamieBennett> won't boot now
<ogra> we had no kernels until mid release
<asac> persia: are you doing callout?
<persia> asac: Define "callout".
<ogra> persia, i'm happy to help researching this round
<asac> odd. then its probably sound chip related
<asac> ekiga also crashes regularly
<asac> also i cannot tell ekiga to use a stun server
<asac> just doesnt have that config field
<persia> Odd.  It worked for me last I tried it, which was a bit ago.
<persia> You can get to that through the config wizard.
<asac> stun?
<asac> thats not there
<asac> for sure
 * ogra considers breakfast a good thing and tries to find some food
<persia> But each and every sound chip (and subcomponent of sound chips) acts differently weirdly, so yes, likely :)
<asac> i wasted so much time in ekiga/linphone/twinkle that i am quite sure you cannot confiugre a stun server in ekiga
<persia> http://wiki.ekiga.org/index.php/Ekiga_behind_a_NAT_router
<persia>  gconftool-2 -s /apps/ekiga/general/nat/stun_server stun.ekiga.net --type=string
<persia> (replace with your faviorite stun server :) )
<asac> hmm. so they have the stun server hard coded
<asac> ok
<persia> Not hard coded, just not exposed in the UI.
<asac> thats hard coded in my book ;)
<asac> gconf default without UI
<asac> similar to using hexedit to edit the binary ;)
<persia> Well, it's *lots* easier to change than when something is behind an #ifdef :)
 * persia has played with far too many foo-default-settings packages to completely agree with that.
<asac> at least gconf doesnt forget your changes on upgrades ;) ... which hexedit often fails to do
<persia> asac: See, you're supposed to hexedit the .deb, and remember to set epoch 47 :p
<armin76> ogra: what wifi does the babbage has?
<armin76> asac: ^
<asac> armin76: baa
<persia> armin76: ogra said before " the babbage doesnt have wireless per se", so I presume nothing by default (but add what you like via USB)
<asac> board-as-antenna ;)
<persia> asac: Do we have a driver for that?
<armin76> oh
<asac> thats hardware hacking ;)
<asac> no driver needed
<asac> just jump on a usb wifi dongle and try to wire the antenna up with the board for best results ;)
<persia> Ah, so you modulate the local EM potentials to inject data streams directly?
<asac> yes, in practice results are much better than the old way of having two antennas in the chassis ;)
<asac> its not injecting data streams directly
 * persia goes back to kernel archeology
<asac> just physical vibration that helps deal with interference ;)
<asac> only works if you put the board on your external usb drive ;)
<asac> which will soon be the standard
<armin76> ojn: did your board got wifi?
<armin76> lool: and the lange has wifi?
<persia> armin76: What's wrong with USB WiFi off-board, as opposed to on-board?
 * persia suspects any consumer device with a battery will likely also have WiFi
<persia> Probably USB WiFi, but on-board :)
<persia> (given previous reports of USB SATA, onboard, etc.)
<armin76> persia: nothing, i'm just asking
<armin76> the efika mx has wifi...i'm not sure if it was usb or not...let's see...
<armin76> it doesn't work though(thats why i'm asking)
<persia> Those are temping little boxes.
<persia> armin76: Which device is it?
<asac> what else would it be if not usb?
<persia> asac: GPIO?
<persia> Or even native (although I'd prefer a subprocessor for that sort of thing)
<shenki> SDIO
<armin76> persia: wifi device you mean?
<persia> armin76: Yeah.
<armin76> oh, i'm stupid
<armin76> well, i just woke up, its expected :P
<shenki> that's the direction olpc has taken with the 1.5, the first revision used USB but USB takes too long to come out of suspend
<armin76> its a ralink 3070usb
<armin76> so yes, its usb :P
<armin76> persia: thanks for asking *g*
<persia> armin76: Not the one I have a driver for then.  Sorry.  I have ks79xx_sdio
<persia> Which reminds me, SDIO is *much* more likely than GPIO.
<persia> armin76: http://wiki.debian.org/rt2870sta claims to support 148F:3070, so there might be something extractable.
<persia> Dunno if it works properly on armel :)
<armin76> persia: the kernel is 2.6.31, and has support for the 2870, and thats what i built
<armin76> it detects it and stuff, but doesn't find any ap
<persia> That's extra annoying.
<armin76> well, i consider more annoying that if you do a reboot, it halts, and if you do a halt, it reboots :P
<asac> armin76: running ubuntu?
<asac> ;)
<armin76> it came with ubuntu yes, but mkfs.ext3 is my friend :P
<asac> the wifi worked in ubuntu?
<armin76> didn't try
<asac> debian is known to not care much about wifi ;)
 * asac *cough*
<armin76> Hostname: efikamx - OS: Linux 2.6.31-ER1/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 1 (v7l) - Processes: 78 - Uptime: 12d 15h 45m - Users: 3 - Load Average: 2.46 - Memory Usage: 109.81MB/470.49MB (23.34%) - Disk Usage: 22.61GB/461.20GB (4.90%)
<asac> try our kernel
<asac> oh wait ;)
<asac> hehe
<asac> armin76: are you using NM+wpasupp?
<armin76> wifi is not a priority for me, i love eth0
<armin76> asac: no desktop at all
<asac> NM works well without desktop
<armin76> i simply tried iwlist wlan0 scan
<asac> i use it for that
<asac> as root ;)?
<asac> j.k.
<asac> i would suggest to try wpasupplicant with nl80211 driver
<asac> if thats supported by rt....
<asac> JamieBennett: MIRs... how are things blocked atm?
<JamieBennett> ok
<JamieBennett> ...
<asac> all fine?
<JamieBennett> 2 MIR's unassigned
<asac> you said some MIR was rejected?
<JamieBennett> Embryo has concerns from pitti, basically we need to commit to supporting it
<asac> whats embryo?
<JamieBennett> a package used by edhe
<JamieBennett> edje
<asac> will it need as much attention as a real baby later ;)?
<asac> JamieBennett: i mean: whats its purpose/use-case
<JamieBennett> Its a VM that only edje uses
<asac> how is that used from a high level perspective? e.g. for what is that used in our launcher stack?
<JamieBennett> Upstream says its essential
<JamieBennett> its used by edje which is an essential part of our launcher
<persia> Isn't that the interpreter for the widget defintions?
<JamieBennett> (its part of the design and layout bit)
<JamieBennett> themes e.t.c
<asac> well. thats not the perspective i mean :)
<asac> i want to undersatnd why we need a VM ;)
<asac> ah
<JamieBennett> FOR EDJE
<asac> so what persia said
<JamieBennett> ;)
<asac> edje doesnt really explain whats it used for ;)
<persia> asac: E17 is all about being able to create really cool interfaces.  It takes modularity to a mind-numbing level.
<asac> so they invented a scripting language?
<persia> For widgets.
<JamieBennett> persia: indeed and edje is responsible for all theme, layout, image and font definitions
<JamieBennett> to allow layout and animations
<persia> Imagine a .desktop file on steroids, and then distill for a few years.
<asac> lol
<asac> ok
<asac> i think i figure
<JamieBennett> We also have code concerns about some pacakges
<asac> JamieBennett: does that thing have a make check testsuite?
<asac> is that run during build time?
<JamieBennett> asac: no and upstream aren't planning on one
<asac> what are the code concerns?
<persia> An embedded turing-complete VM?
<JamieBennett> recasting pointers, tty manipulation, the comments are on the MIR bugs
<JamieBennett> let me bring them up
<asac> thx
<JamieBennett> https://bugs.edge.launchpad.net/ubuntu/+source/edje/+bug/489359 - edje
<ubot4> Launchpad bug 489359 in edje "[MIR] Main inclusion request for edje" [Undecided,Incomplete]
<JamieBennett> https://bugs.edge.launchpad.net/ubuntu/+source/evas/+bug/488923 - evas
<ubot4> Launchpad bug 488923 in evas "[MIR] Main inclusion request for evas" [Undecided,Fix committed]
<persia> The second one looks done, just waiting for the dep to show up.
<JamieBennett> Albin (lutin) is an ubuntu developer as well as upstream
<JamieBennett> persia: Albin has expressed concern that he will fix some issues but the code base is moving and may introduce more errors
<asac> JamieBennett: so integrating embryo as a pkglib into edje sounds like a feasible approach
<asac> like pitti suggested
<JamieBennett> could be
<JamieBennett> not sure what the best option
<persia> I'd be more comfortable following Debian on this, as Debian has close upstream involvement.
<persia> If we start significant change in packaging, we may end up out-of-sync in some awkward way.
<asac> well. pitti is right
<armin76> and debian has asac :D
<persia> armin76: Well, yes, but not for E17
<asac> persia: we wouldnt drpo the package from universe
<asac> just duping code in edje
<asac> so edje can go to main
<persia> asac: Right, but the duplicated code ends up 1) causing security headaches, and 2) causing a merge lag.
<asac> is albin the debian guy?
<asac> JamieBennett: ?
<JamieBennett> asac: yes
<JamieBennett> lutin on freenode
<asac> persia: security headaches are worse with it being a public api
<asac> i will talk to him ;)
<asac> debian shouldnt have this either ;)
<asac> as they support everything
<JamieBennett> k
<asac> in worst case i dont see a big problem with internalizing it
<asac> we have a commitment to support it
<asac> obviously
<ogra> asac, huh ? the babbage only has a mini pci slot you can attach a wlan card to, nothing wlan related on board
<asac> ogra: did you read a bit more context ;)?
<persia> ogra: There's miniPCI?
 * persia is impressed at the growing number of available bus options
<asac> pci feels like news to me. previously i was told arm doesnt have busses ;)
<persia> ARM has busses, just not usually PCI.
<persia> That said, my Orion server has PCI-e, so it's not impossible.
<asac> yeah. thats what it boiled down to
<asac> we have USB ;)
<persia> and SDIO
<ogra> persia, well, a mini pci socket ...
<ogra> its in fact USB in the backend
<ogra> .oO(or are these thigs called micro PCI ? )
<ogra> right, i was talking about the socket form factor
<persia> ogra: But what *kind* of socket.  You can do either SDIO or USB in a socket.
<persia> (and lots of other stuff too)
<asac> ogra: miniPCIe is better
<ogra> i have the same thing in one of my x86 laptops
<ogra> but there its attached to PCI
<asac> all wifi cards for notebooks are PCIe nowadays
<persia> Um, no.
<persia> I purchased a notebook in 2008 with SDIO wifi
<persia> And another one in 2009
<asac> yes. but no miniPCI (which was the point)
<ogra> persia, if i plug in the wifi card i get an usb device in dmesg
<ogra> right, miniPCIe is it then
<ogra> right
<ogra> just a special socket for USB
<persia> Well, again no.  The Panasonic toughbook line is *still* miniPCI
<persia> miniPCIe != USB
<ogra> persia, SATA != USB ...
<ogra> persia, still the babbage has both sockets attached to the USB controller
<persia> ogra: Sure.  I'm just saying "right, miniPCIe is it then"..."just a special socket for USB" doesn't make sense.
<persia> If there's hardware to convert, that's fine.
<ogra> well, i have these sockets, but effectively they only offer USB devices
<persia> But what kind of socket are they?  What's the line protocol?
<ogra> no idea ... i can only judge by the plug :)
<persia> how many pins?
<ogra> 18+8
<ogra> or 36+16 if you count that the board you plug in is double sided
<persia> That does sound like miniPCIe.  Odd to stick a PCIe controller on a USB bus.
<ogra> well, as odd as sticking a SATA socket on a USB bus
<ogra> the board simply has only that one controller
<persia> Actually, that makes  a lot more sense.  I use SATA over USB regularly on lots of machines.
<armin76> persia: which server is that? :)
<asac> what kind of devices are ARMv4 without T?
<asac> armin76: ?
<asac> does debian support that?
<armin76> asac: ARMv4 without T = arm
<armin76> armel = eabi, which requires thumb interworking
<armin76> which is what T means
<asac> k
<asac> but what i am interested in is if someone would want to support that for lets say firefox?
<armin76> what devices...well, old stuff: netwinder, cats
<asac> so probably not
<asac> what specs are we talking about there?
<armin76> nailboard
<armin76> the netwinder is 133mhz/128mb
<armin76> Hostname: coral - OS: Linux 2.6.25/armv4l - Distro: Gentoo 2.0.0 - CPU: StrongARM-110 rev 4 (v4l) - Processes: 41 - Uptime: 283d 20h 46m - Users: 1 - Load Average: 0.08 - Memory Usage: 18.36MB/124.01MB (14.80%) - Disk Usage: 15.37GB/35.82GB (42.92%)
<armin76> oh
<armin76> HP Jornada stuff as well
<armin76> the netwinder was a nice device back in 2003
<armin76> err, wait
<armin76> its 275mhz, not 133 :)
<armin76> asac: http://dev.gentoo.org/~armin76/arm/armhw.xml
<asac> thx
<armin76> thats just a list of hardware ppl at #gentoo-embedded have, its definitely not a list of all ARM hardware
<armin76> asac: but anyway the most important armv4 devices are the netwinder, cats, and HP Jornada, but they're pretty old as of now, and debian has deprecated support for it anyway
<asac> ok. thats more than enough for now ;)
<asac> lets look at the future!
<armin76> asac: teh omgz, hows that ubuntu doesn't have latest pixman?! :D
<asac> thats X topic
<armin76> asac: quick!
<armin76> asac: btw i'm not sure if you guys are going to have trouble with pixman on dove, as it gets built with -mcpu=cortex-a8 and -mfpu=neon
<armin76> i'm no expert though
<armin76> afaik it would fail it if gets built on a dove
<asac> it also fails on bbg
<asac> we dont use NEON enabled kernels atm
<armin76> fails to build or?
<armin76> no point in using neon enabled kernels if dove isn't neon :)
<ojn> Too bad they didn't announce any kind of dates. But sure, they were first to print a press release: http://www.marvell.com/armada/quadruple_core_arm_instruction_set/release/1363/
<armin76> ojn: does your board have wifi? :)
<ojn> armin76: which board?
<armin76> ojn: nettop
<ojn> well, yeah. and it worked in jaunty but not with karmic
<ojn> haven't had time to debug it, still have visiting family and a bunch of stuff going on at work
<armin76> ojn: ah, i see, i remember about your dmesg :)
<tmadsen> Hi. I am using Ubuntu ARM as testing platform on a QEMU emulator. The emulator has 256MB of RAM, but I'm wondering: what are the minimum requirements for running Ubuntu ARM? (CLI only)
<Martyn> Afternoon all
<Martyn> Who here is most familiar with the PL340 (arm DRAM controller?)
<armin76> asac: chromium+v8 built on armv7a, but it still fails on armv5te, i built the latter with debug, this is what it says: http://dpaste.com/141828/
<Martyn> armin76: Are you familiar with how to bring up the DRAM controller?
<Martyn> the PL340?
<ojn> Martyn: Doesn't ARM have the configuration sequence in their documentation?
<armin76> Martyn: i wish :/ sorry i can't help
<Martyn> ojn : It does, but I'm looking for the code that does so in the linux kernel and not finding it
<Martyn> ojn : I'm starting to think the only time the DRAM controller gets touched is during early system boot, in the bootloader...
<ojn> well, yeah
<ojn> it's hard to configure the memory underneath yourself
<ojn> especially since you need DRAM up to load and run linux
<ojn> Some ports do re-tuning of parameters, but that's a pretty scary thing to do (OMAP sometimes changes timings)
#ubuntu-arm 2010-01-07
<shenki> armin76: is v8 being built for arm or in that error message?
<shenki> s/arm or/arm or thumb/
<zooko`> Hello people of #ubuntu-arm!
<persia> Hey zooko`
<zooko`> Suppose I know that on a certain ARM CPU algorithm X takes 60,000 cycles per use and algorithm Y takes 15,000 cycles.
<zooko`> Now, I want to know if the difference between these algorithms would be significant in terms of battery life.
<persia> Depends on what you're doing in general.
<zooko`> Supposing your ARM CPU is battery powered, and you execute one or the other of these algorithms a few thousand times.
<persia> If most of the processor time of the system is spent in the algorithm, you'll likely do better with the one that takes less cycles.
<persia> If most of the processor time is spent rendering html, then it doesn't matter as much :)
<zooko`> So, we should be able to estimate whether 45,000 cycles times let's say 1000 executions of the algorithm adds up to a significant or insignificant fraction of your battery, maybe?
<persia> I'm not sure there's a direct relation.
<persia> Generally, the more you spin the processor, the more power it uses.
<zooko`> Isn't it linear?
<persia> But, depending on the processor, some operations may take more power than others.
<zooko`> Hm, because of RAM access?
<persia> No, because of processor design.
<zooko`> The algorithm that takes more CPU cycles also uses tables in RAM a lot.
<zooko`> Where the other one just does a whole bunch of arithmetic.
<persia> Let's say I have two processors that support vector operations.  One does this with a parallel matrix, and the other spins really, really fast over the operations.
<persia> These are going to have different power characteristics for the same instruction sequence.
<zooko`> Right.
<zooko`> So this page here says http://www.arm.com/products/CPUs/ARM_Cortex-A8.html
<zooko`> 0.59 mW/MHz.
<zooko`> I think that means that 45,000 cycles times 1000 executions is
<zooko`> 26 W
<persia> I may be mistaken, but I believe that is for the reference implementation, which may or may not be the implementation on any actual processor in the wild.
<zooko`> Yes there is a big disclaimer right below that.
<zooko`> Do you know how to get a number drawn from a real implementation?
<zooko`> Say, one running Ubuntu that you happen to have at hand? :-)
<persia> Note that it also says "power with cache".  If the algorithm that uses lots of RAM happens to exceed the cache, you may end up with unexpected latency of operation when polling RAM.
<persia> I wouldn't be able to measure that: there's something wonky with the battery meter in my device.
<zooko`> Anyway, is 26 W a significant amount
<persia> Depends on the battery.
<zooko`> huh-oh it is time for me to stop using electric lights and computer screens.
<persia> If you're talking about a watch, yes.  If you're talking about a workstation, not really.
<zooko`> How big is the battery in your favorite smartphone
<persia> Plus, 26W doesn't really mean anything without the context of runtime.
<zooko`> Yes it does -- I want to know 26W per battery recharge.
<zooko`> Is that going to mean I have to recharge more often, or is it negligible.
<persia> I don't believe in smartphones :)  But let's say something like 3Wh
<persia> So 26W would drain the battery in something like 20 minutes.
<zooko`> This here nexus one thingie http://www.google.com/phone/static/en_US-nexusone_tech_specs.html says 1400 mAH
<persia> At what voltage?
<persia> I'd guess it's probably about 1.8V, so somewhere like 2.5Wh
<zooko`> Hrm, doesn't say.
<zooko`> Ok.
<zooko`> Okay so this tells me that this quick kludgey approximation shows that this difference is significant.
<zooko`> Which means I have to approximate more carefully if I want to know if it is *really* significant. :-)
<persia> Well, if you need to run the operation constantly.
<zooko`> The estimate I was just doing was "if you want to do this thing 1000 times in a row"
<zooko`> and the thing costs either 15,000 CPU cycles or 60,000 CPU cycles each time.
<persia> Right, but you measured it in watts, which is energy/time
<persia> So without knowing how long it takes to do it 1000 times in a row, it's meaningless.
<zooko`> Wait if it has 2.5 Wh and you draw (let's say) 25 W doesn't that mean you drain it in one hour?
<persia> No.
<persia> That's 6 minutes.
<zooko`> Oh, I'm really confusde.
<persia> OK.
<zooko`> 2.5 Wh is ability to provide 2.5 W for 1 h.
<zooko`> ?
<persia> So, energy is voltage times amperage
<persia> And power is energy divided by time
<persia> So 2.5Wh is a measure of energy (power * time)
<persia> It's 2.5W for an hour, or 25W for 6 minutes.
<zooko`> Ok.
<persia> Or 1W for 2.5 hours.  Doesn't matter.
<zooko`> Okay that makes sense.
<persia> Now, if there is a rough guide that x operations / second = x joules / second (1 watt = 1 joule / second), we can estimate the number of joules required for an operation.
<zooko`> Waitasec, why are batteries measured in power * time.  Instead of just in power.
<zooko`> Err.
<persia> And if there is *no* latency, we can then estimate the number of operations available for a given energy budget.
<zooko`> Hm.
<persia> Because batteries contain an amount of energy, rather than an amount of power.
<zooko`> I see.
<persia> Batteries usually have upper and lower limits of power draw, but they can only present power to the total amount of stored energy.
<zooko`> That makes sense.
<persia> So, the average 3Wh battery you buy on the street probably can't be configured to give 3MW even for 3.6 milliseconds.
<persia> And it probably can't handle a draw of 1 nanowatt for centuries.
<zooko`> :-)
<persia> But for sane values, it's usually safe to assume that one is operating within the battery contraints, and just treat it as an energy storage device.
<zooko`> Right.
<persia> So, as long as we're doing wild speculation on potentially invalid specs, we can roughly say that <0.59mW/MHz is <0.59mJ/MOps
<persia> Running 45,000 operations 1,000 times is about 45MOps
<persia> So that's something like 26.5 mJ
<zooko`> Right.
<zooko`> No I think 26.5 J
<persia> Note that not every processor operates at one operation per clock cycle, so we're already in largely invalid calculations.
 * zooko` nods
<persia> 0.59 * 45 = 26.5
<persia> So the unit doesn't change.
<zooko`> I'll run real benchmarks for time, but I'm not sure how to benchmark energy usage.
<persia> It's usually done with power meters on development boards.
<zooko`> Yes, but you left out the 1000 time.
<persia> More usefully, it's probably going to be less power to run the algorithm that requires fewer operations, especially if it also requires fewer calls to RAM.
<zooko`> a thing which takes 45,000 operations is about 26.5 mJ, so 1000 of those is 26.5 J, right?
<persia> No, 45,000 operations * 1,000 times is 45,000,000 operations, or 45Mops.
<zooko`> Oh.
<zooko`> So it takes only 0.59 mJ to do that thing 1000 times.
<persia> Right, which isn't that much.
<zooko`> Why did this come out looking small when the other calculation came out looking large.
<persia> But because it calls to RAM, and because we made all sorts of assumptions to get that value, it's likely to be more than that in real-world usage.
<zooko`> Where did I get that 26 W number earlier...
<persia> Dunno, but 26W would be running the operations all in parallel for soemthing like 10 days.
<persia> (at least if all the operations consume 26mJ)
<zooko`> Heh.
<zooko`> Off by a million error.
<persia> Minor mistake :)
<zooko`> Okay so if our *new* estimate is reasonable then the difference between these two algorithms is insignificant. :-)
<persia> Well, depends on usage.
<persia> If it's the primary application of the processor, a factor of more than 3 can make a difference.
<persia> If it just happens once in a while, it doesn't matter.
<zooko`> What do you mean a factor of more than 3.
<persia> You said 45,000 vs. 15,000 and that the 45,000 one needed more RAM.
<persia> So I read that as a factor of more than 3: 3 times the operations + potentially additional effort to pull from RAM.
<amitk> thinks get even more interesting when the processor does voltage and frequency scaling, because then 1 operation at 1GHz != 1 op at 500MHz
<amitk> *things
<zooko`> I see.
<armin76> shenki: for arm, i'm not using the thumb option, although i believe -march=armv5te includes thumb?
<shenki> armin76: try forcing it with a -marm
<shenki> armin76: are you building locally?
<shenki> s/locally/natively/
 * persia thinks -marm vs. -mthumb are different
<shenki> i would agree :) one will force your compiler to emit 32-bit arm code, the other will force 16-bit thumb code
<shenki> well, the 16bit ness fo thumb is a bit blurry if you're building for thumb2
<persia> Well, yeah, but -march doesn't necessarily imply either, as far as I understand.
<persia> (although this depends on toolchain config, and armin76 has a special toolchain)
<shenki> yeah
<shenki> i think we're on the same page, i was just suggesting he try -marm to make sure that isn't the issue
 * shenki is the author of the v8 build file
<armin76> shenki: persia: will try, but its weird since on armv7 works fine
<armin76> both toolchains are different, thoguh, armv5te is softfloat while armv7 is not
<armin76> though*
<armin76> so what i think is that maybe the assembler is using armv7-only code
<armin76> but i'm no expert
<armin76> and chromium builds fine without v8
<armin76> what does -marm do?
<persia> -marm and -mthumb specify which instruction set to target for the given -march
<persia> (mind you, there are defaults hidden in the toolchain config, but this lets one be explicit)
<armin76> kHH
<armin76> nsh
<armin76> err
<armin76> i don't use -mthumb either :P
<persia> But do you know which is implied by your toolchain config?
<persia> The suggestion was to override, in case this was the problem
<armin76> http://dpaste.com/141952/
<armin76> sure, i'll try
<asac> hi
<asac> armin76: you say with armv7=1 it bult?
<asac> or just on armv7 without that flag
<asac> ogra: ;)
<armin76> asac: without the flag
<ogra> asac, yo
<ogra> asac, well, i built mkimage from the tree now on x86, but still no go :(
<asac> ogra: try the command i gave you ;)
<asac> or was that identitical?
<ogra> it was
<asac> mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n LinuxRocks -d boot/vmlinuz-2.6.31-601-imx51 uImageN
<ogra>  mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n "Linux" -d ./boot/vmlinuz-2.6.31-601-imx51 ./uimage
<asac> the name is important ;)
<ogra> haha
<asac> i swear
<ogra> *g*
<asac> it must be != Linux ;)
<asac> shall i upload that uImageN somewhere?
<ogra> no
<ogra> i have your old one
<asac> ok
<asac> right
<asac> i used mkimage from karmic x86
<asac> if you use that it has to work for you too ;)
<ogra> ogra@osiris:~/Desktop/tmp$ mkimage -l ./uimage|grep ^Data
<ogra> Data Size:    3062156 Bytes = 2990.39 kB = 2.92 MB
<ogra> ogra@osiris:~/Desktop/tmp$ mkimage -l ./uImage.asac.908000000|grep ^Data
<ogra> Data Size:    3063148 Bytes = 2991.36 kB = 2.92 MB
<ogra> the size differs
 * ogra wonders why
<asac> the new size is different yes
<asac> let me check what the new one has
<asac> i thin kit was a different kernel
<asac> Data Size:    3062156 Bytes = 2990.39 kB = 2.92 MB
<asac> thats the new
<asac> that boots
<ogra> same as mine
<asac> md5sum?
<ogra> and you used mkimage from the archive this time ?
<asac> 8c1cf14ad6e4ef9c1479678c8e606872  uImageN
<asac> ogra: yes. i used x86 karmic mkimage
<ogra> ogra@osiris:~/Desktop/tmp$ md5sum ./uimage
<ogra> 6134a0836cb224e3135acbd8c862ed00  ./uimage
 * ogra doesnt get it
<asac> right. you have a different name
<asac> ;)
<ogra> really ...
 * ogra now tries with a different name juts for giggles
<asac> haha
<asac> i tell you it will work. also no ./
<asac> ;)
 * ogra wishes he had a clue whats wrong
<ogra> mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n Lalala -d boot/vmlinuz-2.6.31-601-imx51 uimage
<ogra> no change
<asac> afte3r loading ... http://paste.ubuntu.com/352834/
<asac> does that work for you?
<asac> iminfo?
<ogra> i cant load
<ogra> :P
<ogra> else i'd try
<asac> please run the same command so we can compare md5sums
<ogra> ogra@osiris:~/Desktop/tmp$ mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n LinuxRocks -d boot/vmlinuz-2.6.31-601-imx51 uImageN
<ogra> ...
<ogra> ogra@osiris:~/Desktop/tmp$ md5sum uImageN
<ogra> 807feee5a32a1805eccf4509574211e3  uImageN
<asac> 8c1cf14ad6e4ef9c1479678c8e606872  uImageN
<asac> odd
<asac> ii  uboot-mkimage                        0.4
<ogra> same
<ogra> wait
<ogra> i use a -pae kernel
<asac> 9184c83fbca680969199928bfcb8748d  boot/vmlinuz-2.6.31-601-imx51
<ogra> i wonder if that could make any difference
<asac> 791f2ca366f78922a9a981bd173ba3b9  /usr/bin/mkimage
<ogra> ogra@osiris:~/Desktop/tmp$ md5sum boot/vmlinuz-2.6.31-601-imx51
<ogra> 9184c83fbca680969199928bfcb8748d  boot/vmlinuz-2.6.31-601-imx51
<ogra> aha !
<asac> thats the same
<ogra> oh, i looked at mkimage :P
<ogra> 791f2ca366f78922a9a981bd173ba3b9  /usr/bin/mkimage
<asac> yeah
<asac> so its obviously your computer ;)
<ogra> you are on i386 ?
<asac> uname -a
<asac> Linux tinya 2.6.32-02063202-generic #02063202 SMP Sat Dec 19 11:00:49 UTC 2009 i686 GNU/Linux
<asac> hmm. i am on a .32 kernel
<asac> would be odd if thats causing it
<ogra> ogra@osiris:~/Desktop/tmp$ uname -a
<ogra> Linux osiris 2.6.31-14-generic-pae #48+ureadahead2-Ubuntu SMP Wed Oct 28 16:24:28 UTC 2009 i686 GNU/Linux
<asac> yeah that would be extremely odd ;)
<ogra> still using keybuks toy kernel
<asac> shall i reboot into the karmic kernel?
<ogra> letr me try on a different machine first
<asac> i would suggest that you use a vanilla kernel too rather: http://kernel.ubuntu.com/~kernel-ppa/mainline/
<asac> i have v2.6.32.2/ afair
<asac> what does pae do? memory shuffeling?
<ogra> using above 3G
<ogra> so yes
<asac> above 3g?
<asac> http://en.wikipedia.org/wiki/Physical_Address_Extension
<ogra> ogra@heizung:~/tmp$ mkimage -A arm -O linux -T kernel -C none -a 0x90800000 -e 0x90800000 -n LinuxRocks -d boot/vmlinuz-2.6.31-601-imx51 uImageN
<asac> you have more than 4g?
<ogra> ogra@heizung:~/tmp$ md5sum uImageN
<ogra> 1ad5cba13bce2849dd49bf70ad221bef  uImageN
<ogra> no, i have 4G
<ogra> the std generic kernel can only address 3
<ogra> the machine i tried now is on lucid though
<asac> yeah. thats a different mkimage version?
<ogra> nope
<asac> wow
<ogra> mkimage wasnt updated ever
<asac> so how can it be so different?
<asac> can you try to boot the kernel i have?
<asac> linux-image-2.6.32-02063202-generic  2.6.32-02063202                      Linux kernel image for version 2.6.32 on x86/x86_64
<asac> though i am quite sure i used the .31 kernel from plain karmic as well
<asac> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/linux-headers-2.6.32-02063202-generic_2.6.32-02063202_i386.deb
<asac> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/linux-headers-2.6.32-02063202_2.6.32-02063202_all.deb
<ogra> well, the lucid try makes no difference
<asac> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/linux-image-2.6.32-02063202-generic_2.6.32-02063202_i386.deb
<asac> yeah. but the checksum is different too. really odd that its different in first place
<ogra> err
<ogra> ogra@heizung:~/tmp$ uname -a
<ogra> Linux heizung 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux
<ogra> hmm, why didnt that get upgraded
<asac> let me see if the same run yields the same checksum
<asac> so
<asac> seems they add a timestamp or something
<asac> so the checksum is useless
<ogra> indeed
 * ogra slaps forehead
<ogra> Created:      Thu Jan  7 12:23:59 2010
<ogra> sigh
<asac> yeah
<asac> seeing it now too ;)
<asac> maybe binary diff ;)
<ogra> still doesnt explain why it doesnt work
<ogra> it has to work with hardy btw
<ogra> thats what the builder runs
<ogra> give me your x86 created uImage
<asac> http://people.canonical.com/~asac/tmp/uImageN.1
<asac> thats the one
<asac> be back in 5
<ogra> hmm, hangs too here
<asac> well. it hanged for me for the first try too
<ogra> you used my script to create the card  ?
<asac> after reset it worked
<ogra> i.e. same filesystem
<asac> i did it manually at some point
<asac> one sec
<ogra> hmm
<ogra> FAT32 here
<asac> http://paste.ubuntu.com/352846/
<asac> so ... try it a few times
<asac> maybe the uboot build you did is less reliable wrt to SD
<asac> than mine
<asac> do you have the script somewhere?
<ogra> what script ?
<asac> e.g. something i can use to create it like you do?
<ogra> ah
<ogra> its on the spec
<asac> at best a script called: mkbootfloppy
<asac> yes. i used that manually
<ogra> http://paste.ubuntu.com/352850/
<ogra> the uboot binary is still stuck in NEW
<asac> yes. our archive admin is lagging ;)
<asac> hehe
<asac> why is it in new?
<asac> shouldnt we reuse package names?
<ogra> the binary has a hardcoded version thanks to NC
<asac> anyway. the other image still loads for you?
<asac> e.g. the .asac uImage
<asac> ?
 * ogra tries that again
<asac> ogra: did you fix that this time?
<asac> e.g. without version?
<ogra> nope
<ogra> i updated it ...
<asac> so next time it would be thanks to you ;)
<ogra> indeed :)
<ogra> BBG U-Boot > fatload mmc 0:2 0x90800000 /uimage
<ogra> reading /uimage
<ogra> 3063212 bytes read
<ogra> no prob with your old one
<asac> try the new one right after that
<asac> version
<asac> U-Boot 2009.08 (Dec 07 2009 - 07:37:24)
<ogra> U-Boot 2009.08 (Jan 06 2010 - 09:44:19)
<ogra> same thing
<ogra> built on the babbge from the updated source package
<ogra> did you build it with -marm ?
<asac> ogra: i just build it with the _bbg rule ... no tweaks added
<ogra> on lucid ?
<ogra> you need tewaks
<ogra> *tweaks
<asac> well. i tweaked some config
<ogra> there are some inline finctions gcc will choke on
<ogra> *func
<asac> hmm
<asac> anyway. let me fix your script to do all oob and then try
<ogra> grab the sourcepackage for uboot-imx
<ogra> 1000_fix_gcc_4.4_compatibility.patch is needed
<ogra> i dont get how you got it building without that
<ogra> at least on lucid
<asac> ogra: put your uboot.bin somewhere ;)
<asac> hmm
<asac> ok
<asac> i dont have a lucid install atm. only chroot. but i can try that i guess
<asac> have .dsc link?
<asac> ogra: ?
<ogra> http://people.canonical.com/~ogra/uboot-imx51_to3.bin
<ogra> apt-get source uboot-imx51
<asac> why is that to3?
<asac> thx
<asac> let me try the bin first
<ogra> because FSL updated it to the tape out 3 release
<ogra> for the .bin the -to3 name is right ... for the binary package name not so much
<ogra> but its unlikely that we'll see something >to3 before lucid i guess
<asac> so the get_part_data is busted somewhat
<ogra> is it ?
<asac> its empty
<asac> e.g last dd is:
<ogra> should make the first part end at the end of uboot
<asac> dd conv=notrunc bs= if=./boot.img of=out.bin seek=1
<asac> "`(set -- $(get_part_data 1); echo "$2")`"
<ogra> UBOOT_SIZE is correct ?
<asac> what is $2?
<asac> well. i reused $2 now for KERNEL ;)
<asac> so thats the prob i guess
<asac> but what is that ment to be?
<ogra> good question, i have to check the redboot-install script
<ogra> thats where it inherits from
<asac> PART1_END_B="`(set -- $(get_part_data 1); echo "$2")`"
<asac> i dont know what that means
<asac> what does the set -- do?
<asac> hmm. this doesnt create the .bin ;)
<ogra> echo $2 should realte to the return of get_part_data
<asac> how to best create the .bin?
<ogra> no, its the proof of concept script
<asac> just dd 4G?
<asac> well i am fixing that now
<asac> ;)
<ogra> it expects that you either write to mmc directly or have a .img already
<ogra> 4G ?
<ogra> no, it should determine the size of the squashfs and roll the image based on that
<asac> dd if=/dev/null of=$IMAGE bs=1 count=$IMAGE_SIZE
<asac> like that?
<ogra> thats all stuff i have to do when i sanitize it for debian-cd
<asac> sure
<asac> but is that ok?
<ogra> bs=1 ?
<ogra> thats 1 byte :)
<ogra> use 1M
<asac> right
<asac> using IMAGE_SIZE and count=1
<ogra> i use the script directly on my mmc
<ogra> so i dont care for images atm
<ogra> and it cant be the scripts fault ...
<ogra> given that your kernel works
<asac> well. so just dd doesnt work
<asac> file created is 0 bytes
<asac> dd if=/dev/null of=out.bin bs=1M count=1
 * asac feels dumb
<ogra> if=/dev/null ?
<ogra> better try zero
<asac> great
<ogra> sorry, didnt spot that above
<asac> now things happen
<ogra> note that BOOT_SIZE is set to 17M atm
<ogra> so the image you write to should be 18M at least
<asac> http://paste.ubuntu.com/352869/
<asac> so that feels better
<ogra> looks ok
<ogra> you added a mkimage -l :)
 * asac pumps it to the sd
<asac> oh right
<asac> good idea
<ogra> or just a mkimage ?
<asac> ogra: it already dumped that there
<asac> mkimage itself does that at the end
<asac> ;)
<ogra> right, so you added the mkimage call :)
<asac> ok ... dd'ing
<asac> yes
<asac> everything oob
<ogra> apart from the proper defaults in uboot :)
<asac> cat mkubootimg.sh | pastebinit
<asac> http://pastebin.com/f3e4d51a7
<ogra> great
<asac> hmm didnt work that great
<asac>  1      512B   137kB   136kB   primary
<asac>  2      137kB  16.8MB  16.6MB  primary               lba
<asac> fat32 is missing
<ogra> whats that ? fdisk -l ?
<asac> udo parted /dev/mmcblk0 print
<asac> s
<asac> sudo parted /dev/mmcblk0 print
<asac> after dding
<asac> same for the .bin directly
<ogra> weird
<ogra> line 52 in your script should have created it
<ogra> err
 * asac  adds a set -e
<ogra> and line 56 indeed
<asac> seems to not error at least
<asac> parted -s out.bin mkpart primary fat32 136704B 16777216B
<asac> thats what it runs
<ogra> looks ok
<asac> part data: 512B 136703B 136192B
<asac> why is boot size 16M?
<asac> hmm
<ogra> just because :)
<asac> thats what is printed
<ogra> you can pick any value you like
<asac> just not fat32
<ogra> 16M seems to well fit a kernel and initrd ... was enough for my testing
<ogra> boot size should in the end actually be the image size
<ogra> we only need one vfat partition for squashfs, kernel and initrd
<ogra> i just picked a value that leaves enough space
<asac> mkdosfs ./boot.img
<asac> guess the dd where the boot.img gest dded wipes the part table bits
<ogra> has nothing to do with parted
<ogra> shouldnt
<asac> oh
<asac> ;)
<asac> now it probably works ;)
<ogra> what was missing ?
<asac> well. i had an echo before the final dd ;)
<asac>  2      137kB  16.8MB  16.6MB  primary  fat16        lba
<asac> odd that its fat16 now
<ogra> yeah
<asac> is that normal?
<ogra> nope
<ogra> oh, wait, it is
<ogra>  2      137kB   16,8MB  16,6MB  primary  fat16        lba
<ogra> thats my sd
<asac> ok let me use -F 32
<ogra> cfdisk will report fat32 though
<ogra> or fdisk
<asac> WARNING: Not enough clusters for a 32 bit FAT!
<asac> but it worked
<asac>  2      137kB  16.8MB  16.6MB  primary  fat32        lba
<ogra> i guess we need to properly work with cylinder sizes
<ogra> i.e. the first partition needs to become big enough to end at a cylinder
<asac> ok
<asac> so your 16m was just too small
<ogra> boots ?
<asac> 60 is better
<asac> not there yet ;)
<ogra> to small ?
<ogra> for a 2.5M kernel binary ?
<asac> for fat32
<ogra> oh
<asac> seems it needs a minimums size > 16m
<asac> i used 60 and the warning is gone
<ogra> ah
<asac> now dding
<ogra> cool
<asac> lets hope
<asac> good
<asac> it automounts here
<asac> good... uboot prompt ;)
<asac> http://paste.ubuntu.com/352878/
<asac> hmm
<asac> invalid FAT entry
<asac> but it read it
<asac> Bad CRC
<asac> darn ;)
<asac> now i am not sure if its the SD card
<asac> it never liked me much
<asac> http://paste.ubuntu.com/352881/
<asac> wondering if i should just wipe the windows CE sandisk
<asac> will i need that at some point?
<asac> have no place to dd it to
<ogra> you have a winCE sandisk ?
<ogra> the b2.5 shipped with an ubuntu one
<asac> http://pastebin.com/f63ce246d
<asac> thats the last version
<asac> yes
<asac> i have two: windows CE + ubuntu
<ogra> well, someone on the team will still have one i guess
<asac> good point
<ogra> JamieBennett, did you keep your WinCE babbage SD ?
<asac> JamieBennett: can you keep your winCE SD?
<asac> hehe
<ogra> heh
<asac> let me go through the script again
<asac> maybe we truncate something
<asac> let me try without F32
<ogra> i just tried with a manually created fat32 part (60M)
<ogra> no change here for my uimage
<asac> so fdisk really says 32
<ogra>    Verifying Checksum ... Bad Data CRC
<ogra> ERROR: can't get kernel image!
<ogra> thats what i get after a reset
 * ogra needs a break and fresh pain killers
<ogra> back soon
<asac> kk
<JamieBennett> ogra, asac: no, ran out of SD's and presumed it wasn't needed
<JamieBennett> I think you can download it can't you?
<asac> no clue
<asac> its licensed i guess
<JamieBennett> asac: http://www.microsoft.com/windowsembedded/en-us/products/windowsce/getting-started.mspx
<JamieBennett> need to register though :(
<asac> who knows if that is really the same anyway
<asac> could be a custom build
<JamieBennett> asac: indeed
<asac> http://pastebin.com/f3bc21930
<asac> please run that like
<asac> sh mkubootimg.sh out.bin data/vmlinuz-2.6.31-601-imx51 data/uboot-imx51_to3.bin 110M
<asac> since you probably have a SD for experimenting ;)
<asac> ls data/
<asac> uboot-imx51_to3.bin  vmlinuz-2.6.31-601-imx51
<asac> ls data/
<asac> uboot-imx51_to3.bin  vmlinuz-2.6.31-601-imx51
<asac> http://people.canonical.com/~ogra/uboot-imx51_to3.bin
<asac> vm linuz just from the .deb
 * asac dds wince somewhere
<JamieBennett> asac: Just checked, wince is on a disk in the bsp
<JamieBennett> disk as in dvd (or cdrom, not sure)
<ogra> re
<ogra> asac, does it boot ?
<asac> bad fatfs still
<asac> but thats probably my SD card
<asac> will now wipe the sandisk
<asac> btw, saturn has two 4g sandisk for 12 EUR atm
<asac> ;)
<asac> yesterday TV advertisement
<ogra> heh
<asac> echo $((100000 * 512)) 1200000
<asac> 1200000
<asac> why is that?
<asac> err
<asac> that was two lines
<asac> echo $((100000 * 512))
<asac>  1200000
<ogra> hmm
<ogra> use bc insteadc ?
<ogra> *instead
<asac> bc?
<asac> we use that syntax everywhere in the script
<ogra> ogra@osiris:~/Desktop/tmp$ echo 1+1 |bc
<ogra> 2
<asac> yes. but we use that everwhere
<ogra> right
<asac> wanted to ensure that its properly cylinder aligned
<ogra> no idea why it prints 120000
<asac> but that / 512 * 512 doesnt work
<asac> our arithmetics are unreliable
<ogra> i get 5120000 here
<ogra> as it should be
<JamieBennett> ogra: as do I
<asac> i am in bash
<asac> you are in posh?
<asac> ;)
<ogra> asac, is using an upstream kernel ... missing the ubuntu-count patches :P
<asac> haha
<asac> and the uImage fixup mem patch
<ogra> i'm in bash indeed
<asac> thats the trade
<asac> ;)
<ogra> heh
<asac> no calc, but good images
<ogra> so your system cant count but produce proper images
<ogra> ogra@osiris:~/Desktop/tmp$ sh -c "echo $((100000 * 512))"
<ogra> 51200000
<ogra> dash is fine too
<asac> ok trying
<asac> so ... sandisk doesnt have probs like that ... but i hang on loading ;)
<asac> so bash is broken for me ;)
<asac> works in sh
<ogra> intresting
<ogra> lucid ?
<ogra> or karmic
<ogra> eek !
<ogra> i totally forgot we need a MIR for uboot ... its not in main yet
<asac> karmic
<ogra> asac, do you happen to have a buildlog from your uboot build ?
<ogra> i noticed that gcc seems to forcefully be set to -march=armv5 in mine
<asac> no ... all that was wiped
<asac> have to reboot ... kernel doesnt release the SD anymore
 * ogra drops the thumb disabling patch and checks if it FTBFS
<asac> so how to best figure cylinder boundaries?
<ogra> fdisk probably
 * ogra sighs, where does the -marm come from
<JamieBennett> anyone played with changing the initramfs on lucid? When I call sudo update-initramfs.distrib -u I get 5 "Can't open /scripts/casper-functions" error messages
<ogra> not yet, no
<JamieBennett> :(
<asac> 32768
<asac> Units = cylinders of 64 * 512 = 32768 bytes
<asac> let me try to align that
<ogra> hmm -marm seems to be set upstream
<asac> ogra: odd is that mkpart interprets last argument as size
<asac> _while_ man says its "end"
<asac> ogra: so have the same prob as you if i use that it seems
<asac> the difference is that the SD that works really has a good partition table
<asac>        Device Boot      Start         End      Blocks   Id  System
<asac> /dev/mmcblk0p1               1         256       16383+  da  Non-FS data
<asac> /dev/mmcblk0p2             257       10587      661184    c  W95 FAT32 (LBA)
<ogra> ok
<ogra> so its not uboot's fault, thats good to know
<asac> darn. i killed my good SD by accident :(
<asac> ogra: uboots fault?
<asac> its our script that creates bad partitions
<asac> i dont think its uboot... so far at least ;)
<ogra> i was worried its the uboot in the package vs your home rolled one
<asac> ogra: well. the image i gave you worked with your uboot :)
<ogra> let me roll an SD manually
<asac> darn i hate me for killing my uboot SD
<asac> :(
<asac> so my original uimage doesnt load either
<asac> i think its your uboot bin
<asac> or really the partition table. because mine is now busted too :(
<ogra> HOORAYYY
<ogra> http://paste.ubuntu.com/352937/
<ogra> wiping the table and just creating a vfat partition with gparted with enough offset and my images work too
<ogra> so its definately the poartitioning
<ogra> asac, well, for the live image we could just leave the first partition and only make sure the second one has enough offset
<ogra> i.e. use a fixed value of say 500k
<ogra> that should be enough to fit uboot in
<ogra> or even 200k
<ogra> no reason uboot should ever grow beyond that
 * ogra takes asacs script and just sets UBOOT_SIZE to a fixed value ... lets see
<asac> i did all that already ... didnt help
<asac> darn
<asac> so i didnt wipe my uboot image (still have that
<asac> but my boot floppy for my production system :(
<ogra> aww
<asac> ogra: so now i double checked
<asac> the uboot thing that works really has good partition bounds
<ogra> right
<asac> http://paste.ubuntu.com/352945/
<asac> no complain
<ogra> yep, same here
<asac> same here?
<asac> thought yours doesnt work ;)
<ogra> read above
<asac> how did you produce your partition table?
<ogra> gparted
<ogra> manually
<asac> ok so how can we find good cylinder bounds?
<ogra> i dd'ed uboot to the initialized SD
<asac> seems that cylinder size is target media specific
<ogra> thern created a partition with offset in gparted
<ogra> copied uimage in there and it works with every uimage i have
<asac> so ... why do we create this first partition with the odd fs id again?
 * ogra checks if there is a chance we can use ext2 for /boot
<ogra> asac, to protect the space where the bootloader lives
<asac> we need to enable ext2 in uboot for that
<ogra> right
<ogra> not sure how well it works
<asac> protect in what way?
<asac> if we just create one vfat partition with enough offset
<ogra> from partitioning apps
<asac> how is that not enough ?
<asac> ok
<ogra> if we re-use the SD later as bootfloppy that space should be protected
<ogra> if we dont, we dont really need to care imho
<asac> so ... how can we do that properly? seems that cylinder size is depending on the SD card
<asac> i had one with 32K
<asac> this one is 64K
<ogra> it doesnt depend on the card ...
<ogra> if you get it right in the image file
<asac> really... then why do i have two different values?
<asac> hmm
<ogra> because you look at the partition table
<ogra> the one thats initialized on the card
<asac> yes
<asac> so parted can set that?
<ogra> if that lives in the image it shouldnt matter
<armin76> persia: shenki: fails exactly the same way with -marm
<ogra> let me look into some docs
<asac> ogra: does bbg just run the bootloader from 1024  ... or from first partition?
<asac> probably doesnt matter ... fdisk -l on the .bin says cylinder size that is full
<ogra> babbage doesnt care about partitions
<ogra> it just tries to find the bootloader directly after the MBR
<ogra> well, actually at the start of the SD but skips the MBR
<armin76> ogra: may i ask whats the point on supporting the babbage if real users are going to have it? will all the devices based on imx51 work like the babbage?
<ogra> similar at least
<armin76> s/users are go/users aren't go/
<ogra> its a developer platform
<armin76> you guys have any plan on qualcomm stuff?
<ogra> nope
<ogra> asac, i think we need to shuffle around with the cylinders and heads a bit with fdisk
<asac> with fdisk?
<asac> parted is too dumb?
<ogra> $imagesize_in_bytes / 255 / 63 / 512 = $number_of_cylinders
<ogra> we somehow need to let the partition table know about that number of cylinders
<asac> hmm
<asac> ok
<ogra> checking how parted can do that
<asac> ogra: i am not sure that its really in the partition table
<asac> if i check on the .bin
<asac> its a different number than after dding it to SD
<ogra> use fdisk -C
<asac> i see that number with fdisk -l too
<ogra> i dont get why it works with the reboot images
<ogra>                         Device Boot      Start         End      Blocks   Id  System
<ogra> lucid-desktop-armel+imx51.img1               1         512       32767+  da  Non-FS data
<ogra> lucid-desktop-armel+imx51.img2             513       10591      645056    c  W95 FAT32 (LBA)
<asac> how are the bounds with B ?
<asac> most likely they are just right?
<ogra> the script is the same
<ogra> the one we use to create the image
<ogra> and we dont shuffle the partitions or the table in it
<asac> damn. need to reboot again. this mmc driver stuff is really immature
<asac> thats actually why i am running .32 kernel as its better there
<ogra> on your laptop ?
<asac> yes
<ogra> never had instabilities
<asac> if i dont unmount and unplug it sometimes hangs badly
<ogra> oh, i always unmount
<ogra> i'm lazy, using nautilus :)
<asac> nautilus "eject" never worked for me
<asac> unmount worked
<asac> ok reboot
<asac> most annoying after every reboot:
<asac> screen /dev/ttyUSB0 115200
<asac> Cannot make directory '/var/run/screen': Permission denied
<asac> ls -l /var/run/screen
<asac> ls: cannot access /var/run/screen: No such file or directory
<armin76> asac: btw, i found out that chromium needs to have write access to /dev/shm
<asac> sudo mkdir /var/run/screen
<asac> yes
<asac> thats why its not working in a bindmounted chroot
<asac> because bindmount somewhat fails to keep permissions for /dev
<ogra> use minicom not screen :)
<asac> well. screen always worked ... just started to fall apart 2 month ago :(
<asac> i blame upstart ;)
<armin76> asac: guess you need to bindmount /dev/shm as well, like you have to do with /dev/pts
<ogra> yeah, always a good candidate
<asac> armin76: that alone doesnt help
<asac> i tried that ;)
<asac> ogra: so loading uramdisk hangs
<asac> ogra: sure gzip is enabled?
<asac> you said you werent sure
<armin76> asac: wfm
<armin76> asac: blame upstart as well :D
<armin76> just tried it
<asac> you are right
<asac> have that mounted in lucid chroot
<armin76> asac fails
<armin76> i win
<asac> you are late. thats all ;)
<asac> armin76_the_lagger
<armin76> i don't have so many boards as you do, slacker
<asac> ogra: try this: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x0 -e 0x0 -n LinuxRocks -d boot/initrd.img-2.6.31-105-imx51 uRamdisk
<asac> it doesnt load
<asac> let me unpack that and use none
<ogra> thats what debian on the sheevaplug uses: mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000  -n initramfs -d initrd.img-2.6.29-2-kirkwood uInitrd
<ogra> pretty much the same
<asac> yes. i surely got it loading
<asac> maybe i unpacked it
<ogra> why would you ?
<asac> because maybe uboot doesnt like gzip ;)
<asac> yep
<asac> taht worked
<asac> gunzip the initrd
<asac> put it in as none
<asac> then it loads
<ogra> well, i'm still chewing on the partitioning
<asac> yeah
<ogra> so you get to busybox ?
<asac> i somehow need to get a boot floppy ;)
<asac> as i wiped it and cannot even boot in my great prod environment anymore
<asac> no
<asac> i am now trying ;)
 * asac sets root=UUID=6483f06d-1216-43df-931f-faddc9c1db27
<asac> ogra: it doesnt like that root :( http://paste.ubuntu.com/352971/
<asac> so /dev/ram?
<ogra> it doesnt find the initramfs
<asac> hmm. thought i loaded it
<ogra> but doesnt use it
<asac> http://paste.ubuntu.com/352973/
<asac> thats what i did
 * asac slaps himself
<asac> plugging the usb disk to the board might help ;)
<asac> does that
<ogra> not really
<ogra> your initramfs doesnt get executed
<ogra> by the kernel
<asac> so what is wrong ;)?
<asac> the address maybe?
<asac> initrd=... wrong?
<ogra> the latter i suspect
<ogra> wait, try loading uinitrd first
<ogra> flip the adresses in bootm
<ogra> sigh, i really dont get that partition thing
<ogra> why does it work with the redboot images
<asac> uninitrd first?
<ogra> flip the adresses
<asac> bootm [addr [arg ...]]
<asac>     - boot application image stored in memory
<asac>         passing arguments 'arg ...'; when booting a Linux kernel,
<asac>         'arg' can be the address of an initrd image
<ogra> did you try it ?
<ogra> bootm 0x90B00000 0x90008000
<asac> i read the doc and it says that initrd is second ;)
<asac> now trying
<asac> Wrong Image Type for bootm command
<asac> ERROR: can't get kernel image!
<asac> so expdected
<asac> now trying to not load ramdisk, but rather loading it from vfat
<ogra> ok, was worth a try
<asac> great
<asac> end of work
<asac> board doesnt show any sign of live anymore :(
<JamieBennett> asac: wait, I'm not the only one to have kill a board now ;)
<ogra> did you trash your SD ?
<asac> what do you mean?
<ogra> note that it wont stay on if it doesnt find the bootrecord
<asac> i dont see any lamp if i push on the button :(
<ogra> oh
<asac> yes
<asac> but no lamp goes on
<ogra> how did you manage that ?
<asac> i dont know
<asac> i put in the sd
 * JamieBennett notes he killed his with the wrong power lead not in software
 * ogra hasnt seen anyone fry a board apart from using over-power
<JamieBennett> :)
<armin76> lol
<asac> overpower?
<armin76> flowerpower!
<JamieBennett> asac: in my case it was a mis-labelled (or rather not labelled) power lead running 12v so nothing for you to worry about
<armin76> asac: remove the sd :D
<ogra> it wont power on without SD
<JamieBennett> ogra: but it does light up for a second
<armin76> oh
<JamieBennett> if you hold the power button
<ogra> right, but if it doesnt do that anyway, the Sd shouldnt matter
<JamieBennett> ogra: right
<asac> sigh
<asac> nothing
<plars> ogra: we did have someone make a board produce "magic white smoke" though :)
<ogra> plars, well, but he's known for his magic skills anyway :)
 * ogra enables ext2 in uboot
<asac> JamieBennett: you have a bbg2?
<asac> does that work with same power adapter?
<JamieBennett> asac: I have a 2.0 and 2.5
<JamieBennett> 2.5 has same adapter
<JamieBennett> 2.0 is 12v
<asac> ah ok
<asac> so i need to get the 12v from my other place
<asac> beforei can continue on bbg2
<ogra> measure
<ogra> pick a voltmeter and check if you have no voltage before playing with power adapters
<ogra> the 2.5 should have a 5V adapter btw
<ogra> not 12
<ogra> thats 2.0
<JamieBennett> ogra: yes as I pointed out above. 2.5 and 3.0 have 12v, 2.0 has 12v
<JamieBennett> 5v that should of been
<ogra> :)
<ogra> i just wanted to prevent asac from plugging in 12V
<JamieBennett> I'm in pain, took the kids in the snow for 30 mins sledging and now my backside hurts from a rather fast decent without the sledge :)
<ogra> ouch
<JamieBennett> ogra: yep, can't be too careful with them power adapters ;)
 * ogra only leaves the house if absolutely necessary
<ogra> way to cold outside
<asac> i definitly didnt replug any power adapter or so
<asac> i have a warrenty thing for this board
<asac> though i have no place of purchase
<ogra> BBG U-Boot > ext2ls mmc 0:2
<ogra> <DIR>       1024 .
<ogra> <DIR>       1024 ..
<ogra> <DIR>      12288 lost+found
<ogra>               64 uimage
<asac> cool
<ogra> BBG U-Boot > ext2load mmc 0:2 0x90008000 /uimage
<ogra> Loading file "/uimage" from mmc device 0:2 (xxa2)
<ogra> 64 bytes read
<asac> but that doesnt matter for our problems ;)
<asac> thats wrong
<asac> 64 bytes read
<ogra> no, the file is broken
<asac> oh why it so small?
<ogra> see the ls
<asac> hehe
<asac> yeah
<ogra> well, has the same issues
<crashfourit1> hum... can any one here help me? getting a kernel panic when trying to start ubuntu arm in qemu. The error is "Attempted to kill init"
<asac> fta: do you know where we can tweak the default profile for chromium?
<asac> e.g. different homepage etc.?
<asac> fta: seems todays chromium dailies failed
<asac> probably needs some GL depends?
<asac> fta: build-tree/src/third_party/gles_book_examples/ is in our orig too
<asac> please strip that
<asac> fta: http://pastebin.com/f5f971220 ... somehow the ForwardingHeaders matches are now working
<fta> asac, i have a problem with the gl thing: for webgl, they have a patched glu because of http://crbug.com/16800 (nvidia has its own broken libgl), but for gpu (new), they want the system gl/glu headers
<asac> the rest works well
<asac> http://paste.ubuntu.com/353039/
<fta> so in the current state, i can't provide both gpu & webgl without breaking javascript (like the gmail timezone bug)
<asac> ah ok. so thats not the reason for the build failure?
<asac> why do we need both?
<asac> what is webgl?
<asac> oh thats chromium stuff
<asac> how does that work for them then?
<asac> seems we are not doing anything special ... e.g. use their webgl and system gl/glu headers for gpu
<fta> the build failure could easily be solved with build-deps += mesa-common-dev libgl1-mesa-dev libglu1-mesa-dev but that means breaking js (http://crbug.com/16800)
<asac> ok found the prob with the licensecheck i think
<fta> webgl: http://arstechnica.com/open-source/news/2009/08/webgl-standard-to-bring-3d-web-without-browser-plugins.ars
<fta> http://arstechnica.com/open-source/news/2009/12/webgl-draft-published-khronos-seeks-community-involvement.ars
<asac> breaking js like their time thing?
<asac> why does it work for them?
<fta> because it only breaks if you're using the nvidia driver
<fta> like i do
<asac> ok. so they are happy with that?
<fta> no
<asac> otherwise i would suggest to file a bug and wait till they figure it out
<asac> and for that time accept that nvidia is broken. feels like they will work on that with high prio
<fta> they fixed it for webgl by patching glu to not load libGl.so.1 directly
<fta> but it's back with the new gpu feature
<asac> right
<fta> so they will have to do something about gpu too
<fta> i already reported that to the gpu guy
<asac> right. thats why i think we should just do what they do and accept bugs they have for the time being
<fta> (he's in california)
<fta> the bot kicks off at 4am so i still still have time to discuss with upstream, maybe there's a better fix, if there's nothing, i'll add the build-deps
<asac> yeah
<asac> i would assume that if they build with both enabled they have the same time regression
<asac> so we would just replicate their behaviour
<fta> asac, http://groups.google.com/group/chromium-dev/browse_thread/thread/a7d337e88e63af6d#
<armin76> shenki: around?
<armin76> asac: did you try armv7=1?
<asac> armin76: no, because we have no NEON in kernel and buld system doesnt allow to disable that
<asac> is on my list to fix in build systme
<armin76> ah, right
<armin76> sorry i forgot *g*
<plars> asac: the firefox in that ppa seems to work for me on babbage
<asac> plars: cool thanks. alrady set it to DONE :)
<asac> (the item)
<cwillu_at_work> lool, that was you I was talking to about pixman et al, right?
<armin76> cwillu_at_work: from ubuntu yes, the other guy was ssvb
<lool> cwillu_at_work: Yes
<lool> As armin76 said
<cwillu_at_work> was just re-reading http://lists.cairographics.org/archives/cairo/2009-October/018421.html, looking for confirmation that an neon'ified pixman does what I think it does;  I now think I misread it when I poked you just now :p
 * cwillu_at_work raids cgit.freedesktop.org for unreleased neon pixman patches
#ubuntu-arm 2010-01-08
<shenki> armin76: o/
<shenki> asac: so you need to build for armv7 but no neon?
<shenki> fta: isn't the localtime bug (the one you were referring to as the javascript bug) fixed in newer versions of the nivia driver?
<persia> Anyone ever heard of "xpg3sh" as a shell?
<asac> shenki: hi
<asac> shenki: still there?
<shenki> asac: yeah
<asac> shenki: yes. if such a disable_neon=1 flag would magically appear in gyp I would start to cry ;)
<shenki> okay, i will write the patch
<asac> there are a few other things that need to get fixed
<shenki> asac: why do you need this?
<asac> we dont have NEON on armv7
<asac> because not all armv7 things support that
<persia> Hrm?  I thought it was only available on *some* armv7, rather than none.
<shenki> ok, so some non-cortex chipset?
<asac> yes ... also old cortex chipsets have issues - like CPU hangs etc. - I was told
<shenki> hrm. i wonder if this stuff should be runtime-dependant, like the ffmpeg sse asm
<asac> i asked for that in the bug
<shenki> which bug is this?
<asac> cant remember who replied, but that guy said that chromium doesnt want it
<asac> one sec
<asac> http://code.google.com/p/chromium/issues/detail?id=30991
<persia> Wasn't there a couple chips that claimed NEON support, but it didn't work?  I thought I saw a bug about that.
<asac> not sure. in the end it boils down to NEON not working eeverywhere ;)
<asac> thats why we ended up with this approach
<persia> Well, yeah.  I'm just not even sure it's safe to do runtime-detect (like for altivec)
<shenki> asac: so what floating point hardware do these boards have?
<shenki> ah, the dove ones. i should read the entire bug.
<shenki> 43 celcius here today, brain is suffering
<asac> i thÃ­nk you have no specialized code for those atm
<asac> heh. thats 50 hoter than here ;)
<asac> are you in the outback ;)?
<shenki> heh, nup. i leave next to the sea
<shenki> s/leave/live
 * asac thinks it must be near a desert :)
<asac> only 48 ... its -5 atm
<shenki> nice. i was looking at footage of england on the news, the entire landmass covered in snow. a world away.
<asac> we also need http://code.google.com/p/chromium/issues/detail?id=31274
<asac> and -fno-tree-sink for gcc44_version=1 http://code.google.com/p/chromium/issues/detail?id=31063
<asac> (or -fstrict-aliasing)
<asac> shenki: ^^
<shenki> ok
<shenki> woah, how did you build v8 with strict aliasing turned on?
<shenki> it used to not build with that... dtoa.c was the main culprit, but there was other issues iirc
<asac> shenki: it just builds ;)
<asac> w dont run the test suite
<asac> but the resulting binary worked well too
<shenki> there you go
<asac> in which direction :-P?
<ogra> mind the walls !
<shenki> ha
<asac> anyone awake with a dove board?
<asac> persia: how did the lsb lib packaging mess work out last night?
<asac> i saw things about /opt etc ;)
<persia> tet-harness is complete.  Haven't yet determined if it's sufficient to build t2c-harness yet.
<persia> s/yet/
<asac> super
<asac> persia: do you have a qemu chroot?
<asac> that works quite well for stuff not too big
<persia> I have hardware :)  Can't run a karmic or lucid kernel, but chroots are fine for building.
<persia> The issue is more the complete lack of documentation on t2c-harness, rather than anything else.  The docs about t2c-harness talk about t2c-desktop, and the instructions for t2c-desktop don't actually do the expected stuff for t2c-harness.
<persia> Plus, almost none of the code is actually licensed :)
<persia> But I do have a patch to make t2c-harness build for arm: it's just a matter of fiddling to get a debian/rules that can build it.
<asac> sounds like a perfect job ;)
 * persia really prefers nice clean upstreams
<asac> that reminds me to poke ccheney ;)
<persia> heh
<asac> about ugly backports for rolling ffox 3.6 to hardy ;)
<persia> Um, I don't want to know anything more about that.
<asac> hehe... its actually about rolling lucid webkit to hardy ;)
<asac> including all the gnome libs
<asac> required for that mess
<asac> better?
<asac> ;)
<persia> That's going to totally break some stuff.  Like midbrowser.
<persia> Just hope nobody with Ubuntu MID has backports enabled.
<fta> shenki, yes, it's the one. there's already a patch: http://codereview.chromium.org/525109
<shenki> fta: okay. so ubuntu still ships old nvidia drivers?
<fta> shenki, depends. we have several flavors. but as i do backports of chromium down to hardy, i have to workaround that bug
<shenki> ah
<shenki> i forgot that you build for old releases
<fta> asac, d'oh! http://identi.ca/notice/18474703
<asac> ouch
<armin76> ricing fail
<shenki> why do you guys have so much trouble getting it built :/
<shenki> looks like i was pretty lucky to have it run
<ogra> because we live on the edge
<shenki> :D
<ogra> latest toolchain and compiler as well as the most modern build defaults have their costs
<fta> asac, boooo, upgraded my desktop (karmic), same error
<asac> ok ... escalation needed i guess
<asac> would love to have a working tarball for the archive upload ;)
<asac> :-P
<asac> fta: you said that dev channel isnt updated anymore?
<asac> maybe because of breakages like this?
<asac> fta: gyp was NEWed by heroic seb128 btw
<asac> i already filed a bug ;)
<asac> bug 504716
<fta> no, the channels (mine) are no updated because they stopped maintaining the LATEST.txt file i use to get the revisions
<fta> noT
<ubot4> Launchpad bug 504716 in gyp "debian/copyright incomplete" [High,Triaged] https://launchpad.net/bugs/504716
<asac> any info what they do now?
<asac> or any official reason why they stopped that?
<fta> not yet, internal discussions still going on
<asac> also no reason?
<fta> nope
<asac> sigh
<asac> would prefer to do uploads to archive from dev channel
<fta> sure
<asac> rather than random happy uploads
<fta> but channels are obviously frozen atm
<shenki> dev channel has started up again yesterday
<fta> not in ubuntu
<shenki> oh, your channels are frozen?
<asac> imo they need to use the same resource that we use
<asac> otherwise it will always end up like that
<fta> shenki, yes, because http://src.chromium.org/svn/releases/LATEST.txt is frozen
<asac> similar to mozilla build systems make install always being busted because they dont use it for their own builds
<shenki> asac: where does your system differ?
<asac> from what i understand google uses something internally to update the channels ...
<asac> while LATEST was just for chromium
<fta> yes
<shenki> oh. they use svn to branch and release from those
<shenki> those branches
<asac> well all the DEPS revisions etc.
<asac> all that info isnt available ... e.g. what revision of webkit they pull for a dev update etc.
<asac> so we cannot produce sources matchine their chrome releases
<asac> we can only build trunk ;)
<shenki> okay. i thought that was fixed a while ago...there was a windows guy who kept asking for it
<asac> yes, they introduced LATEST.txt
<shenki> i used to have an awesome contact in the google team, he mentord me for the summer of code
<asac> but as they seem to have stopped it i assume they didnt use the same ... e.g. it was just a secondary service for us
<shenki> but he quit not long after, and i dont really know anoyne else on the team quite as well
<asac> imo something they dont use will never be reliable enough
<asac> yeah. but even then. thats probably a huge process internally
<shenki> yeah
<fta> shenki, i know a bunch of people there, they are working on the problem
<asac> most likely someone loves their cool build system so much that they cannot move to something like LATEST
<asac> but i have no idea whats the status or problems are ;) ... and given that it stalled just a few days ago, i am not yet panicking ;)
<shenki> okay
<asac> most likely fta noticed it before they noticed it ;)
<shenki> are any of the ubuntu arm guys going to be at linux.conf.au?
<asac> not that i know. when is that?
<shenki> week of the 18th
<asac> january?
<shenki> in new zealand
<shenki> yeah
<asac> ah. so yeah. they guy wanting to go there was pulled into something more important ...
<asac> so no.
<shenki> ok
<asac> is that particular important for arm?
<asac> or just a conference you are attending and would like to meet?
<shenki> the latter
<asac> kk
<fta> asac, http://paste.ubuntu.com/353424/
<asac> so it still works without sandbox?
<asac> ;)
<fta> ok, there's already a popular bug: http://code.google.com/p/chromium/issues/detail?id=31809
 * asac voted
<ogra> so plymouth dies
<asac> yeah
<asac> i think we can live with that for now
<asac> also its not even seeded in desktop so there probably is a reason - maybe this?
<ogra> might be
<JamieBennett> oh, nice - http://www.engadget.com/2010/01/07/freescale-smartbook-prototype-is-a-dockable-tablet-we-go-hands/
<persia> nifty
<persia> I remember playing with an old HTC device like that at the shop last year, but feared I'd lose the keyboard.  This one looks a little bigger.
<asac> plars: here ;)
<plars> asac: so the uboot package version is useful?  How if it is different from what's in flash?
<asac> plars: for imx with bootfloppy the uboot package updates the bootloader on install/upgrade .. so there it should match
<asac> i would think we are doing the same for flash on dove
<asac> plars: does dove install update flash?
 * asac has no dove
<plars> asac: the times I've updated uboot on dove before, it was through a tftp image
<plars> manual process, though there may be a better way now
<asac> plars: ok so for now i dont see that we can do anything different than getting the information we see at runtime
<asac> we could mark uboot version as "MIGHT NOT BE RIGHT"
<asac> one thing we could make happen is to pass parameters to the kernel
<persia> Even if there is an mtd driver, and one can access the flash, it's tricky to determine useful information from binary blobs.
<asac> that we can the read later
<asac> like teach uboot to append stuff we want to know: XX_info_uboot_version=XXX
<plars> asac: this might be a good one to defer till A3, when we have uboot support for imx51?
<asac> yeah. i think so
<asac> but we should clarify what info we need for that item
<asac> currently there is just "uboot etc." :)
<plars> certainly
<plars> asac: something we should probably discuss is the review of tests on suspend/resume testing
<plars> the summary data for most of them is filled in, a few NEEDINFO's still there
<plars> but most are not the base tests
<asac> let me check
<plars> asac: https://wiki.ubuntu.com/Specs/Mobile/Lucid/ArmSuspendResumeTesting for the wiki page
<asac> good lp is slow as hell for me atm ;)
<plars> asac: heh
<plars> asac: one of the items targetted for A2 was to review these with you and discuss which should be targetted to do this cycle
<asac> plars: ok lets go through them and assign priorities
<plars> asac: sounds good
<asac> let me dumb what i think maybe update the wiki for things you agree:
<asac> network -> high
<persia> Are these two-level priorities, beyond the BASE, STD, EXTRA we already did?
<asac> no ;)
<asac> heh
<asac> good
<asac> so its done ;)
<persia> I did that last month :)
<plars> I wasn't part of the conversation on base, std, extra
<asac> right. but you didnt put that in the prio column ;)
<plars> so that was a question I had for you
<plars> right
<plars> I'll fix that
<asac> i think memory is not high
<plars> I was thinking that the intention could have been to have priority different from class
<persia> Um, yes it is.
<asac> its of course important
<asac> but we cant test
<persia> If a bank of memory doesn't come back, bad things happen.
<plars> memory/ECC, my thoughts on this were to run [insert memory test here, TBD] while doing suspend/resume, see if anything ugly happens in the process
<asac> besides general stability
<persia> We can certainly test to make sure the amount of ram is the same.
<persia> We can't test the subtleties.
<asac> how do you run a memory test in a running system?
<asac> but do we know that a problem would show up as "reduced amount of memory"?
<asac> otherwise i am fine with that
<plars> that sounds more reasonable
<asac> for me it feels more likely that the system crashes :)
<persia> I can't remember the command right now.  There's one that shows you the detected physical memory map.
<plars> asac: true, and things are using memory no matter what... should get tested implicitly to some degree
<asac> right. what we could write is a script that fills up memory until OOM
<asac> or something
<asac> or just arbitrary use of something that uses lots of mem after resume
<asac> we can certainly compare /proc/meminfo
<asac> is that avail on arm
<asac> ?
<plars> yes
<persia> Yep
<plars> memtotal should match before/after suspend
<persia> Right.  That's enough of a test.
<persia> Anything else is subtle
<asac> ok
<asac> we could run soimething that makes  abit extensive use of mem
<asac> but lets use the memtotal thing for now
<plars> asac: I suspect that will be implicitly covered in some of the other tess
<plars> tests
<plars> for instance, video playback while suspend/resume
<asac> yes, but crashes in there could easily come from graphics driver etc.
<asac> so we have to be carefuly
<asac> some memory intensive calculation algorithm would be a base test
<asac> more we cant do
<asac> audio devices -> the stream should resume where it stopped
<asac> how can that be done?
<asac> using aplay to play something we know how long it is
<asac> and measure the time before suspend and after resume until it finishes?
<asac> and then if the time is close enough we are done?
<plars> asac: that has to be somewhat manual I'm afraid, ask the user to be aware that it doesn't start over, or suddenly skip to the end
<persia> pacat and parec might be a test that more closely matches the audio subsystems in use.
<asac> but we shouldnt use any high level app to rules out app bugs
<plars> asac: user is going to have to listen for it anyway, aplay can't tell you if sound is actually still coming out
<asac> right. but we can measure if it skipped something
<asac> user still needs to provide feedback if there was sound after resume
<persia> Can that just pull the standard test from the desktop hardware testing suite?
<asac> is there such a test?
<persia> Err, yes, but nevermind.
<asac> lets not check how to implement it now
<asac> but rather what we want
<plars> yes, iirc it plays a tone and asks the user if they heard something
<persia> We need to test that it doesn'T skip on suspend, not that it might break on suspend.
<asac> right. but we want to check if things got skipped ... which i am not sure how that can be a suspend/resume problem
<asac> at least not hardware/driver
<asac> feels really like that skipping or starting over would be app prob
<asac> is this spec supposed to cover that?
<asac> if so we should use the default media player
<plars> I recall that was one of the things that was mentioned as an interesting way to test it during the UDS session
<asac> what way is that?
<asac> using default media player? and getting manual confirm that the music continued?
<asac> lets do that then
<plars> if there was heavy skipping, starting over, etc
<asac> ok lets do that
<plars> even if it's an app problem... if it's something that doesn't normally happen, but only happens when returning from resume, then it's good to catch it here I think
<asac> fan/cooling -> we dont have fans on arm, do we?
<asac> thats not BASE imo
<plars> I don't think it's *that* important to have microsecon. accuracy to determine if some amount of audio was skipped though
<asac> cpufreq/voltage can be done by compraing /proc/cpuinfo i woul dhope
<asac> plars: yes. lets implement that .. .asking the user if the music continued
<asac> (explicitly saying: did it start over etc.)
<plars> asac: so should we cancel fan/cooling?  I haven't seen a fan on any of my arm procs so far
<asac> move to EXTRA
<asac> thats currently the dump that doesnt get implemented by us
<plars> hmm
<asac> ok for cpufreq test?
<plars> no
<plars> cpuinfo will not tell us that
<plars> iirc, bogomips only gets calculated on boot, everything else there is pretty static I think
<asac> ok. then you want to do what? see how long a algorithm takes with nice -MAX ?
<asac> yes. but if there is cpufreq change on my intel/amd the output adapts e.g. for powersave
<asac> if thats not good enough we should run something complex and see how long it takes with max prio
<asac> and if it doesnt deviate consierably (like 20%) we are fine
<asac> makes senes?
<asac> i am spotting media playback in STD
<asac> so how about really keeping the desktop test case for the audio devices test
<asac> and doing the media player tihng we discussed there?
<asac> PLUS video
<plars> asac: you mean combining it?
<asac> yes. e.g. the STD: media playback thing would get the high level app testing we discuss
<asac> and the BASE one would be just the current test we already have
<asac> e.g. BASE == hardware ... STD  == application level
<plars> asac: sounds good
<asac> cool
<asac> SD card removal during sleep
<asac> for mounted devices
<asac> ?
<asac> without replug=
<asac> ?
<plars> that is what was discussed at UDS
<asac> same for usb/usb ... isnt that covered by the BASE HID test?
<plars> mounted, but should not be in use
<asac> plars: ok so we want to see that removing mounted SD card during suspend gets unmounted on resume
<plars> I wouldn't think that would be in base HID
<asac> thats easy to check
<asac> plars: the usb/usb thing?
<plars> asac: right, usb
<asac> why not? we have a bunch of usb stuff for HID
<plars> asac: ah, I'm referring to USB block devices, not char
<plars> usb char devs, such as kbd, mouse, etc would certainly be covered under HID
<asac> ok so cant we make a generic "block device" removal + unmount test?
<asac> e.g. combine that with the SD thing?
<asac> anyway, if thats clear its ok to keep it
<plars> asac: it would save us one test, but might muddy up the results
<asac> we can figure that during implementation
<asac> but checking for something being not in mount after resume is easy enough
<plars> if the tester forgets to specify (we hope not, but still) then you know that there was either a problem with SD removal, or USB removal
<asac> lets clarify on wiki that usb/usb is about block devices ... then i am happy
<asac> STD:NAND/MTD -> i think that should go to extra unless we know whats going on
<plars> agree
<asac> for now i would think that NAND is only relevant during boot
<asac> so it isnt even touched at resume/suspend
<asac> cool lets move it down, maybe dropping that comment in there ...
<persia> Um, depends on the device.
<persia> NAND *is* the primary secondary storage on a number of devices.
<persia> But the test is easy: just confirm you can read from the mtd
<persia> writing is a bonus.
<plars> persia: you have generic way of doing that?
<asac> if you think its doable thats ok. is NAND a secondary storage on any of our supported devices?
<asac> how do we detect NAND mounts?
<persia> Umm...
<asac> for me it feels like EXTRA ;)
<persia> Fine.
<asac> backlight ... no idea how to test that. for some devices we might be able to check the value in /sys/proc
<persia> plars: I have a way that works on my hardware.  No idea if it works on supported boards.
<asac> add persia to the comments column ;)
<persia> asac: Do any supported boards have built-in screens?
<asac> no. but devices
<asac> like smartbooks ;)
<persia> Yeah, but it's a lot harder to test backlights when you can't see them.
<plars> right, I don't have a way of testing it with anything I have at the moment
<persia> I'd be happy to do a backlight test, if I had a kernel :)
<asac> we can see them. we need a pegatron or something
<asac> plars: manual would be only option
<asac> imo its EXTRA too ;)
<asac> maybe we can ask if chaning backlight after resume works still
<asac> that would be more STD
<plars> asac: fair enough, we can easily implement a manual test for it at the moment, and that can be adapted later if we have an improved way
<asac> wireless soft switch is a none issue ... for instance NM resets that on resume ;)
<asac> plars: so asking if changing backlight still works or if screen is still same brightness?
<persia> asac: wireless soft switch is to confirm that NM *can* reset it on resume
<plars> asac: both!
<asac> the summary says its supposed to test if its the same
<asac> problem is that we have a race
<persia> Then drop it.  Doesn't make sense to test that.
<asac> but its doable
<asac> we can compare rfkill info
<asac> thats easily
<persia> If it's easy, then nevermind.
<asac> yes. lets keep it. rfkill compare ... and ensuring that its off in the end
<asac> a) compare rfkill output from before suspend with before NM gets resume dbus call
<asac> b) does NM reset it
<asac> latter probably manually
<asac> we can certainly do a)
<asac> keyboard softswitches is probably ok.
<asac> not sure if that is that important though ;)
<asac> if they work its fine
<asac> but thats covered by HID somewhat
<plars> hmm... is there an easy automatic way to determine if caps/num, etc are set/unset?
<asac> encryption engine? ... maybe for installs with encrypted home check if we can still read from home?
<persia> I don't like the HID testcase.
<asac> why?
<persia> I think the thing to check is that putting power back on USB actually restores the device function.
<persia> Not just removal during sleep.
<plars> encryption engines I believe should be in extra
<persia> I've had laptops where USB HID didn't work over suspend/resume.
<plars> persia: so a better test you think would probably be just to see if they still work after resume? makes sense
<persia> plars: Both make sense, but HID still working after resume is significantly more critical than being able to hotplug.
<plars> agree
<asac> encrypted home is a official install option. if that falls under encryption engine we should keep it in STD
<persia> Because if some device has internal USB HID connections to, say, the keyboard, the end user isn't going to be able to reset it.
<asac> persia: HID definitly covers that it still works
<asac> its about replugging while asleep
<plars> asac: I took encryption engine to refer to hardware special purpose processors that some devices may/may not have
<asac> we can extend that test case to ask for not replug though
<persia> asac: But I also want to test that it works when you don't do anything and sleep.
<asac> plars: ok. then extra
<plars> if we extend it to cover ecryptfs, then it's not hardware related at all
<asac> persia: right. lets extend the test case ... add that to summary
<persia> I thought encryption was about encrypted home too, which is why I put it in STD.
<asac> plars: yeah. not sure if the fs thing would make use of those hardware things
<asac> i would hope it does
<persia> Not by default.
<asac> but then i dont think we support hardware that has that?
<persia> Well, at least usually.
<asac> ok its EXTRA
<plars> which is why I think it should be in extra
<asac> i think bluetooth feels more like STD
<asac> but thats not arm specific i would think
<asac> plars: yes. thats fine
<plars> nothing I have has bluetooth builtin
<asac> ok lets just check what of extra might need to be std
<plars> would need to add a dongle
<asac> plars: right. i would expect that devices will have that usually though. so we should ensure that test cases are there
<asac> its something the QA team probably also would wnat
<persia> bluetooth is extra because it's not well supported for any arch right now (although it's getting there)
<asac> well. its really important for us even if its not yet perfect ;)
<asac> but its not really arch dependent, i agree
<persia> And it'S not onboard for any supported boards.
<asac> right. its not arm/hardware specific
<asac> it would be a win for QA
<asac> i am fine to keep it in extra
<asac> just wonder if we should maybe ask QA team to implement it
<asac> aka suggest it
<persia> I think it's EXTRA in the context of suspend/resume
<asac> yes
<asac> fine with me
<asac> anyone managed to keep track ;)?
<persia> I think it would be good to add to the standard checkbox test suite
<asac> right. lets file a bug and mark that as DONE then ;)
<persia> The channel is logged, so we have notes :)
<plars> asac: file what bug?
<persia> plars: against checkbox asking for BT testing
<asac> checkbox -> add bluetooth suspend/resume testcase
<persia> No.
<asac> wishlist
<persia> checkbox gets bluetooth "does it work" testing
<persia> suspend/resume gets bluetooth as EXTRA
<plars> persia: that may already be in the works
<persia> plars: That's what I heard.
<asac> dont care ...
<plars> I think that oem already has some that have not been pulled in yet
<persia> Moving on...
<asac> you can file a generic bug for bluetooth support ;)
<asac> in checkbox
<asac> and say that we came from suspend/resume testing ;)
<persia> PCMCIA and eSATA are EXTRA because of hardware availability with our kernels.
<persia> NFS/CIFS/etc. is just app-level testing of network
<asac> dont we have eSATA?
<persia> Do you?
<asac> i dont know. thought we have SATA ... no clue what it is
<persia> I heard about SATA, but not about eSATA.
<plars> well, my sata port looks pretty external, but that's only because I don't have an enclosure :)
<persia> eSATA is External SATA
<asac> ah
<ogra> asac, i think i found the partition issue ...
<asac> ogra: rocking
<ogra> # round size to next block; note we assume blocks of 512 B
<ogra> IMG_SIZE_BLOCKS="$((($FIS_SIZE + $IMAGE_SIZE + 512 - 1) / 512))"
<ogra> thats from the original script :P
<persia> nbd\iSCSI/etc. is again just more network tests, really.  EXTRA
<asac> i tried that
<ogra> i must have been blind to missi it
<asac> exactly that ;)
<asac> odd
<asac> but great
<persia> multicore runs into hardware issues, as does radio/telephony.
<persia> DOne.
<asac> i first tried round to blocks
<ogra> for what exactly ?
<asac> then i tried to round to cylinders  ;)
<asac> ogra: for all partitions
<plars> persia: otoh, I think multicore would be good to revisit if/when we have supported multicore systems, extra until then though
<ogra> IMG_SIZE_BLOCKS is used in the dd command that creates the raw image
<ogra> before partitioning it ;)
<asac> hmm
<asac> that adds meta info?
<ogra> no
<ogra> but uses a bs=512 ;)
<asac> whats the difference?
<asac> in the end everything is zero ;)
<ogra> that the dd'ed image has a blocksize
<asac> so if there is no meta data then
<asac> so there is meta info
<asac> :)
<asac> thats what i mean
<ogra> there are block boundaries
<asac> right.
<asac> thats meta info
<ogra> its not "meta info"
<asac> sure
<asac> its definitly not payload ;)
<asac> anyway very good
<asac> now i want my board back ;)
<ogra> its just the way the raw image is built
<asac> still ... its meta info ;) because its not payload
<asac> it must be somewhere in the blob
<ogra> anyway, that should give us properly partitioning
<asac> and does not carry data
<asac> right
<asac> please verify
<asac> then lets move swiftly for the uboot spec :)
<asac> plars: so all fine?
<asac> persia: any of the testcases you want to be peer or even owner for?
<plars> asac: yes
<asac> also setting "fill out the wiki items" to DONE
<asac> as i assume you add some stuff we mentioned
<plars> asac: yes, of course
<asac> plars: actually all items are done, right?
<asac> e.g. we decided what is automated too?
<plars> asac: pretty much I think
<asac> plars: you might want to reorder the implementation work items
<asac> that went into extra
<asac> plars: anything from BASE we cant implement?
<asac> i guess we had an idea for everything, right?
<plars> asac: yes
<plars> we're good
<asac> ok
<asac> great
<asac> that brings us close the trendline
<plars> thanks :)
<plars> asac: I might have to move my final two items for the install testing to A3
<asac> plars: thats ok. what is blocking that?
<asac> note: we still have a few days left and you are not bound to freezes ;)
<plars> I've talked to ara about them, and have a RT ticket to get access to the system for adding the tests to the tracker DB
<asac> ok
<asac> thats blocking both?
<plars> if it happens before the cutoff, I could do it, but it may be better to wait anyway
<plars> yeah, but it can't really start until AFTER alpha2 drops
<asac> lets keep them there until tuesday ... and then move them
<plars> so, it's better probably not to go mucking with that db right now anyway
<asac> ok
<asac> lets move them
<plars> otherwise, it's ready to go, and regardless of whether those milestones get created now, or after a2 drops, it will not change the timeline for it actually starting to happen
<asac> plars: one thing. do you have a list of changes to RC bugs ?
<asac> ;)
<asac> since last meeting ...
<plars> no, sorry, I do not
<asac> kk
<asac> ok moved
<ogra> hrm, no, doesnt work either
<asac> plars: isnt bug 431963 fixed
<ubot4> Launchpad bug 431963 in linux-fsl-imx51 "io/fs errors when launching gdm on imx51 with sata" [High,Fix committed] https://launchpad.net/bugs/431963
<asac> ogra: fdisk -l looks good?
<ogra> i guess the image needs to exactly be a multiple of 512
<ogra> no
<asac> i would think that some of the bounds might be wrong
<asac> e.g. -1
<asac> +1
<asac> etc.
<plars> asac: yes, fix released for lucid, and the sru for karmic was just recently confirmed by GrueMaster
<asac> so you probably trash the partition as i expected
<asac> plars: why is it fix committed?
<plars> asac: that's for karmic
<asac> sure?
<asac> thoght the bot always posts the default
<asac> ok
<asac> bug 453682
<plars> asac: according to the bug, the lucid task is fix released
<ogra> asac, parted needs exact 512 bytes boundaries
<ubot4> Launchpad bug 453682 in linux-mvl-dove "late resume failure on dove" [High,Fix committed] https://launchpad.net/bugs/453682
<asac> plars: that one?
<asac> also?
<plars> asac: same there
<ogra> so we need to adjust our partition sizes accordingly
<plars> asac: fix released for lucid
<asac> bug 456659
<ubot4> Launchpad bug 456659 in linux-fsl-imx51 "suspend/resume failure on imx51" [High,Confirmed] https://launchpad.net/bugs/456659
<asac> no need to comment
<asac> just trying to get info ;)
<asac> bug 499881
<ubot4> Launchpad bug 499881 in linux-fsl-imx51 "usb storage with ext4 does not work in lucid" [High,Confirmed] https://launchpad.net/bugs/499881
<plars> asac: I haven't seen an movement from kernel team on 456659, but it seems to work better for me now on bbg3 at least, still may not be quite fixed though
<asac> bug 458501
<ubot4> Launchpad bug 458501 in gnome-screensaver "[armel] screensaver hangs on unlock, eats cpu" [High,Confirmed] https://launchpad.net/bugs/458501
<plars> 458501 is fixed in lucid
<asac> bug 494667
<ubot4> Launchpad bug 494667 in squashfs-tools "[armel] non-ISO-C misaligned pointer punning causes slowness and SIGILLs" [Critical,Fix released] https://launchpad.net/bugs/494667
<asac> really?
<asac> cool
 * asac moves to fix
<plars> someone didn't subscribe 499881 to ubuntu-armel... :)
<asac> i searched for armel tag ;)
<asac> hopefully that has all
<plars> yeah, I need to pull the list of unsubscribed bugs with armel tag again
<plars> ideally, they should also be subscribed to ubuntu-armel if we may do something with them
<asac> https://bugs.edge.launchpad.net/ubuntu/lucid/+bugs?field.searchtext=&orderby=-importance&assignee_option=any&field.assignee=&field.bug_reporter=&field.bug_supervisor=&field.bug_commenter=&field.subscriber=&field.component-empty-marker=1&field.status_upstream-empty-marker=1&field.omit_dupes.used=&field.omit_dupes=on&field.has_patch.used=&field.has_cve.used=&field.tag=armel&field.tags_combinator=ANY&field.has_no_package.used=&search=Search
<asac> maybe compare that with the lucid list you get for ubuntu-armel ;)
<asac> if you see a difference let me know so i can add tha to the report :)
<asac> bug 462798
<ubot4> Launchpad bug 462798 in ubiquity "selecting 'new partition table' confuses the partitioning" [Medium,Triaged] https://launchpad.net/bugs/462798
<plars> asac: I have a script that will show me he ones tagged, but not subscribed
<plars> asac: NCommander is aware of that one
<plars> was something we found towards the end of karmic
<asac> cool
<asac> the other way around would be good for me atm ;)
<asac> e.g. not tagged but subscribed and targetted for lucid :)
<asac> but i can search for that in a bit on my own
<asac> bug 451553
<plars> I updated it recently
<ubot4> Launchpad bug 451553 in linux-mvl-dove "Lots of errors during install on dove" [Medium,Confirmed] https://launchpad.net/bugs/451553
<asac> whats that?
<asac> why is a medium bug targetted for release?
<asac> plars: do you still see that? its old aka october
<plars> asac: i believe the importance may have been lowered at some point
<asac> ok untargetting
<plars> I still see some of those errors, last I checked, but not all of them
<asac> moving to normal baug
<plars> odd
<plars> the lucid task was targetted for karmic updates?!
<asac> yeah ;)
<asac> removed the milestone now
<plars> probably the lucid task was opened after that was milestoned
<plars> that's likely what happened... neat trick though!
<asac> bug 458537
<ubot4> Launchpad bug 458537 in linux-fsl-imx51 "hibernate does not work" [High,Triaged] https://launchpad.net/bugs/458537
<plars> hmm? wontfix for lucid?
<asac> plars: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid -> check that
<asac> plars: wontfix is the way to untarget it ... so the "normal" task reappears
<asac> its the only way ;)
<asac> so ignore that. just means its not tracked by release team anymore
<plars> I see
<plars> odd
<asac> plars: the bug progress was nice this week ;)
<asac> cool
<asac> well not really week ;)
<plars> asac: move 453682 to fix released for lucid
<plars> and 458501
<plars> oh
<plars> nm
<plars> I see the category now
 * plars needs more caffeine
<plars> I keep thinking the fixed this week is the backlog category for some reason
<plars> because the one under it is fix available I guess
<asac> plars: could you test the alternate images?
<asac> do they work
<asac> ?
<plars> asac: I have not so far, but I could pull them and take a look if you'd like
<plars> I thought that ogra or someone had said they had looked recently
<ogra> NCommander did say that
<ogra> but i think he only chacked dove
<NCommander> ogra, they boot for dove, installatoin fell flat on its face due to installability errors
<ogra> aha
<asac> JamieBennett: ogra: plars: GrueMaster: NCommander: persia: https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid
<asac> anything for weekly summary?
<GrueMaster> asac: lsb-lib test porting is done; all that's left is the packaging.
<asac> good
<NCommander> asac, probably want the bug report for thumb, but I haven't written it up yet as I'm reinstalling with latest packages to get the best possible report
<GrueMaster> I'm dropping libstdc++-tests as they only test for api existence, not functionality.
<asac>  * lsb-lib porting
<asac> added that to summary
<NCommander> asac, we also want to track alternates for this alpha, but they aren't a blocker on working/not working
<asac> NCommander: did you read that wiki page?
<asac> thanks
<ogra> whats https://bugs.launchpad.net/bugs/499881 ?
<asac>  * mobile-lucid-arm-alternate-images: DONE - verification pending.
<NCommander> asac, oops, sorry
<ubot4> ogra: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/499881)
<asac> ogra: thats my usb storage not working in lucid
<asac> works perfect in karmic
<asac> but with lucid is broken
<ogra> why the heck is none of these bugs properly subscribed to ubuntu-armel ?
<ogra> i havent heard of either of them
<plars> ogra: I'm pulling a list of unsubscribed bugs right now, will go through them and see if we are still missing some important ones
<ogra> thanks a lot
<plars> there was another one like that I caught earlier this morning too
<ogra> thats a month old, i might have debugged it already had i known about it
<ogra> asac, ok, going through the script items manually i at least get a proper "Non-FS Data" partition again in fdisk
<ogra> and with handing -C to fdisk it doesnt complain anymore ...
<ogra> http://paste.ubuntu.com/353524/
<asac> so ooo failing to biuld would be a problem?
<asac> is it easy for us to unseed?
<asac> or are there libs that are pulled in as base stuff?
<ogra> not easy
<ogra> but possible
<asac> why not?
<ogra> language packs
<asac> seems we get an alpha-2 upload before a2 so i want to discuss with slangasek
<asac> but need to understand how bad it owuld be
<asac> ooo upload before a2
<ogra> it needs some very intrusive shuffling of the translation packages to actually get everything off the image
<ogra> slangasek knows what i'm talking about
<ogra> we did it together the last time we unseeded oo.o because it failed
<ogra> oh !
 * ogra glares at dd if=/dev/zero of=./boot.img bs=1024 count=$(($BOOT_SIZE / 1024))
<ogra> why do we use bs=1024 here ... hmm
<asac> ok
<ogra> aha !
<ogra> http://paste.ubuntu.com/353529/ <- as soon as i create the second partition
<asac> yes. i think you need to add a better start
<asac> e.g. try to add more offset
<ogra> well, i did it manually
<asac> or dont change the fs type before
<ogra> and made it start 1byte after the end of part 1
<ogra> the fstype is changed in the table not on the partition
<asac> try to give it a full block offset
<ogra> yes, thats what i'll try next
<ogra> either a full block or probably better the exact start of the next 512B block
<ogra> i think the latter will solve it
<ogra> but i dont get why ...
<ogra> since we dont need this in the original script on the builder
<ogra> nope, same breakage
<asac> GrueMaster: plars: how do you organize testing of standing RC bugs? do you check each every day? or only if someone claims it to be fixed?
<plars> generally only if someone claims that it has been fixed, or that there is a test package for it.  However, some that are much more obvious will be much more likely to get noticed in testing of daily images
<GrueMaster> I try to test once it's marked as fixed.  Otherwise, I also try to monitor the package in the manifest to see if it changes there.
<plars> asac: what did you recommend for cpufreq/voltage? we discussed that cpuinfo was insufficient to tell us anything there, but going back through the logs it was unclear as to whether you were suggesting to move that one to extra, or the previous item we discussed
<asac> plars: some more or less long running computing thing that doesn consume much memory (e.g. no swapping) run with high prio
<asac> measuring time
<asac> i think priority isnt important if we look at CPU time actually
<plars> still in base?
<asac> why not?
<plars> ok
<asac> feels doable and good to check ;)
<plars> I was wondering... is cpufreq subsystem not supported under arm?
<plars> might give us a better test
<asac> CPU time should be a real test. cpufreq is just exported by kernel and might not match actual performance if there is a bug
<asac> or isnt that true?
<asac> but well. if we have that and the time measuring doesnt feel good, thats probably ok too
<plars> asac: I was thinking in terms of adjusting the freq, making sure it matches after resume
<plars> sure
<ogra> we could grep BogoMIPS from /var/log/dmesg :)
<plars> ogra: iirc, bogomips only gets updated at boot, not on resume
<ogra> yeah, most likely
<ogra> ogra@babbage2:~$ sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
<ogra> 800000
<ogra> btw
<suihkulokki> mmh.. on a preemptively multitasking OS asking the cpu performance is usually wrong question
<plars> ogra: odd, I don't see that on my b3
<ogra> plars, you dont use the shiny new kernel from cooloney ;)
<plars> ogra: ah
<ogra> i wasnt thrilled by nothing when i said we have all devices working ;)
<ogra> that first shot is really better than any released kernel we had before
<asac> its still kernel statistics vs. actual performance
<asac> actual performance is the best test imo
<asac> kernel statistics could be busted
<ogra> indeed
<asac> checking both is the best
<asac> because we dont want good actual performance with busted kernel stats for instance :)
<ogra> i doubt we actually want to scale it at all
<ogra> as long as all graphics rendering is framebuffer and software based it makes no sense to scale down
<ogra> at least with the max 1GHz machines we have atm
<asac> is that relevant?
<asac> ;)
<ogra> well, what for is measuring good if you dont change the value anyway :)
#ubuntu-arm 2010-01-09
<ADcomp> hello ..
<ADcomp> I'm testing jaunty on new board ( omap3 / kernel 2.6.31 ) .. base system is ok but I can't install xserver :  dpkg always return error when unpack 'hal'
<ADcomp> (sorry for my poor english)
<ojn> ADcomp: why jaunty? Karmic will run fine on it too.
<ADcomp> karmic doesn't work (yet) for me ..
<ADcomp> but jaunty works fine so ..
<rcn-ee> ADcomp, what doesn't work? package requirement? or Kernel?
<ojn> karmic rootstock comes up all the way to gdm login for me without modifications, running on various omap platforms (3530, 3630, 4430)
<ojn> with a mainline or TI kernel...
<ADcomp> I don't know .. I just receive this board. just trying what it's working "out-of-the-box"
<ADcomp> btw , I'm not a guru on embedded system ..
<rcn-ee> ADcomp, for reference, what board is it?
<ADcomp> http://www.technexion.com/index.php/thunderpack
<ADcomp> it's like a beagleboard with rj45/wifi + 4.3 touchscreen
<rcn-ee> ADcomp, did they supply an SD card with Jaunty on it?
<ADcomp> no ..
<rcn-ee> what dpkg error comes up?
<ADcomp> but you can download "angstrom" and kernel on technexion 'open' web  : http://www.technexion.org/
<ADcomp> E: sub-process /usr/bin/dpkg returned an error code (1)
<ADcomp> when "--unpack"
<rcn-ee> sounds like just a broken jaunty package...  It's safe to take the kernel and modules  (lib/modules) from their Angstrom download and dump it into a Karmic rootfs...
<ADcomp> I already do it
<ADcomp> karmic run well ?  with X and 128M ram ?
<ADcomp> I do some others tests this w-e with rootstock ..
<rcn-ee> ADcomp, it's also compiled with 'armv6' vs jaunty's 'armv5'...
<rcn-ee> but xfce4 is faster with karmic on my old beagle b5 (128mb) then jaunty..
<ADcomp> ok .. good to know that  :)
<rcn-ee> just make sure you setup a swap partition, once you start opening a bunch of gui apps that ram is going to dissappear..
<ADcomp> size ? 128M ?
<rcn-ee> it depends on your SD card size, but atleast 2xRam size as a ball park..
<ADcomp> ok.. I have a 2G but I buy a new one 4G today :)
<ADcomp> maybe when all work fine , I can write something about this board ( config , hardware , .. ) on ubuntu wiki ?
<rcn-ee> they have this one: https://wiki.ubuntu.com/ARM/DeviceSupport  but i just maintain http://elinux.org/BeagleBoardUbuntu since the beagleboard stuff has always been on elinux.org..
<ADcomp> so thank you .. because I use this one for testing ubuntu on my board  :)
<rcn-ee> your welcome, btw i was very close to picking up that board too..  if you do get a working kernel build defconfig, i'm am interested in adding more omap board support to https://code.launchpad.net/~beagleboard-kernel/+junk/2.6-dev  since you can share one defconfig with multiple omap boards...
<ADcomp> I downloaded kernel source + config from http://www.technexion.org/
<ADcomp> config for 2.6.31 .. http://paste.ubuntu.com/354030/
<rcn-ee> does the kernel have any patches? or just mainline 2.6.31
<ADcomp> patches .. http://paste.ubuntu.com/354034/
<rcn-ee> this diff should make my 2.6-stable tree work: http://pastebin.com/f60903eb6
<ADcomp> ok .. I have to go.
<ADcomp> but thanks for your time .. I 'll be back  :)
<rcn-ee> looks like they used angstrom's 2.6.31 as a base, thats what i'm using too.. http://bazaar.launchpad.net/~beagleboard-kernel/%2Bjunk/2.6-stable/annotate/head%3A/patch.sh
<rcn-ee> ADcomp, download tihs branch: bzr branch lp:~beagleboard-kernel/+junk/2.6-stable and apply that diff, you should get a good kernel for the technexion.org
<ADcomp> yes .. looks like all things ( system/kernel/board ) is pretty close to beagleboard
<rcn-ee> if it works, commit the change noting enable OMAP3_THUNDER support, and it'll have a *.deb on rcn-ee.net.. for easy rootstock installs..
<ADcomp> ok .. downloading ..
<rcn-ee> the script only needs a valid Cross Compiler setup in system.sh... it'll warn you...
<ADcomp> ok .. I'm late .. but I give you more feedback soon ..
<ADcomp> bye
<gregoiregentil> I'm using the rootstock (great stuff!) to create an Ubuntu image for the Always Innovating Touch Book
<gregoiregentil> http://www.alwaysinnovating.com/wiki/index.php/Ubuntu
<gregoiregentil> I've slightly modified the rootstock script to add a postprocess step before roll_tarball to do a few additional customizations
<gregoiregentil> now I would like also to run a script in qemu before it's umounted (I would like to compile some stuff specific to my image)
<gregoiregentil> how could I modify again the rootstock file so that a postprocess script is run at the end of the qemu story?
<rcn-ee> hey gregoiregentil, you work at alwaysinnovating right?  looking at your mod script, we could take care of the module problem by using --kernel-image and generating a deb, what patches do you need for 2.6.31? (i've moved off 2.6.29)
<gregoiregentil> hello, yes, correct, I'm the founder
<gregoiregentil> for the module, yes, but my kernel is a little bit special as it's handling the whole TB and I have a few specific module
<gregoiregentil> like the 3D stuff, the video acceleration to support OMAP DSP and so on
<rcn-ee> Yeap, sgx works.. ;)
<gregoiregentil> so there are many patches ;-) http://git.alwaysinnovating.com/cgit.cgi/ai.openembedded.dev/tree/recipes/linux/linux-omap_2.6.29.bb
<rcn-ee> yeap, just loading it up again in firefox
<gregoiregentil> BTW, rootstock is great work. I have already a good working Ubuntu image on the TOuch Book
<gregoiregentil> just need to have a few more stuff, and it will be almost at the same level to my super-optimized OpenEmbedded image (still better compilation flag but Lucid will catch up)
<rcn-ee> yeah it is. (can't take credit for it, it's Oliver's work) i just added enough support to make it work with the beagleboard and my debian and ubuntu *.deb
<rcn-ee> in rootstock src, about line 646 ${KERNEL_IMAGE_CMD} you could add your script changes.. Ubuntu System User|Always Innovating can be changed with a command line option
<rcn-ee> -n --fullname <quoted string>: --fullname "Always Innovating"
<gregoiregentil> OK. Thanks for the feed-back. I'm appreciate. Let me take a look now
<rcn-ee> line 620 	echo "deb ${MIRROR} ${DIST} ${COMPONENTS}" >/etc/apt/sources.list is where you could add the deb-src line next.. i keep forgeting to email oliver on a patch to add karmic-updates
<rcn-ee> like i did here: http://elinux.org/BeagleBoardUbuntu#Karmic:_.289.10.29_boot_fixup
<gregoiregentil> rcn-ee: cool. I'm integrating ;-)
<gregoiregentil> rcn-ee: so all the stuff around line 630, it's executed inside qemu?
<gregoiregentil> Got you for ${KERNEL_IMAGE_CMD}
<gregoiregentil> yup, exactly the place I want to add my stuff!
<rcn-ee> gregoiregentil, yeap that qemu in there up till about 661.. that spot where KERNEL_IMAGE_CMD seem safest, as after that things start finishing..
<gregoiregentil> yup
<rcn-ee> gregoiregentil, have you had good luck with dspbridge?  I've just started recently looking into it for my kernels (going the oposite route of angstrom and their dsplink)  Other wise everything else could go in my 2.6-stable branch, then you'd have a normal deb install file..
<gregoiregentil> On ubuntu, not yet
<gregoiregentil> on my OpenEmbedded Always Innovating OS, I have both dspbridge and dsplink...
<gregoiregentil> http://www.alwaysinnovating.com/wiki/index.php/DSP_video
<rcn-ee> ah cool..  Yeah just yeasterday i got the dsp-gst tree to build, but haven't tested all 3 parts together yet (dspbridge module, dspbridge userspace and dsp-gst gstreamer stuff)
<gregoiregentil> rcn-ee, you should subscribe to the gst-dsp google newsgroups
<gregoiregentil> Felipe is very active and answer all questions
<gregoiregentil> also, there are a couple of overlay OE (mine and another one) with all the recipes to compile everything. That may be useful to take look if you don't manage to do something
<rcn-ee> cool didn't know, i've been following his blog, will add it to my email
<rcn-ee> about the only thing i'm missing is the dsp stuff, then ubuntu would be feature complete with angstrom.  On the Kernel side i usually test changes against my tree and openembedded so that's usually in sync..  i just moved to 2.6.31 so i didn't have the omap3-touchbook patches anymore..
<rcn-ee> btw is there anything special about xorg/modules/drivers/fbdev_drv.so in your script?
<rcn-ee> i think it's the omapfb driver, it got pulled in from debian, it might not be as up to date as openembedded but... https://launchpad.net/ubuntu/+source/xf86-video-omapfb/0.1.1-2
<rcn-ee> add : xserver-xorg-video-omap3 to your seed for rootstock..
<gregoiregentil> Very long story about fbdev (long story with Koen)
<gregoiregentil> Koen has always prefered omapfb driver while I stick with fbdev
<gregoiregentil> so you have a kind of two branches. I have ported the xrandr to fbdev
<gregoiregentil> as I wanted to have a very good rotation support in fbdev. It's well optimized
<gregoiregentil> then I have for video some mplayer patches to write directly to fb1
<rcn-ee> ahh, that explains it...
<gregoiregentil> those rotation patches have never been published (yet) but the mplayer stuff is in git and Koen has integrated it
<rcn-ee> sounds cool...  I hardly plug my beagle into an lcd, so i just point users to use omapfb..  but with your touchbook design a good visual experience is key
<gregoiregentil> yup!
<suihkulokki> gregoiregentil: where is fbdev with xrandr?
<gregoiregentil> suihkulokki: I have never published yet. It's on the todo list
<suihkulokki> gregoiregentil: I was just bemoaning the lack of xrandr in omapfb, but one in fbdev would do as well
<gregoiregentil> suihkulokki: Yup. very long story with Koen about this. Ideally, it would be better to ahve something really optimized in omapfb
<gregoiregentil> Koen told me that there is a Stanford guy who is working on it
<lool> gregoiregentil, rcn-ee: I just added a --script (untested) in this patch http://paste.ubuntu.com/354096/ which I just pushed at lp:~lool/project-rootstock/user-script if that's useful I'll propose it for merging in tip
<gregoiregentil> yup. Definitely makes sense to me
<lool> Ok, proposed for merging
<lool> gregoiregentil: hy BTW
<lool> *hey
<gregoiregentil> lool: Hello
<lool> gregoiregentil: I've seen a netbook with detachable screen in the CES coverage, but I don't think i was branded always-innovating; is this a derived product?
<rcn-ee> lool, that would be very useful, there's a couple things i have beagleboard users do to tweak the final rootfs...
<rcn-ee> (that are too beagleboardish to be generic for all users)
<gregoiregentil> Not a derived product... I would say a copied product!
<lool> Ok; that's what I guessed
<rcn-ee> lool, ogra: at what point do you guys what lucid tweaks for rootstock to enable lucid?
<armin76> lool: well, i would say that you mean the freescale reference netbook...but i guess its built by pegatron
<armin76> you should know it :P
<armin76> also there is the marvell smartbook
<lool> rcn-ee: I didn't understand the question
<armin76> which was running ubuntu
<lool> armin76: I actually did not!
<lool> I only saw that netbook with removable screen like the AI one on TV for a split second and it looked too different from the AI one, hence my wonders
<rcn-ee> lool, since lucid is only at alpha-1/2 i was holding this back: http://bazaar.launchpad.net/~beagleboard-kernel/+junk/project-rootstock-lucid/revision/31
<armin76> lool: http://www.engadget.com/2010/01/07/freescale-smartbook-prototype-is-a-dockable-tablet-we-go-hands/
<armin76> http://www.engadget.com/2010/01/05/marvell-shows-off-an-odm-smartbook-thinner-than-strict-decency-p/
<lool> rcn-ee: IMO no reason to hold this back
<lool> rcn-ee: I'm rewriting this a bit, following the diff you showed me; thanks
<rcn-ee> cool, i was holding it back since fakeroot 'was' broken since i couldn't generate a deb for lucid, but as of this morning it works..
<lool> rcn-ee: Mind taking a look at http://code.launchpad.net/~lool/project-rootstock/lucid-support ?
<lool> rcn-ee: Ack; just saw a bug coment that it's fixed
<lool> rcn-ee: Sorry, not wasy to see a branch I just pushed
<lool> rcn-ee: https://bazaar.launchpad.net/~lool/project-rootstock/lucid-support/changes
<rcn-ee> lool, it looks like it's loading, btw is the bazzar web server always that slow? i'm use to it with pushing my beagleboard-kernel stuff.
<lool> rcn-ee: I rarely use the bzr web ui, but I don't think it's supposed to be slow once he branch has been scanned
<lool> rcn-ee: the launchpad web frontend is a tad slow due to SSL, lots of database queries, and various inefficiencies, but bazaar should be faster
<rcn-ee> lool, changes look good, the only odd case is jaunty as lucid/karmic share the same path...
<rcn-ee> lool, that make sense, i just got to stop watching my changes hit the web.. ;)
#ubuntu-arm 2010-01-10
<RaffoPazzo> Hi
<RaffoPazzo> Does anybody know why my ubuntu create /dev/event<X> instead of /dev/input/event<X> for the touchsreen ?
<gregoiregentil> Ping lool
<gregoiregentil> regarding the option --script in this patch http://paste.ubuntu.com/354096/ that we discussed yesterday and you proposed this patch
<gregoiregentil> I don't think that it's working because you copy the script into BUILDDIR which is not $MOUNTPOINT
<gregoiregentil> and you need the file in $MOUNTPOINT, not $BUILDDIR I think
<gregoiregentil> ... and I have tested :-(
#ubuntu-arm 2011-01-03
<rsalveti> morning
<rsalveti> ogra: getting back to work I believe the main issue for getting images is the u-boot mkimage transition
<rsalveti> for some reason people decided to remove it first before fixing the archive
<rsalveti> to be faster than debian, but this is still being discussed there
<rsalveti> ogra: and something would be good to have a final conclusion is the kernel for omap 3, and trying to use the linaro one
<rsalveti> if not this week, at least let's have a discussion next one
<janimo> do pandaboard wlan work on natty? I installed the mavertick packages from TI PPA but they don;t seem to work (no chip found by modprobe)
<ogra> rsalveti, i'd like to solve it this week
<ogra> depending on workload
<rsalveti> yeah
<ogra> for mkimage we're waiting for the MIR
<ogra> i agree, it was bad to remove uboot-mkimage first, complain to lool
<rsalveti> janimo: hm, I believe you need to get a new wlan package
<ogra> not that the images did build though
<rsalveti> well, we got a broken image for days just because of the mkimage mess
<rsalveti> the package was removed at 12-14
<ogra> yep
<rsalveti> but yeah, still waiting for the MIR
<rsalveti> janimo: try using https://launchpad.net/~tiomap-dev/+archive/omap-trunk
<rsalveti> ogra: another thing is that I got a new x-loader package for omap 3 and omap 4, and will try to update it this week
<rsalveti> the good thing is that I'm building both from the same sources
<rsalveti> so one less package at the archive
<lool> ogra: Why complain to me?
<rsalveti> janimo: http://omappedia.org/wiki/Ubuntu_OMAP_trunk
<janimo> rsalveti: thanks. upgrading to that PPA now
<rsalveti> janimo: ti updated most packages for 10.10
<rsalveti> but natty is using the same kernel
<rsalveti> janimo: you may need a new x-loader
<janimo> rsalveti: hmm, does that affect the wlan chip?
<rsalveti> if you're using the latest natty's kernel
<lool> ogra: I didn't trigger the mkimage issues; the packages were automatically imported from Debian
<janimo> am using 35- 1001 I think
<rsalveti> janimo: not directly I believe, but it's good to use the new x-loader with latest kernel
<lool> ogra: I just noticed because I have mkimage on my laptop and I saw the uboot-mkimage package as obsolete after an upgrade
<ogra> hmm, so removals happen automatically ?
<janimo> rsalveti: but uBoot actually uses the kernel image on the first partition, and regardless of what I upgrade to on / that kernel is used still right?
<ogra> i thought that needs manual action
<ogra> then i dont blame you :)
<rsalveti> I believe it was manually removed
<rsalveti> but it wasn't lool
<lool> ogra: I have no idea whether they happen automatically; I didn't request removal, and I'm not an archive admin
<rsalveti> janimo: yes, but after a kernel update the flash-kernel tool is called
<rsalveti> and then it upgrades the kernel from the first partition
<janimo> ah, ok
<janimo> did not know that
<rsalveti> lool: ogra: bug 674904
<ubot2> Launchpad bug 674904 in uboot-mkimage (Ubuntu) "Please remove uboot-mkimage from the archive (affects: 1) (heat: 77)" [Undecided,Fix released] https://launchpad.net/bugs/674904
 * ogra rants a bit on that bug
<ogra> asac, are you still active in the MIR team (i.e. could you approve u-boot) ?
<asac> ogra: is that upstream u-boot?
 * asac thought we already had some u-boot in main
<hrw> I even made a patch for u-boot to ship uboot-mkimage transitional
<hrw> http://pastebin.com/g49n8Jde
<lool> asac: it's upstream u-boot
<asac> ogra: bug id please
<hrw> lool: can you finally review it?
<lool> asac: https://bugs.launchpad.net/ubuntu/+source/u-boot/+bug/692613
<ubot2> Launchpad bug 692613 in u-boot (Ubuntu) "[MIR] u-boot (affects: 1) (heat: 509)" [Undecided,New]
<ogra> bug 692613
<ubot2> Launchpad bug 692613 in u-boot (Ubuntu) "[MIR] u-boot (affects: 1) (heat: 509)" [Undecided,New] https://launchpad.net/bugs/692613
<lool> hrw: Ah right; I have it in my TODO for a while, I wanted to fix some small things and fix the i386 build issue as well, but didn't get to it before the break; sorry about that
<hrw> lool: happens. next time I will request bugs/reviews probably so others could look too
<lool> asac: uboot-mkimage was in main, and uboot-envtools is in main; uboot-mkimage is gone and was a fork of the upstream u-boot code
<asac> lool: ftbfs on i386
<asac> https://launchpad.net/ubuntu/+source/u-boot/2010.12~rc2-1ubuntu1
<lool> hrw: Note that the package name will change too, so I expect we will have to do another round
<lool> asac: I've noted that in the MIR
<asac> lool: does this ship anything besides uboot-mkimage?
<asac> e.g. any u-boot bootloader?
<lool> asac: Yes; it ships u-boot
<lool> asac: but we don't use these images
<lool> the Debian maintainer is semi-convinced that we need to split mkimage in a separate package
<asac> lool: so no: http://paste.ubuntu.com/549796/
<lool> This is discussed in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=594937
<ubot2> Debian bug 594937 in u-boot "u-boot: Create binary package for each supported machine instead of for each architecture" [Wishlist,Open]
<asac> not a single relevant bootloader for ubuntu ;)
<ogra> nah
<lool> asac: It's the Debian package
<asac> couldnt we at least produce omap3 from that source?
<ogra> theoretically we could
<lool> asac: I don't see any harm in keeping whatever Debian maintains; we don't care about the bootloader bits
<rsalveti> but we're using the linaro one for that
<ogra> right
<rsalveti> for both omap 3 and omap 4
<lool> I don't see why we should move away of Linaro's u-boot
<ogra> we would have two omap source packages again (linaro omap4 and debian omap3) it would somehow defeat the purpose of unifying but techincally we could indeed build the omap3 binary
<ogra> and i belive there is work going on in debian to actually do that
<asac> i would prefer to wait for u-boot-tools to arrive from debian ... until then couldnt we just use one of our existing u-boot packages to provide mkimage
 * ogra remembers a discussion about building official debian omap3 kernels, they will for sure also build bootloaders if they do that
<lool> asac: Well, we could split u-boot in two in the way that we anticipate Debian to do it and provide the patch
<asac> right
<asac> thats fine with me
<lool> and by we, I obviously don't specifically mean me  :-)
<guerby> rsalveti, hi and happy new year :)
<rsalveti> guerby: hey!
<rsalveti> happy new year!
<guerby> rsalveti, my pandaboard still freeze every few days, did you get any feedback from TI on https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4/+bug/690370 ?
<ubot2> Launchpad bug 690370 in linux-ti-omap4 (Ubuntu) "Strange out of memory on pandaboard (affects: 1) (heat: 202)" [Undecided,New]
<rsalveti> guerby: ti is getting back to work today too, so I expect something this week
<guerby> rsalveti, ok great! thanks for your work on this. I'm still  hoping to put the pandaboard online :)
<rsalveti> guerby: sure, will try to do some work on this bug this week
<ian_brasil> my membership of ubuntu-mobile is due to expire - is this team deprecated now?
<ogra> yep
<ogra> if you are intrested in arm work, there is ubuntu-armel
 * hrw will look at uboot/i386 ftfbs
<ogra> hrw, i doubt thats easily solveable without a package split
<lool> hrw: see u-boot mailing-list
<lool> hrw: I propose two fixes; the maintainer of the board says he is working on sending the patc h
<lool> hrw: I think we should just send two patches
<hrw> lool: official uboot ml one?
<lool> hrw: Yes
<lool> hrw: MID 20101220111358.GA28532@bee.dooz.org
<hrw> lool: author name would be better...
<hrw> gmane lacks mid search
<lool> hrw: It does have it
<lool> hrw: http://mid.gmane.org/20101220111358.GA28532%40bee.dooz.org
<hrw> ok, thx
<aksh1> hi all , i have downloaded  http://rcn-ee.net/deb/rootfs/maverick/ubuntu-10.10-r3-minimal-armel.tar.7z
<aksh1> how to install unity in that
<aksh1> to create a netbook image
<rsalveti> aksh1: if you're using this rootfs already then you just need to install unity, but it doesn't work that well with GL ES
<aksh1> rsalveti, then do i need to do any changes ?
<rsalveti> aksh1: you need to install the unity package
<aksh1> rsalveti, but you told that it doesn't work well
<aksh1> with GL ES
<rsalveti> aksh1: sure, I wouldn't recommend to use it with gl es
<rsalveti> you can, but it's very slow and crashes a lot
<rsalveti> that will be fixed for natty
<aksh1> rsalveti, what will be the best
<rsalveti> for now on arm the efl netbook interface is the best option
<rsalveti> or other wm like xfce
<aksh1> rsalveti, how about lxde
<aksh1> which is good better performance  in xfce4 and lxde
<rsalveti> aksh1: could be, just never tried
<ogra> ion surely has the better performance ;)
<rsalveti> I'd use evilwm
<rsalveti> :P
<ogra> heh
<aksh1> evilwm ?
 * ogra always loved wm2 
<rsalveti> evilwm is a very minimal wm
<rsalveti> you can only open a terminal with it hehe
<rsalveti> and move it
<ogra> wm2 already has a tasklist
<ogra> and shiny window decorations
<ogra> ogra@ac100:~$ apt-cache show wm2|grep -i size
<ogra> Installed-Size: 116
<ogra> Size: 33096
<ogra> ogra@ac100:~$ apt-cache show evilwm|grep -i size
<ogra> Installed-Size: 96
<ogra> Size: 30236
<ogra> hmm, but evilwm wins the size battle
<aksh1> rsalveti, i am looking a wm with full fledged gui to test utouch
<rsalveti> ogra: ;-)
<ogra> i guess you cant have bling without paying for it ;)
<ogra> aksh1, then take the efl launcher
<janimo> GrueMaster: I get banshee UI coming up over ssh -X and I can use the menus. no crash so far
 * janimo has just started banshee for the first time ever
<GrueMaster> Interesting.
<janimo> last liune in the log is [Info  19:58:16.396] nereid Client Started
<janimo> so right before you see the exception
<janimo> this is an up-todate natty on pandaboard
<GrueMaster> same here/
<GrueMaster> Will try normal desktop to see if it is a netbook-ui issue.
<GrueMaster> Nope, still fails.  Different error though, but I suspect the root is the same.
<ogra> did you wash your fingers before firing it up ? its very fragile ;)
<janimo> GrueMaster: so you can reproduce on panda/natty too?
<GrueMaster> This is panda/natty.
<janimo> ok
<janimo> within seconds from startup?
<GrueMaster> yes.
<janimo> can you check if it crashes with ssh -X too?
<janimo> not that it should be much of a difference
<GrueMaster> It doesn't stay up long enough to use the menus.  Will try ssh -x.
<janimo> just to make sure I can try reproduce without pulling out the HDMI cable
<janimo> which means no dual monitor on my workstation :D
<GrueMaster> Also, I am not getting any window frames in classic desktop mode.
<GrueMaster> (different issue).
<ogra> GrueMaster, remove maximus or disable it in the session settings
<ogra> i thought i had solved that one in maverick
<ogra> is that a maverick->natty upgrade ?
<ogra> or a plain natty install
<janimo> FYI mine is a natty image made with rootstock
<ogra> ah
<ogra> dont trust rootstock
<ogra> its as close as possible to a real install, but after all not identical
<rsalveti> ogra: alsa-utils is still broken :-)
<rsalveti> another package to fix soon
<ogra> yeah
<ogra> first images ... then packages
<rsalveti> sure
<ogra> i also have a broken shadow to fix and doko slowly gets nasty
<GrueMaster> ogra: This is the last natty image prior to mkimage snafu, updated to latest packages.
<ogra> k
<ogra> thx
<ogra> that should have the fixed maximus
<ogra> keep the pieces until next week and i'll take a look
<janimo> ogra: rootstock is recommened in the wiki, it is no longer to be used?
<rsalveti> janimo: it's ok to use it
<janimo> are there better ways to do the same?
<rsalveti> but while reproducing issues, the best option is to use the preinstalled image
<janimo> ok
<ogra> janimo, rootstock is o for building for unsupported HW, for test and development images, but you will only get 100% identical results on the real images
<ogra> s/o/ok/
<rsalveti> just because the supported images are the preinstalled ones
<janimo> I used rsalveti's instructions to have / on an external USB drive so could not really use the preinstalled image
<ogra> there is no guarantee that rootstock builds 100% the same as we do with the preinstalled image
<ogra> s
<janimo> it is much much faster this way that on SD card
<janimo> well probabaly not the same, but for individual user space app testing I think there should be no differences
<rsalveti> janimo: sure, while debugging and building stuff the usb disk usage is the best option
<rsalveti> but while reproducing and testing bugs, try using the preinstalled one
<ogra> the setup might differ
<aksh1> i have installed plymouth and updated initrd using update-initramfs -u
<aksh1> do i need to change boot commandline
<ogra> rootstock doesnt track what changes are in oem-config for example
<aksh1> mem=512M console=ttyS2,115200n8 console=tty0 omapfb.mode=dvi:hd720-24@60 root=/dev/mmcblk0p2 rw rootwait  is my commandline
<ogra> so if you use rootstock and set up a user from cmdline, your user setup might be different
<ogra> the way we build the image with rootstock isnt 100% identicaql to livecd-rootfs so fixes that go in there might not be in rootstock
<ogra> etc etc
<ogra> aksh1, add quiet and splash as keywords
<ogra> and make sure your boot setup uses the uInitrd indeed
<aksh1> ogra, i am not sure uInitrd updated one is used while booting
<aksh1> bcoz default initrd will get updated in /boot/ folder and beagleboard has other /boot partition
<ogra> any reason why you didnt use one of the official netbook images for the beagle ?
<ogra> you wouldnt have to fiddle with that now
<aksh1> ogra, want to know how to create similar image
<ogra> well, the same things i wrote for janimo above apply to these images since they are built with rootstock ... they are "similar" but not identical
<GrueMaster> ogra: I looked at the image and maximus is not running while in classic desktop.  I have plenty of SD cards, so I will preserve this one for you to eval.
<ogra> things like the bootloader setup definitely differ heavily
<ogra> GrueMaster, weird, maximus isnt running but you dont get window borders either ?
<GrueMaster> nope.
<ogra> sounds more like metacity being broken
<ogra> unless
<ogra> hmm
<ogra> i heard roumors that metacity would be dropped in favor of a 2D compiz
<ogra> not sure what the status on that is
<GrueMaster> ogra: http://members.dsl-only.net/~tdavis/Screenshot.png
<GrueMaster> Apparently, compiz is the registered WM currently running.
<ogra> aha
<ogra> so thats likely a 2D compiz bug then
<ogra> i think the code is very very young
<davidm> ogra, http://www.viewsonic.com/gtablet/spec.htm
<GrueMaster> must be.  There is no compiz-config utility installed.  grrr,
<ogra> davidm, hmm, sounds like the folio you can buy here
<rsalveti> interesting
<aksh1> ogra, after adding quiet splash it is giving kernel panic
<aksh1> http://pastebin.com/6xyZksqq
<ogra> if its the same, it is overpriced, very bad android adaptions, very bad touchscreen
<GrueMaster> I was emailed info on this:  http://www.tangent-tycoon.com
<rsalveti> very bad android adaptations is kind of expected
<rsalveti> but not a bad touchscreen
<GrueMaster> I asked if we could get some eval units to install a real OS, but no reply.
<rsalveti> GrueMaster: very very ugly hehe :-)
<rsalveti> ubuntu should be a lot better
<GrueMaster> 120GB HD.  2Gb ram.  Just to run Win7 POS edition.
<rsalveti> ouch
 * rsalveti takes a break
 * ogra thinks the galaxy is the only serious ipad competitor atm
<GrueMaster> 1.87 lbs.  I think my netbook is lighter.
<ogra> yeah
<ogra> mine surely is (700grams)
<ogra> :)
<GrueMaster> Heh.  To get the extended battery version, you have to buy it with Win7 Pro.
<GrueMaster> $100 difference.
<GrueMaster> $595 or $695.
#ubuntu-arm 2011-01-04
<micahg> hi, does DEB_BUILD_ARCH = armel for the native builders?
<hrw> morning
<lool> micahg: Yes; but it's usually a bad idea to check this
<StaRetji> is there a link for geexbox image for arm platform?
<ogra> looking at the u-boot packaging i now understand why lool didnt want to do the package split
<ogra> sigh
<ogra> no compat file, no build deps, debian/rules looks horrid ...
<ogra> why cant people just use a proper build system instead of making up debian/rules by hand
<lool> ogra: I actually committed an u-boot-tools package in the Debian git repo this morning
<ogra> oh, cool
<ogra> this rules file is just painful
<ogra> lool, any ETA when that will be in debian (i need it asap so i'm pondering to add it as patch for ubuntu)
<apw> GrueMaster, can you remember what failed in your testing of omap from natty master
<micahg> lool: what's the proper way to check if something is an arm build vs not arm?
<hrw> micahg: 'arm build' as 'build on arm' or as 'build for arm'?
<micahg> hrw: build on arm
<hrw> 'uname -m' may be but debian packagers will want to kill you for it probably
<micahg> right, I was looking at DEB_BUILD_ARCH, but apparently, that's not the best way?
<hrw> micahg: why you need check?
<micahg> hrw: --enable-thumb2 fails the firefox build on non-armel builds
<hrw> ah
<hrw> rules2:  ifneq (,$(findstring $(DEB_TARGET_ARCH),armel hppa ia64 sparc))
<hrw> micahg: so use DEB_TARGET_ARCH check
<hrw> DEB_BUILD_ARCH = amd64 DEB_TARGET_ARCH = armel is 100% proper btw
 * micahg is getting DEB_TARGET_ARCH not supported on maverick
<hrw> let me check how gcc do that
<lool> micahg: It's uncommon to check the architecture of the buildd
<lool> micahg: Usually you test what you're building /for/
<lool> DEB_HOST_ARCH is the Debian architecture of the machine the package will run on
<hrw> rules.defs:  TARGET_VARS := $(shell dpkg-architecture -f -a$(DEB_TARGET_ARCH) 2>/dev/null)
<hrw> rules.defs:DEB_TARGET_ARCH              ?= $(call vafilt,$(TARGET_VARS),DEB_HOST_ARCH)
<hrw> ops
<lool> micahg: It would also be best to test the GNU CPU or something similar rather than the Debian architecture name; for instance the Debian armhf port is very similar to armel, but wont be covered by your test
<hrw> sorry - it is done by different way in gcc
<lool> micahg: Perhaps you could explain your specific problem?  I'm not sure I can comment on which var you should use, as you only asked about native builds but I might have missed when you explained what you're building
<lool> hrw: The packages like gcc which have the concept of a target architecture are fairly rare
<micahg> lool: well, I need to add a build option to arm only for firefox
<lool> micahg: Right, that's a good example of a case where you'd test DEB_HOST_ARCH, and *not* DEB_BUILD_ARCH
<lool> micahg: The main difference is when cross-compiling; when cross-compiling, DEB_BUILD_ARCH might be amd64 while DEB_HOST_ARCH is still armel
<micahg> ah, so HOST_ARCH is the right one, ok, that's good to know for the future
<micahg> thanks lool
<janimo_> micahg, I think it's a simpler change to not check at all and let ff configure drop the option if it is not suitable for the current arch
<micahg> janimo: I tried with it on for amd64 and the build failed
<janimo> micahg, did it pass march arm to gcc?
<lool> micahg: Just saw your firefox changes; would you mind if we discussed these for a sec?
<micahg> lool: actually, I'm about to catch a bug, can we chat in a few hours?
<micahg> *bus
<lool> micahg: Sure; I will send you an email
<micahg> janimo: I have to check the build log
<janimo> lool, you mean the change in the latest upload or something else?
<micahg> lool: thanks
<lool> janimo: Yes, the THUMB2 one
<janimo> lool, I suggested that one to micahg to fix the FTBFS. Tested on a panda before that.
<janimo> the details may need to be done differently but I think that flag needs to be passed
<lool> janimo: Yup; do you want to be Cc:ed?
<janimo> lool, sure
<lool> Hmm apt-cache showsrc janimo wont give me your email address
<janimo> jani at ubuntu.com
 * lool <- tired
<lool> janimo: thanks
<ogra> lool, is there any ETA for the debian u-boot upload or do we need to add the package split as ubuntu patch to get it in this week ?
<ogra> (i think you disconnected above when i asked before)
<lool> ogra: I've contacted Clint this morning to ask him to review these changes; they will hit Debian NEW in any case, so that will probably take some time; however, it wouldn't be too bad to copy the NEW package in Ubuntu
<ogra> lool, do you get any notification you could forward if that happens ?
<ogra> (i mean if it hits NEW, I'll care for teh sync requests etc)
<lool> ogra: Unfortunately, one can't sync from NEW; if I'm doing the upload, I'll tell you once it's done
<ogra> thanks
<GrueMaster> Morning (barely).
<GrueMaster> ogra: rsalveti:  apw: The issues I saw with the previous omap kernel prior to the break was that it literally didn't boot.  I couldn't get any feedback past u-boot loading the kernel.  Not even output from earlyprintk.
<GrueMaster> I'm installing the new kernel now.
<rsalveti> GrueMaster: yeah, I'll also try it here, and then try to fix it if it doesn't work
<GrueMaster> Hmm.  Currently, it appears to be stuck on installing the linux-headers package.
<apw> installing things in general is slow i think if you have the older dpkg
<rsalveti> doesn't seems to boot, will now debug to see why
<GrueMaster> Looks like I was getting a segfault loop of some sort.  Rebooting.
<apw> rsalveti, thanks
<apw> rsalveti, are u gettting any console output at all ?
<rsalveti> apw: nops
<apw> rsalveti, that sound fun to debug
<rsalveti> apw: :-)
<ogra> sounds like an issue with the console driver
<ogra> do you have a monitor attached or do you try purely with serial ?
<rsalveti> hm, ok, got something with earlyprintk
<davidm> folks, the weather report for Dallas is cold next week Daytime 8.3C and nighttime -2.77  Colder then usual around here
<davidm> For some of you that is warmer then you are at but for us it's cold
<rsalveti> ouch, very cold for me hehe
<rsalveti> it's around 30C everyday around here
<rsalveti> good to know
<GrueMaster> I vote we relocate to Sao Paulo.
<rsalveti> hehe :-)
<ogra> at least i wont catch a cold
<ogra> we have constantly around -3Â°C here (day and night)
<rsalveti> ogra: apw: GrueMaster: ok, did boot, you now need to use ttyO2 instead of ttyS2, like panda
<rsalveti> because of the newer console driver
<ogra> awesome
<rsalveti> but I'm now getting tons of mmc i/o errors
<rsalveti> probably a different issue, more debugging
<GrueMaster> I had tried that when I tried the older kernel.
<apw> rsalveti, sounds good!
<rsalveti> apw: will test it more around here, and compare the config with linaro's one
<apw> GrueMaster, the kernel he is testing is two -rc's newer than the one you tested before xmas
<GrueMaster> I know.
<GrueMaster> Just saying that I had tried both serial port settings.
<apw> GrueMaster, good to know, as that means things have improved by osmosis
<rsalveti> apw: ogra: GrueMaster: full maverick desktop up and running
<rsalveti> rebooted and now I didn't get any i/o error
 * rsalveti trying again
<ogra> wohoo
<ogra> apw, so can we get omap3 back ?
<rsalveti> no calltrace during the bootlog
<rsalveti> I believe this could be a good start
<rsalveti> then we can just improve over the time, with more testing and etc
<ogra> yeah
<rsalveti> at least I believe it's good enough to get images
<apw> rsalveti, did you say that you have booted this one successfully ?
<ogra> yes he did :)
<rsalveti> apw: yup, 2 times
<apw> GrueMaster, does it boot for you too ?
<ogra> who cares about GrueMaster :P
<rsalveti> let me know try with a normal beagle
<rsalveti> tried with a beagle-xM
<rsalveti> *now
<GrueMaster> I'm having other non-kernel related issues atm.  Will try again shortly.
<ogra> he always manages to break even the super solid things ;)
<GrueMaster> It's my job, that's what I do.
<GrueMaster> I was hell with my toys.
<ogra> lol
<rsalveti> haha
<apw> ogra, ok tehcnically i can get this renabled yes, so you are going to use this kernel not the linaro in your images, thats the decision
<apw> and your team is going to sign up to keeping it tested and working
<ogra> yes
<ogra> and yes
<rsalveti> :-)
<GrueMaster> bring it, big guy.
<GrueMaster> rsalveti: Did your patch for the serial port error on XM ever get integrated into the maverick kernel?
<ogra> i think i saw some noise about it this week
<rsalveti> GrueMaster: it's commited already I believe
<rsalveti> let me check again
<ogra> yup, mail says "applied"
<GrueMaster> ok, haven't seen it in proposed yet.
<ogra> not uploaded
<apw> yeah -proposed is somewhat behind Fix Committed over this xmas perios
<rsalveti> not uploaded, it's commited at the master-next
<apw> period
<rsalveti> ogra: apw: GrueMaster: ok, also working fine at my beagle c4
<rsalveti> so it seems to be good enough
<ogra> yay
<apw> ogra, so we are saying beagle is the target for the omap kernel
<ogra> apw, XM
<rsalveti> apw: yep, xM will be our main use case
<rsalveti> as it's now quite popular
<rsalveti> and faster than a normal beagle
<apw> so the acceptance criteria for that omap kernel is 'works on Beagle XM'
<ogra> ++
<rsalveti> yup
<loafhead> MADISON, Wis. - Madison police are looking for a burglar who gave back a bottle of tequila after the homeowner hit him in the head.
<loafhead> oops
<loafhead> wrong window ;)
<rsalveti> apw: the config seems fine comparing with the older one from maverick and with linaro's one
<apw> rsalveti, thanks for the confirmation
<GrueMaster> My 8G Class 10 SD cards finally came in.  Woohoo!
<rsalveti> luck bastard
<armin76> 8g class= nice, new class? :D
<ogra> class 10 isnt that new
<ogra> rsalveti, do you need any? i can buy them at the discounter and bring you some to the rally
<rsalveti> ogra: would be good to have, I have none around
<rsalveti> ogra: how much it cost usually around there?
<ogra> i'll have to check, i'll just bring a few, if you dont want them (or they are to expensive) i'll take them back again
<rsalveti> ogra: cool, would like at least 2 :-)
<ogra> ok
<rsalveti> np, just to know, here the problem is that I can't find them easily
<rsalveti> or without spending too much money
<GrueMaster> I bought 2 8G for just under $30.  Last cycle, they were $45 each.
<rsalveti> nice, good price
<GrueMaster> amazon.com
#ubuntu-arm 2011-01-05
<elesueur> hi everyone - can someone tell me the state of CPU power management (cpufreq/cpuidle) for the omap4 port of ubuntu, and suggest a place where power management discussions take place?
<rsalveti> elesueur: latest omap 4 kernel for natty should support pm already
<rsalveti> elesueur: for omap 4 try #pandaboard
<elesueur> thx, will ask at #panda
<rsalveti> elesueur: our tree http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-natty.git;a=shortlog;h=refs/heads/ti-omap4
<rsalveti> and at https://launchpad.net/ubuntu/+source/linux-ti-omap4 you can find the deb files
 * rsalveti brb
<elesueur> out of interest, which cross compiler are you using to compile kernels?
<rsalveti> elesueur: the one available at ubuntu already
<rsalveti> from linaro
<TheUni> rsalveti: ping
<rsalveti> if you're using maverick or natty at your desktop, just try searching for packages with arm in the name and you'll find
<rsalveti> TheUni: pong
<TheUni> ah, good timing, you're here :)
<rsalveti> yup :-)
<TheUni> rsalveti: are you still looking at xbmc as a possiblity for the stb distro? I ask because we're working on our roadmap for 11.0
<rsalveti> TheUni: was going to ping you until the end of this week, how is xbmc going?
<rsalveti> TheUni: it all depends on the current state
<TheUni> rsalveti: going great. finally completed our merge to git today
<TheUni> that was the first big priority after stable
<rsalveti> we can for sure add to the archive, and then use it by default for 11
<rsalveti> cool
<TheUni> rsalveti: ok, tell you what...
<TheUni> we have 1 big merge to go.. where all code is being rearranged to help with buildsystem and packaging woes
<TheUni> how bout i ping you after it's merged and we can evaluate the state of things?
<rsalveti> TheUni: hm, ok, any important feature to add? or just buildsystem related changes?
<rsalveti> TheUni: sure!
<TheUni> rsalveti: new features in the next version ofcourse, but we see this as a major cleanup version as well
<rsalveti> oh, ok, good
<TheUni> we'd love some help from the ubuntu side of things with packaging and etc.
<TheUni> (developing good habits, i mean)
<rsalveti> TheUni: sure, can help on that
<TheUni> ok great. will ping you soon. should be going in as soon as we can get it rebased and tested a bit
<rsalveti> just ping me when you think you're in a good shape
<TheUni> yep. thanks :)
<rsalveti> nice
<rsalveti> np :-)
<jo-erlend_> any news regarding natty on omap3?
<rsalveti> morning
<ogra> so it is (kind of)
<rsalveti> :-)
<dcordes> morning
<ian_brasil> i cannot chroot into the kubuntu mobile natty image..i get a qemu fatal error
<rbelem> ogra, ^ :-D
<rsalveti> ian_brasil: what are you using as host?
<rsalveti> user emulation should depend more on your host and your qemu version
 * rbelem pokes ian_brasil 
<ian_brasil> my host is i386
<rbelem> ian_brasil, which ubuntu version?
<ian_brasil> 0.12.5 of qemu
<ian_brasil> rbelem: natty
<rbelem> ian_brasil, installed on you laptop?
<rbelem> *your
<rbelem> :-D
<ian_brasil> yes
<rbelem> :-o
<rbelem> rsalveti, ^
<ogra> did you install the binary inside the chroot ?
<rsalveti> hm, should be fine
<ian_brasil> ogra: yes
<rsalveti> ian_brasil: which image are you using? I can try to reproduce it over here
<ian_brasil> http://cdimage.ubuntu.com/kubuntu-mobile/daily-preinstalled/current/
<rsalveti> ian_brasil: ok, give a moment and will try over here
<ian_brasil> rsalveti: thx
<rsalveti> vstehle: https://code.launchpad.net/~afrantzis/+junk/egl-composite
<ogra> wigh, thunderbird is a beast
<ogra> *sigh even
<rsalveti> ian_brasil: user mode emulation working fine around here
<rsalveti> with latest natty
<rsalveti> my qemu: 0.13.0+noroms-0ubuntu10
<rsalveti> try updating your natty host
<ian_brasil> ok..thx
 * rsalveti lunch
<GrueMaster> How is it we can build kubuntu-preinstalled images and not our ubuntu-netbook-preinstalled images?
<ogra> ??
<GrueMaster> ogra: We haven't had a daily image since 12/14 because of the u-boot mkimage issue.  Yet I am able to download an image for kubuntu from http://cdimage.ubuntu.com/kubuntu-mobile/daily-preinstalled/20110105/natty-preinstalled-mobile-armel+omap4.img.gz.zsync
<ogra> doe it boot ?
<ogra> *does
<ogra> might be that there is jasper missing in the kubuntu live seed
<GrueMaster> Not sure yet.  Just started downloading it.
<ogra> try it
<ogra> i would guess they miss a jasper dep
<GrueMaster> Ok, finally got it downloaded.  Looks like it is missing the boot partition in the image.
<ogra> yeah, thats what i thought
<ogra> dunno who implemented support for these images, but it seems thats only half way done
<GrueMaster> Any word on when our issue will be fixed?
<ogra> our issue ?
<ogra> which of the 100s we have ?
<GrueMaster> mkimage dependency.
<ogra> once lool uploaded the changed u-boot to debian
<ogra> i'll then pull it over
<ogra> or we'll sync it
<ogra> i hope that happens this week so i have time to get images up before sat.
<GrueMaster> So we have a high chance of not having images for the sprint.  Fun.
<ogra> just pray that the archive is in sync
<ogra> well, if we dont have u-boot in by friday i will manually roll an ubuntu0 package (which will get replaced by a debian sync then) from the debian u-boot git
<janimo> anyone using the wlan interface on panda without a netowkr manager?
<ogra> i'm not thrilled either but now its broken, so we need to make the best out of it
<janimo> I cannot set it up via iwconfig only - usin gopen auth and no encryption
<ogra> iwconfig is blocked as long as NM runs
<ogra> right click on NM and disable wireless networking
<ogra> then iwconfig should work
<janimo> I have no nm installed
<ogra> oh
<janimo> server install
<janimo> well it sets ad-hoc or managed mode
<janimo> but not essid
<janimo> so it works but not all args
<ogra> even if you hand it over manually ?
<janimo> I am only trying manually for now
<ogra> i havent tried a server install for wlan ever i think
<ogra> probably you miss some bits
 * janimo goes back and checks wifi setup
<ian_brasil> ogra: you can boot the kubuntu-mobile preinstalled images using the meego kernel
<ian_brasil> or the linaro one hopefully when it is done
<ogra> ian_brasil, without the first partition you cant boot them on anything
<ogra> at least not on any of the archjes we are building these images for
<ogra> this is broken and needs fixing
<ian_brasil> ogra: what is the best way to do that?
<ogra> i have to look at the build scripts why the partitions are not created
<ogra> will do that next week at the rally
<ogra> or NCommander can take a look
<ian_brasil> rally ?
<ogra> new name for sprint
<ian_brasil> I live and learn
<ogra> heh
<ogra> \o/ omap3 kernel is back
<rsalveti> ogra: \o/
<rsalveti> then we're just missing the proper u-boot fix
<MartynB> so, microsoft is making the SDK available almost immediately for windows 8 ARM
<MartynB> looks like almost all the SoC vendors have been invited to play
#ubuntu-arm 2011-01-06
 * ogra twiddles thumbs ... omap3 kernel still building
<berco> Hi
<berco> I was wondering why the OMAP3 kernel symbols are available in http://ddebs.ubuntu.com repo but not the package for OMAP4
<berco> Is there a reason for this?
<ogra> ask #ubuntu-kernel, they do the packaging
<berco> ogra: thanks
<ogra> theoretically omap4 should be there as well
<ogra> if the ddebs are missing for it we should build them
<berco> ogra: I only see linux-image-2.6.35-22-omap-dbgsym
<ogra> yep
<ogra> berco, hmm, i see omap4 now that i'm looking
<ogra> http://ddebs.ubuntu.com/pool/main/l/linux-ti-omap4/
<berco> ogra: I only added "deb http://ddebs.ubuntu.com/ maverick main" to my sources.list and I don't see it
<berco> ogra: what is the proper syntax for sources.list?
<ogra> depends
<ogra> are you using the kernel from proposed ?
<ogra> or is there one in -updates you use
<berco> if I want the one from 10.10
<ogra> (and indeed, did you run apt-get update after changing sources.list)
<berco> yep :)
<berco> I did run update
<ogra> well, there is definitely a kernel in maverick-updates
<ogra> so you likely run that one
<ogra> which needs to be reflected in your sources.list entry i think
<ogra> dpkg -l|grep linux-image|grep omap4
<ogra> see what version is installed
<ogra> worst case just wget it and dpkg -i
<berco> ogra: yeah, I wanted to answer a partner is trying to get our kernel symbols
<ogra> (also note that the unstripped kernel is around 200M big)
<berco> personnaly I run the kernel that we posted in omap-trunk public PPA
<ogra> ah
<berco> so that makes me think we should also push the kernel symbols for our trunk version, right?
<berco> there's no process on launchpad to do this automatically?
<ogra> i dont think so, it produces really huge packages ... you can just create a dbgsym package by default though
<ogra> (dont ask me how, never did that)
<berco> ok, when I add maverick-updates, I see the OMAP4 kernel.
<ogra> right
<ogra> thats what i thought
<berco> ogra: thanks
<ogra> http://wiki.debian.org/DebugPackage
<ogra> for your ppa kernel, you should be able to just change debian/control as described there
<berco> ogra:  it sounds good. I'll discuss with sebj
<alberto> i have downloaded ubuntu for beagleboard (mine is revision c4) and it works fine. The problem is that the usb hub does not power up. Does anyone know the solution for that?
 * rsalveti lunch
<davidm> G'day all
<davidm> ogra, have you seen persia at all this week?
<ogra> not at all
<ogra> i was already wondering yesterday
<davidm> I've been emailing  and calling with no response
<ogra> damned
<ogra> hopefully he is well
<davidm> I hope so
<rsalveti> yeah, since the last week of december
<rsalveti> no news
<janimo> ogra, managed to get iwconfig running eventually on the panda . The order of the arguments matters, and I did not know that
<ogra> ah
<janimo> so mode, channel and then essid
<janimo> saw how nm does it via iwevent
<rsalveti> interesting, didn't know that
<ogra> lool, i was planning to upload a build from the debian git if you dont do it ... then we need the MIR for u-boot-tools approved and the package promoted
<ogra> and only then i can change jasper to a new dep
<ogra> (and then we have to pray for the archive to not be out of sync :) )
<lool> ogra: There is no reason to push for it quicker in Debian; it wont make it to squeeze anyway, so I don't have any reason to request faster handling of it; I don't know how long it will take, but I would probably upload next week if I don't get feedback
<lool> but Ubuntu shouldn't block on Debian; the package name is agreed upon, so shouldn't be a big issue
<ogra> k
 * ogra sighs having to deal with git then
<ogra> i'll roll it tomorrow and upload an ubuntu0 package
<rsalveti> GrueMaster: just upgraded my natty rootfs and it seems fine, can also confirm that firefox is ok
<rsalveti> apparently no blocker bug
<GrueMaster> I'm in the process of updating now.
<GrueMaster> Ok.  Finally was able to pull down all the updates since yesterday.  Firefox is indeed working again (it was one of the updated packages).
<topfs2> Quick question, is it normal that the netbook UI is rather slow on panda?
<achiang> hm, i have an imx51 system (lucid) where ureadahead doesn't seem to be running during boot. i have an upstart job, not sure why it's not firing
<achiang> ah, there we go, something in /var/log/boot.log -- terminated with status 5
<GrueMaster> rsalveti: Any idea as to why the ti-ppa doesn't install on Natty?
<GrueMaster> looks like a mime issue with gnome-open.
#ubuntu-arm 2011-01-07
<achiang> ah...
<achiang> looks like debugfs isn't enabled in my Kconfig, which ureadahead needs
<hrw> morning
<topfs2> does anyone know a good sample application for GLES, i.e. an application that is supposed to run well on ubuntu already and is in repositories?
<ogra> lool, u-boot 2010.12-1ubuntu1 uploaded
<hrw> ogra: how goes flash-kernel/efikamx merge?
<lool> ogra: cool
<ogra> hrw, in the works
<ogra> getting images has higher prio atm
<hrw> ok
<ogra> asac, mind to approve u-boot-tools in the u-boot MIR ? a u-boot with the split has been uploaded and built (waiting in binary new now)
<asac> ogra: i am late and out for 2h now (errands for travel etc.)
<asac> i will look after if you remind me again ;)
<ogra> asac, ok, i commented on the bug too
<ogra> i'll take care for binary NEWing it meanwhile
<apw> ogra, did the kernle make last nights image ok?
<ogra> apw, we cant build images atm due to uboot-mkimage breakage
<ogra> so i dont know if it would have made it
<ogra> i will take care of that on monday once we have sorted the image issues
<apw> ogra, i note d-i failed to build for armel, i assume it related
<ogra> apw, looks like it didnt fail but is dep-wait
<apw> ogra, yeah sorry, in dep-wait
<ogra> due to u-boot ;)
<ogra> Reading state information...
<ogra> E: Package 'u-boot' has no installation candidate
<ogra> apt-get failed.
<ogra> Package installation failed
<ogra> from the log
<ogra> hmm, crap we will have top revert all the dependency changes that u-boot introduced
<ogra> (since the package is actually called u-boot-tools)
<rsalveti> but I believe there's also a dummy uboot-mkimage package
<rsalveti> didn't check if the dependencies are correct yet
<ogra> rsalveti, doesnt help
<ogra> neither is in main yet
<ogra> first i need to get it de-NEWed
<ogra> then to main
<rsalveti> yeah
<ogra> but i dont think hdstrand is up yet
<ogra> he is archive admin of the day
<ogra> *jdstrand
<lool> ogra: Yes, the rdeps and rbdeps need to be transitioned
<lool> I had sent patches to do this, but they need to be updated for u-boot -> u-boot-tools
<ogra> lool, well, if u-boot stays out of main and the transitional package gets in that should suffice for a quick fix
<ogra> unless you dropped uboot-mkimage from all deps (which i dont belive)
<ogra> hmm, you dropped it from d-i, i see
<rsalveti> jasper should be fine
<rsalveti> u-boot | uboot-mkimage
<ogra> yes
<ogra> but d-i wont be
 * ogra branches d-i 
<lool> No it's not fine
<lool> I mean, not from sbuild's perspective for sure
<lool> So basically, it should be u-boot-tools | uboot-mkimage
<ogra> it will k
<ogra> it will be possible to build images
<ogra> which is our main concern atm
<ogra> jasper changes completely next week anyway
<lool> ogra: you want ot update flash-kernel as well
<ogra> ah, thanks
<ogra> well, it only suggests uboot-mkimage
<lool> ogra: No, flash-kernel-installer apt-installs u-boot and then falls back to uboot-mkimage
<ogra> oh, ok
<ogra> thanks
<ogra> lool, hmm, did you forget to commit the flash-kernel-installer change ?
<ogra> install_mkimage() {
<ogra>         if ! apt-install uboot-mkimage; then
<ogra>                 error "apt-install uboot-mkimage failed"
<ogra>         fi
<ogra> }
<ogra> thats all i can find in the source
<ogra> and grep returns no code for u-boot
<lool> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607614
<ubot2> Debian bug 607614 in flash-kernel "uboot-mkimage -> u-boot" [Minor,Open]
<lool> I thought I had uploaded that to Ubuntu as well
<lool> ogra: Actually, I failed to finish the implementation in Ubuntu
<lool> I did create a install_mkimage() function, but didn't update it for uboot-mkimage -> u-boot
<ogra> well, so we are fine for the moment
<ogra> :)
<ogra> if its in debian i will pull it in with the merge
<lool> you're merging flash-kernel?
<ogra> i have that pending since before vacation
<ogra> planned to do that on monday
<ogra> (actually i planned to do it this week, but now u-boot got in my way and images are more important)
<ogra> i have a half merged branch ready, just needs some touching up
<ogra> lool, why do you ask ?
<lool> ogra: Just out of curiosity
<rsalveti> ogra: u-boot should be fine now
<rsalveti> hopefully we'll be able to generate images over the weekend
<ogra> rsalveti, yep, all sorted
<jhobbs> for vexpress, has the http://www.linux-arm.org/git?p=u-boot-armdev.git;a=summary tree been superseded by the linaro u-boot git tree?
<mattwaddel> jhobbs: for vexpress, the linaro u-boot tree is the same as the main stream u-boot. I believe that is just a forward port of the code in www.linux-arm.org
<GrueMaster> ogra: were you going to manually push an image build prior to the sprint?
<ogra> GrueMaster, tomights omap4 should build, i didnt bother a manual build yet
<GrueMaster> ok, thought I'd check.
<topfs2> do people use maverick or natty for omap4?
<topfs2> I am currently running maverick but I've heard whispers that natty should have much intereting stuff, but sgx and such needs to work for my project :)
<ogra> we dont have sgx packages for natty yet
<ogra> so stick with maverick
<ogra> GrueMaster, if it fails i'll trigger a build on sunday, i'll arrive tomorrow evening already so i have the whole sunday
<topfs2> ogra: ok, thanks :)
<ndec> ogra: if I am correct, you should be able to grab the graphics packages from tiomap-dev/omap-trunk PPA. they should work with natty kernel...
<ndec> not 100% sure, though ;-)
<ogra> ndec, thats publically accessible ?
<ndec> ogra: sure
<ogra> topfs2, ^^^
<ndec> ogra: http://groups.google.com/group/pandaboard/browse_thread/thread/291bf9cbd8c36d15
<topfs2> cool
<topfs2> might try that out then
<Zotan> Has anyone used the instructions at http://42.pl/u/2u8U to rebuild the stock ubuntu maverick kernel? I can build the linux-linaro kernel but am struggling to rebuild the stock ubuntu one
#ubuntu-arm 2011-01-08
<aksh1>  why kernel and intrd need to copy in fat16 partition in sdcard
<aksh1> why not in ext2 like normal desktop system
<averule> how to boot ubuntu in arm board over ethernet card
<averule> or network
<averule> where can i get all documentation for nfs uboot setup info for tha same
<averule> the
<averule> hi all i am trying to boot using nfs-boot but getting error as ping failed; host 192.168.254.10 is not alive
<averule> i have setup nfs and tftp server my server ip i set using  ifconfig eth0 192.168.254.10 netmask 255.255.255.0
<averule> and connected ethernet cable to board
<rgriffit1> looking for documentation that explains the code in arch/arm/kernel/debug.S for example what does the \tmp syntax mean in the line addruart        \tmp1, \tmp2?
#ubuntu-arm 2011-01-09
<VitXXX__> hi
<VitXXX__> linux on pxa270? samsung i710?
<pH5> VitXXX__: ubuntu arm is compiled for armv7-a cpus, pxa270 is only armv5te
<VitXXX__> armv5te - what linux runing on it?
<VitXXX__> i`m use haret loader, but i don`t know what MTYPE on samsung i710 on pxa270, try to run android os... and other linux kernel...
<pH5> I don't know if anyone built a kernel for this device yet.
<VitXXX__> asus p535 and 525 on this cpu, but linux kernel on samsug not start
<pH5> That's because quite a bit of board specific setup has to be done (like configuring GPIOs and LCDC to correctly power on the display etc.)
<osborne6> I have a question on running with qemu-system-arm
<osborne6> I've followed the wiki's instructions, built an image with root stock, populated it...
<osborne6> and when I go to run the image, I get qemu: fatal: Unimplemented cp15 register write (c9, c12, {0, 0})
<osborne6> plus a short stack dump after a few minutes...
<rsalveti> osborne6: interesting, with which kernel?
<rsalveti> osborne6: and, which qemu version are you using?
<osborne6> versatile kernel, and the stock qemu packages from 10.04
<rsalveti> weird, afaik it should work fine
<rsalveti> osborne6: similar bug 570456
<ubot2> Launchpad bug 570456 in qemu-kvm (Ubuntu) (and 1 other project) "Unimplemented cp15 register write (c9, c12, {0, 0}) with Ubuntu OMAP image (affects: 2) (heat: 16)" [Medium,Fix released] https://launchpad.net/bugs/570456
<osborne6> interesting. I'll check that out.
<rsalveti> seems that this was fixed only for maverick
<osborne6> hmmm
<osborne6> thanks for the info!
<rsalveti> np
<sveinse> How can I check which compile and machine options are default enabled in arm-linux-gnueabi-gcc ?
<nevdull> -dumpspecs ?
#ubuntu-arm 2012-01-02
<LetoThe2nd> is there some known best practise to build/run the kernel on the pandaboard? to tinker around with changing or experimental peropherals....
<elementary-site0> Hey
<elementary-site0> I need help guys
<elementary-site0> I am so confused :/
<elementary-site0> I want to install an Ubuntu version of ARM to raspberry-pi ARM11
<elementary-site0> and I don't know which?
<elementary-site0> I can see armel-dove and armel-omap version and I don't know the difference or the process of doing it.
<elementary-site0> Anyone?
<elementary-site0> Is any of these the right one http://ftp.ntua.gr/pub/linux/ubuntu-releases-dvd/11.10/release/ ?
<amitk> elementary-site0: http://askubuntu.com/questions/71828/what-arm-single-board-computers-does-are-supported-by-ubuntu
<elementary-site0> amitk: Hmmm that helped, Thanks. I guess I am stuck with arch linux :/
<elementary-site0> or Debian
<amitk> yes
<elementary-site0> :)
<elementary-site0> They will ship Debian or archlinux cards. nice
<elementary-site0> Thanks amitk
<amitk> elementary-site0: no problem
<LetoThe2nd> is there some known best practise to build/run the kernel on the pandaboard? to tinker around with changing or experimental peripherals.... (platform is a pandaboard)
<ogra_> LetoThe2nd, same procedure as for any other platform running ubuntu ;)
<ogra_> either pull the git tree from kernel.ubuntu.com or use the source package
<ogra_> there should be a few wikipages from the kernel team
<LetoThe2nd> ogra_: ok, so the standard process will take care of the flashkernel things and such?
<ogra_> LetoThe2nd, as long as you build a deb from either of the above, yes
<ogra_> if you want to do it fully manual just copy vmlinuz to /boot/vmlinuz-$your_version ... then run sudo update-initramfs -u -k $your_version
<ogra_> update-initramfs runs flash-kernel at the end of its run in this case
<LetoThe2nd> ogra_: ah ok. but the manual thing is exactly what i do not want... why work around existing mechanisms?
<ogra_> (creating uImage from vmlinuz etc is handled by flash-kernel(
<ogra_> sure, if you feel like rolling a deb every time, do it like that ... it just takes more time
<ogra_> the result will be the same
<LetoThe2nd> thx, will look into it then :)
<ogra_> apart from the fact that dpkg doesnt know about tehz kernel in the manua case indeed
<ogra_> *manual
<LetoThe2nd> yeah. and package management not knowing about things always gives me that icky feeling...
<ogra_> sure sure ... but for quick tests i prefer the manual way... once i have a final solutio i put it into the package as a last step
<ogra_> *solution
 * ogra_ wonders where his chars went ....
<LetoThe2nd> i they prolly all transformed to longints.
<ogra_> heh
 * ogra_ happily closes his mailer ... ~4000 mails piled up in 10 days of vacation, sigh
<LetoThe2nd> ogra_: rm *.mbox
<ogra_> :P
<ndec> ogra_: hi! and happy new year!
<ndec> do you know if our PPA is now armhf enabled?
<ogra_> ndec, same to you !!
<ogra_> ndec, argh, not yet ... will ping you if its done
<ndec> ok. i am testing armhf now, with some luck it might work soon ( i mean the GFX part)
<ogra_> ndec, wow, thanks !!
<ndec> you will thank me when it works ;-)
<ndec> ogra_: i have a FS with precise armhf  and GFX seems ok... I am using openbox + xterm + DDK samples applications... not sure I will get more time to test a full desktop, but I could release what I have at least.
<ndec> if my PPA was armhf ;_)
<ogra_> ndec, yeah, IS is pinged but i didnt get an answer yet
<ogra_> does es2gears work ?
<ndec> ogra_: is there a pkg for it?
<suihkulokki> ndec: mesa-utils-extra or something close to that
<ogra_> right
<ndec> thx
<ndec> ogra_: yep. it seems to work. at least I can see a PVR warning...
<ogra_> awesome !
<ogra_> janimo, did you adjust the config to carry the newly enabled erratas in your ac100 upload ?
<ogra_> seems not having the causes hangs after a while
<ndec> ogra_: if i want to build armhf pkg from an armel FS with multi arch, is that supposed to work?
<ogra_> i dont think anyone tested or focused on hf vs el multiarch yet
<ogra_> so it *might* or might not work :)
<ndec> i can try... how do I install a armhf pkg in an armel fs?
<ogra_> iirc dpkg has teh option --foreign=$targetarch
<ogra_> so that would be --foreign=armel on hf ... and the other way round
<ogra_> ah, no
<ogra_> --foreign-architecture architecture
<ogra_> is what the manpage says
<ogra_> no equal sign
<ndec> ogra_: was trying to install metacity in armhf, it seems that libgtk-3-0 installs its stuf in /usr/lib/{triplet}gtk-3.0 now, however I get errors during configure with "Cannot load module /usr/lib/gtk-3.0/3.0.0/immodules/*.so". is that expected?
<ndec> i wonder how you can build a desktop image with this..
<ndec> ogra_: nevermind... this is not the root cause of my problem, that seems harmless..
<ndec> i have another problem...
<janimo> ogra_, which newly enabled erratas? I am not aware of any discussion/bug
#ubuntu-arm 2012-01-03
<LetoThe2nd> ogra_: ping
<ogra_> yep
<LetoThe2nd> ogra_: finally got around to build a pandaboard kernel as we talked yesterday. for simplicity, just using direct copy, but update-initramfs fails:
<LetoThe2nd> Kernel /boot/vmlinuz-3.2.0-rc7-carthag+ does not match your subarchitecture
<ogra_> why the + ?
<ogra_> add -omap4 instead :)
<LetoThe2nd> ogra_: no idea where it comes from.
<ogra_> juat cp the file
<ogra_> just
<LetoThe2nd> CONFIG_LOCALVERSION=-carthag
<LetoThe2nd> ogra_: make modules_install tells me the kernel itself believes it has to be called "+": DEPMOD  3.2.0-rc7-carthag+
<ogra_> well, the + seems odd
<LetoThe2nd> ogra_: yes, but the first part (searching modules) of update-initramfs only works if you keep the +
<ogra_> k
<ogra_> add omap4 to the localversion though ...
<LetoThe2nd> set to -carthag-omap4 now
<ogra_> k
<LetoThe2nd> ogra_: BTW, it is the tilt kernel from linaro that rsalveti pointed me to.
<ogra_> there should be debs of it already
<ogra_> and i think the ubuntu distro kernel is based on that branch (with ubuntu sauce on top though)
<LetoThe2nd> ogra_: i can't change the platform config in deb files ;)
<LetoThe2nd> ogra_: just for clarity: i use arch/arm/boot/zImage as the vmlinuz?
<ogra_> yep
<ogra_> update.initramfs is a script btw, you could also use a txt file as vmlinuz, it doesnt care
<LetoThe2nd> now modules_install says DEPMOD  3.2.0-rc7-carthag-omap4+
<rsalveti> LetoThe2nd: guess that's a problem with flash-kernel
<LetoThe2nd> rsalveti: but where does that "+" come from in the first line?
<rsalveti> that requires the filename to end up with -omap or something similar
<rsalveti> LetoThe2nd: guess that's part of the kernel scripts to generate the deb file
<LetoThe2nd> rsalveti: i'm not creating a deb, just dumb make.
<rsalveti> LetoThe2nd: that's interesting
<rsalveti> let me check here
<LetoThe2nd> rsalveti: its the most simple use case. native build on the panda with make.
<LetoThe2nd> BTW: how to git pull while i'm on the remote tilt-tracking?
<LetoThe2nd> ah, git pull origin tilt-tracking says up-to-date.
<rsalveti> LetoThe2nd: here I'm still pulling the branch
<LetoThe2nd> rsalveti: no need to hurry, i'm playing skyrim in the meanwhile ;)
<rsalveti> LetoThe2nd: haha :-)
 * LetoThe2nd is on vacation
<rsalveti> LetoThe2nd: yup, seems it adds + by default at the kernel name
<rsalveti> let me check the config options
<rsalveti> LetoThe2nd: # If CONFIG_KALLSYMS is set .version is already updated
<rsalveti> # Use + in front of the vmlinux_version rule to silent warning with make -j2
<rsalveti> from Makefile
<rsalveti> but could also be related with kernelrelease or linux_version_code
<rsalveti> probably something saying the kernel is the tag+ a few patches
<LetoThe2nd> rsalveti: yeah, that was also my first guess.
<doko> GrueMaster, about bug 903695, what is needed to get the "Verification-testing" done?
<ubot2`> Launchpad bug 903695 in kernel-sru-workflow/verification-testing "linux-ti-omap4: 3.0.0-1206.14 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/903695
<GrueMaster> Doko:  Regression-testing 	Fix Released  Undecided   Tobin Davis
<GrueMaster> that means I have already tested it and blessed it from my side.  Not up to me now.
<GrueMaster> Looks like it still needs sign-off from the ubuntu-armel-kernel team and the Canonical Security team.
<GrueMaster> Like I said two weeks ago, I am hardly the bottleneck on these SRU kernels.
<doko> GrueMaster, I'm just getting used to this "processes"
<GrueMaster> doko:  https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
<doko> ppisati, ^^^ looks to be your task ;-) there's only one member in the team
<ppisati> doko: nope, sru team
<doko> ppisati, confused, you're the only member in this team
<GrueMaster> Is it me or is launchpad being extremely slow?
<GrueMaster> ppisati: I'm getting ready to fire some bugs your way for precise omap4 kernel.
<dogan> hi
<dogan> can someone help me about configuring a new sd-card
<dogan> ?
<dogan> for ubuntu
<GrueMaster> dogan: What are you trying to do?
<dogan> thanks for reply :)
<dogan> first i want to know difference between maverick and narwhall distros?
<GrueMaster> Erm, lots?  What platform are you using?  Panda?
<dogan> yep
<dogan> Pandaboard
<dogan> just got it
<dogan> i want to work on a pay tv application
<GrueMaster> I would recommend Oneiric (11.10).  It is more tuned, and will more than likely support your board (if it is newer).
<dogan> which distro has more multimedia options for example...
<dogan> oneiric
<dogan> ok
<dogan> pls wait, i am checking the prebuild binaries
<GrueMaster> Yes, Oneiric.  What rev board are you using?
<dogan> REV A
<dogan> is it good or bad?
<GrueMaster> 4430 or 4460?
<GrueMaster> (Rev A doesn't tell me much).
<dogan> the serial number starts with 4430 so it is 4430 i think...
<GrueMaster> Ok.
<dogan> U4430500...
<GrueMaster> Not sure how the serial number thing works.
<dogan> are there bugs? on old version?
<dogan> let me check the retail box label...
<GrueMaster> Biggest issue is supporting newer rev boards.
<dogan> hÄ±m
<dogan> i see
<dogan> yes it is 4430
<dogan> so it is good for compatibility... right?
<GrueMaster> As sometimes the boards ship before we can get support in the u-boot/kernel.
<GrueMaster> Oneiric should suit your needs well.
<dogan> fine thanks
<GrueMaster> I tested it on A1, A2, and A3 (all of the known shipping 4430 revs).
<dogan>     Natty Narwhal (11.04) Netbook Installation Instructions
<dogan>     Natty Narwhal (11.04) Headless Installation Instructions
<dogan>     Maverick Meerkat (10.10) Netbook Installation Instructions
<dogan> what are these so?
<dogan> bootloaders?
<GrueMaster> They are different spins.  Maverick and Natty are 10.10 and 11.04 ubuntu releases.  Headless is exactly that, it runs w/o keyboard/monitor.  Netbook was what we were shipping prior to Oneiric, when the x86 netbook & desktop images converged.
<dogan> so for pandaboard maverick is right choice?
<GrueMaster> Oneiric desktop installation will be identical to the Netbook release instructions as far as creating a bootable SD.
<dogan> so what am i suppose to do for panda?
<GrueMaster> No, use Oneiric.  Maverick was the first release for that platform, and only works on early rev boards.
<dogan> and win32diskimager works for me?
<dogan> ha ok these are old distros...
<dogan> i see
<GrueMaster> http://cdimage.ubuntu.com/releases/oneiric/release/ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz
<dogan> so i downloaded oneiric
<dogan> can i use win32diskimager for writing to my sd?
<GrueMaster> win32-image-writer will work if you are using windows.  I just released v0.4 yesterday.
<dogan> fine dude trying now :)
<GrueMaster> And I tested it quite extensively.
<dogan> outstanding :)
<dogan> GrueMaster:is it a .net application?
<GrueMaster> No, it is a QT application.
<dogan> himmm ok
<GrueMaster> The binary zip file has everything you need.  Just make sure your path includes "." so that it will pull the dll files from the program directory.
<GrueMaster> I don't have an installer for the program, so you just need to extract everything to one directory.  Then just double click on the .exe
<GrueMaster> A lot of pain went into testing v0.4 (I had to run Windows XP & Windows 7 - shudder).
<dogan> GrueMaster:r u there?
<GrueMaster> Yes, barely (local server issues).
<dogan> i just downloaded the distro
<dogan> also downloaded your image writer
<dogan> but file extension is different
<dogan> so i wrote .raw file
<dogan> will it work? eh?
<GrueMaster> You will need to uncompress the image file.  Winzip (or Windows 7) should be able to do this.
<GrueMaster> win32-image-writer doesn't support file compression natively.
<dogan> yes it worked man
<dogan> yea i know but i meant that the file extension after extration is raw, not img
<dogan> so i wrote sd by forcing to write .raw file instead of .img
<dogan> and it worked yessss :D
<dogan> heyooo
<dogan> thank you so mych GrueMaster, you are really a master :D
#ubuntu-arm 2012-01-04
<doko> janimo, does the linux-ac100 3.0.8-3.1 kernel have the mmap patch for arm?
<janimo> doko, yes
<janimo> forgot to close the bug
<doko> precise
<doko> ok, thanks
<janimo> so ac100 is fine on both oneiric and precise
<doko> cool, thanks
<hrw> guys: any new information about moving arm(el,hf) from ports.ubuntu.com to normal repo?
<ndec> hrw: +1 ;-)
<janimo> hrw, maybe ask on ubuntu-devel?
<janimo> wrt arm moving from ports to regular archives
<ogra_> hrw, https://lists.ubuntu.com/mailman/listinfo/ubuntu-release is the place to ask about arm moving to archive.u.c ... but i wouldnt bet on it happening in the forseeable future
<hrw> ogra_: here I can usually meet ubuntu/ARM people which may know more and often respond faster then ML
<hrw> ;)
<ogra_> well, all i know is that i'm told off every time i ask (which i do once every year at least) because we dont want to piss off our mirros
<ogra_> *mirrors
<ogra_> a.u.c is generally mirrored ... ports isnt (apart from a bunch of inofficial mirrors)
<hrw> k
<[cc]smart> i'm looking at http://cdimage.ubuntu.com/daily-preinstalled/current/precise-preinstalled-desktop-armhf+ac100.bootimg and find that the md5 sum doesnt match the MD5SUMS file, did retries, find the tar.gr match the MD5 sum. should be concerned ?
<ogra_> [cc]smart, just take an older one, someone tried to do a manual build that failed, so whats in current/ might actually be messed up
<[cc]smart> ogra_, unfortunately, previous one shows the same symptoms. happen to kknow an alternative source for hf bootimages ?
<ogra_> no
<ogra_> what are the samptoms ?
<ogra_> *sym.
<[cc]smart> thx anyways
<[cc]smart> mismatch in md5sum
<ogra_> the md5 of the bootimg file really shouldnt matter
<ogra_> as long as the tarball one is right
<[cc]smart> ok, i will in this case try current
<RoyK> erm... small issue here - I have ubuntu installed on a pandaboard, and in this small program, I try to call getuid(), but it seems to block on the getuid32() call: getuid32()                              = 0
<RoyK> any idea?
<GrueMaster> rsalveti: Do you know if the correct settings for the 4460 ever made it into the kernel/u-boot for Precise?
<ogra_> there are in the tree
<ogra_> not sure they made it into the packages yet
<GrueMaster> Ok.
<GrueMaster> I've been limiting my 4460 uptime as I didn't want to have a core meltdown.
<ogra_> i just put a cup of cold coffee on top ...
<ogra_> so its warm in the evening :P
<GrueMaster> Chip is too small and my coffee mug too big.  I'm afraid the mug would topple over or the board would shatter from the weight.
<ogra_> take "light coffee" then :)
<rsalveti> GrueMaster: they should all be in already
<GrueMaster> I have a small heatsink on it now.
<rsalveti> but depends a bit on the last rebase from ppisati
<ogra_> right
<rsalveti> but you should need only a newer kernel
<GrueMaster> rsalveti: Excellent.  I just hadn't heard what the status was.
<ppisati> the last P/omap4 should have all we need for 4460
<ogra_> awesome
<ppisati> GrueMaster: do you have overheating with P kernel?
<GrueMaster> I haven't tested on it yet.  Doing that now.
<GrueMaster> I have been doing most of my testing on my other pandas.  I just hadn't heard the status of this fix, that's why I asked.
<ppisati> k
<GrueMaster> I do occasionally fire up the 4460, but I don't run it for extended periods (the other systems are on 24/7 reimaging and testing core daily).
<ndec> if you have DVFS and thermal management, you should be good
<ogra_> i think it has a builtin fuse mechanism to shut down the power if it gets to hot
<shadeslayer> lilstevie: hey! :)
<shadeslayer> lilstevie: Any new breakthrough's on the transformer situation?
<GrueMaster> Hrm.  Using netinstall for precise armhf (possibly armel as well) to install Ubuntu Desktop to USB, Network Manager refuses to handle eth0.  System has connectivity, but doesn't list it in the applet.
<rcn-ee> it's not still in /etc/network/interfaces ?
<GrueMaster> Not sure how to file a bug on this one.  needs more testing.
<GrueMaster> rcn-ee: No, it is there.  Just not showing up in the applet, even after manually adding it to the wired connections list.
<GrueMaster> ifconfig shows a link as well.
<rcn-ee> you should drop it from there then, as last i check network-manager won't manage anything already listed in /etc/network/interfaces..
<infinity> GrueMaster: That doesn't sound like something that would be even remotely arch-specific.
<infinity> And yes, eth* shouldn't be in interfaces(5) at all on a fresh install.
<infinity> Unless you manually configured the adaptor.
<GrueMaster> No, I doubt it is even platform specific.  Just that I am currently testing armhf.
<infinity> Did you statically configure it in the installer?
<GrueMaster> Probably in my preseed.
<infinity> That would do it.
<infinity> network-manager won't show interfaces with a static config in inerfaces.
<GrueMaster> ah.
<GrueMaster> Well.  That sucks.
<infinity> It's by design.
<infinity> interfaces is considered canonical, network-manager and connman and other high-level tools shouldn't be allowed to override it.
<GrueMaster> Need the static conf in the preseed for automation, but need to remove it post-install.  Hrm.
<infinity> Eh?
<infinity> You can netboot with dhcp.
<infinity> I see no reason for a static config.
<GrueMaster> It is dhcp.
<rcn-ee> GrueMaster,  d-i preseed/late_command ;)
<GrueMaster> rcn-ee: My late_command is gettng a bit long as it is.
<infinity> Oh, you mean you're telling d-i it's a dhcp interface, and it's writing out interfaces(5) with "iface eth0 inet dhcp"?
<infinity> Fixing that could be complicated. :/
<GrueMaster> yep.
<infinity> Could just be one of the subtle d-i versus ubiquity differences we get to live with.  But there might be some clever way around it.
<infinity> (The problem is that we need precisely that behaviour for anything !desktop)
<infinity> So, there would have to be a package in ubuntu-desktop that actually reverts that setup.
<infinity> And only on install.
<infinity> So, a udeb produced from n-m or something equally icky.
<GrueMaster> http://paste.ubuntu.com/793062/ is my preseed for precise.
<rcn-ee> ah, mine was too, eventually i just added another script to "/usr/lib/finish-install.d/08-something" to the patched netinstall initramfs  and run a big script in a chroot..
<GrueMaster> I used tasksel post-install to install ubuntu-desktop.  Will try a preseed with ubuntu-desktop added.
<infinity> GrueMaster: I suspect it will end up the same either way.
<infinity> GrueMaster: Does it do the wrong thing if you change choose_interface to auto?
<GrueMaster> yea, probably.
<GrueMaster> It used to.  Not sure if it works properly.  Will run a quick spin to find out.
<infinity>     - Call /usr/lib/NetworkManager/ifblacklist_migrate.sh from
<infinity>       finish-install if present, so that 'auto dhcp' interfaces are disabled
<infinity>       if network-manager is in use.  May be preseeded away with
<infinity>       netcfg/network-manager.
<infinity> Hrm.
<infinity> Looks like netcfg has code to deal with this.
<infinity> And, supposedly, the code triggers by default...
<GrueMaster> Obviously well documented (considering the pain I went through to get this far with the preseed).
<infinity> Well, the preseed is an inverse.  You only need to preseed to PREVENT the mangling.
<infinity> It's meant to happen by default.
<infinity> So, maybe something's preventing netcfg's finish-install from running correctly.
<GrueMaster> Well, so far it seems to at least connect during netinstall with auto.
<GrueMaster> I'll know in ~15 minutes if this changes things.
<infinity> Hrm.  It might be that /usr/lib/NetworkManager/ifblacklist_migrate.sh is missing.
<GrueMaster> Seems to me I had to add that in for different platforms, and never changed it when I started using different preseeds for different systems.
<GrueMaster> Oh?
<infinity> Well, that's a wild guess.  Haven't looked at the precise n-m package yet.
<infinity> Oh!
<infinity> Wait.
<infinity> You used tasksel after the install was complete?
<infinity> As in, after d-i was done and you were dumped at a loging?
<infinity> login*
<infinity> If so, then yeah, preseeding ubuntu-desktop will fix it.
<GrueMaster> yea.  My bad?
<GrueMaster> ok.
<infinity> Cause this finish-install magic in netcfg is in the udeb (ie: in d-i), but it's checking if n-m is in the target.
 * GrueMaster feels sheepish.
<infinity> So, n-m needs to be installed before d-i is done.
<GrueMaster> Well, better to raise the question here than in a launchpad bug report.
<infinity> Heh.
<infinity> S'ok, every time someone asks something like this, I research and learn a little bit more.
<infinity> Eventually, my head will explode, and paint the walls with d-i internals.
<infinity> It'll be pretty.
<GrueMaster> Yea, if you like crimson & gray walls.
<infinity> Pfft, it's d-i.  Yellow and blue walls.
<infinity> (I still refuse to admit that kirkland changed the terminal color palette for Ubuntu's d-i, yellow and blue for life!)
<badZeppelin> hi folks! I have managed to install sgx opengl drivers on my beagleboard now but only the powervr demo apps make use of those sgx libraries when I check with ldd
<badZeppelin> stock opengl apps like es2gears point to some other library that uses mesa software rasterizer
<badZeppelin> does anyone have a clue how I make all applications use the ones in /usr/lib
#ubuntu-arm 2012-01-05
<nOStahl> hi guys
<nOStahl> so this arm stuff... it will be full featured ubuntu?
<infinity> s/will be/is/
<nOStahl> http://www.geek.com/articles/chips/cubox-is-a-sexy-ice-cube-sized-arm-computer-20111221/
<GrueMaster> We have full Ubuntu desktop and Server images now.
<nOStahl> so something like that could be a decent computer for a web developer?
<GrueMaster> Might.  Looking.
<infinity> Yeah.
<infinity> And that article is wrong.
<GrueMaster> 1G ddr3, Armv7.  Not bad.
<infinity> It claims "ARM7" where they meant "ARMv7"
<nOStahl> interesting
<infinity> nOStahl: But, yes, other than the part where we don't ship a kernel in the archive for that box, it will run Ubuntu just fine.
<GrueMaster> Hrm.  Marvell Armada 510.  could be arm7.
<infinity> GrueMaster: No, the 510 is v7.
<GrueMaster> ok
<nOStahl> ubuntu arm needs to be marketed to the Off grid crowd
<nOStahl> people that live on solar and wind power systems
<nOStahl> they are very interested in low wattage computers :)
<infinity> But this article makes it sound like the Pi is "better" since 11 is a bigger number than 7.
<infinity> They really need to fix that. :P
<nOStahl> Pi is cheaper :)
<infinity> Yeah, but Ubuntu won't run on the Pi.
<GrueMaster> nOStahl: If you get one of these and can get a working image assembled, I think we can add it to the community supported list.
<infinity> The Pi is also fairly crippled.  Fun toy device, likely frustrating to people who want to run a general purpose OS.
<nOStahl> the Pi shipped with an ubuntu image
<nOStahl> I read in an article on the PI
<infinity> nOStahl: Err.  Shipped to who?
<nOStahl> let me find it.
<nOStahl> they auctioned off 10 demo boards
<infinity> Yeah.  They've only barely started shipping, AFAIK.  And there's no way they're running Ubuntu, since it would have to be an ancient release (karmic or earlier).
<nOStahl> http://www.omgubuntu.co.uk/2011/05/raspberry-pi-the-25-usb-sized-ubuntu-pc/
<nOStahl> 9.10 I think it said
<GrueMaster> 9.04.
<GrueMaster> Yuck
<infinity> That's just plain not true.
<GrueMaster> We were barely dabbling in arm back then.  And that was armv5.
<infinity> Unless they did a scorched earth rebuild.  Which seems unlikely.
<infinity> Oh, wait.
<infinity> I'm getting my years mixed up.
<infinity> 9.04 would run on it, yeah.
<infinity> I still can't see them shipping with it, though.
<infinity> Since they even amended their own FAQ to point out that Ubuntu isn't compatible...
<nOStahl> it would be great for running video displays in public restrooms :)
<GrueMaster> 9.04 - armv5.  9.10 - armv6+vfp.  10.04-11.10 - armv7 soft float.
<GrueMaster> Heh.
<infinity> Anyhow.  Way far afield.  If you want a Pi, run Debian.  Beats running an ancient and unsupported Ubuntu.
<infinity> But that other box should run Ubuntu great.
<infinity> And if someone wants to send me one...
<infinity> *shifty look*
<nOStahl> what kind of options are there for netbooks
<infinity> Netbook selection is woefully crap still, which is sad.
<GrueMaster> Well, funny you should ask.  Currently, we have a release for the Toshiba AC100.
<nOStahl> googling
<infinity> But the Tranfsormer Prime (ie: tablet + keyboard dock) can pretend to be a Netbook quite well.  And with recent announcements of a bootloader unlocker from ASUS, I expect we'll ramp up support for them "soon".
<GrueMaster> I hear there is work being done in the community to get running on the Asus Prime, but I don't know the status of that endeavor.
<infinity> (And I'd rather have a Prime than an only-available-on-eBay AC100)
<GrueMaster> Very true.
<GrueMaster> It's sad that M$ pretty much killed the netbook market.
<infinity> It's sad that the hardware vendors let them.
<nOStahl> I Have an asus eeepc 901
<nOStahl> I get 8 hours on a charge easy with it. little atom guy
<infinity> If that insane artificial 1GB RAM limit hadn't been enforced, netbooks would have been great.
<nOStahl> what kind of battery lengths will arm platforms give me
<GrueMaster> I have an Acer Aspire One 532h.  64 bit and with an ssd, boots Ubuntu in ~12 seconds.
<infinity> nOStahl: My AC100 will run under heavy load all day.  The difference is that it's less than half the weight of your Atom netbook.
<GrueMaster> My AC100 lasted for well over 5 hours while flying across the US.
<GrueMaster> recompiling & testing banshee the whole way.
<infinity> My Lenovo S10-3 (Atom N450) and AC100 (Tegra2) last around the same under similar loads.  But the former burns my lap, while the latter doesn't get warm.  And the former is heavy as heck.  The latter is pretty much the weight of a pad of paper.
<GrueMaster> Yea, the AC100 is a lot smaller.  I can fit two in the same sleave I use for my Acer.
<GrueMaster> Smaller meaning thinner.
<nOStahl> ya my 901 has two ssd's in it.
<nOStahl> the new one I bought for it is dead now though
<nOStahl> kernel paniced randomly tried a diff installation on it and it cant finish installing now heh
<nOStahl> so ubuntu -arm can watch youtube videos and everything? (flash support)
<GrueMaster> I had similar issues on my first Acer Aspire One with the proprietary Intel SSD.  Har to rma it twice (first time Acer just dumped Windows back on it and moved the partition table).
<nOStahl> its going to be a neat world in 5 years
<nOStahl> I can see myself with a little arm media server hooked up to the tv
<GrueMaster> You can pretty much do that now with a panda board.
<GrueMaster> I haven't tried it, but it should work well as a mythtv client system.
<nOStahl> all of my viewing online comes from hulu.com or crackle.com etc.
<nOStahl> occasional redbox
<nOStahl> keeps me from having to buy hard drives all the time :P
<infinity> nOStahl: Flash on ARM is usually a non-starter, unless you hack and slash binaries from Android devices.
<infinity> nOStahl: But youtube has an html5 option now.
<nOStahl> ah
<nOStahl> I was just reading article of speculation of apple moving from intel to arm processors
<nOStahl> brb
<nOStahl> rebooting
<twb> "speculation"?  What do you think their iOS kit runs on
<zclei> ubuntu-oneiric let me trouble,when i draw non-texture geometry
<zclei> when i draw three triangles ,only show two
<ndec> ogra_: hi. does any recent 'precise' image work on Panda ES?
<cmagina> K9tdsE4aMz
<LetoThe2nd> cmagina: i'd suggest changing that password now.
<cmagina> LetoThe2nd: yeah, hate when that happens. its only a local password
<LetoThe2nd> :)
<GrueMaster> ndec: Pick one.  I'm running precise armhf now.
<ndec> GrueMaster: i didn't try myself but someone reported it was not working...
<GrueMaster> ndec: I asked yesterday if the kernel mods had made it in because I haven't been testing it.  But yesterday's daily ran just fine.
<ndec> has kernel changed since yesterday?
<GrueMaster> I doubt it.
<GrueMaster> My point is that I hadn't tested the 4460 since Oneiric release  (I have several other pandas).  I knew then that there were kernel mods to correctly set voltages.  Yesterday, I asked if they had made it in and was told they were there for a while.
#ubuntu-arm 2012-01-06
 * ogra_ reboots into 3.0 on the ac100
<ogra_> hmm, no sound istill
<marvin24> there should be sound ...
<marvin24> ogra_: is there a new kernel package?
<ogra_> marvin24, yep
<ogra_> 3.0.8-3-ac100
<ogra_> seems stable yet
<marvin24> ogra_: there is some instability introduced by the upstream update from chromeos to 3.0.13
<ogra_> then its good that we are still on 3.0.8 :)
<marvin24> if possible, hold off any further updates until this is fixed
<marvin24> what about sound?
<ogra_> janimo, ^^^^
<marvin24> did you tried to "fix" the mixers?
<ogra_> well, i get a cracking/popping sound when i unmute the world, havent digged deeper
<ogra_> so i guess its just my old 2.6.xx config getting in the way
<marvin24> ok, keep trying ;-)
<ogra_> heh, will do, its not that important to me
<ogra_> ndec, invalid passcode ??
<ndec> ogra_: it's new year bug...
<ndec> use 72420150
<ogra_> k, thx
<ogra_> better :)
<ndec> rsalveti: ^^
<ogra_> marvin24, hmm, i was wrong, i have sound, its just that the pop sound is louder then the actual sound it plays (does it power up/down all the time ?)
<marvin24> ogra_: possible
<marvin24> ideally we should mute it before blobing
<ogra_> yep
<marvin24> I mean mute the amp
<ogra_> yep
<marvin24> the blob comes from muting the codec
<ogra_> well, there seems ot be some distortion too
<ogra_> playing the ubuntu login sound with paplay has some crackling in it
<ogra_> (wasnt the case with .38)
<marvin24> lower the speaker levek
<marvin24> or some other mixer
<ogra_> yeah
<ogra_> hmm, sad, still screen corruption with the newer kernel and binary driver :(
 * ogra_ was hopig it would magically vanish
<rsalveti> ndec: sorry, wasn't on-line at the time of the call
<ogra_> excuses :P
<rsalveti> ndec: anything I missed? besides you pushing armhf drivers :-)
<rsalveti> ogra_: haha
<ogra_> nice article about xbmc :=
<ogra_> :)
<rsalveti> ogra_: :-) that was the reason
<ogra_> rsalveti, we're waiting for IS to finish the hf PPA setup ... i hope thats done by beginning of next week
<ogra_> beyond that it should just be a matter of uploading :)
<rsalveti> ogra_: yup, would be cool to have the drivers by the time of the sprint
<rsalveti> ogra_: are you driving again to budapest this year?
<rsalveti> must be quite cold I believe
<ogra_> no, its actually warm, i think its the warmest january i can remember
<ogra_> always around 7-10Â°C
<ogra_> so yes, i'll drive :)
<ogra_> and my car has a heating ;)
<rsalveti> oh, ok, not that bad :-)
<ogra_> yeah, its very strange
<ogra_> i would actually have expected snow around this time of year
<ogra_> but i guess we'll have that mid summer from now on :)
<rsalveti> ogra_: which is not bad I believe ;-)
<rsalveti> unless you really like cold weather
<ogra_> not at all :)
<ndec> rsalveti: you didn't miss much... and yes nice blog post.
<Sycro5> Hi, I'm running Ubuntu 11.10 ARM on a pandaboard and am trying to get bluetooth working.  Using a usb bluetooth adapter, I am able to turn on bluetooth and successfully scan for devices.  I am not able to connect though.  When I type 'lsmod', I am getting the btusb module, but not a
<Sycro5> 'bluetooth' module.
<Sycro5> the device shows up successfully on a 'hciconfig -a' query
<Sycro5> I believe there is some bug in Ubuntu arm that is causing the problem.  Does anyone know of a build that has solved this problem, or have other suggesstions for me?
#ubuntu-arm 2012-01-08
<eFfeM> hi, want to drop a short bug report here (I do not have  a launchpad account); on this (immuble) wiki page: https://wiki.ubuntu.com/ARM/OMAP  the installation instructions for natty headless actually point ot the oneiric instructions
<eFfeM> near the end of the page)
<tormod> eFfeM, the "11.10" page says "(note: for 11.04 download images from http://cdimage.ubuntu.com/releases/11.04/release/ . They are called headless instead of server, so the files have different names, but otherwise all instructions below are valid "
<Sage> Hi, should the 11.10 images available at http://cdimage.ubuntu.com/releases/11.10/release/ubuntu-11.10-preinstalled-desktop-armel+omap4.img.gz work out of the box on Blaze?
<b-man`> hello guys - I've been working on a port of Ubuntu 12.04 (linaro) to the HP TouchPad, and so far I've been quite successful (boots to desktop, touch screen works, ect) but when I try to start unity with hardware acceleration (by borrowing the Adreno 220 libs from webos, which are built against standard GNU/Linux libraries and should work) Unity 2d is crashing. Could anyone tell me how I can troubleshoot unity to see what is going wrong?
#ubuntu-arm 2013-01-01
<Noskcaj> does anyone here have a hiapad hi802 or zealz gk802?
<k1l_> Noskcaj: did you search on xda-developers for something related?
<Noskcaj> k1l_, there was an android update, that was it
#ubuntu-arm 2013-01-02
<Noskcaj> double checked, they have nothing. does anyone have either of the sticks?
<Deathspawn> i keep getting error: failed to load 'image-nakasi-jop40d.zip'
<Deathspawn> what do i do? im using Nexus 7
<^Phantom^> paste your pastie Deathspawn
<ivotkl> Hello.
<Noskcaj> ivotkl, welcome to "here"
<ivotkl> Hahaha. Ok, what does ARM mean? =P
<ivotkl> and how do I setup a Raspberry?
<ivotkl> Do I connect things just like in a regular machine?
<Noskcaj> first
<Noskcaj> !raspbian | ivotkl
<ubot2> Factoid 'raspbian' not found
<Noskcaj> !raspberrypi
<ubot2> Factoid 'raspberrypi' not found
<Noskcaj> !arm
<ubot2> ARM is a specific (RISC) processor architecture used in a variety of applications such as handhelds and networkdevices. For more information see https://wiki.ubuntu.com/ARM . For ARM specific support, stop by the #ubuntu-arm channel.
<Noskcaj> arm is there companies. apple, the bbc micro company and one other. they licence cpu designs cheaply
<Noskcaj> ivotkl, sinc you seem to like arm stuff, have a look at this http://www.hiapad.com/?p=2018
<Noskcaj> quad core 1.2ghz
<ivotkl> That's a full computer? =S
<ivotkl> Darn.
<ivotkl> Price?
<Noskcaj> ivotkl, yep, there are cheap, slower ones too. mine arives next week. $90
<ivotkl> Noskcaj: Too bad I'm not where you're at. =P
<ivotkl> Where do I order one?
<Noskcaj> ivotkl, http://www.aliexpress.com/item/Hi802-Android-Mini-PC-HDMI-Dongle-Freescale-imx6-Quad-Core-1-2Ghz-1G-RAM-8GB-Bluetooth/707427957.html
<ivotkl> It does not deliver to Argentina. =P
<ivotkl> I should leave now. Thank you for the help and the chat.
<prpplague> just a reminder, the Call for Participation for the Embedded Linux Conference 2013 ends friday! https://events.linuxfoundation.org/events/embedded-linux-conference/cfp
<rhm> hi all, I was looking at the exciting news of Ubuntu on mobile phones. Anybody knows what is the relation with Ubuntu for Android? And if the code is available? Ubuntu for Android was announced last Feb but it is still not available for download.
<infinity> rhm: U4A is essentially an Ubuntu desktop chroot (and a bit of glue) running on an existing Android installation.  Ubuntu Phone is Ubuntu running directly as the phone OS, rather than a chroot.
<infinity> rhm: So, no relation, really.
<morphis> infinity: the ubuntu phone looks really like the one I am holding in my hands :)
<rhm> well, the video says it uses (or it can use) Android kernels and drivers so I'm guessing some of the work on UfA went into this UfP (I just made this up :)
<tassadar_> morphis: it is probably some dummy device for the renders
<infinity> rhm: Reusing the kernel isn't really the same as reusing the entire userspace.
<rhm> agreed
<infinity> rhm: The obvious difference here being that on a phone with U4A, you're still running Android, Android makes your phone calls, etc.  With Ubuntu Phone, there's no Android anywhere (except, as you note, a kernel in some cases).
<morphis> rhm: take a look at libhybris (https://github.com/morphis/libhybris), it's one way to access android drivers within a eglibc based userspace
<morphis> and it's what we're using over in webOS ports
<tassadar_> what is ubuntu doing by the way?
<tassadar_> using proper linux drivers?
<rhm> infinity: makes you wonder if it will support Android apps natively. I didn't see any of that announced tho
<rhm> morphis: thanks for the link. Will take a look at it. I have ubuntu running chrooted on my HTC Thunderbolt but accessing it via vnc which is pretty slow. I was looking for something like libhybris or any other solution to run the graphics natively
<morphis> rhm: don't expect this to be an easy task
<rhm> morphis: ha! who said using Linux was ever easy?
<morphis> :)
<rhm> any idea if the code is going to be released soon as part of any of the regular Ubuntu releases?
<rhm> tassadar: I guess we won't know till we can take a look at the code
<tassadar_> I mean the nexus 7 port
<Noskcaj>  how can i get ubuntu on a hiapad hi802 / zealz gk802? ideally some instructions or an iso
<thebishop> hi folks
<thebishop> so... is this new Ubuntu Phone UI going to work with the Nexus7 installer?
<robin-gloster> thebishop: are you asking if the phone UI will be available on the Nexus7? if so, no, at least it isn't a goal now
<thebishop> robin-gloster, correct, and ... bummer
<thebishop> so what's the vision for ubuntu on nexus7?
<robin-gloster> thebishop: i'm sure it will be possible as soon the code is open, probably someone will look into it
<infinity> There's no reason the same packages won't work just fine on the Nexus7 as well, once they're in the archive.
<robin-gloster> as far as i have heard at first getting performance and battery lifetime up
<infinity> We probably won't switch the Nexus7 images over to it, however.
<thebishop> interesting, i have to say i'm a little surprised to hear this.  some of the issues interacting with standard ubuntu through touch seem difficult to solve
<infinity> You're not wrong.  We just don't plan to switch the N7 image over right away, that's all.
<infinity> Ultimately, all slate devices should be using the shiny new hotness, but that's not an immediate goal for Canonical.  If some enterprising community folk want to make it happen, we can't stand in their way.
<tassadar_> so the ubuntu phone will be basically the same thing as nexus 7 (full linux distro) with different UI? That is just great Oo
<robin-gloster> infinity: are there plans to modify Unity to be more touch friendly?
<infinity> robin-gloster: This is Unity.
<robin-gloster> infinity: hmm ok didn't realize it was unity, thought it was something different using the Unity APIs
<thebishop> infinity, so the unity interface on ubuntu phone will be cleanly packaged in the archive?  that's pretty awesome
<thebishop> infinity, no big need to change the n7 image in that case i suppose
<infinity> thebishop: This is the plan, yes.
<thebishop> infinity, works on standard laptops/desktops too?
<Xavierdarkness> The phone in the video kind of looks like a galaxy nexus
<robin-gloster> Xavierdarkness: it is
<infinity> Xavierdarkness: That could be because it is.
<Xavierdarkness> Figured it was either that or the nexus 4; given that they look similar. But that's cool, I'd definitely run Ubuntu on mine.
<tassadar_> They wanna to release their own devices, the gnex is just "dummy device" to show Ubuntu phone UI, isn't that right?
<LisaNori1> Has anyone gotten the nexus7 install to work with cellular data?  I can't seem to get it to work.  Just curious if this is a known problem.
<LisaNori1> Sorry, I now see that 1091663 seems to address this.  I'll see if I can capture the logs needed.
<SailorMoon> Does this Ubuntu Phone thing have any connection to the Ubuntu build seen for the Nexus 7?
<lilstevie> SailorMoon: no
<SailorMoon> Darn, then what is the Nexus 7 ubuntu build for?
<SailorMoon> Theres nothing written about it anywhere, from what ive seen.
<lilstevie> the nexus 7 ubuntu build is ubuntu on the nexus 7?
<ubuntubhoy> The N7 build is a full ubuntu OS on the N7
<ubuntubhoy> The ubuntu for phones OS is quite different
<lilstevie> while nice, I don't think it would be as nice on a tablet
<cwayne> the point of the n7 build is to make the core of Ubuntu work better on mobile devices
<cwayne> i.e., get RAM usage down, and get a speedier core system overall
<ubuntubhoy> yip, they have still not said anything about UI changes
<cwayne> there aren't any planned for the nexus 7 build
<cwayne> it's all about the core :)
<ubuntubhoy> but if the core is right, then others can make functioning usable distro's from it
<cwayne> ubuntubhoy: of course
#ubuntu-arm 2013-01-03
<SailorMoon> Will the ubuntu phone be just another OS? Will it have its own apps, or will anything open source from the Ubuntu Software Center run on it, such as OpenJDK (Minecraft?) or Gnome?
<infinity> SailorMoon: It's still Ubuntu under the hood.
<Ethernin> infinity, gestures that work?
<SailorMoon> Any plan to use the System partition of an Android device?
<Tassadar> SailorMoon: what would you use it for?
<SailorMoon> I wouldnt know, im a noob. But it seems like wasted space, expecially on a device like the Nexus 7 where its like 700MB
<SailorMoon> maybe some sort of backup or install partition to recover from if ubuntu explodes :3
<Jef91> Are the latest linux-nexus7 kernel sources that the Ubuntu 13.04 images here -> https://launchpad.net/~ubuntu-nexus7/+archive/ppa/+packages
<Jef91> or are there newer debian sources for that package hiding somewhere?
<Jef91> found it -> https://launchpad.net/ubuntu/+source/linux-nexus7/3.1.10-8.19
<logicbuffer> Has there been much activity here in development for the Samsung Chromebook?
<SmallFry> What sort of Dec? I thought it was working well on the chrimebooks
<SmallFry> Dev*
<logicbuffer> It's working decently well out of the box. Still needs some work as far as touchpad drivers go, and I don't think hardware video acceleration is working at all yet.
<SailorMoon> is Ubuntu Phone going to install like an android rom? will there be individual roms per phone, or will there be one universal installer? lol
<logicbuffer> We'll know in a few weeks when they release the first builds for the Galaxy Nexus
<SailorMoon> i dont have any devices that will be suported, unfortunetly.
<logicbuffer> Lack of hardware acceleration makes Unity a bit of a cramp.
<SailorMoon> If theyd include the Nexus 7, i'd be good. lol
<SailorMoon> its pretty much my only device that meets hardware requirements.
<logicbuffer> Well I know they used the Galaxy Nexus as the demo phone.
<logicbuffer> Luckily I had the foresight to buy one last year.
<SailorMoon> i wanted to
<logicbuffer> Assuming source is released reasonably quickly after the first build is released, I'm assuming that 3rd party development for Ubuntu Phone will take off pretty quick.
<logicbuffer> Hoping anyway
<SailorMoon> But i was broke at the time
<SailorMoon> and now its not worth buying anymore
<logicbuffer> It'd be awesome to have nightly builds up by a bunch of people just like Cyanogenmod & AOKP etc.
<logicbuffer> Yeah it's pretty much pointless to buy one now.
<logicbuffer> The Nexus 4 is superior in every way
<SmallFry> The GNex?
<SmallFry> Cheaper and Samsung.
<SmallFry> I prefer Samsung to LG, but that's me
<logicbuffer> True enough.
<SmallFry> But specs... duh spezs
<logicbuffer> A lot of people who bought the Retina Macbooks prefer Samsung to LG too, judging by the amount of complaints of display burn-in on the LG models.
<SmallFry> Heh
<logicbuffer> There's some burn-in on the GNex that has been with it since the first week I've had it but I'm not sure about the N4. I think it's had its fair share of issues that way too.
<SmallFry> Did you hear about the iTheft in France?
<logicbuffer> Saw something about it but didn't click any links or read more.
<SmallFry> 1.3 million in product stolen. Which is what...2 macbooks and an iPhone?
<SmallFry> I LoLd despite how bad it is
<Jef91> logicbuffer: my samsung works well with the trackpad
<Jef91> after setting somethings in the xorg settings
<logicbuffer> I'll look into that then, I don't remember seeing anything about xorg settings in any of the threads I've read but who knows
<Jef91> logicbuffer: let me find it
<SmallFry> Xorg is nice... very nice for thing like macros etc too right?
<Jef91> logicbuffer: -> http://forums.bodhilinux.com/index.php?/topic/7330-fix-touchpad-on-alpha-image/
<logicbuffer> Did you use the script that downloads all the tarball pieces and unpacks them to the stateful partition?
<logicbuffer> Or some other way of getting Ubuntu on?
<Jef91> logicbuffer: I use a debian based system on my device.
<SmallFry> Could you not pick at the script and install any ARM Linux?
<SmallFry> And did you upgrade your ssd jef91
<logicbuffer> Probably could, I didn't bother to even look into it
<Jef91> I did not SmallFry
<Jef91> still using the stock one
<Jef91> 9GB for my OS is more than enough
<logicbuffer> I thought the ssd was soldered to the motherboard?
<SmallFry> Mar
<SmallFry> Mar
<SmallFry> Bah
<SmallFry> Nay
<SmallFry> Its an MSATA iirc
<logicbuffer> Hmm
<SmallFry> Maybe though. Idk
<SmallFry> Ifixit has a teardown most likely
<SmallFry> I'm sick and don't want to crawl to my rig though
<logicbuffer> Newegg has a 32gb Crucial M4 mSATA drive for $55 w/ free shipping. Not sure if want...
<SmallFry> More than a dollar a gig. Ugh
<SmallFry> Check before you order it though, I could be delusional
<logicbuffer> Yeah I'm not going to spring for it just yet.
<SmallFry> Having the flu messes with your mind, I tell ya
<logicbuffer> hhmm
<logicbuffer> Jef91: how's the memory usage with bodhi? i haven't used enlightenment since the early elive days
<Jef91> generally sub 100MB logicbuffer
<SmallFry> Gnite logicbuffer and jef91, hope to chat again.
<Jef91> under 150MB with compositing
<logicbuffer> SmallFry: take care, i'll be here much more often now
<SmallFry> Cool:) most activity I've seen in here
<logicbuffer> Jef91: if so that's incredible, this is using 1.34gb at the moment
<Jef91> ha unity just eats memory logicbuffer
<logicbuffer> truth
<logicbuffer> i think i'll go run that script instead and then come back here
<SmallFry> Rockbox?
<SmallFry> I haven't seen devs from them in ages
<logicbuffer> SmallFry: So much for sleep
<raster> logicbuffer: beware how you measure memory usage
<raster> 1.3gb of actual memory used
<raster> or that INCLUDEs caches/buffers?
<logicbuffer> raster: http://i.imgur.com/7rPKa.png d
<logicbuffer> i'm not very familiar with top but 1.3g used should mean total ram used, no?
<raster> logicbuffer: ok - so its more like 500m used
<raster> almost 700k is caches and another 75 buffers
<Jef91> logicbuffer:  -> http://www.linuxatemyram.com/
<raster> so under 600
<raster> think of it this way
<raster> cache is where linux stored data you load from disk
<raster> if you opened a 200m video file
<raster> and plqyed it
<raster> 200m of ram will be used
<raster> even if the process that played the video has exited and gone
<raster> as the kernel will have loaded and CACHED that data into memory
<raster> just in case its needed again
<raster> even if the app onlyuses 10mb at any time
<raster> and is walking thru the video stream decoding some of it into ram/buffers
<raster> (yes - i'm ignoring the kernel fadvize calls etc. - i'm keeping it simple)
<logicbuffer> isn't caching to disk a horrible idea on ssds though?
<raster> if u copy 500m of photos from your sd card to your ~/Photos folder
<logicbuffer> especially relatively large caches on disks that are already pretty small?
<raster> those 500m of photos will live in cache
<raster> umm
<raster> caching is never a horrible idea
<raster> ram is faster than an ssd
<raster> (i know of no cases where it is not - and even though i can imagine some bizarre ones... they are truly bizarre)
<raster> so having daat sit in ram that is currently unused is good
<raster> its using ram
<raster> that would otherwise go unused
<raster> unused ram is the tool of the devil
<raster> unused ram is useless ram
<raster> (ok - i simplified again - yes. ram costs power for self-refresh and being able to turn it off and turn off self-refresh can save you some power drain. as such no linux setup "does this" (in any normal case))
<logicbuffer> i'm sorry, i was confusing it with swap
<logicbuffer> actually it says swap ~700m cached
<logicbuffer> does that not mean it's holding 700m of something in a file on the SSD and not in ram?
<raster> thats not swap
<raster> thats cache
<raster> u are using no swap
<raster> its misleading that tis onthe line with "swap"
<logicbuffer> yeah alright i understand now
<raster> so ubuntu isnt AS BAD as u are thinking
<raster> u're being a bit too harsh on it
<logicbuffer> so i'm truly only using about 500m but it's holding another 700ish in memory in case it needs to use it
<raster> what Jef91 os statitng is the actual ram usage
<raster> ie memory excluding disk cache/buffers
<raster> measuring memory is a "fine art"
<raster> ina  virtual memory os setup its hard
<raster> one of the best measurements u can get is "free"
<raster> do this:
<raster> free -m
<Jef91> Yea.
<Jef91> Unity is normally just over 500MB at startup.
<Jef91> So 3-5 times as much as E17
<raster>  2:22PM ~ > free -m
<raster>              total       used       free     shared    buffers     cached
<raster> Mem:          2939       2228        711          0        119       1858
<raster> -/+ buffers/cache:        250       2689
<raster> Swap:         1905         61       1844
<raster> the numebr that matters is that "250" number
<raster> thats your memory used on the os/syst4em as a whole
<raster> excluding what is swapped out, what is cached or in buffers
<raster> that is about the most accurate number you have to measure system meory usage
<logicbuffer> okay i see
<logicbuffer> sounds good
<raster> so the best way to measure gnome vs kde vs unity vs e17 for example
<raster> is boot a system and have them all boot to the same point
<raster> eg a bare xserver
<raster> no wm or anything
<raster> no login manager
<raster> now measure "free"
<raster> that "used -/+ buffers/cache" is the memory you MUST HAVE to run what u have running now
<raster> any memory in addition to that is luxury "caching" memory or memory for added apps or utilities on top
<raster> NOW u run the desktop of choice
<raster> unity/gnome/kde/e17/xfce/whatever
<raster> then meausure again
<raster> free
<raster> that number will have gone up
<raster> the mount it has gone up by is the "cost" of that desktop in addition to your base os
<raster> thasts the fairest way to measure desktops/wm's against eachother
<raster> and of coruse then run specific apps
<logicbuffer> seems like they could've made it slightly more intuitive in top
<raster> or perform specific tasks
<logicbuffer> yeah
<raster> eg open browser, go to a fixed webpage
<raster> etc.
<raster> and then measure as u go
<raster> and see where that number goes
<raster> that's how you are "fair" in measuring
<raster> top/ps are useless for a regular user in terms of telling u actual mem usage
<raster> there is 1 tool i know of that makes a "good attempt" to give you a fair memory rating
<raster> its called "smem"
<raster> therss a pkg for it
<raster> apt-get install smem
<raster> its a python tool
<raster> if u do it as root u can get full details
<raster> sudo smem -t
<raster> and it'll list processes and TRY and allocate a FAIR share of memory to them
<raster> it accounts for sharing of resources - eg libc, code pages etc.
<raster> every process shares the same libc
<raster> so memory used by libc CODE is in memory only once
<raster> across ALL processes u run
<raster> so it figures out the reference counts on these pages and divides by how many processes use them
<raster> etc.
<raster> so they are allocated their fair share
<raster> the PSS column is the "fair share" amount
<raster> its not perfectly accurate
<raster> but as close as u'll get
<raster> again - measuring the os as a whole with free is probably the most fair and best way
<raster> so when Jef91  is saynig 100-150m
<raster> he's saying the "free" number
<raster> minus buffers and cache
<raster> note
<raster> that the amount of memory needed can be wildly different depending on gpu and gl driver stack
<logicbuffer> good to know
<raster> its an artifact of the driver itself
<raster> so hsi numbers and yours may not match if u have different gpus/drivers/versions of driver or even different resolutions of screen
<logicbuffer> yeah since data is moved from ram to kernel to gpu and back and then again to framebuffer, no?
<raster> depends on architecture
<raster> integrated gpus have no framebuffer
<raster> well no dedicated one
<raster> its part of main memory
<raster> they dont need to move memory around
<raster> discrete gpus do
<raster> they may come with 256m or 512m or 1gb or more of dedicated memory on the gfx card in addition to system memory
<raster> anyway. i've done my "measuring memory" rant for the month... :) hope it helps - spend some time reading up on it and experimenting and seeing
<raster> and then when u see the usual misinformation spread as people quote the wrong numbers... spread the word.
<logicbuffer> interesting
<logicbuffer> looks like the mali t604 renders graphics into memory and then passes it from there to another gpu core that handles display
<raster> its an integrated gpu
<raster> its texture data, frameubuffer etc live in system ram
<raster> the gpu has a CACHE on board
<raster> like the cpu
<raster> l1/l2/l3 etc.
<raster> so it'll read data form ram just like your cpu and keep it in a cache
<raster> if it needs the same data it pulls it from its cache, not from ram - just like your cpu.
<logicbuffer> well this was enlightening
<logicbuffer> thanks haha
<raster> enlightenment is what i do
<raster> :)
<raster> pun intended :)
<logicbuffer> should've seen that coming
<raster> ;]
<ogra_> happy new year everyone !
<raster> hny :)
 * ogra_ is wading through backlogs for the last 3 weeks  and through >3000 mails 
<raster> oh ugh
<raster> holidays?
<ogra_> yeah, gotta love them :P
<raster> i'm starting to be of the opinion that email is overrated
<raster> and all discussion/work should be done via irc
<raster> if u arent there - u miss it
<raster> but thats cool
<raster> u dont end up with backlogs out the wazoo
<raster> :)
<tnelson> Can Pandaboards be PXE booted?
<hrw> tnelson: you can boot panda from sd or usb
<ogra_> tnelson, yeas, our u-boot supports PXE since 12.04
<ogra_> (it defaults to it if there is no configuration found)
<hrw> but first you have to provide uboot...
<ogra_> right, you need an SD with u-boot or set up usbboot via OTG
 * ogra_ hugs infinity ... thx for that flash-kernel SRU, somehow i missed it 
<tnelson> Ah, so, 'Das U-Boot' is to embedded devices what grub is to x86?
<ogra_> tnelson, well, its a bootloader, thats what grub and u=boot have in common :)
<lilstevie> I wouldn't go much further than that though :p
<tnelson> So, I'm looking at http://omappedia.org/wiki/Minimal-FS_SD_Configuration versus https://wiki.ubuntu.com/ARM/Server/Install?action=show&redirect=ARM%2FOMAPHeadlessInstall...
<tnelson> The zcat | dd approach would leave me with one pre-sized partition, no?
<tnelson> (I've got a 32GB SD card.)
<tnelson> Although I've got a 2GB usb stick, presumably I can dd onto that, then install onto the sd card?
<ogra_> tnelson, nope
<ogra_> SD needs to be the source device
<Jef91> So I'm trying to compile to nexus 7 kernel found here -> https://launchpad.net/ubuntu/+source/linux-nexus7/3.1.10-8.19 , but towards the end of the compile the build always fails for me with this error message -> http://paste.debian.net/221410/
<Jef91> What am I doing wrong?
<ogra_> Jef91, how do you build it ?
<Jef91> ogra_ untared the sources, CDed into the directory and ran:
<Jef91> dpkg-buildpackage -b
<ogra_> on an arm machine ?
<Jef91> Yes ogra_
<ogra_> did you install the build-deps ?
<Jef91> Yes ogra_ ... If it was missing build deps dpkg-buildpackage would not have let it start compiling
<ogra_> hmm, strange
<Jef91> The error hints to me at a syntax error with the control file
<Jef91> but I honestly don't know exact what that might be after looking at the file
<ogra_> the control file is created during the build process, so its a bit weird, i would bet you have another error further above in your build
<ogra_> (the guys in #ubuntu-kernel might know more btw)
<Jef91> good call, thanks ogra_
<Jef91> thanks ogra_
<ogra_> np :)
#ubuntu-arm 2013-01-04
<wookey> infinity: I just build eglibc current-raring with DEB_BUILD_PROFILE=stage1 and only got a libc-dev:arm64 package - all the other packages gave a dpkg-genchanges: warning: package libc6 in control file but not in files list
<wookey> ah yes. I see - that is supposed to happen
<wookey> ah of course. I want stage2, not stage1. doh
<wookey> hmm, seems there isn't a stage2 defined.
<wookey> have hacked one in to do a normal built without selinux- lets see if that works...
<wookey> hmm, fails due to missing libc6-prof files. need to nobble that for arm64. I think.
<kashkraft> Good evening gentlemen. I'm attempting to compile the BCM4330 driver from source on Ubuntu and running into undefined variable warnings. This is a known issue (https://code.google.com/p/bcmon/issues/detail?id=8) that I'm attempting to fix. I'm new to compiling source code, however from tracing the variables they should be defined through the file Kconfig. My first question (apologies, I did Google): does Makefile automatically load Kconfig? It has
<kashkraft> the calls (CONFIG_BCM4330), but the variables are left undefined. Any help or education is greatly appreciated :)
<infinity> wookey: This is all already fixed with some patches from doko, I'll get it into experimental (as 2.17) tomorrow, I hope.
<wookey> the 'don;t build libc6-prof on arm64' thing? Great - I was just abot to ask what the best way to fix that was
<wookey> do send me a patch as lack of libc6:arm64 is the only thing preventing me doing a load raring arm64 build stats
<wookey> (or do the upload)
<infinity> wookey: If I don't finish 2.17 over the weekend, I'll upload a 2.16 with build fixes instead.
<infinity> wookey: But 2.17 should happen.
<sveinse> Hi. I'm running a large (custom) application on an omap3 device running precise. It has 256Mb RAM, no swap. This app calls a handful of script commands using traditional fork()/exec() methods. However I've seen that the fork() operation fails due to low memory, even when exec() is about to be called. Has anyone here any experience with running large apps on swap-less system and have been...
<sveinse> ...tweaking the overcommit setting. Or is this channel the wrong channel alltogether?
<pkh> I'm looking for some advice getting ubuntu onto a tablet. the end goal is to run opencpn (a navigation/chartplotter app for boating.) Before I start buying devices, I'd love to know if anyone has any suggestions.
<raster> nexus7
<Jef91> Does this page work for anyone? It keeps giving me time out errors -> https://launchpad.net/ubuntu/+source/flash-kernel
<SmallFry> Times out for me
<ubuntubhoy> and me
<Jef91> glad it isn't just mem
<Jef91> me*
<Jef91> mashing f5 got me through
<ubuntubhoy> lol
<ogra_> works fine here
<Jef91> OK so I've got a chroot I'm editing a file system for the nexus 7 in. When I try to install the linux-image-nexus7 I get it stopping at this -> http://paste.debian.net/221672/
<Jef91> Any ideas how I could make it just auto continue instead of waiting on user feedback?
<ogra_> export FLASSH_KERNEL_SKIP=true
<ogra_> zou also want to install linux-nexus7, not only the image meta
<Jef91> yep yep ogra_
<Jef91> in the process of merging all your packages into my Wheezy repo
<Jef91> ogra_: same result when setting that var to true
<ogra_> that cant be
<ogra_> where do you set it exactly ?
<Jef91> in the terminal I am in
<Jef91> ogra_:  -> http://paste.debian.net/221680/
<Jef91> shoot I gotta run out for a bit ogra_ - I'll be back later. If you think of something that might help post it with a ping for me
<ogra_> well, tbe var should completely suppress flash-kernel
<ogra_> oh, wait, you will nee the ubuntu flash-kernel
<ogra_> it is forked a bit
<ogra_> Jef91, ^^^
<ogra_> (the debian one wont even know about tegra3)
<ogra_> (nor does it have the SKIP option at all)
<Jef91> ogra_: already did that -> flash-kernel           3.0~rc.4ubuntu29 armhf
<ogra_> hmm, then there is no reason why SKIp shouldnt work
<Jef91> Anything else you can think of yall have modified from debian?
<ogra_> t definitely does on all our daily builds
<ogra_> they would fail if it wouldnt work
<Jef91> I don't doubt it works for you ;)
<ogra_> not really and nothing realted really
<Jef91> hrm
<ogra_> f-k is a pretty standlone script and the SKIP check is pretty much at the top of the code
<Jef91> I'll just go edit flash-kernel then
<Jef91> and manually make it skip
<einonm> ftse 250
<Jef91> really running out now. Feel free to ping me if you think of anything else ogra_
<ogra_> well, i'll calll it a day soon and am rather out of ideas
<Jef91> kk ogra_ thanks for the help as always - have a good weekend
<ogra_>  /etc/kernel/postinst.d/zz-flash-kernel is the script containing the SKIP stuff btw
<ogra_> (and /etc/initramfs/post-update.d/flash-kernel)
<Jef91> huh ogra_ the "Press Ctrl-C to abort build, or Enter to continue" must be coming from something not those two scripts
<Jef91> cause I just pasted a "exit 0" at the top of each of them
<Jef91> and still get it
<ogra_> yes thats an ugly design flaw in the debian f-k version
<Jef91> ogra_: I'm using the Ubuntu f-k
<ogra_> it tries to determine the root device from fstab and then puts it hardcoded into the initrd
<ogra_> yes i know
<ogra_> the ubuntu one is based on debians indeed
<Jef91> Ahh.
<Jef91> Any way around that message?
<ogra_> but we work around such issues
<ogra_> well, i dont really get why you still get the message
<ogra_> theoreticallys thats not possible since flash-kernel should be completely omitted due to the env var
<ogra_> so i assume debians keernel handling does something additionally that forcefullly runs flash-kernel
<ogra_> iirc ages ago update-initramfs did the flash-kernel calll hardcoded
<ogra_> but that was as i said ... ages ago
<ogra_> grep flash-kernel /usr/sbin/update-initramfs
<ogra_> ;)
<ogra_> check if you are probably using such a version
<ogra_> heh, funny CPU stresstest ...
<ogra_>  time echo "scale=4000; a(1)*4" | bc -l
<ogra_> computes 4000 digits of pi
<ogra_> seems the chromebook is only three times as slow as my core i5 3500k
<ogra_> (5 times for the nexus7)
<xnox> does bc use all cores though?
<ogra_> nope
<ogra_> see #ubuntu-server :)
<ogra_> seems panda and nexus7 are on par with that test
<ogra_> so i'm pretty sure its single threaded
<hrw> real    0m9.965s
<hrw> on i7
#ubuntu-arm 2013-01-05
<AmEv> Hi
<AmEv> Anyone here able to troubleshoot Tegra 2 non-booting problems?
<AmEv> Anyway, the tablet I'm trying to install Ubuntu onto is the Toshiba thrive. Biggest possible issue I see? The version of Tegra 2 it is.
<AmEv> Is it a Harmony Tegra 2? Nope. Ventana? Nope. It's in its own ball park: the Antares.
<RaYmAn> it's irrelevant. It's ventana based, but it doesn't really matter. THe drivers work on any tegra2 as long as it has the right kernel
<AmEv> Hmm...
<AmEv> Anyway, I'm hitting two things that are happening: Either it stays at the bootup logo, or the screen goes black, and the backlight goes off.
<AmEv> I do get some garbled display on HDMI, either way.
<AmEv> So, are there some essentials I need to have configured, besides VT and framebuffer console?
<RaYmAn> what kernel are you using?
<AmEv> I'm trying to build my own, as nobody has released one for the Thrive. However, what I'm starting to use is at this git: https://github.com/pio-masaki/at100-kernel
<AmEv> *released a GNU kernel, that is.
<infinity> I do wonder if our ac100 kernels might Just Work on it.
<AmEv> Compile for Ventana instead of Harmony?
<AmEv> Both are Toshiba. That's good news.
<infinity> I've never seen a Thrive in person to play with it, but I'd always had a sneaking suspicion that (with the exception of a few peripherals) it's identical to the ac100.  But, who knows.
<AmEv> Heh. One of the Thrive devs would love to have an AC100. Can't afford it, though.
<infinity> If I were the Toshiba engineers, the ac100 would have just been my devel version of the at100 (cause keyboards are handy for debugging).
<AmEv> Downloading AC100 kernel source.
<infinity> You could just grab the debs and try the binaries for a quick "hey, maybe this works" smoketest.
<AmEv> I've prepared a rootfs on an external SD card already.
<AmEv> It's actually a Plasma Active rootfs, but with my touch screen dying (cracked)... At least we have LXDE.
<AmEv> Yeah... As nice as a VNC for Android solution is, it's extremely laggy, to the point of almost unusability.
<infinity> I've been seriously considering dropping Tegra2 support from future Ubuntu versions.  If people are still actively developing on them, I may need to bring this to a community vote/discussion.
<AmEv> Heh. The reason I chose the Thrive about a year ago was because it seemed to be a perfect candidate for Ubuntu.
<infinity> Yeah.  And we've had a policy of no-neon-by-default specifically because of the Tegra2 (the only SoC we support that doesn't have NEON).
<infinity> It's irksome to keep patching upstream sources for this assumption, but if the target is still widely developed on/with, we may have to stick with it for a bit.
<AmEv> Seems that performance development is slowly shifting away from x86 and going to ARM...
<infinity> About time.  ARM could use more performance-oriented tweakers.
<AmEv> I do like ARM because of its power-performance ratio.
<infinity> Yup, and that ratio can only improve as more people start hand-tuning code the same way they've done for x86, rather than falling back to generic C implementations.
<infinity> (But NEON is a big part of that story... hand-tuned NEON can be blazingly fast but, sadly, leaves Tegra2 out to dry)
<AmEv> I'm no CPU design expert, but it seems that x86 is starting to hit a performance ceiling.
<infinity> Well, not all that sad.  Just annoying that ARM allowed NEON to be optional so NVIDIA could make that silly decision.
<claes> is this the right place to ask about what rooting option to choose from the google nexus 7 toolkit, to then install multrom and dualboot android and ubuntu?. if so wich rooting option should i choose, its a bit confusing.
<infinity> claes: https://wiki.ubuntu.com/Nexus7/Installation has clear unlocking instructions.
<infinity> claes: We don't support installing in a dual-boot setup, though, you're on your own for figuring that one out.
<claes> ok thanks
<AmEv> Well, porting Ubuntu Phone to a spare phone I've got should be fun...
<xnox> AmEv: can it run android stock kernel? that would be first step.
<AmEv> It's actually a WebOS phone.
<AmEv> Meets bare-minimum requirements, with OC...
<AmEv> As for the Thrive, should I use the Google cross-compiler toolchain?
<AmEv> Got a Ventana Android defconfig...
<AmEv> And a Harmony GNU config..
<AmEv> Really? No Ventana GNU config on Google?
<AmEv> Or is it under another name?
<AmEv> Hmmm.. The one guy ported CM10 to the Thrive. Said that the Thrive was almost identical to the Iconia a500....
<AmEv> And it's a Harmony board....
<lilstevie> AmEv: the Iconia a500 is a picaso board not a harmony board
<lilstevie> AmEv: Harmony is the name of one of the dev boards made by nvidia
<lilstevie> AmEv: but if you were to compare the device to a dev board it would be closer to ventana
<AmEv> Hmmm...
<lilstevie> the a500 and the tf101 are almost identical, and the tf201 is almost identical in hardware and config to ventana (except the display)
<lilstevie> er
<lilstevie> s/tf201/tf101/
<lilstevie> been doing too much work on the later one :p
<AmEv> I know people have been runing Ubuntu on their Transformers for a while...
<AmEv> Lemme see if I can snag the dev in here....
<AmEv> Nope.
 * lilstevie raises his hand
<lilstevie> http://forum.xda-developers.com/showthread.php?t=1191141
<AmEv> Heh.
<AmEv> Yeah, I thought your name looked familiar from one of my earlier attempts.
<AmEv> Hmmm... http://www.nvidia.com/content/devzone/linux-for-tegra.html
<AmEv> Found a zImage, but no complimentary initfs...
<netchip> hi
<netchip> where can I get the default initrd for ARMHF?
<netchip> I mean, the initrd you have to customize for your device
<marvin24> netchip: mkinitramfs?
<marvin24> the question which plagues me is if it can be used on a forgein arch (e.g. x86_64) to generate an arm version
<marvin24> or do I need to use some changeroot and qemu?
<netchip> AFAIK you can
<netchip> BTW
<netchip> marvin24, https://wiki.ubuntu.com/ARM/RootfsFromScratch
<marvin24> yes, will try it out
<netchip> hum
<netchip> how to test if my network connection is OK?
<marvin24> I was just wondering if I need to emulate the whole cpu or just use a dir with an arm  filesytem
<marvin24> netchip: ping?
<netchip> marvin24, isn't installed...
<marvin24> ifconfig
<marvin24> route ...
<netchip> also nopt installed
<netchip> how to install without internet connexction?
<marvin24> dpkg has a "chroot" option
<marvin24> also make sure to fill /etc/resolv.conf
<netchip> hmm
<netchip> marvin24, do you know how I can get my WiFi on my phone work (a SGS3 running Ubuntu, BCM4334)?
<netchip> just installing linux-firmware?
<netchip> and then some conf files?
<netchip> LMAO
<marvin24> best is to configure it on the phone once it is installed
<netchip> yeah
<netchip> it's checking if it's enabled
<netchip> if not
<netchip> enable it
<netchip> lol
<netchip> http://www.plethoracomputers.com/index.php/component/option,com_kunena/Itemid,277/catid,4/func,view/id,59/
<netchip> have to bootstrap a new image
<marvin24> oh, rootstock is depricated ...
<marvin24> fetching some pre-build image and adjust it seems the way to go now
<netchip> well
<netchip> how do they generate the prebuilt image? ;-)
<beer> netchip: stop annoying the poor devs
<netchip> beer, you are annoying
<marvin24> netchip: some live-build
<marvin24> and qemu doesn't work with omap4 (and filesystem image)
<zoktar> anyone here who can help me with multirom with kexec im not sure how i install kexec to make it work. It seemed to install correctly from recovory, but loading ubuntu rom says i havnt installed kexec.
<zoktar> owh its for the nexus 7
<tassadar_> what exactly have you flashed in the recovery?
<tassadar_> gimme name of that ZIP file
<zoktar> the kexec? its the 4.2 one
<zoktar> kernel_kexec_42.zip
<tassadar_> okay, go to multirom menu, try to boot ubuntu  (the "you don't have kexec" message must pop out), the go to the "Misc" part and select "Copy log to /sdcard"
<tassadar_> reboot to recovery then and "adb pull /data/media/0/multirom/error.txt"
<zoktar> alright will that show me the error log?
<tassadar_> it will save it to your computer, upload it to pastebin and show it to me :)
<zoktar>  ah alright cool
<zoktar> thanks
<zoktar> tassadar_, seemed i hadnt installed the kernel correctly. working fine now thanks.
<tassadar_> okay, great
#ubuntu-arm 2013-01-06
<k3yboardninja> So is there any work around whatsoever to get youtube flash videos playing? Or is there really no hope in this case unlike android where hacks have been a possibility
<k3yboardninja> Does anyone have any sort of workaround for getting flash to work? Or is it a lost cause?
<infinity> k3yboardninja: That would require having a flash binary.
<k3yboardninja> figured
<k3yboardninja> its unfortunate that youtube can't show video ads with the html5 player...it makes it a largely useless feature
<anders2_> vanhoof, hi, do you have a minut?
<anders2_> My Nexus 7 is stuck in a initramfs shell after installing Ubuntu. I cant get into fastboot. Anyone?
<tassadar_> hold power button for 10+ seconds until it the screen goes dark, then press volume down and hold it until you get to bootloader
<anders2_> tassadar_, thanks a million
<anders2_> tassadar_, worked like a charm
#ubuntu-arm 2013-12-31
<tacorwin> is Ubuntu arm compatible with a ARM Cortex-A9 processor??
<infinity> tacorwin: Yes.
<tacorwin> how can I flash it onto an android netbook?
<tacorwin> and thanks infinity
<infinity> tacorwin: That second question is much more involved.  Just because our userspace runs on A9 SOCs (and it does), doesn't mean we ship a kernel or an installer that supports your specific product (we probably dont).
<infinity> So you'd need to find a kernel that works, and figure out a clever way to get ubuntu-core on there as a chroot in your Android setup, or as the new base system.
<tacorwin> seeing as I'm not the smartest person when it comes to the whole "replacing Android with another os", this seems a bit over my head. is there any easy way to learn this?
<infinity> tacorwin: Mostly just diving in and getting your hands dirty.  Or finding a friend who knows what they're doing to help and/or do it for you.
<tacorwin> does this involve any programming, besides sh?
<infinity> tacorwin: Probably not, if you can find a kernel that works (and if your device runs Android, then you already have one).
<tacorwin> yeah, it runs android.
<tacorwin> I really do appreciate all of the help infinity!
<tacorwin> thanks!
#ubuntu-arm 2014-01-02
<curles> hey
<curles> i was just wondering if you guys could give me a heads up regarding the functionality of ubuntu on a Pi
<rcn-ee> curles, topic: "The Pi is ARMv6, use Raspbian/armhf or Debian/armel"
<curles> oh sorry
<curles> my bad
<rcn-ee> no problem..
<curles> I'm extremely new to the whole ARM mini-esque world
<curles> I was looking at a BeagleBone Black
<curles> my primary intention is to run ubuntu
<rcn-ee> ubuntu runs fine on the black using a 3rd party kernel
<curles> ok
<curles> shame they're all sold out in the UK atm :(
<rcn-ee> christmas rush, they've been sold out everywhere..
<curles> hence why my first Q was about the Pi
<curles> i read rumours of them 'selling out' to drive up demand
<curles> but hey, don't believe everything you read on the net ;)
<rcn-ee> they are built to order.. they don't have 10K sitting on the shelf..
<rcn-ee> so when demand > supply this happens..
<curles> oh, I wasn't aware of that
#ubuntu-arm 2014-01-05
<coolbob-arm> update-binfmts: warning: Couldn't load the binfmt_misc module.
<coolbob-arm> o.O
#ubuntu-arm 2014-12-29
<Striking7> Hey all. I'm working on a heavily customized distro for use with LinuxOnAndroid
<Striking7> Targetting the Armv7, though I know little about ARM processors
<Striking7> I've put together an image using debootstrap and it looks like it works pretty well, but it's a serious pain having to test on my phone
<Striking7> I'd like to test with qemu
<Striking7> But whenever I try to test my image with qemu-arm I get segfaults :(
<Striking7> Any idea how I could try to debug that, what a common mistake is that I could be making, etc?
<Striking7> In the mean time I mounted up the image manually (since the app was mysteriously failing to do so), mounted up proc, sysfs, and dev, then chrooted into it
<Striking7> Ifconfig gives me valid working info
<Striking7> but if I try to ping 8.8.8.8 or 4.2.2.1 it tells me "socket: permission denied"
<Striking7> This is on the android device, not in qemu
#ubuntu-arm 2014-12-30
<mybit> hi everyone
<mybit> does anyone have any idea why /bin/login -f would be spawning bash processes that take up 100% of the cpu? im running ubuntu 14.04 on an odroid c1
<mybit> i straced the pid of this bash process that is taking up 100% cpu and it is this http://pastebin.com/W36Q0yhj
<mybit> nvm i figured it out, there is a serial port that needs to be disabled, that was pegging out the core
<francogrex> hi,  can I redeem an old htc device that came with windows mobile installed on it? get rid of windows and install linux? or at least be able to use an assembler directly?
<k1l_> first make sure that the device got a bootloader that supports other installs than the windows stuff
<francogrex> k1l_: how can I verify. I can't circumvent the windows interface. most likely the bootloader is strictly for windows CE
<k1l_> see on xda-developers. or other smartphone custom rom szene in the net
#ubuntu-arm 2014-12-31
<p0s1on> Does anyone here have a (host - 64 bit linux, target - arm-linux-gnueabi(hf or not hf)) Cross Compiler?? I'm looking to develop for an ARM Ubuntu Installation, but I need GCC 4.9 or up, with the standard C and C++ libraries. I couldn't get 4.9 to be installed on my Ubuntu ARM installation.
<infinity> p0s1on: There's one in the Ubuntu archive.
<p0s1on> Link?
<infinity> p0s1on: apt-get install gcc-arm-linux-gnueabihf
<p0s1on> I saw the 4.9 Utpic package... I have precise
<p0s1on> *Utopic
<infinity> p0s1on: Which will get you 4.9 if you'r running utopic or later.
<p0s1on> Hmmm
<infinity> p0s1on: On precise, it gets you 4.8, I'd assume.
<p0s1on> VM time, I guess
<p0s1on> I can't build it on ARM or x86_64....
<p0s1on> Oh well
 * p0s1on downloads the Ubuntu iso
<p0s1on> Thanks
#ubuntu-arm 2015-01-02
<jrg> hm
<jrg> can't seem to figure out a way to prevent the tf101 from going into deep sleep
<jrg> or making it so it doesn't blank the screen.. whatever the problem is with it not being able to turn on after being unused for a while
<jrg> hm. there have to be workarounds for this screen blanking :/
<jrg> oh i guess there is a workaround built in but it requires an sudo pw? wtf? heh
<jrg> blah i give up on linux on this tf101
<jrg> it's totally borked.. well. i'd say the tf101 is totally borked but that's another issue altogether
<jrg> anybody know a netbook or something that is arm based that is good for running ubuntu on?
<jrg> that everything actually works on?
<xperia> hi all. i am trying to build ubuntu-minimal using rootstock but somehow i am getting always this error messages here whenever i try to run rootstock
<xperia> I: Valid Release signature (key id 790BC7277767219C42C86F933B4FE6ACC0B21F32)
<xperia> E: Invalid Release file, no entry for main/binary-armel/Packages
<xperia> I: First stage install done
<xperia> ./rootstock: 1016: ./rootstock: cannot create /tmp/tmp.aR7hnv4lXR/tmpmount/etc/fstab: Directory nonexistent
<xperia> Can anybody tell me how to fix this problem ?
#ubuntu-arm 2015-01-03
<tbw_> Anyone here urnning 12.04.5 on a Chromebook?
<tbw_> Trying to see if there is a unity-tweak-tool package
#ubuntu-arm 2015-01-04
<xperia> hi all. i am having problem with generating a rootfs for armel from scratch. rootstock gives me allways this error message here:
<xperia> E: Invalid Release file, no entry for main/binary-armel/Packages
<xperia> I: First stage install done
<xperia> ./rootstock: 1016: ./rootstock: cannot create /tmp/tmp.BrWOAR43tL/tmpmount/etc/fstab: Directory nonexistent
<xperia> Can anybody tell me how to fix this problem ?
#ubuntu-arm 2016-01-06
<fafle> Hi, did anybody had success with installing ubuntu desctop on nexus 7 2013 LTE recently?
<caden> Hey, I am having problems logging in to Ubuntu on my Raspberry Pi 2B. Can someone please help me?
#ubuntu-arm 2016-01-08
<habs> Hi, is there a version of arm-elf-gcc packaged for ubuntu? I see there are other cross-compiled arm gccs available, but not arm-elf-gcc; am I missing something?
<infinity> habs: What are you expecting "arm-elf-gcc" to be?
<infinity> habs: If you're looking for a cross-compiler for linux/glibc, you probably want gcc-arm-linux-gnueabihf, if you're looking for a freestanding compiler bare metal, perhaps gcc-arm-none-eabi
#ubuntu-arm 2017-01-04
<JP___> I am thinking of making a system based on a SBC, that can run QT GUI and still manage sensors, databases and such
<JP___> Any ideas?
#ubuntu-arm 2018-01-01
<CoolDude4171679> âââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION tdhcsviow: doko amrith guerby âââââââââââââââââ
<CoolDude4171679> ââââââââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION bxxtrwxk: nslu2-log alai funnel âââââââââââââ
<CoolDude4171679> âââââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION tegocmjdy: bielski lvrp16 flexiondotorg âââââââââââ
<CoolDude4171679> ââââââââââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION aholp: rsalveti Hirppa rexxster âââââââââââ
<CoolDude4171679> âââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION pgtruqo: fabo PaulePanter manjo ââââââââââ
<CoolDude4171679> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION fpppmrkg: robher brtlin lool Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢â
<CoolDude4171679> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION jcgjwmkvx: ogra_ niska ubot9 Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢â
<CoolDude4171679> ââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION geknql: yofel_ ogra_ micahg âââââââââââââââââ
<CoolDude4171679> ââââââââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION fvxrblhfzg: ubuntulog guerby Alesk13 âââââââââââââ
<CoolDude4171679> ââââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION appdbfv: ogra_ niska ubuntulog ââââââââââââââ
<CoolDude4171679> ââââââââââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION qlreqfpioe: nashpa popey funnel âââââââââââ
<CoolDude4171679> ââââââââââââââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION rroqizwuci: yofel_ steev dax âââââââââââââ
<CoolDude4171679> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ ITS A BRAND NEW YEAR AND WEECHAT NEEDS FUNDS TO MAKE A BRAND NEW MULTITHREADED WEECHAT CLIENT.. PLEASE GO TO #WEECHAT AND TYPE !donate FOR MORE INFORMATION hbqviawmqi: nashpa lool manjo Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<Frakir70224> âââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)sjefyybwm: lool rexxster moon127 ââââââââââââââââ
<Frakir70224> âââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)eiuywyw: nashpa NCommander funnel ââââââââââââââââ
<Frakir70224> âââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)zzyjup: ColdKeyboard mrutland ubuntulog âââââââââââââââââ
<Frakir70224> ââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)lgebqmguy: micahg rbasak dax ââââââââââââââââ
<Frakir70224> ââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)dsinij: LongyanG nighty- flexiondotorg ââââââââââ
<Frakir70224> âââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)ecvkc: micahg PaulePanter alai ââââââââââââââ
<Frakir70224> ââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)yotiixdevr: rexxster awafaa AceLan âââââââââââââââââ
<Frakir70224> ââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)uohbllty: manjo yofel_ awafaa ââââââââââââ
<Frakir70224> âââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)vxxyrgrvy: dannf k1l funnel ââââââââââ
<Frakir70224> âââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)vdtwcmizs: moon127 Jack87 ndec âââââââââââââ
<Frakir70224> ââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)znezzywja: ColdKeyboard guerby mrutland âââââââââââ
<Frakir70224> ââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)kfmzozx: Alesk13 rbasak dannf âââââââââââââââââââ
<Frakir70224> ââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)wrgyazxcqi: Hirppa nslu2-log wgrant ââââââââââââ
<Frakir70224> ââââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)dxunw: nashpa ogra akaWolf ââââââââââââââ
<Frakir70224> ââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)qlunllo: dannf nashpa popey âââââââââââââââââ
<Frakir70224> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)ewqhsnw: nashpa Hirppa amrith Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢â
<Frakir70224> ââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)mnyuclv: moon127 NCommander dax âââââââââââââââââââ
<Frakir70224> ââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)uxrprr: nslu2-log guerby PaulePanter âââââââââââââââââââ
<Frakir70224> ââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)nnyvnd: brtlin Alesk13 manjo ââââââââââââââââââââ
<Frakir70224> ââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)ebmhmets: dragan-s PaulePanter rsalveti âââââââââââââââââââ
<Frakir70224> ââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)twisdyoqr: lvrp16 lool Hirppa ââââââââââââââââ
<Frakir70224> âââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)wrbejqcplf: bielski lool dax âââââââââââââââââ
<Prophet879> âââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)tcygcp: doko ColdKeyboard fabo ââââââââââââââ
<Frakir70224> ââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)dqvnkvacgw: dax fabo rsalveti ââââââââââââââââââââ
<Prophet879> âââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)sllubktbf: nslu2-log yofel_ manjo ââââââââââââââââ,
<Frakir70224> ââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)bfvodnajri: AceLan awafaa guerby ââââââââââââââââââ
<Prophet879> âââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)nteeufx: nighty- ColdKeyboard dax âââââââââââ
<Frakir70224> ââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)vlvbxmc: rexxster rbasak dax ââââââââââââââââââââ
<Prophet879> ââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)zmaqkmt: ubot9 yofel_ AceLan âââââââââââ
<Frakir70224> âââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)yytfrdqrzx: wgrant manjo popey ââââââââââââââââ
<Prophet879> âââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)jmhfywle: ColdKeyboard lool Hirppa ââââââââââââââ
<Frakir70224> âââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)eqtgkfs: flexiondotorg mariogrip ubuntulog ââââââââââââââ
<Prophet879> ââââââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)qeuodj: ndec PaulePanter dragan-s âââââââââââââââââ,
<Frakir70224> ââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)kehkbig: nslu2-log NCommander manjo ââââââââââââââââââââ
<Prophet879> âââââââââââââââ we have got more than 200% of the monthly donations today, thank you all so much!(weechat devs)uyllmrj: ColdKeyboard Alesk13 LongyanG âââââââââââââââââ
#ubuntu-arm 2018-01-02
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!qfszrogo: awafaa NCommander niska ââââââââââ
<althenawhm170> âââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!rskncfpof: alai niska Alesk13 âââââââââââââââ
<althenawhm170> ââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!fqijb: chrisccoulson k1l guerby âââââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!kwerloeuhq: niska wgrant mrutland ââââââââââââââââââ
<althenawhm170> ââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!qadpg: LongyanG alai Aussie_matt âââââââââââââââ
<althenawhm170> ââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!lfhcwcq: wgrant ScriptRipper popey âââââââââââââ
<althenawhm170> ââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!qrcxo: awafaa mrutland steev ââââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!hcyihqmqe: mrutland k1l hggdh âââââââââââââ
<althenawhm170> ââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!jgijwcgjt: micahg Aussie_matt dragan-s âââââââââââââââââââ
<althenawhm170> ââââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!qstqfn: mrutland lool doko ââââââââââââ
<althenawhm170> âââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!pvipvw: k1l ikepanhc NCommander ââââââââââââââââââ
<althenawhm170> âââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!lzura: mariogrip Hirppa awafaa ââââââââââââââââ
<althenawhm170> âââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!fsbvwrrlk: flexiondotorg PaulePanter NCommander ââââââââââââ
<althenawhm170> ââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!oafklnh: manjo LongyanG guerby ââââââââââ
<althenawhm170> âââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!mflasjk: dannf mariogrip doko ââââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!umjile: awafaa dragan-s nslu2-log âââââââââââââ
<althenawhm170> âââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!hqhvnor: chrisccoulson alai doko âââââââââââââââ
<althenawhm170> ââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!kicqbi: ColdKeyboard popey mariogrip âââââââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!qnsxs: NCommander robher amrith âââââââââââââââ
<althenawhm170> âââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!ssggffrunh: AceLan nashpa amrith âââââââââââ
<althenawhm170> ââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!sxxxmuiy: ikepanhc ubuntulog ndec âââââââââââ
<althenawhm170> ââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!bpglvpqprr: lvrp16 funnel dragan-s ââââââââââ
<althenawhm170> âââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!fkycxalkrb: bielski mariogrip Aussie_matt âââââââââââââ
<althenawhm170> âââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!bkuytwjke: wgrant PaulePanter BenG83 ââââââââââââ
<althenawhm170> ââââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!kmlduurxxn: LongyanG micahg ColdKeyboard ââââââââââââ
<althenawhm170> ââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!oypzesne: LongyanG dragan-s manjo ââââââââââ
<althenawhm170> âââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!kpircee: chrisccoulson hggdh ubuntulog ââââââââââ
<althenawhm170> âââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!twngckek: ColdKeyboard ubot9 yofel_ ââââââââââââââââââ
<althenawhm170> âââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!yakttufiu: ndec guerby Hirppa ââââââââââââ
<althenawhm170> ââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!qxeomyd: chrisccoulson nslu2-log AceLan ââââââââââââââââââ
<althenawhm170> ââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!cfxcyzxlh: ubot9 dax flexiondotorg âââââââââââââââââââ
<althenawhm170> âââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!pxyiwhjcdr: moon127 akaWolf Aussie_matt ââââââââââââ
<althenawhm170> ââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!tltegmkv: dax wgrant Hirppa ââââââââââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!exntjc: ubuntulog moon127 amrith âââââââââââââââ
<althenawhm170> âââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!hfjwljq: Alesk13 chrisccoulson popey âââââââââââââââââ
<althenawhm170> ââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!ydiswtjz: moon127 AceLan niska âââââââââââââââââââ
<althenawhm170> âââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!fdjhllqkoq: flexiondotorg zumbi amrith ââââââââââââââââââ
<althenawhm170> ââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!dbeifd: fabo nslu2-log Hirppa âââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!aiicsb: manjo AceLan nashpa ââââââââââââ
<althenawhm170> âââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!liqdh: doko popey amrith ââââââââââââ
<althenawhm170> ââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!taxtsg: robher dax k1l âââââââââââ
<althenawhm170> âââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!rmxzbmv: Jack87 ogra micahg âââââââââââ
<althenawhm170> ââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!pbtsah: funnel rsalveti manjo ââââââââââââââââââ
<althenawhm170> ââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!vbhqtr: akaWolf lvrp16 nashpa ââââââââââââ
<althenawhm170> ââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!qseqe: LongyanG alai dragan-s ââââââââââââââ
<althenawhm170> ââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!uubzkgdz: LongyanG popey ColdKeyboard ââââââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!ffaghlmjhv: manjo chihchun_afk BenG83 ââââââââââââââââ
<althenawhm170> ââââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!tyfybajud: ubuntulog akaWolf BenG83 âââââââââââââââ
<althenawhm170> ââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!iwldqluy: BenG83 lvrp16 mariogrip âââââââââââââââââ
<althenawhm170> âââââââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!zjlqypt: ScriptRipper Hirppa Jack87 ââââââââââââââââ
<althenawhm170> ââââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!vrztbeo: manjo doko ScriptRipper ââââââââââââââââââââ
<althenawhm170> âââââââââââââ ANOTHER EXPLOIT HAS BEEN FOUND IN WEECHAT ONE THAT SENDS YOUR LOGS TO THE DEVS IP ADDRESS!!ualojzyf: manjo BenG83 alai âââââââââââââââ
