**** BEGIN LOGGING AT Tue May 18 02:59:57 2010 May 18 03:45:13 aaron_liuj: Could you be a bit more precise about which materials you seek? May 18 03:57:53 i want to comiple chrome for arm platform May 18 03:58:52 but i find building chromium is so different from other plalform May 18 04:05:04 but i find building chromium is so different from other build system such as autoconfig automake May 18 04:49:57 so, "chrome" and "chromium" are different, in that "chrome" contains special branding magic. May 18 04:50:38 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. May 18 04:51:51 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( May 18 06:39:26 amitk: do you know the quick way to import the omap4 defconfig based on our ti-omap branch configs? May 18 06:39:54 amitk: i already rebased the omap4 branch from omapzoom git server May 18 06:40:16 amitk: need to tweak the configs May 18 06:41:12 how about copy over omap4 defconfig to debain.ti-omap/configs/config.commom.ubuntu May 18 06:41:20 and run fdr genconfigs? May 18 06:41:24 cooloney: I'd append the omap4defconfig at the _end_ of the ubuntu config and then run updateconfigs May 18 06:42:06 amitk: oh, at the end of debain.ti-omap/configs/config.commom.ubuntu? May 18 06:42:28 copying over the defconfig to our config will lose all our ubuntu-fication tweaks May 18 06:42:42 e.g. apparmor, security settings, etc. May 18 06:42:55 amitk: right, i lost them, May 18 06:43:11 cooloney: cat omap4defconfig >> debain.ti-omap/configs/config.commom.ubuntu May 18 06:43:28 amitk: ok, got it. thanks man, will try soon May 18 06:56:43 good morning folks May 18 06:57:51 amitk: too bad, i tried that, but the new config lost all the modules. May 18 06:58:10 amitk: it seems like it turned off all the module configs May 18 06:58:18 any idea about that? May 18 06:58:39 cooloney: I guess the omap4defconfig turns off modules? May 18 07:00:20 amitk: no, it enable modules as the same as our omap3 config May 18 07:00:48 CONFIG_MODULES=y May 18 07:00:49 cooloney: try this, cat omap4defconfig | grep "=[ym]" > /tmp/omap4; cat /tmp/omap4 >> debain.ti-omap/configs/config.commom.ubuntu May 18 07:01:33 but aparently, there is no modules config in omap4defconfig May 18 07:03:51 ok May 18 07:06:21 amitk: btw, i am trying with arch/arm/configs/omap_4430sdp_defconfig as omap4defconfig, since there is no other configs looks ok to me May 18 07:06:31 amitk: this trick works, May 18 07:06:39 thanks a lot May 18 07:07:22 cool May 18 07:07:31 good morning all! May 18 07:07:39 alf__: morning May 18 07:19:12 the ubuntu group photo is online :-) May 18 07:19:39 http://www.flickr.com/photos/kwwii/4610334160/ May 18 07:26:10 morning May 18 07:27:05 zyga: thx - I am 3rd from left in first row May 18 07:28:25 hrw, yeah, I saw you right away May 18 08:20:19 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' May 18 08:20:45 is this even possible? do we always bump package version on rebuild? May 18 08:21:07 (or the inverse question, do we always rebuild as a consequence of an upload with version change) May 18 08:21:16 lool, ^^ > May 18 08:21:59 good question. I can not answer as I did not upload package in Debian May 18 08:22:23 You can check the build log in LP. May 18 08:22:41 I have one use case that would require this and I need to check if it's even possible: tracking code size across releases May 18 08:22:53 and, in crazy situations, across toolchain changes May 18 08:23:23 persia, LP has a collection of build-deps for each package it built? with rich package version etc/ May 18 08:24:08 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/ May 18 08:24:37 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. May 18 08:25:30 persia, hmm, parsing is fragile, does any other part of launchpad maintain a more declarative format for the meta information of each build> May 18 08:25:38 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. May 18 08:26:11 persia, so what would happen if we push a new toolchain? nothing - r-deps do not become invalid? May 18 08:26:18 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. May 18 08:26:21 persia, (we have to upload each package again just to see it rebuilt?) May 18 08:26:27 Yep. May 18 08:26:32 persia: what about 'binary NMU'? they have same source but 'b1' added to version May 18 08:26:54 hrw, good question, I was about to ask for that - someone mentioned this during a session May 18 08:26:59 There's ways to arrange test-rebuilds against arbitrary toolchains with throwaway results, which the toolchain team uses. May 18 08:27:07 hrw: We don't have binNMUs in Ubuntu. May 18 08:27:08 mmm May 18 08:27:45 okay, some of the bits are more clear now, thanks May 18 08:27:50 heh. May 18 08:27:53 I think my use case is not really sensible then ;-) May 18 08:28:00 What was your use case? May 18 08:28:10 persia: ok May 18 08:28:32 persia, tracking daily/weekly binary object sizes vs toolchain revision May 18 08:29:39 zyga: Yeah, you'd need a rebuild-repo for that, and it's a heavy load on the buildds. May 18 08:29:53 (or some other class of derivative repo) May 18 08:30:33 persia, building a sub-main variant could make sense too - like what I did some time ago - toolchain kernel libc and some basic userspace May 18 08:30:55 it takes 3 hours to build this on 8 way xeon inside a ramdisk May 18 08:31:08 I guess. That's more an embedded design pattern, and we don't tend to do embedded here. May 18 08:31:13 and the results are quite representative for the whole repository May 18 08:33:52 * zyga has a crazy idea May 18 08:34:07 hrw, oe could build our toolchain and some packages to check for binary size experiments May 18 08:34:37 zyga: it can, but writing recipes for it would take time May 18 08:34:57 hrw, yeah but if the new toolchain is such a big issue then it could be reasonable May 18 08:35:06 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. May 18 08:35:20 croco? what is that May 18 08:36:09 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. May 18 08:36:21 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 May 18 08:36:27 The results are likely to vary from those build on the buildds, but that's a different issue. May 18 08:36:38 Which bit is broken? May 18 08:36:50 Note that not all debian packages *can* cross-compile. May 18 08:36:57 persia, qemu bit - lool will tell you how it currently hangs/crashes under heavy load May 18 08:37:02 Also, using soemthing like croco makes it significantly less slow. May 18 08:37:11 persia, I have a bunch of backtraces if you want to see May 18 08:37:36 persia, that's true, it could be reasonable tradeoff for time-to-make-it-happen vs time-to-build-each-time May 18 08:37:39 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? May 18 08:38:07 system May 18 08:38:16 zyga, the chroot bit of qemu isnt broken, only qemu-system-arm is, i think croco hooks into the static builds May 18 08:38:19 Oh, yeah, I'm not advocating that for builds at all. May 18 08:38:37 s/hooks into/can hook into/ May 18 08:38:38 croco works best with qemu-user-arm May 18 08:38:46 right May 18 08:38:48 then it could be just right May 18 08:39:37 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. May 18 08:39:58 its a bit like OBS May 18 08:40:13 kinda sorta :) May 18 08:40:29 OBS? May 18 08:40:37 OpenSuSE Build System May 18 08:40:43 opensuses build system May 18 08:40:50 bah, i'm slow today May 18 08:41:44 And following in the footsteps of e.e. cummings :) May 18 12:26:52 how is 10.04 on beagle? May 18 12:27:13 neure, somewhat choppy, depends on which version you are talking about May 18 12:27:15 neure: it works on the C4 beagles May 18 12:27:26 older ones aren't yet supported May 18 12:29:23 how do i see my version? May 18 12:30:52 how about C3? May 18 12:30:58 what is different C3 -> C4? May 18 12:31:16 http://elinux.org/BeagleBoard#Revision_A May 18 12:37:28 apparently i have C2 May 18 12:37:50 so is the "Improved USB Host PHY power rails" that might affect keyboard / mouse? May 18 12:38:04 whatever that means.. May 18 12:38:31 neure: means USB actually works reliably on all C4 May 18 12:39:01 neure: USB EHCI is hit and miss on earlier beagles May 18 12:39:25 EHCI? May 18 12:39:44 ok May 18 12:39:48 the normal looking usb port, not the mini B OTG port May 18 12:39:55 neure: in addition to what XorA said, we have no real reason _not_ to support older beagles except lack of old HW. May 18 12:39:56 ok May 18 12:40:21 amitk: the installer works fine on C3, just because usb is screwed you cant install May 18 12:40:32 so if i use the mini B port, it should work even on C2? May 18 12:41:43 neure, you can use the otg port using my NetInstall setup on elinux using the commuinty kernel... May 18 12:42:59 im currently running ångström on it May 18 12:43:07 i could try ubuntu May 18 12:43:20 on the other hand, i'd like to try something with rt linux kernel May 18 12:43:42 my experience, I have got better performance with ubuntu than Angstrom May 18 12:43:56 Specially with Clutter /EGL etc.. May 18 12:44:44 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 May 18 12:44:47 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 May 18 12:44:51 siji: is angstrom compiled with NEON and ARMv7 ? May 18 12:45:03 amitk: of course we do :-D May 18 12:45:25 * XorA puts on his Angstrom maintainer hat May 18 12:45:38 :) May 18 12:46:56 amitk, with ARM v7 May 18 12:46:58 XorA: just curious why siji is seeing the difference, is all :) May 18 12:48:06 rcn-ee: aah, any headway? May 18 12:48:28 it might just be a thumb2 thing.. May 18 12:48:48 amitk, nope... just triggered the latest opps about 10 mins ago.. May 18 13:46:15 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? May 18 13:47:00 james_w, with the official image you can just set fixrtc on the cmdline May 18 13:47:07 we have a workaround in initramfs May 18 15:09:03 XorA, do you happen to know which DSS2 patches are missing exactly to make the zoom work in ubuntu ? (same question for touchbook) May 18 15:09:26 i'd like to have screen support for both of them in maverick May 18 15:09:50 (just basic stuff is enough though) May 18 15:10:07 ogra: no, the dss2 in the TI zoom2 tree is slightly different to what entered mainline, the patches all need rejigged May 18 15:10:22 hrm May 18 15:11:04 ogra: ask koen about touchbook, he at least has one May 18 15:11:22 ogra: and pandora support in maverick should happen as well May 18 15:11:36 it boots fine here with an ubuntu install ... i just cant convince it to output to the screen ... May 18 15:11:46 nobody on the team has a pandora May 18 15:11:58 ogra: no-one has a pandora yet May 18 15:12:02 ogra: I will have before maverick May 18 15:12:19 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 May 18 15:12:19 sweet ... i'll hunt you down for testing it then May 18 15:13:04 ogra: youll have to come to #linux-omap and pester the guys there for zoom2 support May 18 15:13:15 will do May 18 15:13:26 we dont have a maverick kernel yet though May 18 15:13:52 i'm just looking into the missing bits atm May 18 15:14:00 ogra: well just getting patches against lucid would be good, DSS2 wont change that much now May 18 15:14:00 davidm: Sure, I already had chats with prpplague on the upcoming LCDs May 18 15:14:05 davidm: Thanks for the contact May 18 15:14:19 XorA, maverick will use 2.6.35 May 18 15:14:28 ogra: there was nothing controversial in the 2.6.35 pull request for dss2 May 18 15:14:29 so we need them against that one May 18 15:14:39 great May 18 15:15:02 ogra: so the patches should only need slight rejig between lucid/maverick, its just finding someone with time to do them clean May 18 15:15:08 lucid is done, all i care for wrt lucid is 10.07 which uses its completely own kernel May 18 15:15:43 Im not on the TI display team May 18 15:16:18 but you are owning all that knowledge :) May 18 15:16:41 ogra: sumitsemwal I think knows the actual guys who own that part of kernel May 18 15:16:56 * zyga is bac May 18 15:16:58 k May 18 15:17:05 ok, i'll first wait to see what we get with the maverick kernel May 18 15:17:10 ogra: extend my day to 48 hours and Ill do it :-D May 18 15:17:14 and whats still missing May 18 15:17:18 heh May 18 15:17:50 i assume dss2 improved between .33 and .35 May 18 15:18:26 I think bugfixes only, no architectural changes May 18 15:18:36 hmm May 18 15:26:35 XorA: :) .. I will ask people who're involved with the DSS2 to join.. maybe tomorrow? May 18 15:27:35 sumitsemwal: good to see you hang out here :) May 18 15:27:42 yeah ! May 18 15:28:00 amitk: newbie, be gentle :P May 18 15:30:06 sumitsemwal: hehe :) May 18 20:58:19 sebjan: ping? May 18 21:00:27 robclark: ping? May 18 21:00:57 NCommander: pong May 18 21:01:53 robclark: see PM May 18 21:02:46 robclark, how did you compile the kernel i have on the blaze ? i see a lot of segfaults using a lucid rootfs May 18 21:03:19 was it cross built ? May 18 21:04:13 ogra_cmpc: y, it was cross built.. but I don't think that is the issue May 18 21:04:21 hmm May 18 21:04:22 I wonder if you are just seeing the empty_zero_page issue.. May 18 21:04:45 kernel is unlikely to get pissy over glibc or runtime lib mismatch.. May 18 21:04:56 might be i just noticed that git, dpkg and apt segfault May 18 21:05:46 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.. May 18 21:05:51 i didnt resarch anything yet, juwst playing around with it while watching tv May 18 21:05:59 avoid 'git clone' May 18 21:06:07 that is really good at triggering the problem May 18 21:06:07 heh, noticed that May 18 21:06:12 yeah May 18 21:06:35 fatal: git fetch_pack: expected ACK/NAK, got '' May 18 21:06:41 yup, that's the one May 18 21:06:56 * ogra_cmpc was already worried its gits fault in out amrel build May 18 21:07:01 *armel May 18 21:07:19 until i noticed apt and dpkg suffering too May 18 21:07:27 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.. May 18 21:08:20 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) May 18 21:08:48 but I've been busy with other debugging since I got back, so haven't had a chance to revisit that issue May 18 21:09:02 we'll see, i think cooloney already works on a kernel package thats based on a checkout from today May 18 21:09:10 ogra_cmpc: if you need a quick stop-gap solution, an older version of git (1.5.x) doesn't seem to trigger it May 18 21:09:23 i should be able to test it within the next days May 18 21:10:09 well, i usually dont even touch git :) but i can host trees on my laptop if needed and just rsync back and forth May 18 21:10:22 <- bzr user ... May 18 21:10:28 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 ;-) May 18 21:10:36 heh, k **** ENDING LOGGING AT Wed May 19 02:59:57 2010