[03:35] <aaron_liuj> where i can get the whole doc of build chrome
[04:45] <persia> aaron_liuj: Could you be a bit more precise about which materials you seek?
[04:57] <aaron_liuj> i want to comiple  chrome for arm platform
[04:58] <aaron_liuj> but i find building chromium is so different from other plalform
[05:05] <aaron_liuj> but i find building chromium is so different from other build system such as autoconfig automake
[05:49] <persia> so, "chrome" and "chromium" are different, in that "chrome" contains special branding magic.
[05:50] <persia> If you download the source (`apt-get source chromium-browser`), there is a file debian/rules that contains the instructions to build the source.  Build logs are available on laiunchpad.
[05:51] <persia> If you've an armel install, building for arm is as simple as `apt-get build-dep chromium-browser; debuild -b` in the downloaded sources (although we usually recommend tools like sbuild or pbuilder(
[07:39] <cooloney> amitk: do you know the quick way to import the omap4 defconfig based on our ti-omap branch configs?
[07:39] <cooloney> amitk: i already rebased the omap4 branch from omapzoom git server
[07:40] <cooloney> amitk: need to tweak the configs
[07:41] <cooloney> how about copy over omap4 defconfig to debain.ti-omap/configs/config.commom.ubuntu
[07:41] <cooloney> and run fdr genconfigs?
[07:41] <amitk> cooloney: I'd append the omap4defconfig at the _end_ of the ubuntu config and then run updateconfigs
[07:42] <cooloney> amitk: oh, at the end of debain.ti-omap/configs/config.commom.ubuntu?
[07:42] <amitk> copying over the defconfig to our config will lose all our ubuntu-fication tweaks
[07:42] <amitk> e.g. apparmor, security settings, etc.
[07:42] <cooloney> amitk: right, i lost them,
[07:43] <amitk> cooloney: cat omap4defconfig >> debain.ti-omap/configs/config.commom.ubuntu
[07:43] <cooloney> amitk: ok, got it. thanks man, will try soon
[07:56] <zyga> good morning folks
[07:57] <cooloney> amitk: too bad, i tried that, but the new config lost all the modules.
[07:58] <cooloney> amitk: it seems like it turned off all the module configs
[07:58] <cooloney> any idea about that?
[07:58] <amitk> cooloney: I guess the omap4defconfig turns off modules?
[08:00] <cooloney> amitk: no, it enable modules as the same as our omap3 config
[08:00] <cooloney> CONFIG_MODULES=y
[08:00] <amitk> cooloney: try this, cat omap4defconfig | grep "=[ym]" > /tmp/omap4; cat /tmp/omap4 >> debain.ti-omap/configs/config.commom.ubuntu
[08:01] <cooloney> but aparently, there is no modules config in omap4defconfig
[08:03] <amitk> ok
[08:06] <cooloney> amitk: btw, i am trying with arch/arm/configs/omap_4430sdp_defconfig as omap4defconfig, since there is no other configs looks ok to me
[08:06] <cooloney> amitk: this trick works,
[08:06] <cooloney> thanks a lot
[08:07] <amitk> cool
[08:07] <alf__> good morning all!
[08:07] <amitk> alf__: morning
[08:19] <zyga> the ubuntu group photo is online :-)
[08:19] <zyga> http://www.flickr.com/photos/kwwii/4610334160/
=== hrw|gone is now known as hrw
[08:26] <hrw> morning
[08:27] <hrw> zyga: thx - I am 3rd from left in first row
[08:28] <zyga> hrw, yeah, I saw you right away
[09:20] <zyga> toolchain guys, package guys, I have a question - let's say you push a toolchain patch that affects something (be it code size or some critical bug fix) - how can I (qa guy) determine which set of packages were used to build/cross build certain package - I want to be able to tell 'ah package FOO-1.2-0 was built with old toolchain while FOO-1-2.1 was built with the new toolchain'
[09:20] <zyga> is this even possible? do we always bump package version on rebuild?
[09:21] <zyga> (or the inverse question, do we always rebuild as a consequence of an upload with version change)
[09:21] <zyga> lool, ^^ >
[09:21] <hrw> good question. I can not answer as I did not upload package in Debian
[09:22] <persia> You can check the build log in LP.
[09:22] <zyga> I have one use case that would require this and I need to check if it's even possible: tracking code size across releases
[09:22] <zyga> and, in crazy situations, across toolchain changes
[09:23] <zyga> persia, LP has a collection of build-deps for each package it built? with rich package version etc/
[09:24] <persia> Absolutely.  See https://launchpad.net/ubuntu/+source/libvirt/0.7.5-5ubuntu27/+build/1702547/+files/buildlog_ubuntu-lucid-armel.libvirt_0.7.5-5ubuntu27_FULLYBUILT.txt.gz as an example/
[09:24] <persia> Note that this is a verbose format, so you'd have to parse, but there's often other interesting things in the log if you're tracking down a regression when you don't think the source changed.
[09:25] <zyga> persia, hmm, parsing is fragile, does any other part of launchpad maintain a more declarative format for the meta information of each build>
[09:25] <persia> Every upload generates a new build, and rebuilding the same source twice without an upload is only accepted in the case where the first attempt FTBFS.
[09:26] <zyga> persia, so what would happen if we push a new toolchain? nothing - r-deps do not become invalid?
[09:26] <persia> Note that from the fragmentary bits I got from some of the UDS discussions, this may not hold true for some classes of repository, but it is how it is implemented in Soyuz today.
[09:26] <zyga> persia, (we have to upload each package again just to see it rebuilt?)
[09:26] <persia> Yep.
[09:26] <hrw> persia: what about 'binary NMU'? they have same source but 'b1' added to version
[09:26] <zyga> hrw, good question, I was about to ask for that - someone mentioned this during a session
[09:26] <persia> There's ways to arrange test-rebuilds against arbitrary toolchains with throwaway results, which the toolchain team uses.
[09:27] <persia> hrw: We don't have binNMUs in Ubuntu.
[09:27] <zyga> mmm
[09:27] <zyga> okay, some of the bits are more clear now, thanks
[09:27] <persia> heh.
[09:27] <zyga> I think my use case is not really sensible then ;-)
[09:28] <persia> What was your use case?
[09:28] <hrw> persia: ok
[09:28] <zyga> persia, tracking daily/weekly binary object sizes vs toolchain revision
[09:29] <persia> zyga: Yeah, you'd need a rebuild-repo for that, and it's a heavy load on the buildds.
[09:29] <persia> (or some other class of derivative repo)
[09:30] <zyga> persia, building a sub-main variant could make sense too - like what I did some time ago - toolchain kernel libc and some basic userspace
[09:30] <zyga> it takes 3 hours to build this on 8 way xeon inside a ramdisk
[09:31] <persia> I guess.  That's more an embedded design pattern, and we don't tend to do embedded here.
[09:31] <zyga> and the results are quite representative for the whole repository
[09:33]  * zyga has a crazy idea
[09:34] <zyga> hrw, oe could build our toolchain and some packages to check for binary size experiments
[09:34] <hrw> zyga: it can, but writing recipes for it would take time
[09:34] <zyga> hrw, yeah but if the new toolchain is such a big issue then it could be reasonable
[09:35] <persia> zyga: If you're just experimenting locally, why not just use schroot+qemu-user-arm+croco, and use the debian/rules files that already exist.
[09:35] <zyga> croco? what is that
[09:36] <persia> croco is a system that allows you to wrap various binaries in a cross-arch chroot and run native.  For example, there's no good reason to run armel bash to process a bash script during build when doing local cross-compile analysis.
[09:36] <zyga> persia, one of the things I don't want to depend on is qemu - it's currently broken and it really kills performance - OE approach has the strength of working cross compilation of selected packages
[09:36] <persia> The results are likely to vary from those build on the buildds, but that's a different issue.
[09:36] <persia> Which bit is broken?
[09:36] <persia> Note that not all debian packages *can* cross-compile.
[09:36] <zyga> persia, qemu bit - lool will tell you how it currently hangs/crashes under heavy load
[09:37] <persia> Also, using soemthing like croco makes it significantly less slow.
[09:37] <zyga> persia, I have a bunch of backtraces if you want to see
[09:37] <zyga> persia, that's true, it could be reasonable tradeoff for time-to-make-it-happen vs time-to-build-each-time
[09:37] <persia> I believe you.  It doesn't tend to crash for me, but I don't push it hard.  Was that qemu-system-arm or qemu-user-arm?
=== wgrant_ is now known as wgrant
[09:38] <zyga> system
[09:38] <ogra> zyga, the chroot bit of qemu isnt broken, only qemu-system-arm is, i think croco hooks into the static builds
[09:38] <persia> Oh, yeah, I'm not advocating that for builds at all.
[09:38] <ogra> s/hooks into/can hook into/
[09:38] <persia> croco works best with qemu-user-arm
[09:38] <ogra> right
[09:38] <zyga> then it could be just right
[09:39] <persia> It does things like call the right cross-compiler instead of calling the native compiler, but it still provides the ability to run native code, which helps with stuff like test suites.
[09:39] <ogra> its a bit like OBS
[09:40] <persia> kinda sorta :)
[09:40] <zyga> OBS?
[09:40] <persia> OpenSuSE Build System
[09:40] <ogra> opensuses build system
[09:40] <ogra> bah, i'm slow today
[09:41] <persia> And following in the footsteps of e.e. cummings :)
=== plars is now known as plars-away
=== hrw is now known as hrw|gone
[13:26] <neure> how is 10.04 on beagle?
[13:27] <zyga> neure, somewhat choppy, depends on which version you are talking about
[13:27] <amitk> neure: it works on the C4 beagles
[13:27] <amitk> older ones aren't yet supported
[13:29] <neure> how do i see my version?
[13:30] <neure> how about C3?
[13:30] <neure> what is different C3 -> C4?
[13:31] <amitk> http://elinux.org/BeagleBoard#Revision_A
[13:37] <neure> apparently i have C2
[13:37] <neure> so is the "Improved USB Host PHY power rails" that might affect keyboard / mouse?
[13:38] <neure> whatever that means..
[13:38] <XorA> neure: means USB actually works reliably on all C4
[13:39] <XorA> neure: USB EHCI is hit and miss on earlier beagles
[13:39] <neure> EHCI?
[13:39] <neure> ok
[13:39] <XorA> the normal looking usb port, not the mini B OTG port
[13:39] <amitk> neure: in addition to what XorA said, we have no real reason _not_ to support older beagles except lack of old HW.
[13:39] <neure> ok
[13:40] <XorA> amitk: the installer works fine on C3, just because usb is screwed you cant install
[13:40] <neure> so if i use the mini B port, it should work even on C2?
[13:41] <rcn-ee> neure, you can use the otg port using my NetInstall setup on elinux using the commuinty kernel...
[13:42] <neure> im currently running ångström on it
[13:43] <neure> i could try ubuntu
[13:43] <neure> on the other hand, i'd like to try something with rt linux kernel
[13:43] <siji> my experience, I have got better performance with ubuntu than Angstrom
[13:43] <siji> Specially with Clutter /EGL etc..
[13:44] <rcn-ee> amitk, just hit bug 563650 with 2.6.34 + dss2 -for-next with my kernel.. discussion on linux-omap... http://www.spinics.net/lists/linux-omap/msg30138.html
[13:44] <ubot2> Launchpad bug 563650 in linux-ti-omap (Ubuntu Lucid) (and 1 other project) "DSS2 oops when shutting down while DPMS is active (affects: 1) (heat: 10)" [Medium,Confirmed] https://launchpad.net/bugs/563650
[13:44] <amitk> siji: is angstrom compiled with NEON and ARMv7 ?
[13:45] <XorA> amitk: of course we do :-D
[13:45]  * XorA puts on his Angstrom maintainer hat
[13:45] <siji> :)
[13:46] <siji> amitk, with ARM v7
[13:46] <amitk> XorA: just curious why siji is seeing the difference, is all :)
[13:48] <amitk> rcn-ee: aah, any headway?
[13:48] <rcn-ee> it might just be a thumb2 thing..
[13:48] <rcn-ee> amitk, nope... just triggered the latest opps about 10 mins ago..
[14:46] <james_w> I have my beagle partially booting now, but due to having no rtc battery it won't get pass fsck, is there a way to force mounting without an interactive shell?
[14:47] <ogra> james_w, with the official image you can just set fixrtc on the cmdline
[14:47] <ogra> we have a workaround in initramfs
=== jmcgee|gone is now known as jmcgee
=== JaMa is now known as JaMa|Sports
[16:09] <ogra> XorA, do you happen to know which DSS2 patches are missing exactly to make the zoom work in ubuntu ? (same question for touchbook)
[16:09] <ogra> i'd like to have screen support for both of them in maverick
[16:09] <ogra> (just basic stuff is enough though)
[16:10] <XorA> ogra: no, the dss2 in the TI zoom2 tree is slightly different to what entered mainline, the patches all need rejigged
[16:10] <ogra> hrm
[16:11] <XorA> ogra: ask koen about touchbook, he at least has one
[16:11] <XorA> ogra: and pandora support in maverick should happen as well
[16:11] <ogra> it boots fine here with an ubuntu install ... i just cant convince it to output to the screen ...
[16:11] <ogra> nobody on the team has a pandora
[16:11] <XorA> ogra: no-one has a pandora yet
[16:12] <XorA> ogra: I will have before maverick
[16:12] <ogra> sweet ... i'll hunt you down for testing it then
[16:12] <lool> zyga: Build information > yes, the versions are recorded in the log, but as you note it's a bit fragile and doens't cover everything; there's a dh_buildinfo which does something more extensive
[16:13] <XorA> ogra: youll have to come to #linux-omap and pester the guys there for zoom2 support
[16:13] <ogra> will do
[16:13] <ogra> we dont have a maverick kernel yet though
[16:13] <ogra> i'm just looking into the missing bits atm
[16:14] <XorA> ogra: well just getting patches against lucid would be good, DSS2 wont change that much now
[16:14] <lool> davidm: Sure, I already had chats with prpplague on the upcoming LCDs
[16:14] <lool> davidm: Thanks for the contact
[16:14] <ogra> XorA, maverick will use 2.6.35
[16:14] <XorA> ogra: there was nothing controversial in the 2.6.35 pull request for dss2
[16:14] <ogra> so we need them against that one
[16:14] <ogra> great
[16:15] <XorA> ogra: so the patches should only need slight rejig between lucid/maverick, its just finding someone with time to do them clean
[16:15] <ogra> lucid is done, all i care for wrt lucid is 10.07 which uses its completely own kernel
[16:15] <XorA> Im not on the TI display team
[16:16] <ogra> but you are owning all that knowledge :)
[16:16] <XorA> ogra: sumitsemwal I think knows the actual guys who own that part of kernel
[16:16]  * zyga is bac
[16:16] <zyga> k
[16:17] <ogra> ok, i'll first wait to see what we get with the maverick kernel
[16:17] <XorA> ogra: extend my day to 48 hours and Ill do it :-D
[16:17] <ogra> and whats still missing
[16:17] <ogra> heh
[16:17] <ogra> i assume dss2 improved between .33 and .35
[16:18] <XorA> I think bugfixes only, no architectural changes
[16:18] <ogra> hmm
[16:26] <sumitsemwal> XorA: :) .. I will ask people who're involved with the DSS2 to join.. maybe tomorrow?
[16:27] <amitk> sumitsemwal: good to see you hang out here :)
[16:27] <ogra> yeah !
[16:28] <sumitsemwal> amitk: newbie, be gentle :P
[16:30] <amitk> sumitsemwal: hehe :)
=== sbambrough is now known as sbambrough-lunch
=== sbambrough-lunch is now known as sbambrough
=== JaMa|Sports is now known as JaMa
=== rsalveti_ is now known as rsalveti
[21:58] <NCommander> sebjan: ping?
[22:00] <NCommander> robclark: ping?
[22:00] <robclark> NCommander: pong
[22:01] <NCommander> robclark: see PM
[22:02] <ogra_cmpc> robclark, how did you compile the kernel i have on the blaze ? i see a lot of segfaults using a lucid rootfs
[22:03] <ogra_cmpc> was it cross built ?
[22:04] <robclark> ogra_cmpc: y, it was cross built.. but I don't think that is the issue
[22:04] <ogra_cmpc> hmm
[22:04] <robclark> I wonder if you are just seeing the empty_zero_page issue..
[22:04] <robclark> kernel is unlikely to get pissy over glibc or runtime lib mismatch..
[22:04] <ogra_cmpc> might be i just noticed that git, dpkg and apt segfault
[22:05] <robclark> ogra_cmpc: yeah, that sounds like the issue... give me a minute and I'll post real simple test code to see if you hit that..
[22:05] <ogra_cmpc> i didnt resarch anything yet, juwst playing around with it while watching tv
[22:05] <robclark> avoid 'git clone'
[22:06] <robclark> that is really good at triggering the problem
[22:06] <ogra_cmpc> heh, noticed that
[22:06] <ogra_cmpc> yeah
[22:06] <ogra_cmpc> fatal: git fetch_pack: expected ACK/NAK, got ''
[22:06] <robclark> yup, that's the one
[22:06]  * ogra_cmpc was already worried its gits fault in out amrel build
[22:07] <ogra_cmpc> *armel
[22:07] <ogra_cmpc> until i noticed apt and dpkg suffering too
[22:07] <robclark> it is an arm arch prob in kernel.. from looking at code, I'm not really sure how it should work.. how copy_to_user() would trigger a page fault..
[22:08] <robclark> one of our baseport guys claims to not see this bug.. using a newer kernel, but unsure about what commit fixes it (if it is indeed fixed)
[22:08] <robclark> but I've been busy with other debugging since I got back, so haven't had a chance to revisit that issue
[22:09] <ogra_cmpc> we'll see, i think cooloney already works on a kernel package thats based on a checkout from today
[22:09] <robclark> ogra_cmpc: if you need a quick stop-gap solution, an older version of git (1.5.x) doesn't seem to trigger it
[22:09] <ogra_cmpc> i should be able to test it within the next days
[22:10] <ogra_cmpc> well, i usually dont even touch git :) but i can host trees on my laptop if needed and just rsync back and forth
[22:10] <ogra_cmpc> <- bzr user ...
[22:10] <robclark> ok.. let me know if you discover anything... it's on my list of interesting things to debug, but unfortunately I have some less interesting things to debug first ;-)
[22:10] <ogra_cmpc> heh, k
=== jmcgee is now known as jmcgee|gone