**** BEGIN LOGGING AT Tue Mar 09 02:59:58 2010 Mar 09 03:46:33 I've a tarball of the root file system Mar 09 03:46:41 How to transfer it to the board? Mar 09 03:46:53 And how to extract it there? Mar 09 03:47:16 jussi01, ? Mar 09 03:49:00 What is actually a uImage? Mar 09 03:58:34 !hawkboard Mar 09 03:58:35 Factoid 'hawkboard' not found Mar 09 03:58:46 !angstrom Mar 09 03:58:48 Factoid 'angstrom' not found Mar 09 03:59:30 ANYONE CAN HELP ME OR ATLEAST RESPOND??? Mar 09 09:02:43 Bother. Had to be a Tuesday :( Mar 09 09:42:48 persia: they call it stormy monday, but tuesday's just as bad? :) Mar 09 09:43:42 kblin: No, it's that I like to help folk, but tend not to be around in the 3-9 UTC range on Tuesdays. Most days that range is quiet anyway, but not today. Mar 09 09:44:44 And nobody else ever seems to answer questions at those hours any day, so if someone comes by on Tuesdays looking for help, I wish they'd picked a different day :) Mar 09 09:46:14 I see :) Mar 09 11:29:29 * ogra pokes the builder "come on glib ... paddle faster !" Mar 09 11:32:19 boing Mar 09 11:33:29 ogra: how can we best produce a log of info about failed/succeeded image builds? Mar 09 11:33:43 asac: We can get that from Soyuz. What do you need? Mar 09 11:33:47 image or livefs builds ? Mar 09 11:33:52 at best both Mar 09 11:33:52 asac: And how do you want it presented? Mar 09 11:33:59 i would think image comprises livefs Mar 09 11:34:07 so if livefs fails and image suceeds we have a problem Mar 09 11:34:12 Oh, images. We can get those from people.canonical.com Mar 09 11:34:15 persia: a daily log table Mar 09 11:34:31 like: row: date / column: arch/subarch Mar 09 11:34:34 asac: Why is it a problem if livefs fails and image succeeds? That happens for most livefs failures. Mar 09 11:34:37 and then just "green" ... "red" Mar 09 11:34:42 with link to the logs if available Mar 09 11:35:04 i guess that would either need a script that parses people.u.c or a mail filter and a generic mailbox for the build failures Mar 09 11:35:06 persia: how does image succeed if no livefs is produced? Mar 09 11:35:09 That's not hard to implement, but it'd be easiest to implement *inside* the build-system. Mar 09 11:35:15 asac: It uses the old livefs. Mar 09 11:35:17 right thats what i thought (inside) Mar 09 11:35:34 persia, we have the mails ... we could add a ML to ubuntu-armel Mar 09 11:35:47 the prob is that you cant filter them by arch easily Mar 09 11:35:49 i think we need three data sources published: 1. cron job publishes info about started /scheduled build (so we can figure if something broke seriously Mar 09 11:35:52 at least server side Mar 09 11:36:04 2. log info about livefs failure/success Mar 09 11:36:08 the cronjob never changes Mar 09 11:36:11 3. log info about image failure/success Mar 09 11:36:13 we know when it starts Mar 09 11:36:32 2 and 3 are alreasdy existing Mar 09 11:36:34 ogra: yes, but something has to seed the info Mar 09 11:36:43 ogra: where? Mar 09 11:36:44 just not merged/parsed automatically Mar 09 11:36:49 asac: Let's get the build system to publish a summary in a machine-parsable format daily, and then we can use that to construct reports as we like. Mar 09 11:36:50 where is the raw data Mar 09 11:36:58 with just date/imageid: FAIL/SUCCESS Mar 09 11:37:01 for the livefs on the live builder Mar 09 11:37:10 for the image builds its on antimony Mar 09 11:37:15 persia: yes. just wanted to understand what parts we need Mar 09 11:37:24 ogra: what format do those files have? Mar 09 11:37:27 what you see on peole is an exact mirror of either of them Mar 09 11:37:30 txt Mar 09 11:37:34 *people Mar 09 11:37:37 and yes, i figure that we probably hav that. i just want it to be exported in a parsable fashion Mar 09 11:37:42 ogra: where? Mar 09 11:37:54 http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ Mar 09 11:37:58 for the livefs Mar 09 11:37:59 those are the logs Mar 09 11:38:05 those dont say: "fail/success" Mar 09 11:38:12 thats not that useful Mar 09 11:38:12 http://people.canonical.com/~ubuntu-archive/cd-build-logs/ for the images Mar 09 11:38:16 we need to publish the exit code Mar 09 11:38:19 with date Mar 09 11:38:23 as i said, you need to parse them Mar 09 11:38:34 for the image builds there exists a mail function Mar 09 11:38:41 well. thats too difficult. too many things can happen Mar 09 11:38:46 antimony mails about failures Mar 09 11:38:48 if it would print "exited (code=X) Mar 09 11:38:48 " Mar 09 11:38:50 that would be ok Mar 09 11:38:51 but thats not easy to filter Mar 09 11:39:06 May I? Mar 09 11:39:07 since it only mails per-flavour, not per arch Mar 09 11:39:09 right. in short. that info isnt there ;) Mar 09 11:39:20 it is Mar 09 11:39:22 makes no sense to write an ever greowing parser of the logs Mar 09 11:39:30 persia: go ahead ;) Mar 09 11:39:35 its just not broought to the right people atm :) Mar 09 11:39:37 So, let's alter the scripts that build stuff to make a shortlog, and publish the shortlog. Mar 09 11:39:48 ogra: this discussion is about what to do ;) Mar 09 11:39:51 We can then parse the shortlogs, and build the reports we want. Mar 09 11:40:03 persia: shortlog is good. or a good parseable tag at the end of the log Mar 09 11:40:08 as i said, thats already there for the image builds Mar 09 11:40:10 like: EXITCODE====1 ;) Mar 09 11:40:21 asac: Can't do that: the logs are per-flavour Mar 09 11:40:21 ogra: its not there, because i dont see it on the web Mar 09 11:40:33 asac, you could get it by mail Mar 09 11:40:43 ogra: right. but thats not the preferred way Mar 09 11:40:46 but as i said above its lacking filtering on subarches Mar 09 11:40:51 we want something parsable through http ;) Mar 09 11:41:00 persia: you say there is no common code? Mar 09 11:41:11 asac, right Mar 09 11:41:14 or you dont want to add that to logs of other flavours? Mar 09 11:41:17 its only per flavour Mar 09 11:41:21 not per subarch Mar 09 11:41:28 asac: I say that the logs don't currently have enough information in a format that is easily extracted. Mar 09 11:41:38 persia: yes. Mar 09 11:41:54 so we alter the scripts to either add something easily parsable there Mar 09 11:41:57 i.e. all ubuntu-netbook failures are the same atm ... there is no distinction between i386, ppc, armel etc Mar 09 11:41:57 or we produce shortlogs ;) Mar 09 11:42:09 asac: I suggest that publishing a separate shortlog is likely to better enable lots of uses of this data, and will cost less bandwidth than expensive log parsing. Mar 09 11:42:24 ogra: That's not precisely the case, although they are in the same log. Mar 09 11:42:27 ack ... if that doesnt kick off loads of things Mar 09 11:42:28 to do Mar 09 11:42:32 and coordinate i am for shortlogs Mar 09 11:42:41 RIght. Mar 09 11:42:56 its quite complex and requires a lot of debian-cd hackery Mar 09 11:43:03 persia: can you check how much work that would be ? Mar 09 11:43:23 effectively what you want it to turn the mial function into a spit-out-log-to-http function Mar 09 11:43:40 but you need to additionally write a filtering for arch/subarch Mar 09 11:43:46 that feels too difficult Mar 09 11:44:00 asac: To expose the shortlogs? Sure. Mar 09 11:44:03 but thats the place to add it Mar 09 11:44:07 i want to fix the place that currently execs the image/livfs process Mar 09 11:44:14 that place should just check exit code Mar 09 11:44:15 debian-cd has that feature already Mar 09 11:44:16 and produce a log Mar 09 11:44:23 ogra: You're complicating things. let's get shortlogs, and parse them in some other script. Mar 09 11:44:25 it simply doesnt filter and doesnt spit out http Mar 09 11:44:34 if it already has that place, then its easy to do ;) Mar 09 11:44:53 yes, it just mails the short logs Mar 09 11:44:56 i agree with persia ... lets let him check ... i would epxect this to be trivial if someone knows the details Mar 09 11:45:05 * ogra knows the details Mar 09 11:45:14 i worked through that with StevenK before Mar 09 11:45:17 if we already send the mails, then its really easy Mar 09 11:45:18 more than one time Mar 09 11:45:26 just push them in a file ;) Mar 09 11:45:40 and we decided that adding the filtering was quite complex... Mar 09 11:45:52 Right. We don't need the filtering. Mar 09 11:45:56 We just need shortlogs. Mar 09 11:46:14 that wont help much for armel Mar 09 11:46:22 Yes it will. Mar 09 11:46:27 sinc eits still just by flavour Mar 09 11:46:29 I can write a parser for shortlogs in a day. Mar 09 11:46:55 As long as the shortlog has a machine-readable format. e.g. flavour:arch:result Mar 09 11:47:08 (probably less than a day, but still) Mar 09 11:47:10 date Mar 09 11:47:11 ;) Mar 09 11:47:16 or buildid Mar 09 11:47:17 * ogra doesnt remember anymore and tries to dug up some edubuntu failure mails Mar 09 11:47:21 needs to be a column Mar 09 11:47:53 the mail contains the full log :/ Mar 09 11:48:02 for all arches Mar 09 11:48:11 so that wont help without having a parser Mar 09 11:48:32 its like 1MB big only for a failed edubuntu build for all arches Mar 09 11:48:34 ogra: Right. I don't want the mail. I want to be able to get shortlogs from people.canonical.com/~ubuntu-archive/*-build-logs/... Mar 09 11:48:50 persia, so you screen scarep the files ? Mar 09 11:48:51 and I want the logs to go in the appropriate dated directories, etc. Mar 09 11:48:54 *scrape Mar 09 11:49:18 we can make a good html page out of such shortlogs and rss feeds etc. Mar 09 11:49:21 ogra: No. I don't want HTML. I want files specifically designed to be consumed by a program at deterministic URIs. Mar 09 11:49:28 i really would like to have info about kicked off builds though Mar 09 11:49:30 e.g. just build-id Mar 09 11:49:43 in that way we can see if stuff is overdue and display a big burning icon ;) Mar 09 11:49:51 but thats nice to have ;) Mar 09 11:49:59 cron gets that info ... (or whoever fires off a build manually) Mar 09 11:50:24 its two lines per flavour Mar 09 11:50:37 right. so lets add that to the wanted feature list for shortlogs Mar 09 11:50:38 asac: That's less interesting, because of how it works. Mar 09 11:50:53 build started on livebuilder at 12:34:56 etc Mar 09 11:51:03 build succeeded on livebuilder at 15:34:56 etc Mar 09 11:51:17 i dont mind how it happens ;) .... just want to see a big burning state on the final HTML page if a build never lead to a livefs etc. Mar 09 11:51:22 thats what you get if you fire off a manual build Mar 09 11:51:22 or never even lead to a log Mar 09 11:51:36 and these lines whould be in the logs if cron execs them Mar 09 11:51:41 *should Mar 09 11:51:56 yeah. that thing could create a shortlog entry then Mar 09 11:52:00 right Mar 09 11:52:12 but i dont think we have access to the logs cron writes to Mar 09 11:52:19 at least not the cdimage team Mar 09 11:52:28 cjwatson would know Mar 09 11:52:50 yes. thats the other question. we need to get the logs we produce to a public location Mar 09 11:52:52 * ogra checks on antimony Mar 09 11:53:14 maybe it just publishes a full dir or something that is produced by the parts Mar 09 11:53:20 that would make things easy ;) Mar 09 11:53:28 if it just copies the log there needs some work done Mar 09 11:54:08 nope, no access to syslog or messages on the builder machine Mar 09 11:54:49 i dont see why we want to access those logs Mar 09 11:55:04 because they have the one line info you want from cron Mar 09 11:55:06 we would need to produce a log file wherever the main log goes Mar 09 11:55:29 ogra: right the hook should happen in whatever script is run rather than relying on that Mar 09 11:55:37 its crond Mar 09 11:55:47 what script does that run? Mar 09 11:56:05 anyway, details. lets wait for persias eval ;) Mar 09 11:56:14 What eval? Mar 09 11:56:22 ARCHES='armel+imx51 armel+dove' buildlive ubuntu-netbook && ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live Mar 09 11:56:26 thats our cron line Mar 09 11:56:26 persia: checking what it would take to get shortlogs Mar 09 11:56:37 e.g. what needs to be done, how much time is it etc. Mar 09 11:56:55 Oh, sure. I was just going to bother a different member of the cdimage team. ogra is a fair candidate. Mar 09 11:56:56 thought you signed up for evaling that ;) Mar 09 11:56:56 so you need to edit buildlive for putting the info into some place additionally to writing to stdout Mar 09 11:57:09 ogra: yep Mar 09 11:57:21 ogra: if you manually kick a build off it also runs buildlive? Mar 09 11:57:21 additionaly you need to edit for-project Mar 09 11:57:26 ogra: That's just >&3 though. Mar 09 11:57:31 what about buildalternative etc.? do such scrpts exist? Mar 09 11:57:32 which will be a lot more complicated Mar 09 11:57:47 for-project is highly modular Mar 09 11:58:22 asac, no, for-project does everything realted to image building ... that includes alterante and live Mar 09 11:58:25 right. but if there is an initial point of entry that feels like the right place to put the "started" log Mar 09 11:58:38 for-project might be a candidate? Mar 09 11:58:41 buildlive just creates the livefs Mar 09 11:58:50 we also want to know about that ;) Mar 09 11:58:55 you need to edit both if you want info for both+ Mar 09 11:58:58 yeah Mar 09 11:59:05 we want started for buldlive and started for for-project Mar 09 11:59:10 buildlive should be easy to achive Mar 09 11:59:12 and whatever other variant might exist Mar 09 11:59:26 i think buildlive would be most essential Mar 09 11:59:29 its only these two Mar 09 11:59:30 thats the starting point Mar 09 11:59:45 persia, buildlive is in livecd-rootfs iirc Mar 09 11:59:47 then with the "exit" results for the livefs build and the image fs production scripts Mar 09 11:59:53 that would give us all we need i think Mar 09 12:00:00 that should be the easiest Mar 09 12:00:20 asac: It's not really exit codes: it's more complex than that, but that's the idea. Mar 09 12:00:37 ogra: So, how much effort does this shortlog creation involve? Mar 09 12:02:31 oh, buildlive isnt in livecd-rootfs, i lied :) Mar 09 12:02:39 thats BuildLiveCD Mar 09 12:02:50 * ogra checks on antimony Mar 09 12:30:05 ogra: its there, its installed into /usr/share (and it was in the source package) Mar 09 12:30:28 NCommander, hmm ? Mar 09 12:30:42 ogra: BuildLiveCD is in the livecd-rootfs package Mar 09 12:30:54 sure Mar 09 12:31:05 thats what i said above Mar 09 12:31:12 ogra: you just said it wasn't O_o; Mar 09 12:31:37 * NCommander makes another interesting OOo discovery Mar 09 12:31:37 Doesn't matter. Mar 09 12:32:00 Can anyone help me to install on hawkboard? Mar 09 12:32:22 oh, buildlive isnt in livecd-rootfs, i lied :) Mar 09 12:32:22 thats BuildLiveCD Mar 09 12:32:25 napster: That's an ARM920T, right? Mar 09 12:32:27 NCommander, ^^^ Mar 09 12:32:54 persia, I think its OMAP L138 Mar 09 12:33:11 ogra: oh, I read that as you typoed on buildlive, and meant that BuildLiveCD isn't in livecd-rootfs Mar 09 12:33:15 EPARSERFAIL Mar 09 12:33:18 heh Mar 09 12:33:51 buildlive is part of debian-cd i think Mar 09 12:33:58 napster: OK. That can run Ubuntu Jaunty, but nothing newer, and requires a custom kernel. Mar 09 12:34:24 napster: So, do you have a known working kernel >= 2.6.28 ? Mar 09 12:34:42 http://blog.binaerwelt.com/2010/02/ubuntu-on-the-hawkboard/ Mar 09 12:34:55 Even better :) Mar 09 12:34:59 persia, Not yet, (I'm new can you be a little bit simpler?) Mar 09 12:35:15 * ogra slowly starts to know all the places where rootstock is mentioned :) Mar 09 12:35:27 (and they get more every day it seems :) ) Mar 09 12:35:46 napster: Try the link ogra referenced. There are no images, so that install is very much a do-it-yourself thing. Mar 09 12:37:17 ogra: No, of cdimage Mar 09 12:37:30 oh, ok Mar 09 12:38:00 napster: We're happy to help you if you get stuck, but we may not be able to help you set up your kernel very well. Mar 09 12:41:18 persia, ok, will be back to you when I'm stuck :) Mar 09 12:41:44 napster: Good luck. Mar 09 14:06:39 dmart: ping? Mar 09 14:07:30 dmart: I need to poke a toolchain expert's brain Mar 09 14:08:08 Hi... hang on, I'll see if Ramana's around. Mar 09 14:10:46 hey ramana Mar 09 14:11:04 hi NCommander. I'm just about to go get a shower. Can I chat with you in about 10 minutes. Mar 09 14:11:06 ? Mar 09 14:11:19 ramana: sure, I'm going to go then run towalmart, so I'll beback in 20 :-) Mar 09 14:29:55 I wonder whether we might be stripping .debug_frame and that would cause the unwind failures (oops) Mar 09 14:31:01 dmart: Do you know how to test/list .debug_frame presence/contents? Mar 09 14:31:07 or ramana ^ Mar 09 14:31:38 lool: Probably best to wait for ramana to answer this one. Mar 09 14:32:00 If we have a bug in strip or dh_strip, we're in trouble I tell you Mar 09 14:32:48 We call strip --remove-section=.comment --remove-section=.note --strip-unneeded on shared libs Mar 09 14:33:00 and strip --remove-section=.comment --remove-section=.note on binaries Mar 09 14:33:06 (and strip --strip-debug on static libs) Mar 09 14:33:56 Do all of those get shoved into -dbgsym packages, or is it more complicated than that? Mar 09 14:34:07 I think it gets into -dbgsym Mar 09 14:34:26 sorry, these do in -dbg.debs Mar 09 14:34:56 It sounds a bit broken if debug frame info is somehow essential for runtime exception handling... Mar 09 14:35:33 hi . back again. Mar 09 14:35:37 the -dbgsym packages have the result of "objcopy --only-keep-debug" and objcopy -R .gnu_debuglink --add-gnu-debuglink=$1 on the same file Mar 09 14:36:36 dmart: I think there were two standards, and they picked the best one Mar 09 14:36:40 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521 Mar 09 14:36:42 gcc.gnu.org bug 40521 in debug "[4.4/4.5 Regression] -g causes GCC to generate .eh_frame" [Critical,Resolved: fixed] Mar 09 14:36:44 OK. That's a little different, but that makes sense. Mar 09 14:37:04 ramana: So, how would one check whether a binary has a .debug_frame? Mar 09 14:38:10 I see .eh_frame in readelf -l, but not .debug_frame, not even on an unstripped binary I built with -g Mar 09 14:38:38 readelf -w should tell you if there is a debug_frame Mar 09 14:39:17 but why is there a .eh_frame in an ARM shared library ? There should only the .ARM.exidx and .ARM.extable sections. Mar 09 14:40:47 ramana: Indeed Mar 09 14:40:55 Contents of the .debug_frame section: Mar 09 14:40:57 [...] Mar 09 14:40:59 DW_CFA_def_cfa: r13 ofs 0 Mar 09 14:41:04 DW_CFA_advance_loc: 2 to 00008da2 Mar 09 14:41:04 etc. Mar 09 14:41:34 ramana: Well I think the .eh_frame stuff as due to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521 wasn't it? Mar 09 14:41:38 gcc.gnu.org bug 40521 in debug "[4.4/4.5 Regression] -g causes GCC to generate .eh_frame" [Critical,Resolved: fixed] Mar 09 14:41:41 Exactly. Mar 09 14:41:50 But that's presumably been fixed . Mar 09 14:42:18 and we need to figure out where this is being pulled from ? The correct fix for that is in the Ubuntu tree . I need to be removing my workaround from the FSF tree now. Mar 09 14:42:31 ramana: That was only fixed "recently" a lot of binaries might have been built before that Mar 09 14:42:40 ramana: Also, readelf -w libgtk-x11-2.0.so|grep .debug_frame => empty Mar 09 14:42:50 I see it on a self built binary built with -g Mar 09 14:43:00 But I suspect it's missing in pretty much all our shared libs if it gets stripped Mar 09 14:43:29 ramana: back Mar 09 14:43:31 if it gets stripped that's fine. Mar 09 14:43:38 ramana: I'm pretty sure we have the fix in Ubuntu lucid tip, what I don't know is how many binaries still have .eh_frame instead of .debug_frame; in fact .debug_frame seems to be missing *everywhere* Mar 09 14:43:49 ramana: Can you unwind without .debug_frame? Mar 09 14:44:00 lool: manually built OOo packages still show the same issue Mar 09 14:44:06 (that is to say, packages that haven't been stripped) Mar 09 14:44:09 NCommander: It's not just oo.o Mar 09 14:44:16 NCommander: it's all the libs they call Mar 09 14:44:51 lool: I manually built OOo from source end to end to get gdb traces, and still got the issue Mar 09 14:44:54 The exception stack unwinder should use the .ARM.exidx and .ARM.extable implementations. It doesn't have anything to do with.eh_frame. Mar 09 14:44:59 NCommander: I'm not entirely clear on which software does the unwinding, but say that it assumes that if the first lib hsa .debug_frame or .eh_frame, then all libs do... Mar 09 14:45:21 ramana: Ok; good to know, that pretty much kills the theory I was proposing Mar 09 14:46:16 ramana: is that an ARM specific quirk? I thought eh_frame was the standard location of exception handling information Mar 09 14:46:40 Ncommander: Yes that is ARM quirk. Mar 09 14:46:56 We prefer to call it the ARM exception handling ABI :) Mar 09 14:47:07 ramana: I thought ARM and ia64 shared an ABI Mar 09 14:47:18 not really . Mar 09 14:47:23 ramana: so the difference in eh_frame information is nothing to be concerned about w.r.t. to determining our exception handling issues? Mar 09 14:47:38 all binaries I see do have a .ARM.exidx Mar 09 14:47:43 Well it is something to be concerned about. I don't understand why there is a .eh_frame section in the first place. Mar 09 14:48:36 ramana: I built a little C++ program that does exception handling, and it has a *very* full .eh_frame Mar 09 14:49:08 Is this with the lucid toolchain ? Mar 09 14:49:08 bug 532548 Mar 09 14:49:10 Launchpad bug 532548 in ubuntu "[needs-packaging] [FFe] ubuntu-weboffice-zoho package for armel netbook (affects: 1)" [Wishlist,Confirmed] https://launchpad.net/bugs/532548 Mar 09 14:49:11 Manually built OOos have more info in the eh_frame regardless of distro Mar 09 14:49:28 ramana: I'm very confused then ... Mar 09 14:51:31 ramana: so then .ARM.* is passed to libgcc for unwinding versus .eh_frame/.eh_frame_hdr? (I'm thinking I need to shove some debug libgcc_s.so, assuming of course that exception handling frames are registered with libgcc_s on ARM Mar 09 14:51:37 ^) Mar 09 14:51:50 I believe that to be the case. I'll have to ask someone else internally. Mar 09 14:53:19 JamieBennett: sponsored zoho Mar 09 14:53:33 asac: Cool, thanks Mar 09 14:53:35 StevenK: ^^ maybe check in NEW in a few minutes Mar 09 14:54:00 JamieBennett: the Exec command should open browser if %F is empty Mar 09 14:54:02 imo Mar 09 14:54:15 ramana: *grumble*, then the difference in eh_frame information was a red hairing Mar 09 14:54:18 *herring Mar 09 14:54:20 so if you click on it in the applications menu it opens xdg-open https://...zoho.com/... Mar 09 14:54:21 *fish Mar 09 14:54:51 asac: OK, that makes sense Mar 09 14:55:05 I don't think it's a red herring yet. Mar 09 14:55:38 asac: let me finish this FTBFS then I'll take a look Mar 09 14:55:45 sure Mar 09 14:56:13 asac: what were the bugs you mentioned in your comment? Mar 09 14:57:03 JamieBennett: the bug from above ... and icons Mar 09 14:57:08 being wrong ... and apikey Mar 09 14:57:14 but we dont have anything better yet ;) Mar 09 14:57:30 also we need to verify that all the mime-types are ok somehow (or not) Mar 09 14:57:30 asac: ah, so known bugs, thats OK, thought you'd found some more :) Mar 09 14:57:34 nope Mar 09 14:57:47 JamieBennett: didnt know you had the menu not doing anything on your list ;) Mar 09 14:57:48 so somewhat new Mar 09 14:57:51 (one) Mar 09 14:58:22 :) Mar 09 15:00:59 ramana: I have another interesting tidbet since doko pointed me to a readelf that can properly read unwind info; the karmic version has a ton of cantunwind flags in it that aren't in jaunty Mar 09 15:01:31 Ah good that you found that. I had pointed that out to someone last week. Mar 09 15:01:45 It skipped my mind to point you at it. Mar 09 15:02:05 ramana: yeah, on karmic, .ARM.exidx has 233 entries, and 52 of those are marked cantunwind Mar 09 15:02:17 ramana: jaunty has 332, no cantunwind Mar 09 15:02:40 The CANTUNWIND generation happened between the jaunty and karmic toolchains. Mar 09 15:03:06 ramana: sounds like that may confirm the original theory that we're running into a CANTUNWIND where we shouldn't Mar 09 15:03:09 and that's the comment by the author about us debugging to find out what the problem is there. Mar 09 15:03:17 ramana: but biulding with gcc 4.4 in a jaunty chroot works Mar 09 15:03:55 NCommander : How many of the dependencies have you rebuilt with 4.4 ? Is it just ooo that you've rebuilt ? Mar 09 15:04:06 ramana: just OOo Mar 09 15:04:20 ramana: I did some tests with karmic and jaunty toolchain bits. Results are in the Lp bug Mar 09 15:04:56 there is someone else looking at this internally I'll pass on this conversation and your comments on the LP bug. Mar 09 15:05:42 s/looking at this/starting to look at this Mar 09 15:06:22 ramana: thats good. I think I've done a pretty good job at isolating the root cause of the bug; specifically, the phase2 unwind blowing up in our faces, but I'm not sure how we can determine what segment it dislikes Mar 09 15:06:58 other than poking something in libgcc's unwinder. Mar 09 15:07:09 ramana: I tried that, and I felt my brain ooze Mar 09 15:07:42 ok Mar 09 15:09:25 ramana: its not very clear to me where libgcc checks the CANTUNWIND bits, I didn't see anything as I stepped through the code with gdb. Mar 09 15:11:51 if you look at get_eit_entry in unwind-arm.c it's checking if the frame can't be unwound. Mar 09 15:12:19 asac: if your in an uploading mood theres Bug #535093 and Bug #535000 :P Mar 09 15:12:33 Launchpad bug 535093 in kbuild (Ubuntu) "FTBFS: kbuild fails to build on armv7l hardware (affects: 1)" [Undecided,New] https://launchpad.net/bugs/535093 Mar 09 15:12:34 JamieBennett: Bug 535000 on http://launchpad.net/bugs/535000 is private Mar 09 15:12:40 doh Mar 09 15:13:03 both are public according to launchpad Mar 09 15:14:07 ramana: right, which then triggers a _URC_END_OF_STACK. If the expcetion handler hasn't been found, theres a ton of logic that causes the unwind command to return, and then finally call std::terminate() Mar 09 15:14:37 JamieBennett: looks good Mar 09 15:15:05 ramana: so at the risk of being dense, why are sectoins marked CANTUNWIND? Mar 09 15:15:31 lool: great Mar 09 15:16:02 ramana: http://sourceware.org/ml/binutils/2009-05/msg00048.html - nm, this seems to answer my question Mar 09 15:16:10 JamieBennett: uploaded; sent to Debian and/or upstream? Mar 09 15:16:21 lool: which one? Mar 09 15:16:26 JamieBennett: fio Mar 09 15:16:38 no, I'll submittodebian now Mar 09 15:17:22 JamieBennett: kbuild > looks like this will break every now and then; can't we support arm*? Mar 09 15:17:38 Yes I was looking for that. Mar 09 15:18:13 lool: Yes with a more invasive patch, this simple patch will stop the FTBFS while we work on a generic solution for all packages (dmart is looking into it) Mar 09 15:18:27 JamieBennett: Is there another bug on the generic solution? Mar 09 15:18:33 ramana: seems libgcc can actually unwind parts of the table that are marked CANTUNWIND Mar 09 15:18:43 which seems to mean that CANTUNWIND really should be SHOULDNTUNWIND :-) Mar 09 15:18:49 lool: yes Mar 09 15:18:53 * JamieBennett hunts for a number Mar 09 15:19:03 JamieBennett: just mention it in your bug Mar 09 15:19:08 OK Mar 09 15:19:24 uploaded Mar 09 15:19:28 lool: Thanks Mar 09 15:19:37 JamieBennett: "dmart is looking into it": which package is this? Mar 09 15:19:44 what gives you that idea ? Mar 09 15:19:48 dmart: the generic arm detection Mar 09 15:19:53 script Mar 09 15:19:55 JamieBennett: actually, please rename Vcs-* fields when you change a package from Debian Mar 09 15:20:12 lool: Oh, OK Mar 09 15:20:16 JamieBennett: oh, right. I don't have a solution on that yet. Mar 09 15:20:38 JamieBennett: uploading a fix there too Mar 09 15:20:47 dmart: Yes, I had a simple fix for kbuild which can be done better when we have a more generic solution Mar 09 15:20:59 ramana: since if the CANTUNWIND entries aren't in the linker table, it seems unwinding successes Mar 09 15:21:17 JamieBennett: I agree; probably best to go for a simple stopgap solution for now. Mar 09 15:21:36 *successes Mar 09 15:21:39 er Mar 09 15:21:43 * NCommander spelt it right the first time Mar 09 15:23:45 succeeds? Mar 09 15:24:44 lool: er *cough* Mar 09 15:24:53 * NCommander goes to relearn basic English Mar 09 15:25:55 NCommander: Don't do that. Odgen&Richards were smart, but there are many lost subtleties in such communication. Mar 09 15:25:59 I guess it matters more here that you can read ARM unwind sections Mar 09 15:27:16 NCommander : I need to get into another meeting in a few minutes and need to finish something before that. Mar 09 15:27:40 Before I disappear - I'll look out for the following bits of info. Mar 09 15:28:06 1. Why is there a .eh_frame being generated for exception handling in C++ for ARM ? It was my understandign that this should not happen. Mar 09 15:28:48 2. Look into unwind-arm.c for more about how CANTUNWIND entries are handled . Mar 09 15:29:00 ramana: for 2, it aborts the unwind Mar 09 15:29:29 yes it should gracefully abort the unwind but you said something about unwinding "succeeding" Mar 09 15:29:48 ramana: oh, no, I said the unwind succeeds if the CANTUNWIND entries aren't there Mar 09 15:29:59 (as when we build the code in jaunty) Mar 09 15:30:04 NCommander - ah ok . Mar 09 15:31:17 ramana: if we can determine how the linker determines if something should be CANTUNWIND would be most helpful Mar 09 15:31:35 * NCommander suspects we're looking at a binutils regression, although its not clear when just using binutils 2.19 by itself doesn't resolve the issue Mar 09 15:31:46 or bug, not sure if this is a regression or not Mar 09 15:31:48 well it's hard to say. Mar 09 15:32:31 We'll have to look into it further. I'll pass this on to the guy who'll be looking at it. Mar 09 15:32:58 ramana: thanks. If you can point them my way, it would be appericated. Mar 09 15:35:40 I have already pointed your LP comments to him . Mar 09 15:43:00 ramana: well, talking with him on IRC always helps :-) Mar 09 15:43:34 http://www.engadget.com/2010/03/09/freescales-7-inch-tablet-runs-android-chrome-os-or-linux-cost/ - I want :-) Mar 09 15:46:57 For too big :p Mar 09 15:47:18 That resolution would be fine at 3.5" Mar 09 16:45:56 NCommander : are you around ? Mar 09 16:47:36 ramana: yup Mar 09 16:48:11 mgretton has been looking at the LP bug and has some questions . Mar 09 16:49:01 mgretton: what can I do to help you? Mar 09 16:49:20 Hi, I'm interested in the functions privateSnippetExecutor and GetVersionInfo. I believe these are C functions, were they compiled with -fexceptions? Mar 09 16:49:46 mgretton: where are those functions? Mar 09 16:49:49 oh wait Mar 09 16:50:00 mgretton: privateSnippetExecutor is an ARM ASM stub Mar 09 16:50:26 * NCommander looks for GetVersionInfo Mar 09 16:50:45 In the test case associated with bug 417009 these functions are marked 'can't unwind' and the backtrace for the test case shows that privateSnippetExecutor is in the call stack when the exception is thrown Mar 09 16:50:49 Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 3 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,Won't fix] https://launchpad.net/bugs/417009 Mar 09 16:51:29 mgretton: I don't see GetVersionInfo Mar 09 16:52:18 NCommander: GetVersionInfo doesn't matter so much its privateSnippetExecutor I see in the call stack. Mar 09 16:53:03 mgretton: we're not building with -fexceptions Mar 09 16:53:36 mgretton: but thats an ARM ASM function (.s) thats build separately into a .o, and then linked in Mar 09 16:54:22 mgretton: .cantunwind is not within the .s file, so the linker shouldn't be marking it as CANTUNWIND Mar 09 16:55:49 NCommander: Are there any unwind directives at all in the .s file? Mar 09 16:55:59 mgretton: no Mar 09 16:56:03 mgretton: let me pastebin it Mar 09 16:56:37 NCommander: ld now explicitly marks code that it can't unwind through due to lack of unwind tables as CANTUNWIND. Mar 09 16:56:59 mgretton: http://paste.ubuntu.com/391906/ Mar 09 16:57:13 mgretton: that sounds like that might be the cause. How do we add unwind information? Mar 09 16:59:53 NCommander: You need to add .fnstart, .fnend, .save, and .setfp directives into the assembly... Mar 09 17:00:27 pixman could use some looking at to see why its not building with SIMD enabled on arm, I haven't been able to figure out why Mar 09 17:00:37 mgretton: got a doc for me to look at? Mar 09 17:00:39 NCommander: Write a simple hello-world program compile with -fexceptions -S and look at the assembly file produced. Mar 09 17:01:05 The gas info pages have full info - I'll find a link. Mar 09 17:01:49 it sets the -mcpu=arm1136j-s CFLAG and tries asm("uqadd8 r1, r1, r2"); in the check to see if it should enable it Mar 09 17:02:06 Sarvatt: I see that in the code, but I don't have any clue why it would fail either Mar 09 17:02:07 NCommander: See http://sourceware.org/binutils/docs-2.20/as/ARM-Directives.html#ARM-Directives Mar 09 17:02:18 Hmm it's prepended to CFLAGS though Mar 09 17:02:33 mgretton: how'd you determine that there was no unwind info for privateSnippetExecutor out of curiosity? Mar 09 17:02:37 but we dont pass anything fancy, so shouldn't matter Mar 09 17:05:25 So that would be a v6 instruction hmm Mar 09 17:06:39 NCommander: I used readelf from a very recent trunk binutils which will decode unwind tables, and looked for the areas of code marked CANTUNWIND, and then mapped that to functions. Mar 09 17:07:03 mgretton: ah! Mar 09 17:07:26 NCommander: I then checked the call frame and privateSnippetExecutor became the immediate suspect. Mar 09 17:08:02 Sarvatt: /tmp/cciD0vDI.s:37: Error: selected processor does not support `uqadd8 r1,r1,r2' Mar 09 17:08:11 configure:12379: gcc -c -mcpu=arm1136j-s -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden conftest.c >&5 Mar 09 17:08:41 Sarvatt: Could it be that uqadd8 is a vfp instructions which we dont turn on by default? Or perhaps a NEON one? Mar 09 17:08:49 I didn't find it in the ARM reference manual Mar 09 17:09:08 mgretton: test building my first try Mar 09 17:09:20 NCommander: After fixing this, the question still remains about why there is a .eh_frame section. Talking to other folks around and looking at stuff makes me believe that's also something which is not correct and should be looked at . Mar 09 17:09:49 mgretton: Ah, could it be it's an ARM only instruction, and isn't available under Thumb? Mar 09 17:10:05 err s/mgretton/Sarvatt Mar 09 17:11:57 mgretton: well, for my first attempt, the program just blows up versus reaching std::terminate :-) Mar 09 17:12:12 * NCommander guesses he didn't quite get everything right Mar 09 17:13:23 NCommander: Do you mind binpasting your attempt and I'll take a quick look as well? Mar 09 17:13:34 mgretton: sure, let me just try one other thing before I post it Mar 09 17:14:45 Sarvatt: checking whether to use ARM SIMD assembler... yes Mar 09 17:14:51 Sarvatt: That's with CFLAGS=-marm Mar 09 17:14:56 if -mcpu is prepended is the gcc default that gets added at the end overriding the first one? Mar 09 17:15:18 Sarvatt: No, the gcc defaults isn't added at the end; it's the default CPU mode which causes it Mar 09 17:15:40 We switched to -mthumb by default in lucid, and -mthumb lacks uqadd; only -marm has it Mar 09 17:15:45 Sarvatt: Mind opening a bug on that? Mar 09 17:17:20 mgretton: http://paste.ubuntu.com/391919/ - if I remove the saves, I don't get a crash, but it just hangs Mar 09 17:17:26 Sarvatt: Quick workaround for you: add CFLAGS+=-marm in debian/rules Mar 09 17:17:33 mgretton: with this, I get the terminate message again (phase2 unwind error) Mar 09 17:19:13 NCommander: Before mov ip, sp add a .movsp ip directive, before the sub fp, ip, #4 add a .setfp ip, #4 directive and see what happens. Mar 09 17:20:21 mgretton: I admit my ARM ASM isn't so good :-/ Mar 09 17:20:30 NCommander: If that doesn't work change the .setfp ip, #4 to .setfp ip, #-4 Mar 09 17:20:37 mgretton: .setfp needs two arguments Mar 09 17:21:02 I think that has to be .setfp fp, ip, #4 Mar 09 17:21:09 NCommander: Sorry .setfp fp, ip, #4 (or .setfp fp, ip, #-4) Mar 09 17:21:15 mgretton: According to the binutils doc you pointed at earlier, #4 seems correct Mar 09 17:21:38 sure thing lool, can we just patch configure.ac to add -marm to the check? Mar 09 17:21:41 NComamnder: Yes but its the opposite of what GCC produces... Mar 09 17:22:01 Sarvatt: I need to dive a bit in where that's actually used Mar 09 17:22:11 Sarvatt: Adding -marm in configure is probably not a good idea Mar 09 17:22:23 https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/535183 Mar 09 17:22:25 mgretton: no luck with either one. with .setfp ip, #4, I get to std::terminate Mar 09 17:22:27 Launchpad bug 535183 in pixman (Ubuntu) "pixman doesn't autodetect SIMD support at build time on arm. (affects: 1)" [Undecided,New] Mar 09 17:22:35 mgretton: with #-4, it just quits, no message Mar 09 17:23:20 Sarvatt: So I had a look, and it's used in the middle of pixman/pixman-cpu.c Mar 09 17:23:29 Where I can get a uImage file? Mar 09 17:23:57 Sarvatt: Hmm sorry, apparently for libpixman-arm-simd.la only Mar 09 17:24:00 thats the runtime autodetection code I think? Mar 09 17:24:03 Which has pixman-arm-simd.c only Mar 09 17:24:23 Sarvatt: So it would appear to be ok to pass -marm in pixman-arm-simd.c Mar 09 17:24:48 Sarvatt: However note that this means that the code will be switching to arm-mode whenever it's jumped to Mar 09 17:25:00 Sarvatt: Would it be possible to rewrite the functions in thumb instead? Mar 09 17:25:47 wasnt pixman on the thumb2 porting page ? Mar 09 17:25:54 NCommander: Not sure - have all C files been compiled with -fexceptions as well? (main.c springs to mind in the call stack in the image we're looking at) Mar 09 17:26:09 * ogra cant remember but i thought i saw it Mar 09 17:26:25 mgretton: not explicately Mar 09 17:26:42 https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList yep Mar 09 17:26:43 I think pixman was on the list, but flagged as done Mar 09 17:26:44 mgretton: I'd have to rebuild OOo from scratch to force -fexceptions to be built, but thats going to take days Mar 09 17:26:54 https://bugs.launchpad.net/ubuntu/+bug/514237 Mar 09 17:26:57 Launchpad bug 514237 in pixman (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] Mar 09 17:27:03 invalid Mar 09 17:27:05 was marked as invalid though Mar 09 17:27:15 ogra: it was listed for something else Mar 09 17:27:19 NCommander: All files need to have exception unwind information added to them. Sorry - that sound horrible. Mar 09 17:27:21 yeah for mov Mar 09 17:27:58 Our greps couldn't tell the difference between broken and non-broken asm, but pixman has been under recent maintenance and should work fine. Mar 09 17:28:18 dmart: Problem is that it uses uqadd which isn't available in thumb mode Mar 09 17:28:20 NCommander: You'll also need the right fix for privateSnippetExecutor that we might have worked out above :-) Mar 09 17:28:40 dmart: Do you have a suggestion on replacing it, or should we just build the arm_composite_add_8000_8000() routine in arm mode? Mar 09 17:28:52 (and others) Mar 09 17:29:00 Basically the whole pixman/pixman-arm-simd.c file Mar 09 17:29:11 mgretton: ugh, that seems broken. Mar 09 17:29:21 mgretton: we shouldn't need -fexceptions on ARM where no other architecture requires it Mar 09 17:30:03 NCommander, if it makes it work its still a better workaround than shipping a jaunty binary .so though Mar 09 17:30:14 ogra: that's true Mar 09 17:30:43 mgretton: at the risk of being dense, main.c isn't part of the UNO library that has the issue Mar 09 17:31:03 mgretton: so I'm not sure that being built with -fexceptions would change anything Mar 09 17:31:10 NCommander: Agreed. Mar 09 17:31:12 dmart: Also, I'm thinking perhaps we should grep for uqadd? Mar 09 17:31:31 mgretton: how can I determine if we're actually emitting unwind info? (i.e., our fix is correct and ld isn't doing something stupid silently) Mar 09 17:31:37 NCommander: Where are we expecting this exception to be caught? Mar 09 17:31:50 mgretton: er, you haven't seen the code, have you? Mar 09 17:32:02 NCommander: Grab and build a trunk binutils and use readelf... Mar 09 17:32:15 mgretton: I already have a patched version, just not sure what to look for in the output :-) Mar 09 17:32:21 lool: possibly; I hadn't previously been aware of that one. Mar 09 17:32:22 mgretton: we're bypassing throw(), and calling __cxa_throw directly :-/ Mar 09 17:32:34 mgretton: it should end up landing in deleteException in UNO before being rethrown Mar 09 17:32:41 The quickest solution is simply to build the affected parts of pixman for ARM (or all of it) Mar 09 17:33:00 dmart: Yes; but Sarvatt is upstream apparently; what would the proper upstream fix be? Mar 09 17:33:15 dmart: They have a separate file and separate CFLAGS for it, so -marm doesn't sound too bad Mar 09 17:33:39 NCommander: readelf -u will dump the unwind tables. Look for PrivateSnipperExecutor in the tables Mar 09 17:34:00 mgretton: ok, so I have an unwind table entry for it Mar 09 17:34:01 woo Mar 09 17:34:16 (not sure its correct, but its close enough that we're not breaking the stack over it) Mar 09 17:34:36 NCommander: I'm afraid I've got to go. I'll have a think about this and come back tomorrow with any other thoughts. Mar 09 17:34:42 Sarvatt: At least for now, s/ARM_SIMD_CFLAGS="-mcpu=arm1136j-s"/ARM_SIMD_CFLAGS="-mcpu=arm1136j-s -marm"/ would be fine Mar 09 17:34:53 mgretton: fair enough. Is there a way to get the old linker behavior back? Mar 09 17:34:58 (some sorta LDFLAG or something?) Mar 09 17:35:13 lool: Is the build log on launchpad? uqadd8 is available in Thumb-2 Mar 09 17:35:17 Sarvatt: I don't know whether there's a high cost in switching between thumb and arm, nor whether comparable instructions exist in thumb mode Mar 09 17:35:22 dmart: I can reproduce here Mar 09 17:35:28 dmart: Yes, it's on launchpda Mar 09 17:35:34 Can you paste me a log? Mar 09 17:35:37 NCommander: No - you need to revert the original patch that added the functionality. Mar 09 17:35:48 dmart: http://launchpadlibrarian.net/38024749/buildlog_ubuntu-lucid-armel.pixman_0.16.4-1_FULLYBUILT.txt.gz Mar 09 17:35:54 dmart: (was looking it up) Mar 09 17:36:00 dmart: checking whether to use ARM SIMD assembler... no Mar 09 17:36:05 mgretton: I'm going to guess we want this cantunwind functionality? Mar 09 17:36:19 dmart: I can reproduce with ./configure in an arm qmeu chroot here, and CFLAGS=-marm passes! Mar 09 17:36:24 mgretton: (I should note that I tried using an earlier binutils from 2.19 on karmic, which we built OOo with before, and I still got a broken library build) Mar 09 17:36:34 Can you paste me your failing log? Mar 09 17:36:39 lool: ^ Mar 09 17:36:44 dmart: the launchpad log is the failing one Mar 09 17:36:52 dmart: Oh you mean config.log? Mar 09 17:36:52 NCommander: Yes - its better than the alternative - that we unwind using a different function's unwind table. Mar 09 17:37:12 mgretton: *grumble* :-/ Mar 09 17:37:13 dmart: 18:08 < lool> Sarvatt: /tmp/cciD0vDI.s:37: Error: selected processor does not support `uqadd8 r1,r1,r2' Mar 09 17:37:16 18:08 < lool> configure:12379: gcc -c -mcpu=arm1136j-s -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden conftest.c >&5 Mar 09 17:37:19 (above) Mar 09 17:37:31 mgretton: I have no good ideas where to go from here, hopefully you'll get a brainwave later today Mar 09 17:37:38 dmart: Ah I know, they force a CPU which has an older thumb2 implementation -- could that explain? Mar 09 17:37:38 NCommander: Original change here: http://sourceware.org/ml/binutils/2009-05/msg00048.html Mar 09 17:37:44 * mgretton is back Mar 09 17:37:50 * mgretton is back Mar 09 17:38:05 mgretton: that was quick Mar 09 17:38:19 NCommander: I'm really going this time :-) Mar 09 17:38:24 lool: -mcpu=arm1136j-s [-mthumb] will be broken, because Thumb-1 doesn't have these instructions. Do you know why it's building for ARM1136? Mar 09 17:38:50 mgretton: heh Mar 09 17:38:58 dmart: I guess earliest CPU adding quadd Mar 09 17:39:01 NCommander, thats ARMs "instant on" function :) Mar 09 17:39:25 gets you such quick suspend/resume cycles Mar 09 17:39:58 ogra: hrm, what I need is an ARM enginneer fork() function so I can have one always available versus having them be a shared resource :-) Mar 09 17:40:33 lool: We had in instance of this in something before: the build must not downgrade -mcpu or -march in order to "turn on" features. If you just build this file with the Ubuntu defaults (-march=armv7-a -mhumb) I believe it should work. Mar 09 17:40:37 dmart: Testing CFLAGS=-mcpu=cortex-a8 right now Mar 09 17:40:51 lool: that should work, yes Mar 09 17:40:58 dmart: The thing is that they likely want to turn it on under Debian for instance Mar 09 17:41:29 dmart: It's a separate function which only gets called if auxv says v6 is preesnt Mar 09 17:41:39 It passes Mar 09 17:41:53 lool: I think you need two tests for this: Mar 09 17:42:07 Sarvatt: So the bug is in that -mcpu= you're setting, it's incompatble with Ubuntu's -mthumb default; let's find something Mar 09 17:42:28 lool: echo '... uqadd8 blah ...' | gcc => if OK then turn on this file and build it with default opts Mar 09 17:42:33 otherwise Mar 09 17:43:04 dmart: Well AC_TRY_COMPILE, but right Mar 09 17:43:12 lool: echo '... uqadd8 blah ...' | gcc -mcpu=arm1136j-s => if OK then turn on this file and build it the overridden opts Mar 09 17:43:43 (I know, but it's pseudocode anyway) Mar 09 17:43:52 ...if neither works, turn off that file. Mar 09 17:43:58 dmart: I would like you to please talk autoconf on this chan Mar 09 17:44:13 pseuco-code is not an acceptable conduct! Mar 09 17:44:15 :-P Mar 09 17:44:26 meh Mar 09 17:44:32 dmart: Ok will try cooking some autofoo for Sarvatt if he like Mar 09 17:44:33 s Mar 09 17:45:16 anyway, I think that's the answer; you need 2 tests to determine the right options Mar 09 17:46:14 NCommander: fork: Resourse temporarily unavailable Mar 09 17:46:24 ;) Mar 09 17:47:15 dmart: thats not a valid error code from fork() :-) Mar 09 17:47:30 dmart: sounds like your having some issues with too many threads touching errno Mar 09 17:47:59 fork(8) Mar 09 17:48:01 ... Mar 09 17:48:02 ERRORS Mar 09 17:48:04 EAGAIN fork() cannot allocate sufficient memory to copy the parent's ... Mar 09 17:48:15 Cygwin does this to me a lot for no reason... Mar 09 17:48:40 ...but I digress... Mar 09 17:51:24 dmart: I thought EAGAIN translated to a different strerror() message ... Mar 09 17:51:26 * NCommander might be wrong Mar 09 17:52:11 ah, maybe. It wasn't a good joke anyway... Mar 09 17:54:26 dmart: yes, but we're geeks for understanding it anyway :-) Mar 09 17:54:44 Sarvatt, dmart: http://paste.ubuntu.com/391944/ Mar 09 17:54:49 (untested) Mar 09 17:55:55 I think the second test needs ARM_SIMD_CFLAGS="-mcpu=arm1136j-s -marm" Mar 09 17:56:19 ...if the toolchain might default to Thumb Mar 09 17:56:32 (may not be an issue for Debian though?) Mar 09 17:57:39 dmart: good point Mar 09 17:58:56 http://paste.ubuntu.com/391946/ Mar 09 17:59:16 Makes sense, I guess. Mar 09 18:01:25 * dmart has to disappear... Mar 09 18:12:07 Sarvatt: checking whether to use ARM SIMD assembler... yes Mar 09 18:12:11 with the second patch Mar 09 18:12:40 Sarvatt: Could you merge that upstream? Mar 09 18:35:33 lool, Sarvatt: just send a patch to http://lists.freedesktop.org/mailman/listinfo/pixman it should not make arm simd (aka armv6) support any worse Mar 09 19:43:51 sure thing, sorry I'm at work at the moment and missed all that earlier. I will upstream it, no problems :) Mar 09 19:45:20 thanks for looking into it and fixing it, I wasn't having any luck Mar 09 19:51:24 Sarvatt: I just subscribed to the pixman list; shall I send it here, or will you just pick it up from the bug report? Mar 09 19:51:35 ssvb: thanks for the pointer ^ btw Mar 09 19:52:03 ah that works, was just about to ask you for attribution info and such :) Mar 09 19:58:10 Sarvatt: sent there Mar 09 19:58:33 JamieBennett: https://launchpad.net/ubuntu/+source/kbuild/1:0.1.98svn2318-4ubuntu1/+build/1552 Mar 09 19:58:36 656/+files/buildlog_ubuntu-lucid-armel.kbuild_1:0.1.98svn2318-4ubuntu1_BUILDING. Mar 09 19:58:40 txt.gz Mar 09 19:58:43 kbuild failed to build on armel Mar 09 19:58:48 and mutt ate my link Mar 09 19:59:04 JamieBennett: Actually: * State: Failed to upload Mar 09 19:59:31 JamieBennett: It seems this was retried, so don't worry Mar 09 19:59:52 lool: so what was the problem? Mar 09 20:00:17 Sarvatt: Sorry for the lack of proper From: Mar 09 20:00:26 JamieBennett: Dunno, transient buildd upload failure Mar 09 20:00:31 e.g. connection reset or something Mar 09 20:00:36 JamieBennett: apparently it reached the archive Mar 09 20:00:45 lool: OK Mar 09 20:02:06 Anyone got experience with the OMAP2 hsmmc driver? Mar 09 20:04:30 weird... the rcn-ee 2.6.33 kernel doesn't get any input from the "twl4030_powerbutton" input device. Mar 09 20:31:49 apw: I guess you saw -dove failed to build due to perf trying to include/link libelf Mar 09 20:42:19 hi all Mar 09 20:42:42 hi Mar 09 20:43:09 * lool wnders off Mar 09 20:45:39 I'm building a arm system to run ubuntu from scratch and i'm having some trouble to make the kernel deb that rootstock need does someone knows where I can find some help on this topic ? Mar 09 20:47:09 I have tried to make deb-dpkg but when it arrives at dpkg-gencontrol it tels me gcc arm-eabi uncnown :/ Mar 09 20:47:12 guilhem: rootstock should fetch the kernel that it needs itself Mar 09 20:47:43 guilhem: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ this kernel works with rootstock AFAIK Mar 09 20:47:43 yeah I know that in fact i need to make it clean to be able to share with others Mar 09 20:49:09 in fact i need to build my own kernel Mar 09 20:50:29 what i'm doing is that i'm building ubuntu on nvidia platform Mar 09 20:51:37 and the only bootloader available today is fastboot which boot my zImage flrom flash and then should mount the rootfs from the memory stick sda1 Mar 09 20:52:08 I have managed to boot the memory stick and mount the ext3 filesystem Mar 09 20:52:26 but now I want to put ubuntu on top of that Mar 09 20:52:39 and it's a litle bit dark for me Mar 09 20:55:36 I have understand that i should build my rootfs with rootstock and then put my vmlinuz & modules on the rootfs Mar 09 20:57:27 but when i try to boot this i get a kernel panic after mounting the filesystem Mar 09 20:57:30 [42949392.430000] PC is at setup_arg_pages+0x28/0x20c Mar 09 20:57:33 [42949392.440000] LR is at load_elf_binary+0x3fc/0x1268 Mar 09 20:57:46 anyone knows ? :| Mar 09 21:32:32 lool ... dove should have that turned off ... hrm **** ENDING LOGGING AT Tue Mar 09 23:10:55 2010 **** BEGIN LOGGING AT Wed Mar 10 21:48:21 2010 Mar 10 21:49:55 Hi all! I just came across this: http://news.softpedia.com/news/Acer-Prepares-Freescale-i-MX515-Powered-Smart-Monitor-131435.shtml Mar 10 21:51:01 and it occured to me that the monitor could be ideal for running a mythfrontend and X server only, assuming it has the power... Mar 10 21:52:35 I don't know if mythtv-frontend is packaged for ARM, but would it be realistic to do something like that with Ubuntu? **** BEGIN LOGGING AT Thu Mar 11 09:00:15 2010 Mar 11 13:38:46 JamieBennett: gave you a RC bug so we can upload in freeze: bug 537356 Mar 11 13:38:48 Launchpad bug 537356 in webservice-office-zoho (Ubuntu Lucid) (and 1 other project) "application menu entries dont do anything (affects: 1)" [High,Triaged] https://launchpad.net/bugs/537356 Mar 11 13:42:49 xserver with imx fallback patch is about to finish building ;) Mar 11 13:43:25 asac: thanks :) Mar 11 13:43:41 wohooo Mar 11 13:44:08 asac, now it just needs proper EDID detection :) Mar 11 13:44:23 ogra: the current solution is quite good enough i think ;) Mar 11 13:44:34 Well, depends on one's monitor Mar 11 13:44:36 i want my 1900x1002 ! Mar 11 13:44:36 oh edid Mar 11 13:44:38 yeah Mar 11 13:44:40 *1200 Mar 11 13:44:41 ogra: how is that done? Mar 11 13:45:06 no idea i have to look into it, it wasnt ready in the old driver i have around here Mar 11 13:45:18 well its not ready here either Mar 11 13:45:22 but maybe its just a code fix ;) Mar 11 13:45:23 but i think its already done when the fb device inits Mar 11 13:45:37 hmm on init feels wrong Mar 11 13:45:46 monitor might get plugged in/out swapped etc. Mar 11 13:45:56 xrandr should tell us better info ;) Mar 11 13:46:06 xrandr is after EDID Mar 11 13:46:16 iirc Mar 11 13:46:31 ok i will check that Mar 11 13:47:04 sure xrandr hopefully just reflects what EDID gave us Mar 11 13:47:12 or gives us (when mohnitor changes) Mar 11 13:47:50 I was under the impression xrandr wasn't available based on the snipped of the log that was pasted yesterday. Mar 11 13:48:09 fbcvt: 1024x768@60: CVT Name - .786M3 Mar 11 13:48:15 thats what i have in dmesg Mar 11 13:48:37 xrandr is available but only with a handfull of default resolutions Mar 11 13:48:45 up to 1024x768 Mar 11 13:48:53 ack Mar 11 13:49:12 at least it detects for me its a lcd with proper subpixel Mar 11 13:49:15 and we dont know if resolution changing works yet Mar 11 13:49:38 cant you try lower resolution in fbdev? Mar 11 13:51:54 you can try setting modelines with fbset Mar 11 13:52:06 and you can indeed add modelines in xorg.conf Mar 11 13:52:25 if xranbdr works you should even be able to use modelines there to add new modes Mar 11 13:56:47 dmart: ping? Mar 11 13:57:13 NCommander: hi there Mar 11 13:57:19 dmart: sorry I missed you yesterday Mar 11 13:57:41 no probs; just wondering what our next steps should be on OOo Mar 11 13:57:56 dmart: funny, I was going to ask you the same thing :-) Mar 11 13:58:33 dmart: I retested karmic gcc-4.3 + jaunty binutils, and got a working uno from fresh sources Mar 11 13:59:13 NCommander, did you talk to doko btw, i think he did all these varaition tests already Mar 11 13:59:47 he should have a test matrix for what combo works and which one doesnt Mar 11 13:59:58 ogra: I talked to him earlier, but he didn't say anything about that. I'll make sure to ask him for that Mar 11 14:00:18 i tested a *ton* of different builds he did Mar 11 14:00:34 each with a different combo of gcc and binutils Mar 11 14:00:43 ogra: I'll ping him Mar 11 14:01:01 ogra: that's good to know. I just wish it was on the bug :-/ Mar 11 14:01:02 dmart: TBH, I'm kinda out of ideas on this one. Mar 11 14:01:32 dmart: we know what appears to be the base underlying cause for the OOo boom Mar 11 14:01:53 but I don't really know how to fix it, or how to even rewrite the ASM snippet to be less evil Mar 11 14:03:03 NCommander, just build it with --no-uno-crash Mar 11 14:03:06 ;) Mar 11 14:03:31 * NCommander whacks ogra Mar 11 14:03:41 * NCommander feels better Mar 11 14:03:45 * ogra feels short now Mar 11 14:04:36 So, about OO.o. Mar 11 14:05:02 From what I saw recently, I thought we knew what changes to the toolchain were providing what extra bits that caused which problems. Mar 11 14:05:20 Was the .eh... issue resolved or still open upstream? Mar 11 14:05:38 Or did someone confirm this wasn't really the issue? Mar 11 14:11:26 dmart: I'm not even sure what to bring to OOo upstream about this, from there perspective, it looks like a pure toolchain bug Mar 11 14:21:22 NCommander: the problem file had some maintainers' names -- have you tried to contact them? I think the first thing is to understand from them what the code is trying to do, and explain our concerns about why it looks incorrect. Mar 11 14:22:58 dmart: no, I haven't Mar 11 14:24:18 I can draft a mail if you like. Mar 11 14:28:14 oooh Mar 11 14:28:27 hang on a moment Mar 11 14:30:21 NCommander: did you look at this?: http://pastebin.ubuntu.com/393294/ Mar 11 14:31:26 dmart: I smell magic in that file Mar 11 14:31:28 deep scary magic Mar 11 14:31:33 Ummm, yeah Mar 11 14:31:47 The two first *p++ poke ARM instructions into memory Mar 11 14:31:57 > mov r12, pc Mar 11 14:32:06 > ldr pc, [pc, #4] Mar 11 14:32:27 This explains why privateSnippetExecutor assumes there is something in ip (r12) Mar 11 14:32:48 dmart: I think my crack fuse just burt out :-/ Mar 11 14:33:35 I guess it's used to look up the functionIndex and vtableOffset values which get poked Mar 11 14:34:40 dmart: there is no guarette thats going to laid out like that in memory though, or with no padding and stuff done Mar 11 14:36:35 dmart: actually, it could have been the move to ARMv6 that might have brokened it in the first place since that removed the strict algnment access requirements Mar 11 14:36:39 (not sure, but a possible theory) Mar 11 14:40:01 Hey ramana Mar 11 14:40:22 I know what's in ip (ish) Mar 11 14:41:00 It contains the pc value in a trampoline used to read the destination vtable offset and function index, see http://pastebin.ubuntu.com/393294/ Mar 11 14:41:56 ...or at least it would contain that if any version of the linker ever provided a guarantee Mar 11 14:41:56 dmart: on a scale of 1-10, how high is the crack factor of what OOo is doing here? Mar 11 14:42:16 dmart: but privateSnippetExecutor works Mar 11 14:42:27 dmart: thats been previously tested, and works as expected Mar 11 14:42:56 Shouldn't it not work as expecting, as with all the mov *,pc stuff? Mar 11 14:43:03 The linker is allowed insert trampolines for function calls, which are permitted to corrupt ip. The chance of this happening is pretty low, but it's not "safe" Mar 11 14:43:50 I think the code in question will get executed as ARM, and the way it branches it interworking-compatible. Mar 11 14:44:20 ...anyway, I don't think this code is failing, it's just a bit scary Mar 11 14:44:29 dmart: bit? Mar 11 14:44:47 dmart: ugh, I just realized something nasty Mar 11 14:45:01 dmart: part of the ASM instructions exist outside the .S (as the hex magic) Mar 11 14:45:12 dmart: so even if we add unwind table entries, ther're not going to properly "mesh" Mar 11 14:46:20 Because the trampoline generated by privateSnippetExecutor only trashes ip, it might not need any unwind info... but I'm not the expert on this Mar 11 14:47:33 Also, I think no exception can occur in the trampoline itself, because it calls no functions except for jumping to privateSnippetExecutor Mar 11 14:48:09 dmart: thats not the problem, the problem is libgcc bails out because on CANTUNWIND segments (in theory) Mar 11 14:48:11 * dmart is grepping the OOo source to try and work out where this code gets called from, but it will take a while Mar 11 14:48:16 cortex a9 processor seems to be the fastest and most fitting processor for a small client with gui, does someone know where I can buy a mainboard with this cpu? Mar 11 14:48:53 nvidia tegra2 Mar 11 14:49:21 johannes_: I've seen Ubuntu at least Ubuntu karmic working on tegra2 Mar 11 14:49:21 dmart: uno2cpp.cxx only Mar 11 14:49:24 dmart: same folder Mar 11 14:49:48 NCommander: I mean, where the functions codeSnippet and flushCode in uno2cpp.cxx are called from... Mar 11 14:49:49 johannes_: http://tegradeveloper.nvidia.com/tegra/ Mar 11 14:49:53 dmart: if you read the UNO CPP code, your mind will release itself from mundane concerns as the horror of it takes over Mar 11 14:50:13 thanks Ill have a look at tegra2 Mar 11 14:50:15 dmart: ah. theres a porting uno guide you might want to look at Mar 11 14:50:36 Oh, where? That sounds useful Mar 11 14:50:52 dmart: http://wiki.services.openoffice.org/wiki/Lazy_Hackers_Guide_To_Porting - skip to the first part of Hard Bit Mar 11 14:51:00 dmart: it deals with how the HPPA port was done. Mar 11 15:02:45 mhm bei tegra2 finde ich nur dinge, wie tablet pcs, ich suche aber nach etwas, wie dem beagleboard nur mit einem oder mehreren Cortex A9 Mar 11 15:03:23 johannes_, i dont think they are freely sold yet Mar 11 15:03:32 One needs to apply. Mar 11 15:03:47 oh sry for writing in german Mar 11 15:03:53 macht nix :) Mar 11 15:04:02 johannes_: Are you looking to build something, or do you want a shipping device? Mar 11 15:04:46 I thought about a fileserver with a quadcore Cortex A9 as I read some articles it would have a lot of power Mar 11 15:05:01 I want to build something for myself Mar 11 15:08:50 tegra is dual core "only" Mar 11 15:09:14 yeah, lame, isnt it ? :P Mar 11 15:09:41 but there are processor on it, I dont need, 3d graphics for example Mar 11 15:09:49 and I couldnt find a mainboard yet Mar 11 15:09:58 it's too hot Mar 11 15:10:10 you can't even buy it in Europe Mar 11 15:10:10 I've not seen any bare mainboards except for "development boards". Mar 11 15:10:22 Most stuff seems to be inside devices. Mar 11 15:10:57 thats sad Mar 11 15:11:00 http://www.dlink.com/boxeebox Mar 11 15:11:07 that will use a tegra2 Mar 11 15:11:24 i read somewhere Mar 11 15:11:29 but who knows when they start shipping it out :) Mar 11 15:12:19 Real Soon Now Mar 11 15:12:40 hm, good Mar 11 15:12:47 heh Mar 11 15:13:01 That's why I like the devices I *know* are shipping. Mar 11 15:13:06 We can get them today. Mar 11 15:13:46 well, just hit the fast forward button ... Mar 11 15:14:10 One of those several-month retreats? Mar 11 15:14:36 heh, yeah Mar 11 15:15:45 a question in general: would a quadcore Cortex A9 actually be powerful enough to support: mdadm raid 5, trunked Gigabit Ethernet, 2 HDTV tuner cards (for a vdr backend without decoding)? Mar 11 15:16:42 if you find HDTV cards that fit into any ARM device ... Mar 11 15:17:05 are there HD USB tuner cards ? Mar 11 15:17:07 size doesnt matter, it is only about power consumption Mar 11 15:17:18 some but most are pcie or pci Mar 11 15:17:29 right, PCI is rare on ARM boards Mar 11 15:17:58 sockets at least Mar 11 15:18:29 There are USB HD DTV devices. Mar 11 15:18:34 mhm I guess I was a bit naive, thinking I could simply change my opteron board with a armsystem Mar 11 15:19:04 Well, there exist a few boards with PCIe, but nothing running those chips I've seen Mar 11 15:19:15 * persia has PCIe on an orion board Mar 11 15:19:29 there will surely be some server boards with a9 chips *soon* Mar 11 15:19:43 what do you mean by soon? Mar 11 15:19:45 those would have PCIe i assume Mar 11 15:20:02 johannes_, within the next 254 months ? Mar 11 15:20:02 Maybe. Maybe PCIx Mar 11 15:20:03 err Mar 11 15:20:05 24 :) Mar 11 15:20:18 No, 254 is definitely correct. 24 is a bet. Mar 11 15:20:25 mhm better than 254, but still a long time Mar 11 15:20:27 no idea ... i dont know how many companies wortk on server boards Mar 11 15:21:09 but a9 are definately somehting thats intresting for datacenters Mar 11 15:21:30 When ubuntu is installed on an arm system, can I use all the programs, that are available for x86 ubuntu too? Mar 11 15:21:31 johannes_: I suspect that what you want is a next-generation NAS box (for the raid), with the HDTV USB bits plugged in the back. Mar 11 15:21:51 This wouldn't be building it yourself, but is probably the earliest purchase option. Mar 11 15:22:19 johannes_: There's a couple hundred packages that don't work right now, but we try to get that as close to zero as we can. Mar 11 15:22:32 johannes_, yes, the majority works on arm as on x86 Mar 11 15:22:34 I would prefer if it was still more pc than NAS, as I like to try things out with linux Mar 11 15:22:44 that sounds great Mar 11 15:23:16 what about drivers? (for tuner cards) can they simply be installed or do I need special ones? Mar 11 15:23:28 johannes_: The difference between a "Small form factor PC" and a "NAS box" is a USB keyboard and a USB Display module :) Mar 11 15:24:10 johannes_, as long as there are linux drivers they should just work Mar 11 15:24:13 For USB tuner cards, the same drivers should work for any architecture. For other tuners, you may need to do some tweaking. Mar 11 15:24:16 johannes_: openrd board comes with one PCIe slot Mar 11 15:24:28 I look it up Mar 11 15:24:39 suihkulokki, but can the CPU do HD processing ? Mar 11 15:25:05 though its a backend ... probably thats not actually needed if the card is powerful Mar 11 15:25:07 ogra: didn't he say we won't do decoding ? Mar 11 15:25:10 suihkulokki: That's the ARMv5 chip that's in the SheevaPlug, right? Mar 11 15:25:36 persia: which is good enough for the usecase. Mar 11 15:25:57 Absolutely. Just wanted to confirm my reading. Mar 11 15:26:00 suihkulokki, well, recording and streaming i guess Mar 11 15:26:20 basically streaming only Mar 11 15:27:35 oviously thing like recompressing streams or analyzing + cutting out ad breaks is out of question with any arm cpu Mar 11 15:27:48 dmart: *sigh*, how best do we draft this email? Mar 11 15:30:04 I will look a bit more and then send you something... But I think the code in armhelper.s is a fairly straightforward trampoline in which case the solution might not be too complicated. Too early to say though... Mar 11 15:32:12 how about using a network tuner like hd homerun Mar 11 15:34:05 i think thats only DVB-T Mar 11 15:34:22 there are no german HD channels over DVB-T Mar 11 15:34:31 k Mar 11 15:34:46 (assuming johannes_ is german after he spoke german here :) ) Mar 11 15:35:06 wikipedia claims there are 4 modles of which only one is DVB-T Mar 11 15:35:34 I use the US version Mar 11 15:35:48 persia, the german version is DVB-T only afaik Mar 11 15:36:10 Ah. Mar 11 15:38:22 yes, I am german and thing is: I already got myself a skystar hd2 for the server I am using right now Mar 11 15:44:25 NCommander, ramana: The code which looks interesting is in: Mar 11 15:44:43 bridges/source/cpp_uno/shared/vtablefactory.cxx Mar 11 15:44:57 bridges/source/cpp_uno/gcc3_linux_arm/cpp2uno.cxx Mar 11 15:45:03 bridges/source/cpp_uno/gcc3_linux_arm/armhelper.s Mar 11 15:45:15 (if you want to look and didn't already look at one of those) Mar 11 16:23:58 NCommander: hi again Mar 11 16:24:17 dmart: Yes, that's the uno2cpp bridge, and it's what upstream told me was likely broken Mar 11 16:25:39 dmart: hola again Mar 11 16:25:54 Hi there... I was just chatting for ramana and matt Mar 11 16:26:12 We now understand better what privateSnippetExecutor is doing Mar 11 16:26:27 and we think we have a fix: http://pastebin.ubuntu.com/393376/ Mar 11 16:26:42 (i.e., delete 2/3 of the function :P ) Mar 11 16:26:46 dmart: O_o; Mar 11 16:26:58 dmart: Amazing! Mar 11 16:27:03 that will be one hell of a fix if it works Mar 11 16:27:09 This may just expose the next bug :/ Mar 11 16:27:19 Could you give it a try? Mar 11 16:27:26 haha Mar 11 16:27:29 My OOo build will take some more days to finish... Mar 11 16:27:32 funny fix :) Mar 11 16:27:56 * dmart admits that we did change a couple of lines as well as deleting some Mar 11 16:28:30 !ohmy Mar 11 16:28:31 Please remember that all Ubuntu IRC channels share the same attitude of providing friendly and polite interaction with all users of all ages and cultures. Basically, this means no foul language and no abuse towards others. Mar 11 16:28:33 dmart: incremently building, please stand by Mar 11 16:29:07 persia: where was the language violation? Mar 11 16:29:12 Basically, the unwinder doesn't need to see this function at all if we tail-call optimise it (i.e., just jump to cpp_vtable_call and let it worry about the return) Mar 11 16:29:33 persia, if i would mention it in a religious context would you also "ohmy" me ? Mar 11 16:29:46 ogra: No. Mar 11 16:30:01 so why do you do it in this context ? Mar 11 16:30:22 (but if I don't ohmy people in #ubuntu-* I may get chastised by those who oversee me keeping the channels open) Mar 11 16:30:44 dmart: we MAY have a winner Mar 11 16:30:44 stand by Mar 11 16:30:48 ogra: IRC guidelines for #ubuntu-*. I don't personally really care, but I like having IRC channels :) Mar 11 16:31:05 Ummm, actually, who was the ohmy for? If no-one can tell it will just cause confusion... Mar 11 16:31:09 thats a pretty silly rule Mar 11 16:31:23 dmart, that will be one hell of a fix if it works Mar 11 16:31:38 (risking another ohmy) Mar 11 16:32:09 * dmart kpees smoe fngries cssoerd but it mkeas it hrad to tpye Mar 11 16:32:15 heh Mar 11 16:33:02 * persia should get better at passing | to the bot Mar 11 16:33:17 NCommander: it would also be interesting if you can shove this patch into your current working distro+libs+OOo combination and see whether it breaks anything Mar 11 16:34:00 If not, pushing the patch is a no-brainer because is provides some cleanup, and also will avoid the risk the current code has of an incoming signal corrupting the stack Mar 11 16:34:31 dmart: buildingnow Mar 11 16:34:39 (with g++ 4.4/binutils 2.20) Mar 11 16:35:15 =lucid? Mar 11 16:35:28 dmart: kmaric Mar 11 16:35:36 Oh, right Mar 11 16:35:36 ladies and gentleman Mar 11 16:35:36 IT WORKS! Mar 11 16:35:42 \o/ Mar 11 16:35:42 (also tested on lucid) Mar 11 16:35:43 well, try lucid Mar 11 16:35:49 hooray !!!! Mar 11 16:35:50 * lool thinks the ARM folks deserve some Champagne Mar 11 16:35:52 Ooo works, or just builds? Mar 11 16:35:56 dmart: works Mar 11 16:36:08 Wow, cool :D Mar 11 16:36:11 lool, free beer for dmart and his team for the whole UDS i'D say ! Mar 11 16:36:22 ogra: +1 Mar 11 16:36:24 What, I have to wait till then :( Mar 11 16:36:35 dmart: we don't have beer transport over IRC Mar 11 16:36:35 * ogra send some virtual beer right now Mar 11 16:36:41 dmart: how'd you figure out to reduce armhelper.s to what it is now? Mar 11 16:36:46 Someone uploads to lucid? Mar 11 16:36:48 * NCommander quite envious to cracked this so quickly Mar 11 16:36:48 *german* beer Mar 11 16:36:49 Save some for ramana and matt, this was definitely a collaborative effort Mar 11 16:37:10 free beer for anyone who touched this bug Mar 11 16:37:16 dmart, so i hope we'll see them in brussels Mar 11 16:37:19 lool: someone has to dump it into ooo-build upstream. OOo in lucid has no patch system of its own Mar 11 16:37:31 * NCommander goes to grab ccheney Mar 11 16:37:43 NCommander, heh, then i'd get the most beer, i filed it :P Mar 11 16:37:57 touching really doesnt count :) Mar 11 16:38:17 ogra: we can just make david file it as expense. Brain damage remover! Mar 11 16:38:33 NCommander: looking at the call too privateSnippetExtractor, we observed that it does nothing after the call to cpp_vtable_call, except to tidy up a stack frame which is only needed at all because it was set up Mar 11 16:38:59 ...so we just branch to cpp_vtable_call. cpp_vtable_call's return later goes straight back to the original caller. Mar 11 16:39:08 dmart: thats clever Mar 11 16:39:14 It's basically a jump trampoline I guess Mar 11 16:39:26 Because there's no return address on the stack pointing into privateSnippetExecutor, the unwinder doesn't need to know about it at all Mar 11 16:40:11 dmart: so the unwinder was the root cause of the problem, and you just made privateSnippetExecutor disappear? Mar 11 16:40:56 When an exxception occurs, the unwinder saw that there was a pending return into privateSnippetExecutor, but didn't know how to unwind that function Mar 11 16:41:23 But since no state needs restoring anyway, we can have the unwinder skip it completely simply by not returning to it. Mar 11 16:42:07 dmart: wow. thats clever Mar 11 16:42:10 * NCommander feels humbled Mar 11 16:42:16 ^in the precense of greatness Mar 11 16:47:17 dmart: you guys fixed it? Mar 11 16:48:50 asac: That's the theory : we have to do the upload / builder / install dance to 100% verify. Mar 11 16:49:22 yep Mar 11 16:49:39 NCommander: patch attached to bug? ooo target opened? Mar 11 16:50:07 asac: I just poked ccheney to add it to ooo-build Mar 11 16:50:35 yeah saw in -deesktop Mar 11 16:50:48 dmart: plenty of kudos to whoever was involved in this!! Mar 11 16:52:07 Since we don't really understand OOo, I don't understand much about exceptions and we couldn't debug or test this locally, I'll certainly be happy if it works ;) Mar 11 16:52:34 I passed on the good news to ramana and matt here Mar 11 16:55:33 dmart: lets call it a successful joint effort between Canonical-ARM in futhering the position of ARM on the desktop. Regardless, this wouldn't have been possible without you, ramana and matt :-) Mar 11 16:57:59 Well, the OOo community might have fixed it, but it's harder to persuade upstreams to undertake that when we're not sure whether the real problem is a tools issue or something else. Mar 11 16:58:14 dmart: the arm port isn't actually upstream, it's a fedora patch Mar 11 16:58:25 * dmart anticipates a shiny new .deb to confirm all this Mar 11 16:58:33 lool: its partially upstream, but not considered a priority by OOO as far as I can tell Mar 11 16:58:45 half of it is in their CVS, the other half is in ooo-build Mar 11 16:59:22 Anyway, hopefully they'll accept the patch without problems; it cleans up some code if nothing else. Mar 11 16:59:54 ...and we still think the old code wasn't signal-safe Mar 11 17:01:20 ramana: take a bow :) Mar 11 17:02:20 *clap* *clap* *clap* *clap* *clap* *clap* Mar 11 17:02:28 :) Mar 11 17:05:06 Thanks but the credit is actually due to Matt and the others in the team who spotted the differences with respect to the frame. Mar 11 17:05:55 Well, it was a shared effort... Mar 11 17:06:03 NCommander: thanks to you too Mar 11 17:06:26 dmart: Oh I'm sure the maintainer of that piece of code will welcome it heartily Mar 11 17:06:28 dmart: I just figured out how build the beast Mar 11 17:06:51 I'm pretty sure it's going to hit the next RHEL and I think they care about the ARM port there Mar 11 17:08:14 thanks to me too! Mar 11 17:08:35 ;) Mar 11 17:09:34 mgretton: quick, take some credit before it's all gone! Mar 11 17:19:19 ogra: ping - I've got an issue with building from rootstock and the wiki says to come and talk to you... Mar 11 17:19:54 whats the issue ? Mar 11 17:22:20 ogra: I'm using a Lucid VM to build a lucid image, and it got as far as unpacking libglibmm but has been hung for the last two (ish_) hours after outputting the message 'udevd[45]: specified user 'usbmux' unknown' Mar 11 17:22:44 that message is there three times Mar 11 17:22:45 yeah, known bug (and no fix yet) Mar 11 17:23:08 bug 532733 Mar 11 17:23:09 Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733 Mar 11 17:23:18 ogra: so for now, there's not a way to build a lucid image that requires libglibmm? Mar 11 17:23:39 ogra: thanks Mar 11 17:23:46 Who_, build an image with ubuntu-minimal for now, then just apt-get install waht you need on real HW Mar 11 17:24:09 minimal definately works Mar 11 17:24:20 ogra: yep - I was just modifying my script :) Mar 11 17:24:55 ogra: do you know much about sound on Beagle/IGEP? Mar 11 17:24:58 its some mystical qemu issue i'm not able to track down properly Mar 11 17:25:05 or can you point me to someone who does? Mar 11 17:25:27 no, sadly not, rcn-ee builds the beagle kernel package, he might at least know the kernel side Mar 11 17:26:03 ogra: it doesn't seem to be kernel related: I've got an 9.04 image (shipped with device) that has working sound and my 9.10 rootstock (using the same kernel and modules) doesn't work... Mar 11 17:26:21 NCommander, so since you like to dig into the odd bugs ... i'm lost on bug 532733, probably you have any ideas Mar 11 17:26:22 Launchpad bug 532733 in qemu-kvm (Ubuntu) "apt/dpkg in qemu-system-arm hangs if a big task is installed (affects: 1)" [Medium,Incomplete] https://launchpad.net/bugs/532733 Mar 11 17:26:25 dmart: what do we want to call teh patch? Mar 11 17:26:47 Who_, try to create an audio group and add your user to it Mar 11 17:27:26 NCommander: dmart: Also, to whom should be given author attribution? Mar 11 17:27:48 ogra: also, while I'm thinking about it... I made this for myself: https://launchpad.net/rfsm - I don't know if it is of any interest more generally - but if there's now a good way to tie it in to the rootstock system I should look at doing that... (I notice rcn-ee seems to be using a --script command) Mar 11 17:28:27 Who_, rootstock in lucid has the --script option Mar 11 17:29:33 Who_, even the new gui has the option to select a post install script :) Mar 11 17:30:44 ogra: okay, I'll try and tie in with that Mar 11 17:31:02 ogra: also, audio group already exists. I'll keep digging on the sound issue Mar 11 17:31:52 NCommander: How about "privateSnippetExtractor simplification to avoid exception unwind failures and stack corruption risk" ? Mar 11 17:32:19 or Mar 11 17:32:21 "privateSnippetExtractor simplification to avoid exception unwind failures and stack corruption risk on ARM" Mar 11 17:32:50 Ideally we want a name that can also be a filename :) Mar 11 17:33:05 That looks like a Description: entry for DEP3 Mar 11 17:33:26 branch_directly_to_cpp_vtable_call_on_arm.patch Mar 11 17:33:32 and dmart's description Mar 11 17:33:42 Just needs Author: then. Mar 11 17:33:43 Yeah, sounds ok Mar 11 17:33:58 "the arm guys" Mar 11 17:34:18 It's supposed to be a person who can grant license for reuse in the project, etc. Mar 11 17:34:30 silly tort law to work around silly copyright law, etc. Mar 11 17:49:02 I'm going to spend my day porting this: http://community.livejournal.com/openvz/24651.html to Lucid Mar 11 17:49:39 I think that a bunch of that work was already done Mar 11 17:49:41 Martyn, openvz was rejected from the ubuntu kernel Mar 11 17:49:42 * persia hunts for the bug Mar 11 17:50:07 ogra : I know, but I need to get it working for a demonstration of virtualization on the A9 Mar 11 17:50:12 ogra : Rejected or not ... Mar 11 17:50:34 then you likely need to maintain your own kernel as well Mar 11 17:50:43 Because OpenVZ is the Path of Least Resistance .. unless you have a suggestion for a better container solution? Mar 11 17:51:07 ogra : I already do ... the Versatile2 is anything but supported... Mar 11 17:51:18 whats versatile2 ? Mar 11 17:51:35 ogra : Quad core a9 platform from ARM .. I showed one off at UDS Mar 11 17:51:44 now generally available Mar 11 17:51:49 ah, you call it versatile ? Mar 11 17:51:52 heh Mar 11 17:51:54 * persia can't find the bug Mar 11 17:51:57 That's it's final name "Versatile2" Mar 11 17:52:06 (our internal codename for it is 'crandall') Mar 11 17:52:16 i like the internal one more :) Mar 11 17:52:32 persia : If you happen to come across it, ping me : martin@smooth-stone.com Mar 11 17:52:37 Versatile makes me thing of qemu which makes me think of underpowered Mar 11 17:52:40 "Versatile2" is too easy to confuse with the qemu target. Mar 11 17:52:59 Martyn: I'm not likely to, since I didn't find it in a search. Mar 11 17:53:00 persia : The QEMU target is a simulation of /real/ hardware, called versatile :) Mar 11 17:53:12 Ah! Mar 11 17:53:13 Martyn, which is underpowered as well :) Mar 11 17:53:20 There are various models over time .. Versatile PB, PBX, EB ... Mar 11 17:53:28 (EB is the current generation -- Cortex-A9) Mar 11 17:53:49 ogra : hey, don't scoff at a 400MHz quad core processor. It's pretty snazzy Mar 11 17:53:58 heh, ok ok Mar 11 17:54:08 ogra : And I've already got another, faster platform to play with now too -- tegra2 Mar 11 17:54:12 i'm waiting for the 1GHz quad cores Mar 11 17:54:20 yeah Mar 11 17:54:26 i'd love a tegra2 Mar 11 17:54:32 its the future ! Mar 11 17:54:34 ogra : We're targeting 1.6GHz now. Mar 11 17:54:54 ogra : If Global Foundries becomes available to us, the second rev of the chip will be shrunk and probably hit 2.2GHz Mar 11 17:55:00 * ogra thinks tegra2 will be the direct atom competiotor Mar 11 17:55:09 Martyn: Based on https://lists.ubuntu.com/archives/kernel-team/2010-March/thread.html I believe there's a git tree, but not a package. Mar 11 17:55:10 it's a nice chip, but has it's .. issues. Mar 11 17:55:20 indeed, nvidia built it :) Mar 11 17:55:34 persia : Git tree of a valid, running kernel is enough Mar 11 17:55:39 but i'd be willing to live with that drawback :) Mar 11 17:55:43 persia: that would save me -tons- of time Mar 11 17:56:06 ogra : I /need/ 8x PCIe .. and tegra2 doesn't have it Mar 11 17:56:13 only 1x and 4x Mar 11 17:56:28 you should really switch your servers to USB Mar 11 17:56:30 * ogra ducks Mar 11 17:56:58 persia : Looking at the threads, haven't found the mention of openVZ yet Mar 11 17:57:02 Martyn: Mail Kir for details : I didn't see a git repo listed. Mar 11 17:57:08 done already :) Mar 11 17:57:14 he has patches available for the overo Mar 11 17:57:15 There you go :) Mar 11 17:57:21 Cool. Mar 11 17:57:25 http://download.openvz.org/.kir/overo/kernel/ Mar 11 17:57:30 2.6.27 though Mar 11 17:57:30 Martyn, "OpenVZ kernel for Ubuntu 10.4" Mar 11 17:57:36 ids the thread name Mar 11 17:57:44 Martyn: If you get it all working, toss it in a PPA :) Mar 11 17:58:09 Yes, PPAs don't build for armel, but it means that anyone can build it easily from your source. Mar 11 17:59:11 rcn-ee: are you there? I've got a sound-on-igep question (I have no sound from aplay, but can by piping to /dev/dsp) and I'm making very little headway with just my head and Google. Mar 11 18:00:08 persia : You got it Mar 11 18:00:18 Martyn: Thanks. Mar 11 18:00:47 persia : although if it's integrated into Lenny, would I still have to build a PPA? (it's upstream at that point) Mar 11 18:01:05 ojn: You around? Mar 11 18:01:15 (we really need a messaging bot on channel :) ) Mar 11 18:01:25 Martyn: If it's in Lenny, people can grab from there and build, so it doesn't matter. Mar 11 18:01:30 Martyn: email? Mar 11 18:01:41 mine? Mar 11 18:01:48 martin@smooth-stone.com Mar 11 18:01:56 OH .. Mar 11 18:02:10 heh .. no, because I don't have everyone's email on channel Mar 11 18:02:30 there used to be a note-server capability on chanserv ... you could leave someone a sticky note that would be displayed when they next came on channel Mar 11 18:02:35 sort of like: Mar 11 18:02:46 chanserv, tell Mar 11 18:02:57 doesnt that still work ? Mar 11 18:03:05 however it's long gone... Mar 11 18:03:05 though its nickserv i think Mar 11 18:03:27 One can use /ms for that, I thnk Mar 11 18:03:32 (MemoServ) Mar 11 18:04:13 ah Mar 11 18:04:16 yeah Mar 11 18:04:54 /msg memoserv help ;) Mar 11 18:05:10 "/ms help" works Mar 11 18:05:57 /msg MemoServ SEND Martyn "get me a tegra2" Mar 11 18:06:00 ;) Mar 11 18:06:24 "/ms send Martyn" is *shorter* and *easier* :p Mar 11 18:06:52 tsk ... you embedded folks Mar 11 18:07:02 *g* Mar 11 18:07:38 Me? Embedded? No. I happen to like 3.5-4" laptops, but I want full features. Mar 11 18:11:51 http://www.arm.com/products/tools/versatile-express.php Mar 11 18:13:35 Oh! We have a msgserv again! Mar 11 18:13:37 I had no idea :) Mar 11 18:13:47 me? Embedded? Mar 11 18:14:01 * Martyn points to the mid-sized tower with a Tegra2 mini-ITX board Mar 11 18:14:34 It's got 2 sata drives, a DVD burner, but is using the integrated graphics .. and a whole -2GB- of memory Mar 11 18:14:39 embedded my buttocks... Mar 11 18:15:04 Precisely. ARM != embedded. Mar 11 19:08:14 ogra (et al - anyone who will know): are there plans to change the build scripts for some packages in the arm repositories so they make 'more sense' on ARM - such as specifying EGL as or XEGL as the clutter backend? Mar 11 19:09:43 sorry - that should have been to ogra_cmpc, I guess ^ Mar 11 19:10:28 Are we sure that makes more sense for arbitrary hardware solutions? Mar 11 19:10:44 I'd much prefer not to align "armel" and "embedded" in any way. Mar 11 19:13:09 persia: interesting. do you know of any armel devices with full OpenGL support (just asking, not suggesting there aren't!)? Mar 11 19:13:55 persia: I guess though that there'd be no harm in a 'clutter-backend-egl' package or equivalent Mar 11 19:14:14 I know of armel devices with PCIe slots. Mar 11 19:14:25 Getting full OpenGL there is just a matter of driver testing. Mar 11 19:14:26 persia: and armel drivers for the cards? Mar 11 19:15:01 I also stuffed some DisplayLink drivers in the archive for lucid, for which I hear there are plans to grow OpenGL support upstream. That's USB, and arch-independent. Mar 11 19:15:21 persia: okie, sounds like changing the build isn't ideal Mar 11 19:15:24 Who_: Why not? No good reason any of the existing opensource drivers can't be ported. Mar 11 19:15:43 Who_: Well, maybe building twice and making two flavours of a binary is useful. Mar 11 19:16:01 persia: Sorry - I should be more clear - I was agreeing with you that making the default packages more 'embedded' didn't make sense Mar 11 19:16:02 That's just tricky, and it's important to identify which packages make sense for that, and how much work. Mar 11 19:16:29 but I think it would be helpful for people like me if there were some more embedded-target style packages built Mar 11 19:17:20 persia: and I guess you also then need to have some (likely non OS) graphics libraries on the build system to be able to compile? Mar 11 19:17:36 Right, that's why I say that in some cases, two flavours may make sense. Mar 11 19:17:55 I'm not sure I understand that last question. Mar 11 19:19:44 persia: My understanding is that in order to build Clutter with, for example, an EGL backend, you would need to have EGL development headers on the system - are there Open Source headers that you can link against, and then still get hw accelerated performance on systems that have hardware drivers? Mar 11 19:20:11 But I think the real solution for X is to have a more pluggable GL library, so that various libraries can register the ability to do various functions, using a GPU, CPU, DSP, etc. (whatever hardware happens to be available). Mar 11 19:20:41 Oh. I have no idea if there are open-source EGL headers available. Mar 11 19:26:06 persia: seems so http://www.khronos.org/registry/gles/ Mar 11 19:26:21 Cool. Mar 11 19:26:43 It's probably too late for lucid, but we ought be able to get that stuff into the next release. Mar 11 19:41:34 persia: sounds sweet Mar 11 19:42:28 persia: I made sound work on my IGEP, but the process was a bit... confusing... I'm not entirely sure I should have needed to do what I had to do (run .snddevices from the alsa-driver source package on the arm) - is it worth raising as a bug, or is it too device specific? Mar 11 19:42:52 persia: more specifically, I made aplay work. Pulseaudio is still unhappy Mar 11 19:44:02 It's worth filing as a bug. If you're not using a distro kernel, and it looks like a kernel thing, don't be too surprised if it gets rejected. Mar 11 19:46:03 persia: I _think_ it's a kernel thing - I don't know where the line between kernel and userspace is when it comes to alsa. I am using the kernel sources from the board manufacturere Mar 11 19:46:49 If you want help with investigation, file a bug :) Mar 11 19:46:57 Worst case someone tells you it's your kernel. Mar 11 19:47:05 :) Mar 11 20:07:52 persia: on further investigation, it seems udev is at fault, as it is supposed to create these devices. any new thoughts? Mar 11 20:08:16 If it's udev, file a bug. Mar 11 20:08:40 But udev mostly relies on kernel events, so it might be a kernel issue or a udev rules issue. Hard to say without looking closely. Mar 11 23:46:16 i followed the guide at http://elinux.org/BeagleBoardUbuntu page and im getting "Unhandled fault: external abort on non-linefetch (0x1018) at 0x40..." errors on booting my Beagleboard rev C4. im not new to coding, but im new to kernel debugging...help? Mar 11 23:49:05 Unfortunately, the best person to help you is rcn-ee, who tends to be idle at this time of day. Mar 11 23:50:18 sweet timing.. just walked in after work... Mar 11 23:50:27 Wonderful :) Mar 11 23:50:45 andruk, those errors are annoying, but safe to ignore.. Mar 11 23:51:07 aka i haven't debugged to figure out what it was, but it doesn't seem to affect anything.. ;) Mar 11 23:53:55 persia, just noticed this last night: https://wiki.ubuntu.com/KernelTeam/TopicBranches your kernel guys are going to be busy. ;) Mar 11 23:54:18 so they say :) Mar 11 23:54:33 rcn-ee: Feel free to jump into #ubuntu-kernel if you want to help push that effort. Mar 11 23:55:50 persia, of course.. ;) already queied my first patch https://code.launchpad.net/~beagleboard-kernel/+junk/lucid-ti-omap Mar 11 23:56:20 still need the beagle/iegp2 to boot before i open my mouth on ubuntu-kernel. ;) Mar 11 23:57:20 heh. Mar 12 00:08:34 rcn-ee: they may be safe to ignore, but they halt my booting process.... Mar 12 00:16:56 andruk, really? it shouldn't... could you pastebin your boot.scr? Mar 12 00:41:05 rcn-ee: sure, give me a sec Mar 12 00:50:08 rcn-ee: boot.scr: http://pastebin.com/SearKknE and boot process: http://pastebin.com/aGw0dzpf Mar 12 00:50:51 rcn-ee: im going to move to a friends house, so ill be offline for a bit, but ill be back on in about 15-30 mins. thanks for all your help. Mar 12 00:51:22 ah, it's bombing here: # Mar 12 00:51:23 [ 30.379852] EXT3-fs: Unrecognized mount option "error=remount-ro" or missinge Mar 12 00:51:28 what's your /etc/fstab list.. Mar 12 00:53:16 rcn-ee: errors=remount-ro is the correct syntax. note the missing "s" Mar 12 00:54:16 yeap, that should fix andruk's boot problem... Mar 12 00:54:45 so the question, did i miss type it somewhere on the wiki/fixup.sh script. ;) Mar 12 00:55:55 Nope, my wiki is clear, looks like copy paste error.. Mar 12 01:35:50 rcn-ee: back Mar 12 01:36:16 andruk, check your /etc/fstab, it looks like your missing an 's' in 'errors' Mar 12 01:43:05 rcn-ee: updated boot process failure: http://pastebin.com/mu0LGjvL Mar 12 01:43:21 rcn-ee: oh, wait, it actually does present me with a login... Mar 12 01:43:50 yeah, it takes a good 30 seconds, there's actually a package that optimizes it.. ;) Mar 12 01:43:53 sweet! Mar 12 01:46:10 rcn-ee: thanks so much. :-) now, would you happen to have a guide/walkthough/wiki/FAQ/forum/etc. (anything really) regarding exposing an SPI device to userspace so i can get hacking on interfacing with a few sensors? Mar 12 01:48:28 Sorry andruk, not really... Other then writing an application for i2c access, i haven't done much other then getting the kernel to work... Mar 12 01:49:01 sweet! my x2 545 is now a x4.. time to start cross building.. ;) Mar 12 01:53:17 rcn-ee: cool, thanks anyway, i really appreciate the help. i will be looking into eliminating that error; ill let you if i find anything (I assume you are rcn-ee.com and Robert Nelson on the mailing list?) Mar 12 01:54:45 your welcome, yeap that's me... that would be cool, it's some package.. if you want a big challenge on lucid right now there are like 3-4 annoying errors messages.. ;) Mar 12 02:59:01 plars: paul, thanks for the testing, i got your bug post Mar 12 02:59:21 cooloney: which one was that? Mar 12 02:59:21 plars: the suspend regression might be related to the patch for kexec Mar 12 02:59:46 plars: one is the suspend regression, the other is the usb cause crash **** ENDING LOGGING AT Fri Mar 12 02:59:57 2010