[05:07] <DanaG> Feb 15 23:02:44 beagleboard NetworkManager: <WARN>  device_creator(): /sys/devices/platform/musb_hdrc/gadget/net/usb0: couldn't determine device driver; ignoring...
[06:10] <DanaG> argh, so I can't use NM on the onboard usbnet.
[06:11] <DanaG> anyway, I've set the beagleboard up to be dhcp server now, instead of client.
[06:11] <DanaG> That's consistent with what WinMobile does, at least.
[08:42] <lool> apw: Hey
[08:43] <lool> apw: So I discussed linux-versatile on ubuntu-mobile@
[08:43] <lool> apw: See <20100211101825.GA5444@bee.dooz.org>; had a reply from ogra
[08:43] <lool> apw: I think it's helpful to provide udebs and a meta
[08:43] <lool> apw: Do you want a bug report?
[08:43] <lool> or two rather
[08:46] <apw> bug report yes please
[08:49] <lool> apw: lp #522516 and lp #522515
[08:49] <ubot4> Launchpad bug 522516 in linux-meta (Ubuntu) "linux-versatile meta (affects: 1)" [Undecided,New] https://launchpad.net/bugs/522516
[08:49] <ubot4> Launchpad bug 522515 in linux (Ubuntu) "linux-versatile udebs (affects: 1)" [Undecided,New] https://launchpad.net/bugs/522515
[08:50] <lool> apw: Also, just an unrelated heads up on lp #522308 which I filed and probably went under the radar when moving to 2.6.32
[08:50] <ubot4> Launchpad bug 522308 in linux (Ubuntu) "linux-source-2.6.32 is empty (affects: 1)" [High,New] https://launchpad.net/bugs/522308
[08:50] <apw> no i suspect i broke that when i did the abstraction simplification
[09:44] <Sleep_Walker> hello ubuntu people
[09:50] <Sleep_Walker> I'd like to ask about Sharp PC-Z1 Netwalker a bit
[09:51] <Sleep_Walker> does anyone here knows about this device?
[09:51] <lool> Sleep_Walker: Some people here do, yes
[09:52] <Sleep_Walker> 1] is it based on some babbage board?
[09:52] <lool> Babbage is the name of the reference design boards from freescale used for development purposes
[09:52] <lool> It's based on the same SoC, but it's a different board
[09:53] <Sleep_Walker> I see
[09:53] <lool> for instance it has no NIC, one USB port, no MIC jack so it's different from the babbage boards
[09:53] <Sleep_Walker> 2] is someone working on merging drivers to upstream Russel's kernel?
[09:54] <ogra> someone upstream imx51 drivers where appropriate
[09:54] <ogra> *upstreams
[09:55] <lool> Sleep_Walker: ATM, I am not sure that any imx51 SoC based board boots with an upstream kernel, so that would need to happen first; the kernel trees are hard to merge for various reasons
[09:55]  * ogra doesnt know how big the portion beyond general basic mx51 stuff is though
[09:56] <lool> IIRC, there were some people working on getting at least the basic boot stuff working for imx51 upstream, but that's a long way to go until we get to things like wifi or video drivers...
[09:56] <amitk> Sleep_Walker: it will boot with a 2.6.34, I've pushed the base mx51 code upstream
[09:57] <Sleep_Walker> and where are these people gathered? (mailing list, irc, forum...)
[09:57] <amitk> but there's a LOT to be done, in case you're looking to help
[09:57] <Sleep_Walker> amitk: yeah, I had something like that in my mind...
[09:58] <Sleep_Walker> (if there will be time)
[09:58] <Sleep_Walker> I noticed your patches so I was curious
[09:58] <Sleep_Walker> unfortunately I don't know much about Netwalker's HW
[09:59] <Sleep_Walker> only that I was able to read from sources and from running system
[09:59] <amitk> Sleep_Walker: Just hang out on #ubuntu-kernel if you need some help and on linux-arm-kernel otherwise
[09:59] <persia> amitk: You pushed the Netwalker code upstream?
[09:59] <amitk> persia: Babbage base code (serial port, timers, clocks)
[10:00] <persia> Ah.  Do you know if anyone is pushing the Netwalker patches?
[10:00] <persia> lool: There's actually two USB ports : one full-size, one mini.
[10:01] <Sleep_Walker> is it OTG capable?
[10:01] <Sleep_Walker> and can that be charged from USB?
[10:01] <amitk> persia: Netwalker is the pegatron stuff?
[10:01] <persia> amitk: Not at all (why does everyone think this?)
[10:02] <ogra> heh
[10:02] <amitk> persia: too many codenames...
[10:02] <persia> Sleep_Walker: The mini port looks like an OTG port, but I haven't tried to use it, actually.
[10:02] <amitk> with no context
[10:03] <persia> Yeah, well.  Netwalker is it's own beast.  There's kernel patches for the kernel that shipped, but I haven't heard about anyone porting them to newer kernels or pushing them upstream.
[10:03] <Sleep_Walker> persia: I tried to connect it with PC with no success
[10:03] <lool> persia: Well true, I meant one full size one compared to 4 on babbage boards
[10:03] <amitk> persia: is there a public git tree for the sources? Who did the kernel? What company made it?
[10:03] <lool> Both have mini-USB ports
[10:03] <persia> Sleep_Walker: I don't believe the USB Gadget driver is included in the shipping kernel: you might need to fiddle the kernel configuration.
[10:04] <Sleep_Walker> and that is the problem - I wasn't able to find any comunity about this device
[10:04] <persia> amitk: Not git, but there's a public apt-get source repo.
[10:04] <persia> (I heard the Netwalker kernel devs don't use git)
[10:04] <lool> amitk: netwalker is a sharp device
[10:05] <persia> Sleep_Walker: The community is almost entirely local.  The device has seen very little adoption overseas.
[10:05] <Sleep_Walker> persia: I saw some SW support but I wasn't sure about HW support
[10:05] <persia> Sleep_Walker: Aside from accellerated audio/video codecs, everything seems to be open-source.
[10:05] <amitk> persia: and their kernel is based on freescale's SDP?
[10:05] <lool> http://www.ubergizmo.com/15/archives/2009/08/sharp_netwalker_unveiled.html
[10:06] <persia> amitk: I don't know precisely.  When it comes to kernels, I'm just a user :)
[10:06] <persia> That's not quite right.  It's 10 hours JEITA, which means 5-7 depending on load.
[10:07] <amitk> persia: if you can point me to the source, I could have a quick look when I have some time.
[10:07] <persia> Sharp just released a new "Dictionary edition" in the past couple weeks.  The specs seem about the same (just different software load), but all the samples at the shop were password-locked, and I didn't want to try to hack them.
[10:08] <persia> amitk: Sure.  Let me dig up what I have.
[10:08]  * persia fusses with apt sources
[10:09] <persia> amitk: If you find it's not terribly hard to get up-to-date kernels, I'll give you one :)
[10:10] <persia> amitk: http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux-fsl-imx51/linux-fsl-imx51_2.6.28-15.50fsl1araneo19.dsc
[10:11] <persia> That's from January.  I'm unsure if there's a newer one on the new "Dictionary Edition" devices.
[10:11] <persia> But that's definitely enough for basic HW enablement.
[10:12] <Sleep_Walker> psi died - sorry - did I miss something?
[10:15] <persia> Sleep_Walker: I posted the URL to kernel sources for the Netwalker.  Dunno if those are useful to you.
[10:15] <persia> Nothing else meaningful.
[10:16] <Sleep_Walker> persia: does it differ from the ones I get with apt-get source
[10:16] <Sleep_Walker> or from the one provided by sharp?
[10:16] <persia> Don't think you.  You're getting linux-fls-imx51 2.6.28-15.50fsl1araneo19 ?
[10:16] <persia> s/you/so/
[10:17] <persia> But I haven't checked the uname on the newest edition, so I don't know if there's a new kernel available from Sharp.
[10:17] <Sleep_Walker> ....araneo18
[10:17] <Sleep_Walker> I don't think so
[10:18] <Sleep_Walker> and I thought I bought finaly device for work and not to hack :b
[10:19] <amitk> persia: I don't see any 28-15.50 at http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux/
[10:19] <persia> amitk: `dget http://netbook-remix.archive.canonical.com/updates/pool/public/l/linux-fsl-imx51/linux-fsl-imx51_2.6.28-15.50fsl1araneo19.dsc` should get you want you want.
[10:20] <persia> It's in the linux-fsl-imx51 subdirectory.
[10:21] <Sleep_Walker> ok, I'll try to create wiki page about Netwalker (sorry, but not ubuntu one) to gather informations and possible community around Netwalker
[10:21] <Sleep_Walker> thanks for all your help
[10:21] <Sleep_Walker> bbl from work
[10:21] <persia> Sleep_Walker: Please share the URL when you get it together.
[10:21] <ogra> Sleep_Walker, if you create one, can you point us to it so we can at least link it from the ubuntu wiki ?
[10:22] <Sleep_Walker> of course
[10:22] <Sleep_Walker> I don't want to split efforts around t
[10:23] <amitk> persia: so it's called erdos...
[10:25] <Sleep_Walker> I'lll put it on hackndev.com - distro neutral area :)
[10:25] <persia> amitk: erdos?
[10:26] <amitk> persia: the board is called erdos in the kernel tree
[10:26] <persia> Ah.
[10:27] <amitk> and from a 5s look, the patches that I pushed upstream ought to be able to boot on it (given that IO mappings are identical to babbage)
[10:27] <persia> So I should be able to boot a babbage kernel?  I can test with lucid if you like.
[10:28] <Sleep_Walker> erdos is name of Netwalker's board in kernel?
[10:28] <lool> persia: I don't think so, the bootloader board id needs to match
[10:28] <persia> lool: That's a bootloader thing or a kernel thing?
[10:28] <amitk> persia: naah, it'll require a tweak or two, but the kernel should probably be 99.99% identical
[10:28] <lool> Plus the board support file will try to load drivers at various I/O addresses where you might miss devices or have other ones, for instance the netwalker has builtin wifi and not babbage etc.
[10:28] <ogra> persia, upstream, not lucid
[10:28]  * persia is *not* overwriting the nice dual-boot support redboot
[10:29] <amitk> lool: we're talking about the upstream (minimal) babbage kernel
[10:29] <Sleep_Walker> you can do it on kernel side
[10:29] <persia> lool: wifi is through separate modules.
[10:29] <lool> persia: The kernel needs to grow a new netwalker board file with the proper board id and this file needs to be tweaked to list the proper devices
[10:29] <lool> amitk: I'm not sure which babbage kernel persia meant
[10:29] <amitk> lool: the board id is mapped to babbage
[10:29] <lool> exactly
[10:30]  * persia was kinda hoping for the lucid babbage kernel, but will trust statements that this doesn't work (didn't work with karmic kernel)
[10:30] <lool> amitk: Oh you mean netwalker uses babbage's?
[10:30] <amitk> MACHINE_START(MX51_BABBAGE, "SHARP PC-Z1") .phys_io      = AIPS1_BASE_ADDR, .io_pg_offst  = ((AIPS1_BASE_ADDR_VIRT) >> 18) & 0xfffc,
[10:30] <ogra> which should be fine for bringup
[10:30] <lool> Hmpf
[10:30] <ogra> just not for all devices
[10:30] <amitk> lool: right
[10:30] <lool> amitk: isn't this ugly?
[10:30] <ogra> lool, did you expect beauty ?
[10:30] <lool> persia: it seems that a minimal upstream kernel would work with the babbage id then; nervermind
[10:30] <amitk> lool: tell me about it, they were too lazy to even get their own board id
[10:30] <Sleep_Walker> :b
[10:31] <lool> persia: I wouldn't try booting a full blown kernel though, that might blow things up
[10:31] <persia> lool: As in physical damage?
[10:31] <lool> I can't exclude that
[10:32] <amitk> persia: I think there is no danger with physical damage with the minimal kernel going upstream in 2.6.34. Since it keeps most IO pins to their defaults
[10:32] <amitk> and we're no where close to a full-blown kernel yet
[10:32] <lool> amitk: I think persia intended to use the lucid babbage binary kernel against a netwalker
[10:33] <persia> Ah.  I think I'll wait then, since I use this daily as a handheld, and it also houses my lucid pbuilder environment :)
[10:33] <lool> Which I fear has a small chance of being dangerous
[10:33] <amitk> true
[10:58] <lool> apw: Thanks for the quick fix
[10:58] <apw> we get into trouble if the source is missing ...
[11:26] <NCommander> lool: ping. for ARM softbootloader, I need to have kexec-tools available for kexec, but the package unfortunately then changes the installed system to use kexec for rebooting as well which is unfortunate. I want to split the package out so I can have kexec installed and on its own without having the restart script stuff, any ideas on how to best do that?
[11:26] <lool> apw: Ah?  I saw only three rbdeps in universe
[11:27] <lool> NCommander: the restart stuff is disabled in Ubuntu by default
[11:27] <apw> people complain when that package is empty as they percieve it contains the source, and if its empty we arn't publishing it, even though its in the the 'source' package
[11:28] <lool> apw: Ah so a lot of people get it wrong, eh
[11:28] <apw> yep
[11:30] <persia> apw: Now you just need to find a way to make `apt-get source linux` work :)
[11:30] <apw> persia, define work
[11:30] <persia> apw: heh.  DWIM : download the source for the source package named "linux".
[11:31] <persia> Current trick is to use `apt-get --only-source source linux`
[11:32] <NCommander> lool: hrm, that must be a recentish change. Ignore previous ping then :-)
[11:32] <lool> NCommander: It's not
[11:32] <lool> It might be that you used the Debian package during the sprint
[11:32] <NCommander> lool: It still did the kexec-load in karmic.
[11:32] <NCommander> Which was the last time I looked at this
[11:33] <lool> This was disabled in June
[11:34]  * NCommander shrugs
[11:34] <NCommander> lool: sorry for the noise
[11:41] <dmart> dyfet: ping
[11:42] <dyfet> *yawn*
[11:43] <dyfet> morning
[11:43] <dmart> Hi... wasn't sure if you'd be up
[11:43] <dmart> I had a question on gmp
[11:44] <dyfet> oh I remember that...
[11:44] <dmart> Did you try to build the asm code for Thumb-2 in the end?
[11:45] <dyfet> I had some trouble with coming up with a patch for configure.  They reject using try_compile, and try to do everything by the gnu target architecture tags alone
[11:46] <dmart> Actually, I had an idea for that... you can maybe get the predefined macros out of GCC and munge that.  I wrote some notes on the Thumb-2 howto wiki page.
[11:46] <dyfet> Oh, okay, cool!  I did not notice that
[11:47] <dmart> It was late yesterday :)
[11:47] <dyfet> But that is kind of what I need to do for that one :)
[11:48] <dmart> However, if you do try to build this code for Thumb-2, we do need to check that the function symbols in the asm are properly tagged as function symbols, otherwise they would get called as ARM accidentally.
[11:48] <dmart> I think that the PROLOGUE() m4 macro used in the asm does this, but I didn't fully track down where it's defined.
[11:49] <dyfet> Ah....
[11:49] <asac> great. we have 1 builder again ;)
[11:49] <asac> https://edge.launchpad.net/builders
[11:50] <dmart> Did you have >1 or 0 builders before?
[11:50] <asac> perfect timing in a3 week ;)
[11:50] <persia> dmart: 0
[11:50] <dmart> (I'm guessing >1)
[11:50] <asac> dmart: this morning we had 0 ;) ... usually we have 7
[11:50] <dmart> Oh, OK
[11:50] <dmart> What's the problem?
[11:51] <dyfet> For me, lack of coffee :)
[11:51] <asac> dmart: not sure. our is knows about it and are investigating. most likely the aweful pegatrons died again
[11:52] <dmart> Hum
[11:53]  * asac hopes for new build machines ;)
[11:54] <dmart> dyfet: To check whether a symbol is a proper Thumb code symbol, you need to use readelf -s <object>
[11:54] <dmart>      6: 00000001     0 FUNC    GLOBAL DEFAULT    1 f
[11:54] <dmart> Crucially, the symbol type if FUNC, and the value is an odd number (bottom bit set)
[11:55] <dmart> objdump helpfully masks of the bottom bit so as not to confuse you, so it's no good for this check :P
[11:55] <dyfet> This should be described on the wiki page too...
[11:55] <dmart> Yeah, I'll post it.  (I was just figuring out how to check...
[11:56] <saeed> asac
[11:57] <asac> saeed: hi
[11:57] <saeed> hey
[11:58] <saeed> I want to install lucid img on dove
[11:58] <asac> right
[11:58] <asac> whats the prob?
[11:58] <saeed> http://cdimage.ubuntu.com/ports/releases/lucid/alpha-2/ has only imx images
[11:59] <asac> saeed: just pick latest daily
[11:59] <saeed> link?
[11:59] <asac> and yes. we didnt publish alpha2, because at that time we had severe issues with dove ;)
[11:59] <asac> saeed: http://cdimage.ubuntu.com/ports/daily-live/current/
[11:59] <asac> http://cdimage.ubuntu.com/ports/daily-live/current/lucid-desktop-armel+dove.img
[12:00] <saeed> ok
[12:00] <persia> saeed: If /current/ doesn't work for you, there's often an archive of the past couple days which ought work if current doesn't.
[12:00] <asac> yeah. just navigate one up in the tree
[12:00] <asac> and you will find it
[12:00] <persia> (end the URL at .../daily-live/ to see the (short) archive list.
[12:00] <asac> but current should work afaict
[12:00] <persia> Usually does.
[12:01] <saeed> can you update me which issues still unresolved with dove
[12:04] <asac> saeed: i planned to do some thorough testing on dove this week ... afaik all bad issues are fixed with the X0
[12:04] <saeed> great
[12:04] <asac> NCommander: any unresolved dove issues for saeed ?
[12:04] <NCommander> asac: saeed, X0 isn't here yet (I wasn't home yesterday to get the delivery)
[12:05] <NCommander> saeed: I did see the patch to fix kexec()'s decompression speed, thanks for the fast turnaround on that.
[12:05] <persia> saeed: I can't find a good list of *all* the issues with dove, but https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove probably includes a good chunk of them.
[12:05] <saeed> you're welcome
[12:06] <asac> NCommander: can you throw mrpt on one of your many babbage boards and check if that builds?
[12:06] <asac> NCommander: seems that package killed all our biulders
[12:06] <NCommander> asac: ugh. I'm still not setup on any of the boards, and may need to do a purchase order to get them all up
[12:07]  * NCommander is kinda still coming off unpacking from the long weekend
[12:07] <asac> k
[12:08] <saeed> NCommander: when I tried kexec, the bootargs were not passed to the kexeced image
[12:09] <saeed> I've had to append all the command line in order to make it work properly
[12:18] <NCommander> saeed: I thought that's the way kexec is supposed to work but I'm not 100% sure
[12:21]  * persia is 100% sure : one may well want to have completely different bootargs from the bootloader and to the target kernel
[12:32] <NCommander> dmart: is there a handy list of arm opcodes? I think I need to tear some code apart by hand without a disassembler
[12:32]  * NCommander feels like crying
[12:34] <asac> NCommander: for ooo=?
[12:35] <NCommander> asac: uh huh :-/
[12:35] <suihkulokki> NCommander: not handy but IIRC the only place to find opcode->instruction mapping is arm archictecture reference manual (aka ARM ARM)
[12:36]  * NCommander is trying to determine where this code is blowing up
[12:37] <suihkulokki> alternatively, if you can run the binary under qemu linux-user, qemu-arm -d in_asm ./binary can give good insight
[12:38] <dmart> NCommander: really best to use a disassembler ;) (You could create an assembler file with the data words in it and disassemble that.)
[12:38] <dmart> If you really want to decode instructions by hand, you need to refer to the ARM ARM
[12:38] <NCommander> dmart, suihkulokki its just a buch of hexcodes in a C file. No specific binary to take apart ;.;
[12:39] <dmart> Ah, is this in the kexec implementation?
[12:40] <NCommander> dmart: OpenOffice
[12:40]  * NCommander is trying to track down where it explodes
[12:40] <dmart> oh!  Which file?  I think I have that unpacked somewhere...
[12:41] <asac> its in the uno bridge
[12:41] <asac> we currently need to ship a jaunty .so fo rthat
[12:41] <asac> because otherwise it fails
[12:41] <asac> we have a binutils bug open for that
[12:41] <asac> iirc
[12:42] <NCommander> asac: its not clear that binutils is the issue
[12:42] <NCommander> the debugger breaks and cries though when you try and solve this, so I'm just scattering debug printfs
[12:42] <dmart> Can you point me to the affected file in OOo?
[12:43] <NCommander> dmart: we don't know specifically where its going bust
[12:43] <asac> NCommander: can you please give dmart the bug id ;)
[12:43] <NCommander> dmart: https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009
[12:43] <ubot4> Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 3 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,Won't fix]
[12:44] <asac> bug 436617
[12:44] <ubot4> Launchpad bug 436617 in binutils (Ubuntu Karmic) (and 2 other projects) "ARM unwind table linker processing broke OO's uno2cpp (affects: 1)" [High,Won't fix] https://launchpad.net/bugs/436617
[12:44] <asac> i think thats the bug
[12:44] <asac> dmart: NCommander: ^^
[12:44] <dmart> thanks
[12:45] <asac> hmm ... the sata disk i have is really really slow here for imx51
[12:45]  * asac break before meeting
[12:52] <dmart> NCommander: Is this any help? http://pastebin.ubuntu.com/377573/
[12:52] <NCommander> dmart: I'll play with it in a moment
[12:52] <dmart> It should allow you to decode invidual opcodes
[12:52]  * NCommander is making some headway
[12:53] <dmart> ok
[15:11] <asac> dmart: the links to the quick references in the asm intro you posted dont exist
[15:11] <asac> like http://www.arm.com/pdfs/QRC0001H_rvct_v2.1_thumb.pdf
[15:16] <asac> dmart: hmm for libv4l compiler wth thumb2 complains about  cbnz    r5, .L2  ... with "jidctflt.s:74: Error: branch out of range"
[15:16] <asac> i found a quick refernce and that refers to CBNZ as T2 :/
[15:17] <asac> with -marm it doesnt fail
[15:19] <asac> cat jidctflt.s | pastebinit
[15:19] <asac> http://pastebin.com/f350081ab
[15:19] <asac> thats the full asm generated
[15:19] <asac> cc -Wp,-MMD,"jidctflt.d",-MQ,"jidctflt.o",-MP -c -I../include -I../../../include -fvisibility=hidden -fPIC -DLIBDIR=\"/usr/local/lib\" -DLIBSUBDIR=\"libv4l\" -g -O1 -Wall -Wno-unused -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -o jidctflt.o jidctflt.c
[15:19] <asac> /tmp/cctyjob8.s: Assembler messages:
[15:20] <asac> /tmp/cctyjob8.s:74: Error: branch out of range
[15:20] <asac> thats the error
[16:09] <dmart> asac: Thumb-2 has different range limits for some instructions.  If cbnz can't branch far enough, you may be able to move the branch destination closer, or recode using cmp <Rn>, #0 // bne (I think)
[16:12] <dmart> Hmmm, actually CB(N)Z is Thumb only
[16:25] <NCommander> saeed: ping?
[16:25] <NCommander> saeed: I just got my X0, it won't boot; kernel hangs at Uncompressing; the X0 I used in Portland worked just fine with our existing images
[16:27] <asac> dmart: hmm. i think that .s is generated by gcc
[16:27] <asac> i only get that with -save-temps
[16:27] <asac> (already found that range thing in the quick reference)
[16:28] <asac> dmart: yeah. i think for -marm its probably not generated by gcc at all
[16:28] <asac> will produce a .s with -marm and compare
[16:28] <dmart> Oh, right.  That's a compiler bug then.  Can you raise a launchpad bug on gcc and stash the preprocessed source there?
[16:29] <dmart> The compiler should not generate out-of-range branches in its own code...
[16:29] <asac> dmart: yep
[16:29] <asac> will give you a bugid when filed (once off the call)
[16:29] <dmart> I posted info on the porting wiki page showing where to find the up-do-date instruction set quick references btw (in case you didn't already find them)
[16:29] <dmart> thanks
[16:31] <asac> dmart: oh on top of the asm intro?
[16:31] <asac> good
[16:31]  * asac checks
[16:31] <dmart> yes
[16:31] <asac> found
[16:39] <NCommander> plars: GrueMaster, I'm reminded of what happens when the bootloader machine id and the kernel machine id fail to match :-/
[16:40] <asac> dmart: bug 522717
[16:41] <ubot4> Launchpad bug 522717 in gcc-4.4 (Ubuntu) "libv4l code compiles to invalid asm: jidctflt.s:74: Error: branch out of range (affects: 1)" [Undecided,New] https://launchpad.net/bugs/522717
[16:42] <dmart> asac: Can you attach the preprocessed source?  This makes it easier for the compiler guys to reproduce the problem.
[16:42] <asac> right ;)
[16:44] <asac> done dmart
[16:47] <dmart> asac: cool, thanks
[16:48] <saeed> Ncommander
[16:51] <NCommander> saeed: ah, your around!
[16:52] <saeed> what it's the board rev?
[16:53] <plars> saeed: mine is 1.4, same problem
[16:54] <saeed> NCommander, please try the patches I just sent you be email
[16:55] <plars> GrueMaster: did you see the posting that just came across ubuntu-qa? how does that relate to the libtest stuff you've been doing? any help at all?
[16:58] <NCommander> saeed: will try as soon as I can
[16:58] <saeed> ok
[17:02] <GrueMaster> just a sec.
[17:10] <GrueMaster> plars: which channel?
[17:10] <plars> GrueMaster: ubuntu-qa mailing list
[17:12] <GrueMaster> Forward to me.  I don't appear to be on that list.
[17:15] <plars> sure
[17:26] <GrueMaster> It might be useful.  It does more api level testing, whereas the test suite I am working with does more low level testing (like at the fpu level).
[17:27] <GrueMaster> It is also very new.
[17:27] <GrueMaster> Wiki is dated this month.
[17:31] <GrueMaster> plars: A good read on the different test suites would be http://ispras.linux-foundation.org/index.php/LSB_Tests.
[17:32] <GrueMaster> It lists the different types of tests and compares them.
[17:32] <plars> GrueMaster: cool, will take a look.  I was mostly just wondering if that one would also be useful
[17:32] <plars> or if it added anything really
[17:35] <GrueMaster> My understanding is that the tests mentioned in the email are essentially smoke tests.  They will quickly tell you if there is a problem with a library function.  What they don't give you is an underlying understanding of the problem (i.e. is it a toolchain issue, hardware issue, etc).
[18:00] <asac> anyone can install netbook-launcher and see if it fails to start?
[18:00] <asac> the 3d one
[18:00] <asac> idea is to understand if we need another probing on top ... or can just rely o nthat failing to determine if we want to go for 2d
[19:11] <ogra> asac, why dont we have the compiz wrapper in netbook-launcher ? that works pretty relaibly
[19:17] <asac> ogra: thats too slow
[19:18] <asac> for une
[19:18] <asac> takes 2 seconds or something on boot time
[19:35] <ogra> oh, i wasnt aware it takes 2sec
[19:53] <JamieBennett> GrueMaster: https://wiki.ubuntu.com/MobileTeam/Meeting/2010/20100223
[19:54] <GrueMaster> Cool.  Send me that link on 20100222 and I'll be good.
[19:54] <JamieBennett> :)
[20:01] <ojn> Wow, i.MX51 cell phones announced? Not having POP in that form factor must hurt.
[20:01] <ojn> (yeah, off topic, I know :)