aaron_liuj | where i can get the whole doc of build chrome | 03:35 |
---|---|---|
persia | aaron_liuj: Could you be a bit more precise about which materials you seek? | 04:45 |
aaron_liuj | i want to comiple chrome for arm platform | 04:57 |
aaron_liuj | but i find building chromium is so different from other plalform | 04:58 |
aaron_liuj | but i find building chromium is so different from other build system such as autoconfig automake | 05:05 |
persia | so, "chrome" and "chromium" are different, in that "chrome" contains special branding magic. | 05:49 |
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:50 |
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( | 05:51 |
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:39 |
cooloney | amitk: need to tweak the configs | 07:40 |
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:41 |
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:42 |
amitk | cooloney: cat omap4defconfig >> debain.ti-omap/configs/config.commom.ubuntu | 07:43 |
cooloney | amitk: ok, got it. thanks man, will try soon | 07:43 |
zyga | good morning folks | 07:56 |
cooloney | amitk: too bad, i tried that, but the new config lost all the modules. | 07:57 |
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? | 07:58 |
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:00 |
cooloney | but aparently, there is no modules config in omap4defconfig | 08:01 |
amitk | ok | 08:03 |
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:06 |
amitk | cool | 08:07 |
alf__ | good morning all! | 08:07 |
amitk | alf__: morning | 08:07 |
zyga | the ubuntu group photo is online :-) | 08:19 |
zyga | http://www.flickr.com/photos/kwwii/4610334160/ | 08:19 |
=== hrw|gone is now known as hrw | ||
hrw | morning | 08:26 |
hrw | zyga: thx - I am 3rd from left in first row | 08:27 |
zyga | hrw, yeah, I saw you right away | 08:28 |
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:20 |
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:21 |
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:22 |
zyga | persia, LP has a collection of build-deps for each package it built? with rich package version etc/ | 09:23 |
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:24 |
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:25 |
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:26 |
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:27 |
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:28 |
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:29 |
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:30 |
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:31 |
* zyga has a crazy idea | 09:33 | |
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:34 |
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:35 |
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:36 |
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? | 09:37 |
=== wgrant_ is now known as wgrant | ||
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:38 |
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:39 |
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:40 |
persia | And following in the footsteps of e.e. cummings :) | 09:41 |
=== plars is now known as plars-away | ||
=== hrw is now known as hrw|gone | ||
neure | how is 10.04 on beagle? | 13:26 |
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:27 |
neure | how do i see my version? | 13:29 |
neure | how about C3? | 13:30 |
neure | what is different C3 -> C4? | 13:30 |
amitk | http://elinux.org/BeagleBoard#Revision_A | 13:31 |
neure | apparently i have C2 | 13:37 |
neure | so is the "Improved USB Host PHY power rails" that might affect keyboard / mouse? | 13:37 |
neure | whatever that means.. | 13:38 |
XorA | neure: means USB actually works reliably on all C4 | 13:38 |
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:39 |
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:40 |
rcn-ee | neure, you can use the otg port using my NetInstall setup on elinux using the commuinty kernel... | 13:41 |
neure | im currently running ångström on it | 13:42 |
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:43 |
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:44 |
XorA | amitk: of course we do :-D | 13:45 |
* XorA puts on his Angstrom maintainer hat | 13:45 | |
siji | :) | 13:45 |
siji | amitk, with ARM v7 | 13:46 |
amitk | XorA: just curious why siji is seeing the difference, is all :) | 13:46 |
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.. | 13:48 |
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:46 |
ogra | james_w, with the official image you can just set fixrtc on the cmdline | 14:47 |
ogra | we have a workaround in initramfs | 14:47 |
=== jmcgee|gone is now known as jmcgee | ||
=== JaMa is now known as JaMa|Sports | ||
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
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:15 |
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:16 |
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:17 |
XorA | I think bugfixes only, no architectural changes | 16:18 |
ogra | hmm | 16:18 |
sumitsemwal | XorA: :) .. I will ask people who're involved with the DSS2 to join.. maybe tomorrow? | 16:26 |
amitk | sumitsemwal: good to see you hang out here :) | 16:27 |
ogra | yeah ! | 16:27 |
sumitsemwal | amitk: newbie, be gentle :P | 16:28 |
amitk | sumitsemwal: hehe :) | 16:30 |
=== 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 | ||
NCommander | sebjan: ping? | 21:58 |
NCommander | robclark: ping? | 22:00 |
robclark | NCommander: pong | 22:00 |
NCommander | robclark: see PM | 22:01 |
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:02 |
ogra_cmpc | was it cross built ? | 22:03 |
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:04 |
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:05 |
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:06 | |
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:07 |
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:08 |
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:09 |
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 | 22:10 |
=== jmcgee is now known as jmcgee|gone |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!