=== bjf is now known as bjf[afk] [06:16] * rsalveti interested at what display issue ndec had === hrw|gone is now known as hrw [08:28] morning [08:29] ogra_cmpc: The daily image looks nice :) I just replaced the kernel and kept everything else (MLO, u-boot, etc...) === XorA|gone is now known as XorA [08:46] ogra_cmpc: I remark there is no console on UART with the pre-installed image. Don't you think it would be useful for some to have the 'login' prompt on UART too? [08:48] That's semi-intentionally not present. [08:48] We generally don't feel that most end-users are likely to understand the concept of serial console, let alone have any need to use one. [08:49] Mind you, it might be interesting to make it easier to enable. [08:54] Hmm, I set up my beagle boot.scr and user.scr so normal is normal and alternate is development mode. Normal has splash (had to force with FRAMEBUFFER=Y), aufs, and no serial console (because serial console forcibly disables splash). Alternate has serial console, and no aufs. [08:55] https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/516825 [08:56] Ah, maybe I should move my comments to a new bug. [08:56] My desired behavior would be to show the splash on tty0, but not hide output on ttyS0. [08:57] https://bugs.freedesktop.org/show_bug.cgi?id=22239 [08:57] Yeah, you want a new bug. [08:58] But one could strongly argue that having plymouth run *twice*, once in splash mode and once in console mode is a bit messy. [08:59] What's odd is that pressing escape toggles the text-as-splash thing... and ruins the serial console. [09:00] Couldn't you just have Plymouth completely disregard the serial console, and handle only tty? [09:00] Why does it have to hook into both? [09:01] Dunno. I'd suggest asking either Keybuk (in -devel), or upstream. [09:51] vstehle, i have a hack i plan to apply to jasper (the firstboot tool) that will enable a login prompt automatically if a serial console is set on cmdline... [09:52] ogra_cmpc: Nice! [09:52] vstehle, for the reasons persia and DanaG pointed out we wont set a serial console by default in boot.scr though [09:52] ogra_cmpc: To continue with the image: I think the 'system testing' tool gets stuck on my board... [09:52] so that setp is something i expect a dev to be able to do manually [09:52] *step [09:52] checkbox is getting stuck? How? [09:53] sounds like a bug [09:53] 'Gathering information from your system...' (since one hour now) [09:53] Shall I enter a launchpad bug? [09:53] Hrm. [09:53] Please enter a bug, [09:53] on cdimage? [09:53] might be confused when nt finding a pci bus or something, file a bug using ubuntu-bug (that will attach all the needed logs) [09:54] That's what I'm thinking, but I thought that got patched out in karmic [09:54] ogra_cmpc: I have no network on the board for now... :( [09:54] the package for the test tool is called checkbox [09:54] Oh, it's the GL check. [09:54] ah [09:54] makes sense [09:54] ogra_cmpc: Is there a checkbox 'log' I could look at, somewhere? [09:55] * ogra_cmpc doesnt know but i would expect so [09:55] There definitely is a log. [09:56] Ah, found it. It's probably `lspci | grep -q VGA` that hangs. [09:56] vstehle, Could you try that command to see if it does hang? [09:57] persia: It complains but does not hang. (cannot open /proc/bus/pci, etc...) [09:58] How about `grep Loading $XORG_LOG | grep -q "${i}_drv\.so"` ? [09:58] * persia isn't seeing much that might be contentious [09:58] Oh, that won't hit: we'll drop into DRV=$UNKNOWN. Nevermind [09:59] Does xvinfo work? [09:59] persia: Xorg loaded two so: fbdev & evdev [10:00] Right, but the ${i} is apparently from a whitelist, which escaped me at the first readthrough of the code :) [10:00] persia: xvinfo is a bit strange: screen #0\n no adpators present [10:00] That's incorrect, but oughtn't break the script. [10:01] Bug #633005 :) [10:04] Looks like by default checkbox.log drops into . [10:05] persia: There is a /tmp/checkbox*** dir [10:05] persia: Hmm. With pipes, after all. [10:06] Well, /usr/bin/checkbox-gtk and /usr/bin/checkbox-cli both contain what looks like an attempt to use $CHECKBOX_DATA, falling back to . if absent. [10:06] But I may be mistaken. [10:06] persia: $HOME/.cache/checkbox/checkbox.log ? [10:07] Quite possibly: I may have read that wrong. [10:08] Ah, indeed. it's "$XDG_CACHE_HOME/checkbox", so that's the right log. [10:08] persia: Traces before "hang" are Started firing gather , Calling None.ScriptsInfo.gather() ... , Calling None.BackendInfo.gather() ... [10:08] * persia misses the bot [10:11] How did you file that bug? [10:12] persia: Launchpad, go to package checkbox, click on 'Report a bug' [10:12] Ah. That explains the lack of data :) [10:13] persia: Yes, sorry, no network (I have troubles finding eth switches those days) [10:13] Would you mind running `apport-collect 633005` on the affected system (if it has access to LP)? [10:13] * ogra_cmpc wonders why we didnt have an image build tonight [10:13] Oh, right. Nevermind :) [10:13] not even an attempt it seems [10:13] persia: I'll disconnect another board, hold on [10:14] No worries. In general, it's best to try to file the bugs from the boards, because that includes more information, but that's more important with crashes than hangs. [10:14] The odd bit is that BackendInfo.gather() only creates some named pipes... [10:15] persia: Maybe there is a "spawned" process, which exited? [10:15] persia: And the father is waiting for some data on the pipes? [10:16] Potentially. [10:17] Had you passed the request for the administrative password? [10:18] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-omap4/20100908/livecd-20100908-armel.out [10:18] GRRRRR !!!!!!!!!!!!!!!! [10:18] persia: I don't remember. More than one our ago is too much for my little brain :) [10:18] apw, seems its still messed up ^^^^ [10:18] Try it again. The request for administrative rights should be quick (or if it isn't, we found the bug) [10:19] persia: I need to reboot because I cannot kill the window (other bug?) hold on... [10:24] No rush :) [10:25] ogra_cmpc, which kernel was in the archive when it failed [10:25] due to a disconnect between tim and myself there were two uploads for that kernel [10:26] oh, then it might be stuck in NEW [10:26] i'll check as soon as i'm on the other computer [10:26] ogra_cmpc, the fixed version looks to have hit the archive around 3am [10:27] (my time) [10:27] the 903.10 one seems to have built [10:27] (your time is buildd time too ;) ) [10:27] i thought they were on UTC [10:27] which for half the year we are on [10:28] isnt BST = UTC ? [10:28] ah [10:28] GMT == UTC, BST == UTC + 1 [10:28] so i have to wait 2 months for my statement to be true :) [10:28] BST is within 1 second of UTC half the time, and closer to 3600 the rest of the time. === kmargar is now known as markos_ [10:29] no BST is always GMT+1 hour, and GMT is <1s different from UTX [10:29] * ogra_cmpc twiddles thumbs [10:29] UTC [10:29] ogra_cmpc, i am still not sure this damn thing is right [10:29] * persia declares everyone should always use numeric timezone designators [10:29] it looked good in my testing, but i am not sure its built the common headers [10:29] it doesnt seem to have the dot version in it [10:30] you may have what you need in the archive, but this build isn't quite right yet [10:30] damn they made a mess when they rebuilt this branch for .35 ... not quite sure how they made it so wrong [10:30] and 7 hour rebuilds are not helpful [10:31] linux-headers-2.6.35-903-omap4 is what you built [10:31] yeah that is right, and it should depend on linux-headers-2.6.35-903, which it did no build [10:31] it may be in the archive however [10:31] linux-ti-omap4-headers-2.6.35-903 is what the meta looks for [10:32] according to the image build log [10:33] how do you manage all that without getting your brain fried ? [10:34] ahh crap is meta fried too ... [10:34] ogra_cmpc, where in the 20 pools do i find the built images ? [10:35] http://ports.ubuntu.com/pool/main/l/linux-ti-omap4/ you mean ? [10:36] and http://ports.ubuntu.com/pool/main/l/linux-meta-ti-omap4/ i think [10:37] ogra_cmpc, ok i think the bits you need happen to be in the archive binary wise though the build needs another fix [10:37] an old one is there at the moment which i believe the dependancy would use [10:37] now the meta package seems broken as well ? [10:38] well, the images need it proper to be buildable [10:38] the meta package ? [10:39] Package: linux-headers-omap4 [10:39] Architecture: armel [10:39] Section: devel [10:39] Priority: optional [10:39] Depends: ${misc:Depends}, linux-headers-${kernel-abi-version}-omap4 [10:39] i need to check the NEW queue, let me finish breakfast to see whats going on (this classmate isnt powerful enough to open more than one website and xchat) [10:39] the meta package seems to point to the correct name [10:40] ogra_cmpc, so i _think_ whats in the archive right now ought to install, though its not quite right [10:40] apw: i failed to see the bug #632235 in https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4 [10:41] apw: is that because that it is 'Fix Released'? [10:41] yep, it would have autoclosed on upload [10:41] apw, i just triggered an image build, lets see if it gets through, might just have been a timing issue [10:41] not sure it was in in time to fix the CD though [10:41] ogra_cmpc, how long does that take? i'll get the remaining issue sorted out shortly [10:41] but want to know its the last issue first [10:42] The image is trying to pull ${Kernel-Stem}-omap4 [armel] as a metapackage. [10:42] apw, if it fails, it fails fast [10:43] grr, why is the omap3 buildd dieing all the time [10:43] ssh: connect to host acorn.buildd port 22: No route to host [10:43] acorn.buildd finished at Wed Sep 8 10:40:56 BST 2010 (failed) [10:43] Null message body; hope that's ok [10:43] (omap4 didnt fail yet) [10:44] * ogra_cmpc ignores breakfast and goes upstaris to the office [10:45] ok, the NEW queue is empty [10:50] apw, failed, same message [10:50] can you paste the message pls [10:52] oh, wait, its different [10:52] * ogra cant copy paste from w3m which i need to use for reading the logs ... one sec [10:52] heh always the way [10:52] linux-headers-2.6.25-903-omap4 depends linux-headers-2.6.35-903 [10:53] s/25/35/ [10:54] no subarch at all on the latter now [10:54] yep === amitk is now known as amitk-afk [10:54] also 20100908.1 should show up soon at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-omap4/ [10:55] OH now i understand ... i am getting fooled ... [10:55] the build is producing the headers, but in 'all' [10:56] but its doing that ... during the armel build ... so they don't get picked up [10:56] ie ... test builds make both, one armel, one all, but the build will only pick up the _armel builds during a real buildd build [10:56] oh, right [10:57] you should make the package "arch: armel" only [10:57] dammit, i'd claim noone had tested, but ... its very very easy to overlook in our test harnesses [10:57] that saves you from all the build failure spam on x86/amd64/ppc too ;) [10:57] ogra, yep, am doing so [10:58] * persia encourages folk to use sbuild so that building arch:all packages happens only by intent [10:59] the annoying bit is that this was all correctly configured prior to the conversion to .35 and it un [10:59] unexpectedly all got lost [11:00] persia, yeah sbuild would be good, but iirc it [11:00] it has some assumptions about naming that clashes with naming we use already for different things [11:00] so its not a simple slot in [11:06] apw, The key bit is that sbuild is what runs on the real buildds, so ... :) [11:07] Anyway, bug me about it in October, and maybe we can find a way to drop it in to your framework in November. Sooner is unlikely, what with release and next cycle planning. [11:07] persia, don't get me wrong its the right thing, but setting things up its way is more tricky [11:07] due to some contraints on our existing framework [11:08] specially as we have few machines which can even do an arm build in a sensible time [11:08] I figured. I've just written a number of scripts using the sbuild framework, so thought there may be opportunity for synergy. I won't complain if you don't want me to look at it :) [11:08] persia, should do, at one of the sprints i recon [11:08] That's why I suggested October. I'm expecting to be at UDS. [11:09] heh good enough [11:24] cooloney, who cares for the imx51 kernel beyond smb ? [11:24] seems we have a bad bug in the lucid kernel that makes java builds fail [11:24] bug 605042 [11:24] Launchpad bug 605042 in eglibc (Debian) (and 10 other projects) "[armel] java fails to start with eglibc-2.12-0ubuntu4 (affects: 2) (heat: 12)" [Unknown,Unknown] https://launchpad.net/bugs/605042 [11:26] Ugh. [11:26] yes [11:26] very ugh [11:27] apw, do you know who we can assign that to ? its rather urgent else we cant build any java related packages it seems [11:28] And that blocks a whole bundle of stuff, unfortunately. [11:29] ogra, which arm is it? [11:29] apw, imx51 ... its the buildd kernels [11:30] well i guess we need one of eric/bryan or lee on it, they are are area experts [11:30] right [11:34] ogra, do you know where the userspace stack is normally on arm ? [11:35] can you elaborate === amitk-afk is now known as amitk [11:35] which userspace stack ? [11:39] ogra, any/all userspace stacks, what addy are they placed at on arm by defualt [11:42] apw, i still dont get what you want :/ [11:42] apw, We don't do it that way. [11:42] do you want to know where the packages live ? [11:42] or where the archive is .. [11:43] Rather, we pass an initrd to the bootloader (varies by device), and then pass root= as a kernel argument. [11:43] the kernel puts the userspace stack in a specific place, the actual address of the actual memory which represents the stack of the CPU [11:43] oh [11:43] trying to work out if these addresses are stack related [11:43] * ogra was associating userspace with desktop/console tools etc [11:43] heh understandable [11:45] ogra, so what makes us think this is a kernel issue, i see nothing other than a change to elibc causes SEGV's [11:45] Because it's only reproducible on imx51 [11:46] it seems to not happen on other arches [11:46] that doens't meant its not broken on all arches though [11:46] other *boards* [11:46] https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/605042/comments/20 [11:46] Launchpad bug 605042 in eglibc (Debian) (and 10 other projects) "[armel] java fails to start with eglibc-2.12-0ubuntu4 (affects: 2) (heat: 12)" [Unknown,Unknown] [11:46] there is no analysis at all as to cause [11:58] ogra, ok i've followed it as far as I can quickly, its a non-trivial arch specific function that i can't easily find ... so we need an imx expert on that one [11:58] yeah [11:59] thats why i asked in the beginning :) [12:07] indeed [12:10] ogra, ok i've pushed and uploaded what should fix that last headers bug [12:11] yay [12:11] i'll try as soon as its in the archive [12:13] ogra, its on a buildd already amazingly [12:14] wohoo [12:14] the publisher will take ages though [12:14] as will the build :( [12:15] oh, it wasnt the meta ... [12:15] yeah [12:15] ogra, no sadly its the main kernel [12:15] well, 5h plus publisher [12:16] * apw will be invistigating why the configuration was not simply carried forward [12:16] avoiding all this pain [12:16] avoiding the pain in a real way would mean TI hires 100 monkeys to upstream all that stuff :) [12:17] heh there is that [12:17] we still should have avoided this, not happy [12:41] * ogra takes a break === freeflyi1g is now known as freeflying [13:36] ogra: hi... when is the next daily image being planned? the one with es2.0 support, i mean. [13:47] persia: hi! any update on the pulse bug #631362? [13:47] ndec: did you get your audio tested ? [13:47] Launchpad bug 631362 in pulseaudio (Ubuntu Maverick) (and 1 other project) "Include several configuration files (affects: 1) (heat: 14)" [Medium,In progress] https://launchpad.net/bugs/631362 [13:48] hi prpplague... I am just doing it ;-) I can use HMDI, but not headset. [13:48] ndec: which board version do you have? [13:48] prpplague: the latest and greatest ;-) [13:48] prpplague: 8-layer, es2.0 [13:48] ndec: any errors? [13:49] prpplague: the speaker-test command you sent works for HMDI, I can alsa play gst stream through alsasink to HDMI. [13:51] prpplague: but the same command fail with HS. speaker-test tells me : playback open error: -16, device/resource busy [13:52] ndec: most likely you have some other userspace apps accesing the device [13:52] brb [14:01] ndec, once the kernel team fixed all issues with dependencies we had due to the version change ... we think this is fixed with the currently building package and i will fire off an image build as soon as thats in the archive (likely later this evening) [14:01] prpplague: ok. might be. I am doing an upgrade, when it's done, I will kill GDM and restart the same test. === rgreening_ is now known as ghost === ghost is now known as rgreening [14:02] ndec, i talked to TheMuso (luke, our pulse maintainer) yesterday in #ubuntu-devel, he said he has a bunch of other fixes too and wants to upload all of them in one go, the multi config file support will be included in that but he couldnt give an ETA for the upload [14:03] ogra: great. I just wanted to know if it will be committed in 10.10.. looks like yes. [14:03] yes, promised :) === ogra changed the topic of #ubuntu-arm to: Ubuntu ARM Discussion & Development | https://wiki.ubuntu.com/ARM | Want to Submit a Bug? https://bugs.launchpad.net/ubuntu/+filebug | Build a rootfs from scratch: https://wiki.ubuntu.com/ARM/RootfsFromScratch | also visit #linaro | Maverick beta see https://wiki.ubuntu.com/ARM/OMAP | wanna cross build ? see http://idlethread.blogspot.com/2010/09/cross-compilation-redux.html [14:05] * ogra makes amitk famous :) [14:07] ogra: or infamous (since the debuild recipe for ubuntu kernels fails due to perf dependency) :-/ [14:07] bah [14:08] should i drop it from the topic again ? or is someone working on a fix for that ? [14:08] ogra: will need to fix that with some dpkg-cross instructions [14:08] k [14:08] ogra: the blog post itself might be useful to advertise the toolchain [14:08] right, thats what i thought [14:08] I'll update the exact kernel instructions [14:09] great [14:09] in case the url changes through that, please tell me, i'll update it [14:11] morning [14:12] ndec: hey, you were having display issues yesterday [14:12] yesterday ? [14:13] Est-ce que ndec est par ici? [14:13] ndec: "We are waiting for the chair person to join" :) [14:14] lol [14:14] * ogra knows that feeling [14:14] she has such a nice voice :) [14:14] ogra: *Oups* Wrong chan. Now you know that we have our own problems... ;) [14:15] heh [14:15] ogra: (She indeed has a nice voice.) [14:21] ogra: rsalveti: if I turn my display ON a few sec after boot, the resolution is fine. I think i have same problem with race condition and X start... [14:21] ogra: ^ this issue [14:21] rsalveti: thanks for the follow up... [14:21] * rsalveti wants to know with which kernel [14:22] rsalveti, yeah i was just jokiag about the "yesterday" he always has these issues :) [14:22] *joking [14:22] rsalveti: i am using sebjan's kernel, es2.0, 8-layer. this should be equivalent to what has been uploaded today [14:22] * rsalveti still has lots of emails and backlog to ready [14:22] ndec, i think we are one patchset behind [14:22] don't you have the same issue? [14:22] let me check our git tree [14:22] ogra: cooloney pull request was uploaded this morning, i haven't checked but it might be building now [14:23] the merge request was only filed today [14:23] we got an updated tree already [14:23] i think whats building now wasnt a fresh checkout, just a packaging fix from apw [14:24] ndec, ogra, yep ... not his pull request. if he had mentioned it 2 hours ago we might have put it in the same one! [14:24] ogra: .11 is building now, and has all patches for 6 and 8-layer, and es2 [14:25] yep, but we're still behind some pm fixes [14:25] right [14:25] but our current kernel will work fine for es2 6 and 8 layers [14:25] ndec: the issue I'm having is: http://www.flickr.com/photos/rsalveti/4932601965/ [14:25] because of the disconnect/connect during hdmi detection [14:26] ndec, i was referring to the pull request from 14:49 today (local time) ... all other patches should be in [14:26] apw: ogra: rsalveti: right... i missed today's pull request... anyways, .11 should work on 6 and 8 layer ES2.0. the today's pull request is another set of fix [14:28] rsalveti: so... i have another one ;-) I only see on the screen the top left part of the desktop. if i turn off HDMI on the TV, let the kernel boot and GDM come, and then turn TV to HDMI resolution is fine. I have a 1920x1080 display (xrandr). [14:29] ndec: hm, interesting [14:30] can you boot with omapdss.debug=1 and check both boot logs? [14:30] * rsalveti never tried to turn on his monitor after boot [14:30] * rsalveti will also try that [14:31] if gdm (X) is fine, then it got the correct resolution before opening it [14:32] so when it doesn't work then it could be a racing condition when starting X and the size_notify (that changes the fb resolution) [14:32] ogra: hm, no new images to download :-) [14:33] rsalveti, yeah, kernel package breakage [14:33] rsalveti, we should have new images by end of my day so you have something to play with for your afternoon [14:33] hm, that's why a lot of apw's commits [14:33] cool [14:33] right, he saved out butts :) [14:33] *our [14:33] :-) [14:34] apw is our new amitk *g* [14:34] yeah its very difficult to test outside a real build [14:34] i hope its all resolved now [14:44] sakoman: cool, thanks for including the patch [14:45] now just need to add it to jcrigby linaro's package [14:45] rsalveti: i will share the dssdebug later, i am doing an apt-get upgrade ;-) [14:46] ndec: haha, got it working like you! [14:46] rsalveti, yeah, we'll also need to talk to slangasek and jcrigby about ES2.1 support (since we will need a freeze exception for it) [14:46] ndec: after turning it on later, it worked fine! [14:46] * rsalveti can now check his logs [14:46] rsalveti: cool... it's actually funny that I found out this use case ;-) [14:46] ogra: es2.1 support? [14:46] rsalveti, yep [14:47] when are we getting es2.1? [14:47] beginning of oct. i'd guess [14:47] rsalveti: I'm going to try to sneak that in upstream as a single patch [14:47] rsalveti: the thing is I received a new TV, put it out of the box, plug the cable and booted. and after a few seconds I realized that I was not on HDMI, so switch the TV to this ;-) [14:47] oh, ok, the "final" one [14:47] rsalveti: if they complain I'll break it back into two [14:47] right [14:47] sakoman: yep, saw that, cool [14:48] ndec: hah, cool :-) [15:11] amitk: Would you be tempted to send a patch for fixing cross-compilation of the kernel in the standard way? currently, it needs -eCROSS_COMPILE; in other packages, debian/rules takes care of setting this kind of stuff so that "dpkg-buildpackage -aarmel" just works; what would need to be changed is setting CROSS_COMPILE to $(DEB_HOST_GNU_TRIPLET)- when DEB_HOST_ARCH and DEB_BUILD_ARCH aren't equal (cross-compilation) [15:16] lool: let see if I can tempt apw for this ^^^ ;) [15:17] as in a simple if and set? that doesn't sound too onerous === bjf[afk] is now known as bjf [15:22] apw: pretty much [15:22] apw: Yup, you need to DEB_HOST_GNU_TRIPLET ?=, DEB_HOST_ARCH ?= etc. if they aren't already set somewhere, then ifneq ($(DEB_HOST_ARCH),$(DEB_BUILD_ARCH)) export CROSS_COMPILE=... [15:23] In fact, you might want to CROSS_COMPILE ?= in the if body as this allows overriding CROSS_COMPILE as amitk did [15:23] lool: but what is the std. prefix for CROSS_COMPILE? [15:23] So that one can still use non-standard toolchains [15:24] (arm-none-linux-gnueabi- from CodeSourcery comes to mind, it's not the same triplet as the Debian arch expects) [15:24] amitk: I don't understand the question [15:24] lool: I use CROSS_COMPILE=arm-linux- (by linking arm-linux-gnueabi-* to arm-linux-*) [15:24] amitk: Oh, you should CROSS_COMPILE=arm-linux-gnueabi- [15:25] arm-linux- is incorrect [15:25] CROSS_COMPILE is what gets prepended to all toolchain tools, e.g. upstream just calls $(CROSS_COMPILE)gcc and CROSS_COMPILE is empty for native builds [15:25] and the upstream toolchain will prefix all tools with the triplet in cross-toolchains, so CROSS_COMPILE should be triplet suffixed by a - [15:26] lool: where can I find a good explanation of the 'triplet'? I assume the triplet is the std. prefix [15:28] isn 't that triplet some kind of gnu standard [15:29] amitk: GNU triplet is what you configure a toolchain with [15:29] let me find some referene [15:29] a triplet is a standard gnu config string [15:30] it's heavily used to differentiate between the build, host, and target system [15:32] apw, amitk: I'm unable to point at a concise definition; multiple places refer to these, and have various lists [15:32] http://gcc.gnu.org/install/configure.html explains --host/--build/--target which all take triplets [15:32] triplets values are best defined in configure.ac [15:32] http://gcc.gnu.org/install/specific.html has some lists of targets [15:32] http://gcc.gnu.org/onlinedocs/libstdc++/manual/internals.html explains some components of the triplet [15:32] the idea at the time was build is the machine you are on, host is what it will be running on, and target is the final output of gcc [15:33] most other apps use just build and host [15:43] apw, amitk: Sorry, can't find a precise reference for GNU triplets, but it's basically a toolchain concept telling the toolchain how to configure itself at the highest level; a Debian/Ubuntu port has only one such triplet, and cross-gcc is expected to be at $triplet-gcc [15:44] same for -ld, -objdump etc. === bjf is now known as bjf[afk] [15:44] lool: I can talk about config triplets all you want, what exactly do you need to do ? [15:45] lool: sounds complicated policy. I'll go through your links... [15:45] hey guys [15:45] rsavoye: just what they are and why we should care when we set CROSS_COMPILE :) [15:45] rsavoye: I don't think we need any detail; amitk and apw needed some kind of primer on the concept [15:45] anyone noticed a launchpad bug or anything that describes X taking up 90% of the CPU *all* the time? [15:45] amitk: It's just a toolchain input to configure it [15:45] amitk: the output is that the tools are at $triplet-tool :-) [15:46] right, so other configure scripts can find their tools [15:46] amitk: CROSS_COMPILE is a linux var, it's also used in other projects like U-Boot, but it's not extremely wide-spread [15:46] Neko: This can happen for a variety of reasons [15:46] the reason here seems to be that I started X and opened a terminal [15:46] it just hit 80% [15:46] which is where issues like arm-linux-eabi or arm-linux-gnueabi are important [15:47] I close the terminal and it stays at 80% even if I'm on another VT [15:47] X is spinning wildly somewhere [15:47] https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/617994 <-- this does help btw (the disable lcd font smoothing thing) [15:47] Launchpad bug 617994 in nvidia-graphics-drivers-180 (Ubuntu) "Slow performance and high CPU usage on Maverick (affects: 11) (heat: 58)" [Undecided,Confirmed] [15:47] Neko: you could try tracing it [15:48] Neko: it could be anything, like a X client doing a lot of server requests [15:48] what do I use to trace X activity :/ [15:48] Neko, i'd swing by ubuntu-x they'll be better equiped to answer [15:48] okay [16:03] ndec: any luck on the audio? [16:03] prpplague: not yet... upgrade is taking forever... [16:04] ndec: np, i'll be online all day if you need assistance === zyga is now known as zyga-kids [16:09] so, has anyone had success in making arm images that run w/ qemu in maverick ?? and if so, can I download one ? :) === amitk is now known as amitk-afk === orbarron1 is now known as orbarron === bjf[afk] is now known as bjf === hrw is now known as hrw|gone [18:24] ogra, those images are built [18:31] He may be monitoring on his other system. ogra_cmpc ^^^ [18:39] apw, thanks, but publishing will take a while [18:41] * ogra_cmpc waits for .11 to show up at http://ports.ubuntu.com/pool/main/l/linux-ti-omap4/ [18:42] Will this also fix the missing headers issue? [18:43] its meant to only sort out those headers [18:43] GrueMaster, the missing headers were fixed two days ago with the last netbook-meta upload [18:44] The following packages have unmet dependencies: [18:44] linux-headers-2.6.35-903-omap4 : Depends: linux-ti-omap4-headers-2.6.35-903 but it is not installable [18:44] * ogra_cmpc thinks GrueMaster means a different issue than apw :) [18:44] GrueMaster, yeah, thats apw's fix [18:44] ahh [18:44] Cool [18:44] oh, actually i might have introduced it [18:45] the omap4 headers were missing completely from the images until monday [18:45] apw, so that breakage was always hidden, it could as well have been present from day one, we just didnt see it [18:46] i.e. not introduced with the version change [18:46] indeed, i see those two issues as one big "headers is bust" problem [18:47] as you say the bad linkage was hidden by the bad meta linkage and the bad everything else [18:47] heh, yeah [18:47] ogra_cmpc, is ports publish slower than normal publish ? [18:47] about 45 min at least [18:47] dammit [18:48] its a bit slower than the main archive ... [18:48]