**** BEGIN LOGGING AT Wed Sep 08 02:59:59 2010 Sep 08 05:20:01 * rsalveti interested at what display issue ndec had Sep 08 07:31:46 morning Sep 08 07:32:43 ogra_cmpc: The daily image looks nice :) I just replaced the kernel and kept everything else (MLO, u-boot, etc...) Sep 08 07:49:26 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? Sep 08 07:51:38 That's semi-intentionally not present. Sep 08 07:51:59 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. Sep 08 07:52:22 Mind you, it might be interesting to make it easier to enable. Sep 08 07:57:39 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. Sep 08 07:59:10 https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/516825 Sep 08 07:59:16 Ah, maybe I should move my comments to a new bug. Sep 08 07:59:31 My desired behavior would be to show the splash on tty0, but not hide output on ttyS0. Sep 08 08:00:32 https://bugs.freedesktop.org/show_bug.cgi?id=22239 Sep 08 08:00:46 Yeah, you want a new bug. Sep 08 08:01:27 But one could strongly argue that having plymouth run *twice*, once in splash mode and once in console mode is a bit messy. Sep 08 08:02:39 What's odd is that pressing escape toggles the text-as-splash thing... and ruins the serial console. Sep 08 08:03:22 Couldn't you just have Plymouth completely disregard the serial console, and handle only tty? Sep 08 08:03:28 Why does it have to hook into both? Sep 08 08:04:24 Dunno. I'd suggest asking either Keybuk (in -devel), or upstream. Sep 08 08:54:54 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... Sep 08 08:55:21 ogra_cmpc: Nice! Sep 08 08:55:32 vstehle, for the reasons persia and DanaG pointed out we wont set a serial console by default in boot.scr though Sep 08 08:55:46 ogra_cmpc: To continue with the image: I think the 'system testing' tool gets stuck on my board... Sep 08 08:55:55 so that setp is something i expect a dev to be able to do manually Sep 08 08:56:08 *step Sep 08 08:56:10 checkbox is getting stuck? How? Sep 08 08:56:18 sounds like a bug Sep 08 08:56:34 'Gathering information from your system...' (since one hour now) Sep 08 08:56:51 Shall I enter a launchpad bug? Sep 08 08:56:51 Hrm. Sep 08 08:56:55 Please enter a bug, Sep 08 08:57:01 on cdimage? Sep 08 08:57:01 might be confused when nt finding a pci bus or something, file a bug using ubuntu-bug (that will attach all the needed logs) Sep 08 08:57:22 That's what I'm thinking, but I thought that got patched out in karmic Sep 08 08:57:24 ogra_cmpc: I have no network on the board for now... :( Sep 08 08:57:28 the package for the test tool is called checkbox Sep 08 08:57:54 Oh, it's the GL check. Sep 08 08:57:59 ah Sep 08 08:58:05 makes sense Sep 08 08:58:09 ogra_cmpc: Is there a checkbox 'log' I could look at, somewhere? Sep 08 08:58:27 * ogra_cmpc doesnt know but i would expect so Sep 08 08:58:40 There definitely is a log. Sep 08 08:59:26 Ah, found it. It's probably `lspci | grep -q VGA` that hangs. Sep 08 08:59:42 vstehle, Could you try that command to see if it does hang? Sep 08 09:00:40 persia: It complains but does not hang. (cannot open /proc/bus/pci, etc...) Sep 08 09:01:29 How about `grep Loading $XORG_LOG | grep -q "${i}_drv\.so"` ? Sep 08 09:01:37 * persia isn't seeing much that might be contentious Sep 08 09:02:04 Oh, that won't hit: we'll drop into DRV=$UNKNOWN. Nevermind Sep 08 09:02:40 Does xvinfo work? Sep 08 09:03:12 persia: Xorg loaded two so: fbdev & evdev Sep 08 09:03:42 Right, but the ${i} is apparently from a whitelist, which escaped me at the first readthrough of the code :) Sep 08 09:03:47 persia: xvinfo is a bit strange: screen #0\n no adpators present Sep 08 09:04:03 That's incorrect, but oughtn't break the script. Sep 08 09:04:20 Bug #633005 :) Sep 08 09:08:09 Looks like by default checkbox.log drops into . Sep 08 09:08:43 persia: There is a /tmp/checkbox*** dir Sep 08 09:09:02 persia: Hmm. With pipes, after all. Sep 08 09:10:00 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. Sep 08 09:10:08 But I may be mistaken. Sep 08 09:10:09 persia: $HOME/.cache/checkbox/checkbox.log ? Sep 08 09:10:23 Quite possibly: I may have read that wrong. Sep 08 09:11:43 Ah, indeed. it's "$XDG_CACHE_HOME/checkbox", so that's the right log. Sep 08 09:11:53 persia: Traces before "hang" are Started firing gather , Calling None.ScriptsInfo.gather() ... , Calling None.BackendInfo.gather() ... Sep 08 09:11:54 * persia misses the bot Sep 08 09:15:01 How did you file that bug? Sep 08 09:15:42 persia: Launchpad, go to package checkbox, click on 'Report a bug' Sep 08 09:15:55 Ah. That explains the lack of data :) Sep 08 09:16:25 persia: Yes, sorry, no network (I have troubles finding eth switches those days) Sep 08 09:16:32 Would you mind running `apport-collect 633005` on the affected system (if it has access to LP)? Sep 08 09:16:32 * ogra_cmpc wonders why we didnt have an image build tonight Sep 08 09:16:39 Oh, right. Nevermind :) Sep 08 09:16:43 not even an attempt it seems Sep 08 09:17:11 persia: I'll disconnect another board, hold on Sep 08 09:17:52 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. Sep 08 09:18:13 The odd bit is that BackendInfo.gather() only creates some named pipes... Sep 08 09:18:41 persia: Maybe there is a "spawned" process, which exited? Sep 08 09:18:54 persia: And the father is waiting for some data on the pipes? Sep 08 09:19:19 Potentially. Sep 08 09:20:48 Had you passed the request for the administrative password? Sep 08 09:21:40 http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-omap4/20100908/livecd-20100908-armel.out Sep 08 09:21:45 GRRRRR !!!!!!!!!!!!!!!! Sep 08 09:21:53 persia: I don't remember. More than one our ago is too much for my little brain :) Sep 08 09:22:07 apw, seems its still messed up ^^^^ Sep 08 09:22:13 Try it again. The request for administrative rights should be quick (or if it isn't, we found the bug) Sep 08 09:23:04 persia: I need to reboot because I cannot kill the window (other bug?) hold on... Sep 08 09:27:48 No rush :) Sep 08 09:28:32 ogra_cmpc, which kernel was in the archive when it failed Sep 08 09:28:55 due to a disconnect between tim and myself there were two uploads for that kernel Sep 08 09:29:56 oh, then it might be stuck in NEW Sep 08 09:30:08 i'll check as soon as i'm on the other computer Sep 08 09:30:13 ogra_cmpc, the fixed version looks to have hit the archive around 3am Sep 08 09:30:22 (my time) Sep 08 09:30:28 the 903.10 one seems to have built Sep 08 09:30:49 (your time is buildd time too ;) ) Sep 08 09:30:59 i thought they were on UTC Sep 08 09:31:12 which for half the year we are on Sep 08 09:31:19 isnt BST = UTC ? Sep 08 09:31:24 ah Sep 08 09:31:53 GMT == UTC, BST == UTC + 1 Sep 08 09:31:54 so i have to wait 2 months for my statement to be true :) Sep 08 09:31:56 BST is within 1 second of UTC half the time, and closer to 3600 the rest of the time. Sep 08 09:32:23 no BST is always GMT+1 hour, and GMT is <1s different from UTX Sep 08 09:32:23 * ogra_cmpc twiddles thumbs Sep 08 09:32:26 UTC Sep 08 09:32:38 ogra_cmpc, i am still not sure this damn thing is right Sep 08 09:32:50 * persia declares everyone should always use numeric timezone designators Sep 08 09:33:03 it looked good in my testing, but i am not sure its built the common headers Sep 08 09:33:05 it doesnt seem to have the dot version in it Sep 08 09:33:30 you may have what you need in the archive, but this build isn't quite right yet Sep 08 09:33:58 damn they made a mess when they rebuilt this branch for .35 ... not quite sure how they made it so wrong Sep 08 09:34:09 and 7 hour rebuilds are not helpful Sep 08 09:34:18 linux-headers-2.6.35-903-omap4 is what you built Sep 08 09:34:41 yeah that is right, and it should depend on linux-headers-2.6.35-903, which it did no build Sep 08 09:34:51 it may be in the archive however Sep 08 09:35:07 linux-ti-omap4-headers-2.6.35-903 is what the meta looks for Sep 08 09:35:39 according to the image build log Sep 08 09:36:28 how do you manage all that without getting your brain fried ? Sep 08 09:37:41 ahh crap is meta fried too ... Sep 08 09:37:54 ogra_cmpc, where in the 20 pools do i find the built images ? Sep 08 09:38:58 http://ports.ubuntu.com/pool/main/l/linux-ti-omap4/ you mean ? Sep 08 09:40:02 and http://ports.ubuntu.com/pool/main/l/linux-meta-ti-omap4/ i think Sep 08 09:40:30 ogra_cmpc, ok i think the bits you need happen to be in the archive binary wise though the build needs another fix Sep 08 09:40:44 an old one is there at the moment which i believe the dependancy would use Sep 08 09:40:56 now the meta package seems broken as well ? Sep 08 09:41:47 well, the images need it proper to be buildable Sep 08 09:42:04 the meta package ? Sep 08 09:42:36 Package: linux-headers-omap4 Sep 08 09:42:36 Architecture: armel Sep 08 09:42:36 Section: devel Sep 08 09:42:36 Priority: optional Sep 08 09:42:39 Depends: ${misc:Depends}, linux-headers-${kernel-abi-version}-omap4 Sep 08 09:42:41 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) Sep 08 09:42:44 the meta package seems to point to the correct name Sep 08 09:43:30 ogra_cmpc, so i _think_ whats in the archive right now ought to install, though its not quite right Sep 08 09:43:58 apw: i failed to see the bug #632235 in https://bugs.launchpad.net/ubuntu/+source/linux-ti-omap4 Sep 08 09:44:23 apw: is that because that it is 'Fix Released'? Sep 08 09:44:31 yep, it would have autoclosed on upload Sep 08 09:44:46 apw, i just triggered an image build, lets see if it gets through, might just have been a timing issue Sep 08 09:44:49 not sure it was in in time to fix the CD though Sep 08 09:45:04 ogra_cmpc, how long does that take? i'll get the remaining issue sorted out shortly Sep 08 09:45:15 but want to know its the last issue first Sep 08 09:45:19 The image is trying to pull ${Kernel-Stem}-omap4 [armel] as a metapackage. Sep 08 09:45:20 apw, if it fails, it fails fast Sep 08 09:46:46 grr, why is the omap3 buildd dieing all the time Sep 08 09:46:50 ssh: connect to host acorn.buildd port 22: No route to host Sep 08 09:46:50 acorn.buildd finished at Wed Sep 8 10:40:56 BST 2010 (failed) Sep 08 09:46:50 Null message body; hope that's ok Sep 08 09:47:07 (omap4 didnt fail yet) Sep 08 09:48:01 * ogra_cmpc ignores breakfast and goes upstaris to the office Sep 08 09:49:03 ok, the NEW queue is empty Sep 08 09:53:33 apw, failed, same message Sep 08 09:54:05 can you paste the message pls Sep 08 09:55:17 oh, wait, its different Sep 08 09:55:38 * ogra cant copy paste from w3m which i need to use for reading the logs ... one sec Sep 08 09:55:46 heh always the way Sep 08 09:56:16 linux-headers-2.6.25-903-omap4 depends linux-headers-2.6.35-903 Sep 08 09:56:36 s/25/35/ Sep 08 09:57:19 no subarch at all on the latter now Sep 08 09:57:28 yep Sep 08 09:58:00 also 20100908.1 should show up soon at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-omap4/ Sep 08 09:59:02 OH now i understand ... i am getting fooled ... Sep 08 09:59:13 the build is producing the headers, but in 'all' Sep 08 09:59:25 but its doing that ... during the armel build ... so they don't get picked up Sep 08 09:59:48 ie ... test builds make both, one armel, one all, but the build will only pick up the _armel builds during a real buildd build Sep 08 10:00:15 oh, right Sep 08 10:00:31 you should make the package "arch: armel" only Sep 08 10:00:54 dammit, i'd claim noone had tested, but ... its very very easy to overlook in our test harnesses Sep 08 10:01:02 that saves you from all the build failure spam on x86/amd64/ppc too ;) Sep 08 10:01:02 ogra, yep, am doing so Sep 08 10:01:19 * persia encourages folk to use sbuild so that building arch:all packages happens only by intent Sep 08 10:02:44 the annoying bit is that this was all correctly configured prior to the conversion to .35 and it un Sep 08 10:02:49 unexpectedly all got lost Sep 08 10:03:18 persia, yeah sbuild would be good, but iirc it Sep 08 10:03:32 it has some assumptions about naming that clashes with naming we use already for different things Sep 08 10:03:36 so its not a simple slot in Sep 08 10:09:47 apw, The key bit is that sbuild is what runs on the real buildds, so ... :) Sep 08 10:10:38 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. Sep 08 10:10:58 persia, don't get me wrong its the right thing, but setting things up its way is more tricky Sep 08 10:11:07 due to some contraints on our existing framework Sep 08 10:11:38 specially as we have few machines which can even do an arm build in a sensible time Sep 08 10:11:39 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 :) Sep 08 10:11:55 persia, should do, at one of the sprints i recon Sep 08 10:12:13 That's why I suggested October. I'm expecting to be at UDS. Sep 08 10:13:11 heh good enough Sep 08 10:27:34 cooloney, who cares for the imx51 kernel beyond smb ? Sep 08 10:27:58 seems we have a bad bug in the lucid kernel that makes java builds fail Sep 08 10:28:06 bug 605042 Sep 08 10:28:09 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 Sep 08 10:29:52 Ugh. Sep 08 10:29:58 yes Sep 08 10:30:01 very ugh Sep 08 10:30:52 apw, do you know who we can assign that to ? its rather urgent else we cant build any java related packages it seems Sep 08 10:31:17 And that blocks a whole bundle of stuff, unfortunately. Sep 08 10:32:34 ogra, which arm is it? Sep 08 10:32:43 apw, imx51 ... its the buildd kernels Sep 08 10:33:19 well i guess we need one of eric/bryan or lee on it, they are are area experts Sep 08 10:33:27 right Sep 08 10:38:13 ogra, do you know where the userspace stack is normally on arm ? Sep 08 10:38:57 can you elaborate Sep 08 10:39:11 which userspace stack ? Sep 08 10:42:50 ogra, any/all userspace stacks, what addy are they placed at on arm by defualt Sep 08 10:45:39 apw, i still dont get what you want :/ Sep 08 10:45:49 apw, We don't do it that way. Sep 08 10:45:52 do you want to know where the packages live ? Sep 08 10:46:07 or where the archive is .. Sep 08 10:46:23 Rather, we pass an initrd to the bootloader (varies by device), and then pass root= as a kernel argument. Sep 08 10:46:24 the kernel puts the userspace stack in a specific place, the actual address of the actual memory which represents the stack of the CPU Sep 08 10:46:34 oh Sep 08 10:46:46 trying to work out if these addresses are stack related Sep 08 10:46:51 * ogra was associating userspace with desktop/console tools etc Sep 08 10:47:09 heh understandable Sep 08 10:48:59 ogra, so what makes us think this is a kernel issue, i see nothing other than a change to elibc causes SEGV's Sep 08 10:49:17 Because it's only reproducible on imx51 Sep 08 10:49:24 it seems to not happen on other arches Sep 08 10:49:30 that doens't meant its not broken on all arches though Sep 08 10:49:31 other *boards* Sep 08 10:49:45 https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/605042/comments/20 Sep 08 10:49:47 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] Sep 08 10:49:48 there is no analysis at all as to cause Sep 08 11:01:57 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 Sep 08 11:02:14 yeah Sep 08 11:02:25 thats why i asked in the beginning :) Sep 08 11:10:44 indeed Sep 08 11:14:00 ogra, ok i've pushed and uploaded what should fix that last headers bug Sep 08 11:14:29 yay Sep 08 11:14:40 i'll try as soon as its in the archive Sep 08 11:16:58 ogra, its on a buildd already amazingly Sep 08 11:17:32 wohoo Sep 08 11:17:42 the publisher will take ages though Sep 08 11:18:11 as will the build :( Sep 08 11:18:33 oh, it wasnt the meta ... Sep 08 11:18:35 yeah Sep 08 11:18:48 ogra, no sadly its the main kernel Sep 08 11:18:59 well, 5h plus publisher Sep 08 11:19:28 * apw will be invistigating why the configuration was not simply carried forward Sep 08 11:19:31 avoiding all this pain Sep 08 11:20:11 avoiding the pain in a real way would mean TI hires 100 monkeys to upstream all that stuff :) Sep 08 11:20:18 heh there is that Sep 08 11:20:28 we still should have avoided this, not happy Sep 08 11:45:03 * ogra takes a break Sep 08 12:39:50 ogra: hi... when is the next daily image being planned? the one with es2.0 support, i mean. Sep 08 12:51:10 persia: hi! any update on the pulse bug #631362? Sep 08 12:51:11 ndec: did you get your audio tested ? Sep 08 12:51:12 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 Sep 08 12:51:30 hi prpplague... I am just doing it ;-) I can use HMDI, but not headset. Sep 08 12:51:47 ndec: which board version do you have? Sep 08 12:52:00 prpplague: the latest and greatest ;-) Sep 08 12:52:08 prpplague: 8-layer, es2.0 Sep 08 12:52:16 ndec: any errors? Sep 08 12:52:41 prpplague: the speaker-test command you sent works for HMDI, I can alsa play gst stream through alsasink to HDMI. Sep 08 12:54:26 prpplague: but the same command fail with HS. speaker-test tells me : playback open error: -16, device/resource busy Sep 08 12:55:27 ndec: most likely you have some other userspace apps accesing the device Sep 08 12:55:30 brb Sep 08 13:04:23 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) Sep 08 13:05:13 prpplague: ok. might be. I am doing an upgrade, when it's done, I will kill GDM and restart the same test. Sep 08 13:06:03 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 Sep 08 13:06:41 ogra: great. I just wanted to know if it will be committed in 10.10.. looks like yes. Sep 08 13:06:51 yes, promised :) Sep 08 13:09:01 * ogra makes amitk famous :) Sep 08 13:10:35 ogra: or infamous (since the debuild recipe for ubuntu kernels fails due to perf dependency) :-/ Sep 08 13:10:53 bah Sep 08 13:11:19 should i drop it from the topic again ? or is someone working on a fix for that ? Sep 08 13:11:22 ogra: will need to fix that with some dpkg-cross instructions Sep 08 13:11:34 k Sep 08 13:11:54 ogra: the blog post itself might be useful to advertise the toolchain Sep 08 13:12:02 right, thats what i thought Sep 08 13:12:14 I'll update the exact kernel instructions Sep 08 13:12:18 great Sep 08 13:12:35 in case the url changes through that, please tell me, i'll update it Sep 08 13:15:12 morning Sep 08 13:15:35 ndec: hey, you were having display issues yesterday Sep 08 13:15:48 yesterday ? Sep 08 13:16:52 Est-ce que ndec est par ici? Sep 08 13:17:10 ndec: "We are waiting for the chair person to join" :) Sep 08 13:17:18 lol Sep 08 13:17:22 * ogra knows that feeling Sep 08 13:17:38 she has such a nice voice :) Sep 08 13:18:11 ogra: *Oups* Wrong chan. Now you know that we have our own problems... ;) Sep 08 13:18:19 heh Sep 08 13:18:42 ogra: (She indeed has a nice voice.) Sep 08 13:24:34 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... Sep 08 13:24:40 ogra: ^ this issue Sep 08 13:24:47 rsalveti: thanks for the follow up... Sep 08 13:24:52 * rsalveti wants to know with which kernel Sep 08 13:25:19 rsalveti, yeah i was just jokiag about the "yesterday" he always has these issues :) Sep 08 13:25:24 *joking Sep 08 13:25:29 rsalveti: i am using sebjan's kernel, es2.0, 8-layer. this should be equivalent to what has been uploaded today Sep 08 13:25:40 * rsalveti still has lots of emails and backlog to ready Sep 08 13:25:46 ndec, i think we are one patchset behind Sep 08 13:25:46 don't you have the same issue? Sep 08 13:26:07 let me check our git tree Sep 08 13:26:16 ogra: cooloney pull request was uploaded this morning, i haven't checked but it might be building now Sep 08 13:26:18 the merge request was only filed today Sep 08 13:26:36 we got an updated tree already Sep 08 13:26:50 i think whats building now wasnt a fresh checkout, just a packaging fix from apw Sep 08 13:27:56 ndec, ogra, yep ... not his pull request. if he had mentioned it 2 hours ago we might have put it in the same one! Sep 08 13:27:59 ogra: .11 is building now, and has all patches for 6 and 8-layer, and es2 Sep 08 13:28:19 yep, but we're still behind some pm fixes Sep 08 13:28:26 right Sep 08 13:28:43 but our current kernel will work fine for es2 6 and 8 layers Sep 08 13:29:01 ndec: the issue I'm having is: http://www.flickr.com/photos/rsalveti/4932601965/ Sep 08 13:29:11 because of the disconnect/connect during hdmi detection Sep 08 13:29:41 ndec, i was referring to the pull request from 14:49 today (local time) ... all other patches should be in Sep 08 13:29:42 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 Sep 08 13:31:40 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). Sep 08 13:32:57 ndec: hm, interesting Sep 08 13:33:25 can you boot with omapdss.debug=1 and check both boot logs? Sep 08 13:33:53 * rsalveti never tried to turn on his monitor after boot Sep 08 13:34:01 * rsalveti will also try that Sep 08 13:34:33 if gdm (X) is fine, then it got the correct resolution before opening it Sep 08 13:35:34 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) Sep 08 13:36:02 ogra: hm, no new images to download :-) Sep 08 13:36:24 rsalveti, yeah, kernel package breakage Sep 08 13:36:50 rsalveti, we should have new images by end of my day so you have something to play with for your afternoon Sep 08 13:36:55 hm, that's why a lot of apw's commits Sep 08 13:37:03 cool Sep 08 13:37:07 right, he saved out butts :) Sep 08 13:37:11 *our Sep 08 13:37:16 :-) Sep 08 13:37:36 apw is our new amitk *g* Sep 08 13:37:38 yeah its very difficult to test outside a real build Sep 08 13:37:47 i hope its all resolved now Sep 08 13:48:17 sakoman: cool, thanks for including the patch Sep 08 13:48:33 now just need to add it to jcrigby linaro's package Sep 08 13:49:15 rsalveti: i will share the dssdebug later, i am doing an apt-get upgrade ;-) Sep 08 13:49:18 ndec: haha, got it working like you! Sep 08 13:49:19 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) Sep 08 13:49:37 ndec: after turning it on later, it worked fine! Sep 08 13:49:44 * rsalveti can now check his logs Sep 08 13:49:45 rsalveti: cool... it's actually funny that I found out this use case ;-) Sep 08 13:50:09 ogra: es2.1 support? Sep 08 13:50:17 rsalveti, yep Sep 08 13:50:20 when are we getting es2.1? Sep 08 13:50:33 beginning of oct. i'd guess Sep 08 13:50:33 rsalveti: I'm going to try to sneak that in upstream as a single patch Sep 08 13:50:35 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 ;-) Sep 08 13:50:41 oh, ok, the "final" one Sep 08 13:50:47 rsalveti: if they complain I'll break it back into two Sep 08 13:50:49 right Sep 08 13:50:57 sakoman: yep, saw that, cool Sep 08 13:51:48 ndec: hah, cool :-) Sep 08 14:15:09 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) Sep 08 14:20:06 lool: let see if I can tempt apw for this ^^^ ;) Sep 08 14:21:18 as in a simple if and set? that doesn't sound too onerous Sep 08 14:26:11 apw: pretty much Sep 08 14:26:16 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=... Sep 08 14:27:03 In fact, you might want to CROSS_COMPILE ?= in the if body as this allows overriding CROSS_COMPILE as amitk did Sep 08 14:27:04 lool: but what is the std. prefix for CROSS_COMPILE? Sep 08 14:27:10 So that one can still use non-standard toolchains Sep 08 14:27:32 (arm-none-linux-gnueabi- from CodeSourcery comes to mind, it's not the same triplet as the Debian arch expects) Sep 08 14:27:42 amitk: I don't understand the question Sep 08 14:27:55 lool: I use CROSS_COMPILE=arm-linux- (by linking arm-linux-gnueabi-* to arm-linux-*) Sep 08 14:28:15 amitk: Oh, you should CROSS_COMPILE=arm-linux-gnueabi- Sep 08 14:28:23 arm-linux- is incorrect Sep 08 14:28:49 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 Sep 08 14:29:15 and the upstream toolchain will prefix all tools with the triplet in cross-toolchains, so CROSS_COMPILE should be triplet suffixed by a - Sep 08 14:29:22 lool: where can I find a good explanation of the 'triplet'? I assume the triplet is the std. prefix Sep 08 14:32:17 isn 't that triplet some kind of gnu standard Sep 08 14:32:38 amitk: GNU triplet is what you configure a toolchain with Sep 08 14:32:43 let me find some referene Sep 08 14:32:50 a triplet is a standard gnu config string Sep 08 14:33:27 it's heavily used to differentiate between the build, host, and target system Sep 08 14:35:20 apw, amitk: I'm unable to point at a concise definition; multiple places refer to these, and have various lists Sep 08 14:35:37 http://gcc.gnu.org/install/configure.html explains --host/--build/--target which all take triplets Sep 08 14:35:51 triplets values are best defined in configure.ac Sep 08 14:35:57 http://gcc.gnu.org/install/specific.html has some lists of targets Sep 08 14:36:07 http://gcc.gnu.org/onlinedocs/libstdc++/manual/internals.html explains some components of the triplet Sep 08 14:36:17 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 Sep 08 14:36:31 most other apps use just build and host Sep 08 14:47:18 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 Sep 08 14:47:26 same for -ld, -objdump etc. Sep 08 14:48:16 lool: I can talk about config triplets all you want, what exactly do you need to do ? Sep 08 14:48:21 lool: sounds complicated policy. I'll go through your links... Sep 08 14:48:28 hey guys Sep 08 14:48:40 rsavoye: just what they are and why we should care when we set CROSS_COMPILE :) Sep 08 14:48:41 rsavoye: I don't think we need any detail; amitk and apw needed some kind of primer on the concept Sep 08 14:48:47 anyone noticed a launchpad bug or anything that describes X taking up 90% of the CPU *all* the time? Sep 08 14:48:54 amitk: It's just a toolchain input to configure it Sep 08 14:49:06 amitk: the output is that the tools are at $triplet-tool :-) Sep 08 14:49:23 right, so other configure scripts can find their tools Sep 08 14:49:26 amitk: CROSS_COMPILE is a linux var, it's also used in other projects like U-Boot, but it's not extremely wide-spread Sep 08 14:49:51 Neko: This can happen for a variety of reasons Sep 08 14:50:07 the reason here seems to be that I started X and opened a terminal Sep 08 14:50:12 it just hit 80% Sep 08 14:50:14 which is where issues like arm-linux-eabi or arm-linux-gnueabi are important Sep 08 14:50:19 I close the terminal and it stays at 80% even if I'm on another VT Sep 08 14:50:27 X is spinning wildly somewhere Sep 08 14:51:13 https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers-180/+bug/617994 <-- this does help btw (the disable lcd font smoothing thing) Sep 08 14:51:15 Launchpad bug 617994 in nvidia-graphics-drivers-180 (Ubuntu) "Slow performance and high CPU usage on Maverick (affects: 11) (heat: 58)" [Undecided,Confirmed] Sep 08 14:51:16 Neko: you could try tracing it Sep 08 14:51:30 Neko: it could be anything, like a X client doing a lot of server requests Sep 08 14:51:54 what do I use to trace X activity :/ Sep 08 14:52:06 Neko, i'd swing by ubuntu-x they'll be better equiped to answer Sep 08 14:52:12 okay Sep 08 15:06:35 ndec: any luck on the audio? Sep 08 15:06:52 prpplague: not yet... upgrade is taking forever... Sep 08 15:07:41 ndec: np, i'll be online all day if you need assistance Sep 08 15:13:14 so, has anyone had success in making arm images that run w/ qemu in maverick ?? and if so, can I download one ? :) Sep 08 17:27:24 ogra, those images are built Sep 08 17:35:11 He may be monitoring on his other system. ogra_cmpc ^^^ Sep 08 17:43:07 apw, thanks, but publishing will take a while Sep 08 17:44:59 * ogra_cmpc waits for .11 to show up at http://ports.ubuntu.com/pool/main/l/linux-ti-omap4/ Sep 08 17:46:18 Will this also fix the missing headers issue? Sep 08 17:46:35 its meant to only sort out those headers Sep 08 17:47:08 GrueMaster, the missing headers were fixed two days ago with the last netbook-meta upload Sep 08 17:47:29 The following packages have unmet dependencies: Sep 08 17:47:29 linux-headers-2.6.35-903-omap4 : Depends: linux-ti-omap4-headers-2.6.35-903 but it is not installable Sep 08 17:47:31 * ogra_cmpc thinks GrueMaster means a different issue than apw :) Sep 08 17:47:42 GrueMaster, yeah, thats apw's fix Sep 08 17:47:48 ahh Sep 08 17:47:49 Cool Sep 08 17:48:02 oh, actually i might have introduced it Sep 08 17:48:24 the omap4 headers were missing completely from the images until monday Sep 08 17:49:10 apw, so that breakage was always hidden, it could as well have been present from day one, we just didnt see it Sep 08 17:49:26 i.e. not introduced with the version change Sep 08 17:50:17 indeed, i see those two issues as one big "headers is bust" problem Sep 08 17:50:34 as you say the bad linkage was hidden by the bad meta linkage and the bad everything else Sep 08 17:50:43 heh, yeah Sep 08 17:50:52 ogra_cmpc, is ports publish slower than normal publish ? Sep 08 17:51:07 about 45 min at least Sep 08 17:51:12 dammit Sep 08 17:51:39 its a bit slower than the main archive ... Sep 08 17:51:56 even though persia always claims thats supposed to be fixed Sep 08 17:54:03 Will the next build have the new xloader & uboot? I tried 20100906.2 on ES2 8L, but it hung with an xloader crash. Sep 08 17:54:50 (could also possibly be my desktop system & flashing SD cards.) Sep 08 17:55:32 i would blame your desktop Sep 08 17:55:59 just installing the linux-image from the archive gets me a working system Sep 08 17:56:17 though ... hmm, i'm using 6 layer here Sep 08 17:56:34 since 8 layer has USB issues Sep 08 17:56:39 Yea, I was afraid of that. There appears to be a bug in my system that requires me to reboot weekly. Sep 08 17:57:25 Otherwise the SD i/O is very slow on my USB multicard reader. Sep 08 17:58:19 apw, BAH !!, we're stuck in NEW Sep 08 17:58:39 https://edge.launchpad.net/ubuntu/maverick/+queue Sep 08 17:58:50 ogra_cmpc, wtf .... arg i guess the headers package may not have been seen before Sep 08 17:58:57 yeah Sep 08 17:58:58 i'll let you wake up an admin! Sep 08 18:01:17 GrueMaster: it should work with your es 2 8 layer Sep 08 18:01:26 linux-headers-2.6.35-903_2.6.35-903.11_armel.deb (10.1 MiB) NEW ... Sep 08 18:01:27 hmm Sep 08 18:01:29 the new x-loader got updated at monday Sep 08 18:01:33 says universe too Sep 08 18:01:46 I'll try again after a desktop reboot. Sep 08 18:02:52 GrueMaster: with the latest x-loader you should at least boot your kernel Sep 08 18:03:47 ogra_cmpc, looks like its what i'd expect that file to look like at least Sep 08 18:03:54 yeah Sep 08 18:04:05 i'm just worried about universe Sep 08 18:04:12 requires special treatment Sep 08 18:04:22 up to the AA though Sep 08 18:04:34 i pinged the admins of the day in -devel Sep 08 18:05:08 ogra_cmpc, thats the default isn't it, anywhere else is an override set on accept Sep 08 18:05:34 right, but all other binaries of that package are in main already Sep 08 18:05:50 easily overseen that one goes to universe Sep 08 18:06:12 yeah Sep 08 18:06:28 i think kernel accept is scripted somehow, so hopefully its sorted Sep 08 18:06:35 yep Sep 08 18:06:45 we'll just have to wait Sep 08 18:07:08 * GrueMaster is good at waiting. Sep 08 18:07:20 Lots of experience. Sep 08 18:07:26 lol Sep 08 18:18:08 ogra_cmpc: Could you trigger a dove build? NCommander can't ssh in. Sep 08 18:19:21 GrueMaster, running Sep 08 18:19:37 thank you ogra_cmpc Sep 08 18:20:10 90min ... Sep 08 18:21:05 ok Sep 08 18:21:27 * GrueMaster sets his tea timer accordingly. Sep 08 19:00:00 GrueMaster, NCommander failed Sep 08 19:01:02 sigh. Sep 08 19:03:13 :D Sep 08 19:04:11 ogra_cmpc: Not seeing an email. what was the failure? Sep 08 19:04:21 check the logs Sep 08 19:05:37 And they would be located.... Sep 08 19:05:50 http://people.canonical.com/~ubuntu-archive/livefs-build-logs/maverick/ubuntu-netbook-dove/20100908/ is empty Sep 08 19:06:37 grrr. Omap4 headers?!? Really? Sep 08 19:08:12 .... Sep 08 19:08:14 *argh* Sep 08 19:12:02 lol Sep 08 20:44:48 I just installed ubuntu lucid in beagleboard and logged in terminal Sep 08 20:45:15 which command shoud I type to lunch gui Sep 08 20:45:23 ? Sep 08 20:45:42 *launch Sep 08 20:46:02 beaglee: Where did you download the image from? Our live image should boot right into the netbook launcher. Sep 08 20:46:37 http://elinux.org/BeagleBoardUbuntu#RootStock:_Build_an_Ubuntu_root_file_system Sep 08 20:47:20 i build with rootstock and including xfce4,gdm,xubuntu-gdm-theme,xubuntu-artwork Sep 08 20:47:22 Oh. Well, that is one way to do it. Try "sudo apt-get install ubuntu-netbook" Sep 08 20:47:43 I don't know much about xfce. Sep 08 20:48:05 You could also just try startx Sep 08 20:48:14 ok Sep 08 20:48:49 did'nt work Sep 08 20:49:55 ubuntu Sep 08 20:50:01 argh, wrong terminal :-) Sep 08 20:50:02 ok. Try "sudo tasksel" and select an installation type. Sep 08 20:50:44 hm, you installed gdm, so trying to load it seems the way to go Sep 08 20:54:21 didn't work neither Sep 08 21:14:56 ogra_cmpc, any luck with finding an AA ? Sep 08 21:29:33 apw, yes, waiting for publisher now Sep 08 21:30:58 ogra_cmpc, excellent, it was there just a 10 mins or so ago, glad to see it gone Sep 08 21:31:25 well, colin said he did it Sep 08 21:33:16 he is a star Sep 08 21:33:23 yep Sep 08 21:35:43 ogra_cmpc, when do the CDs build, in a couple of hours ? will you let it run naturally ? Sep 08 21:36:37 1:55 UTC Sep 08 21:37:05 i'll monitor the archive though and trigger a build earlier Sep 08 21:44:21 rsalveti: I'm going back through my backlog of todo's & retests, and was retesting bug 566645. Doesn't appear to have been fixed. Sep 08 21:44:27 Launchpad bug 566645 in linux-ti-omap (Ubuntu Maverick) (and 2 other projects) "OTG configuration is broken on omap kernel (affects: 4) (dups: 1) (heat: 52)" [High,Fix released] https://launchpad.net/bugs/566645 Sep 08 21:44:51 No errors, but also no OTG functionality. Sep 08 21:45:31 GrueMaster: hm... with maverick? Sep 08 21:45:52 Yesterday's image. 20100806.2 Sep 08 21:47:13 GrueMaster: ok, because of bug 608312 Sep 08 21:47:15 Launchpad bug 608312 in linux (Ubuntu) "Usb host mode on OTG doesn't work on Maverick with BeagleBoard (affects: 1) (heat: 89)" [High,In progress] https://launchpad.net/bugs/608312 Sep 08 21:47:23 so not having an oops at maverick is a "fix" Sep 08 21:47:36 but to make OTG work we have this other bug Sep 08 21:47:48 GrueMaster: another test is to check if this was changed for lucid Sep 08 21:48:30 Ok. Sep 08 21:48:43 No oops, so I guess that is fixed at least. Sep 08 21:48:51 GrueMaster: yep Sep 08 21:58:49 GrueMaster, rsalveti: so USB client is working? Sep 08 21:59:43 Still need to test that on beagle/XM. Sep 08 22:00:03 persia: just usb gadget I think Sep 08 22:00:12 host is still broken at otg (using beagle) Sep 08 22:00:17 Err, right. I meant "gadget" :) Sep 08 22:00:49 Well, cool! That at least gives us network. Do we have any other gadget software? Sep 08 22:00:50 That's what I meant as well. Added to my todo testing. Sep 08 22:02:27 GrueMaster, By "no OTG functionality", you mean gadget isn't working? Sep 08 22:03:10 I plugged in my OTG cable and should be able to use a USB keyboard or see a USB drive attached. Nothing at this time. Sep 08 22:03:19 GrueMaster: but this is host Sep 08 22:03:26 Oh, that's host. Yeah, 608312 Sep 08 22:03:34 It does switch from b_idle to a_idle. Sep 08 22:03:47 it should for a_host Sep 08 22:03:51 I have not tested gadget stuff. Sep 08 22:03:59 yep, never used :-) Sep 08 22:04:05 It's the connection of a [A <-> mini_B] cable between some host and the device that tests gadget. Sep 08 22:04:12 just with my n900, but no more than that Sep 08 22:04:39 Last time I tested USB OTG was at Intel working on Moblin 1.0. Sep 08 22:04:49 * persia used to use it all the time for usb0 networking, but hasn't played in a couple years Sep 08 22:04:49 * GrueMaster is kinda rusty. Sep 08 22:05:07 I have nothing that supports it. Sep 08 22:05:10 GrueMaster, For Moblin 1.0, we never got gadget working acceptably at all. Sep 08 22:05:24 I know. Sep 08 22:05:45 SCH driver issues. Sep 08 22:05:52 * rsalveti calls it a day, will be back in some hours Sep 08 22:06:27 Oh, was that it? I remember arguing about lack of software support for various blue-sky use cases, and didn't realise that either test cases were created, or concrete problems existed at the kernel layer. Sep 08 22:06:28 It would work somewhat with a Windows PC on the other end. Sep 08 22:07:01 But it was unreliable at best. Sep 08 22:08:23 That was when usb_gadget support was in its infancy. Sep 08 22:20:40 Hrm? The userspace stuff hasn't seemed to get much innovation since 2001 or so, and was working fine then. Have there been improvements kernelside since? Sep 08 22:21:34 I would assume so. I really don't know. It may have just been an SCH issue that I was working with back then. Sep 08 22:21:47 I have never tested OTG on arm. Sep 08 22:32:06 apw, fyi, build survives the header install Sep 08 22:35:31 So, does this mean I'll get new images for omap4 soon? Sep 08 22:46:15 GrueMaster, Needs someone to respin an image. You might ask in -release in case any of those with access to the button are around. Sep 08 22:46:42 Otherwise it will automatically get pushed in about 2 hours Sep 08 22:47:05 At this point, I can wait. I have other things to look at until then. Sep 08 22:47:27 Besides, it is almost 4pm my time. EOD is coming soon. Sep 08 23:13:39 GrueMaster, only if a miracle happens and oem-config gets installable Sep 08 23:14:10 we now fail on oem-config/ubiquity Sep 08 23:14:16 heh. Figures. Sep 08 23:14:35 but at least all header issues are fixed Sep 08 23:16:42 anyway, bedtime Sep 08 23:18:47 g'night Sep 08 23:32:46 'ello Sep 08 23:33:01 ogra: You should really get out more **** ENDING LOGGING AT Thu Sep 09 02:59:57 2010