| === debio264__ is now known as debio264 | ||
| napster | I've a tarball of the root file system | 03:46 |
|---|---|---|
| napster | How to transfer it to the board? | 03:46 |
| napster | And how to extract it there? | 03:46 |
| napster | jussi01, ? | 03:47 |
| napster | What is actually a uImage? | 03:49 |
| napster | !hawkboard | 03:58 |
| ubot4 | Factoid 'hawkboard' not found | 03:58 |
| napster | !angstrom | 03:58 |
| ubot4 | Factoid 'angstrom' not found | 03:58 |
| napster | ANYONE CAN HELP ME OR ATLEAST RESPOND??? | 03:59 |
| persia | Bother. Had to be a Tuesday :( | 09:02 |
| kblin | persia: they call it stormy monday, but tuesday's just as bad? :) | 09:42 |
| persia | 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. | 09:43 |
| persia | 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 :) | 09:44 |
| kblin | I see :) | 09:46 |
| * ogra pokes the builder "come on glib ... paddle faster !" | 11:29 | |
| asac | boing | 11:32 |
| asac | ogra: how can we best produce a log of info about failed/succeeded image builds? | 11:33 |
| persia | asac: We can get that from Soyuz. What do you need? | 11:33 |
| ogra | image or livefs builds ? | 11:33 |
| asac | at best both | 11:33 |
| persia | asac: And how do you want it presented? | 11:33 |
| asac | i would think image comprises livefs | 11:33 |
| asac | so if livefs fails and image suceeds we have a problem | 11:34 |
| persia | Oh, images. We can get those from people.canonical.com | 11:34 |
| asac | persia: a daily log table | 11:34 |
| asac | like: row: date / column: arch/subarch | 11:34 |
| persia | asac: Why is it a problem if livefs fails and image succeeds? That happens for most livefs failures. | 11:34 |
| asac | and then just "green" ... "red" | 11:34 |
| asac | with link to the logs if available | 11:34 |
| ogra | 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 | 11:35 |
| asac | persia: how does image succeed if no livefs is produced? | 11:35 |
| persia | That's not hard to implement, but it'd be easiest to implement *inside* the build-system. | 11:35 |
| persia | asac: It uses the old livefs. | 11:35 |
| asac | right thats what i thought (inside) | 11:35 |
| ogra | persia, we have the mails ... we could add a ML to ubuntu-armel | 11:35 |
| ogra | the prob is that you cant filter them by arch easily | 11:35 |
| asac | 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 | 11:35 |
| ogra | at least server side | 11:35 |
| asac | 2. log info about livefs failure/success | 11:36 |
| ogra | the cronjob never changes | 11:36 |
| asac | 3. log info about image failure/success | 11:36 |
| ogra | we know when it starts | 11:36 |
| ogra | 2 and 3 are alreasdy existing | 11:36 |
| asac | ogra: yes, but something has to seed the info | 11:36 |
| asac | ogra: where? | 11:36 |
| ogra | just not merged/parsed automatically | 11:36 |
| persia | 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. | 11:36 |
| asac | where is the raw data | 11:36 |
| asac | with just date/imageid: FAIL/SUCCESS | 11:36 |
| ogra | for the livefs on the live builder | 11:37 |
| ogra | for the image builds its on antimony | 11:37 |
| asac | persia: yes. just wanted to understand what parts we need | 11:37 |
| asac | ogra: what format do those files have? | 11:37 |
| ogra | what you see on peole is an exact mirror of either of them | 11:37 |
| ogra | txt | 11:37 |
| ogra | *people | 11:37 |
| asac | and yes, i figure that we probably hav that. i just want it to be exported in a parsable fashion | 11:37 |
| asac | ogra: where? | 11:37 |
| ogra | http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ | 11:37 |
| ogra | for the livefs | 11:37 |
| asac | those are the logs | 11:37 |
| asac | those dont say: "fail/success" | 11:38 |
| asac | thats not that useful | 11:38 |
| ogra | http://people.canonical.com/~ubuntu-archive/cd-build-logs/ for the images | 11:38 |
| asac | we need to publish the exit code | 11:38 |
| asac | with date | 11:38 |
| ogra | as i said, you need to parse them | 11:38 |
| ogra | for the image builds there exists a mail function | 11:38 |
| asac | well. thats too difficult. too many things can happen | 11:38 |
| ogra | antimony mails about failures | 11:38 |
| asac | if it would print "exited (code=X) | 11:38 |
| asac | " | 11:38 |
| asac | that would be ok | 11:38 |
| ogra | but thats not easy to filter | 11:38 |
| persia | May I? | 11:39 |
| ogra | since it only mails per-flavour, not per arch | 11:39 |
| asac | right. in short. that info isnt there ;) | 11:39 |
| ogra | it is | 11:39 |
| asac | makes no sense to write an ever greowing parser of the logs | 11:39 |
| asac | persia: go ahead ;) | 11:39 |
| ogra | its just not broought to the right people atm :) | 11:39 |
| persia | So, let's alter the scripts that build stuff to make a shortlog, and publish the shortlog. | 11:39 |
| asac | ogra: this discussion is about what to do ;) | 11:39 |
| persia | We can then parse the shortlogs, and build the reports we want. | 11:39 |
| asac | persia: shortlog is good. or a good parseable tag at the end of the log | 11:40 |
| ogra | as i said, thats already there for the image builds | 11:40 |
| asac | like: EXITCODE====1 ;) | 11:40 |
| persia | asac: Can't do that: the logs are per-flavour | 11:40 |
| asac | ogra: its not there, because i dont see it on the web | 11:40 |
| ogra | asac, you could get it by mail | 11:40 |
| asac | ogra: right. but thats not the preferred way | 11:40 |
| ogra | but as i said above its lacking filtering on subarches | 11:40 |
| asac | we want something parsable through http ;) | 11:40 |
| asac | persia: you say there is no common code? | 11:41 |
| ogra | asac, right | 11:41 |
| asac | or you dont want to add that to logs of other flavours? | 11:41 |
| ogra | its only per flavour | 11:41 |
| ogra | not per subarch | 11:41 |
| persia | asac: I say that the logs don't currently have enough information in a format that is easily extracted. | 11:41 |
| asac | persia: yes. | 11:41 |
| asac | so we alter the scripts to either add something easily parsable there | 11:41 |
| ogra | i.e. all ubuntu-netbook failures are the same atm ... there is no distinction between i386, ppc, armel etc | 11:41 |
| asac | or we produce shortlogs ;) | 11:41 |
| persia | 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. | 11:42 |
| persia | ogra: That's not precisely the case, although they are in the same log. | 11:42 |
| asac | ack ... if that doesnt kick off loads of things | 11:42 |
| asac | to do | 11:42 |
| asac | and coordinate i am for shortlogs | 11:42 |
| persia | RIght. | 11:42 |
| ogra | its quite complex and requires a lot of debian-cd hackery | 11:42 |
| asac | persia: can you check how much work that would be ? | 11:43 |
| ogra | effectively what you want it to turn the mial function into a spit-out-log-to-http function | 11:43 |
| ogra | but you need to additionally write a filtering for arch/subarch | 11:43 |
| asac | that feels too difficult | 11:43 |
| persia | asac: To expose the shortlogs? Sure. | 11:44 |
| ogra | but thats the place to add it | 11:44 |
| asac | i want to fix the place that currently execs the image/livfs process | 11:44 |
| asac | that place should just check exit code | 11:44 |
| ogra | debian-cd has that feature already | 11:44 |
| asac | and produce a log | 11:44 |
| persia | ogra: You're complicating things. let's get shortlogs, and parse them in some other script. | 11:44 |
| ogra | it simply doesnt filter and doesnt spit out http | 11:44 |
| asac | if it already has that place, then its easy to do ;) | 11:44 |
| ogra | yes, it just mails the short logs | 11:44 |
| asac | i agree with persia ... lets let him check ... i would epxect this to be trivial if someone knows the details | 11:44 |
| * ogra knows the details | 11:45 | |
| ogra | i worked through that with StevenK before | 11:45 |
| asac | if we already send the mails, then its really easy | 11:45 |
| ogra | more than one time | 11:45 |
| asac | just push them in a file ;) | 11:45 |
| ogra | and we decided that adding the filtering was quite complex... | 11:45 |
| persia | Right. We don't need the filtering. | 11:45 |
| persia | We just need shortlogs. | 11:45 |
| ogra | that wont help much for armel | 11:46 |
| persia | Yes it will. | 11:46 |
| ogra | sinc eits still just by flavour | 11:46 |
| persia | I can write a parser for shortlogs in a day. | 11:46 |
| persia | As long as the shortlog has a machine-readable format. e.g. flavour:arch:result | 11:46 |
| persia | (probably less than a day, but still) | 11:47 |
| asac | date | 11:47 |
| asac | ;) | 11:47 |
| asac | or buildid | 11:47 |
| * ogra doesnt remember anymore and tries to dug up some edubuntu failure mails | 11:47 | |
| asac | needs to be a column | 11:47 |
| ogra | the mail contains the full log :/ | 11:47 |
| ogra | for all arches | 11:48 |
| ogra | so that wont help without having a parser | 11:48 |
| ogra | its like 1MB big only for a failed edubuntu build for all arches | 11:48 |
| persia | ogra: Right. I don't want the mail. I want to be able to get shortlogs from people.canonical.com/~ubuntu-archive/*-build-logs/... | 11:48 |
| ogra | persia, so you screen scarep the files ? | 11:48 |
| persia | and I want the logs to go in the appropriate dated directories, etc. | 11:48 |
| ogra | *scrape | 11:48 |
| asac | we can make a good html page out of such shortlogs and rss feeds etc. | 11:49 |
| persia | ogra: No. I don't want HTML. I want files specifically designed to be consumed by a program at deterministic URIs. | 11:49 |
| asac | i really would like to have info about kicked off builds though | 11:49 |
| asac | e.g. just build-id | 11:49 |
| asac | in that way we can see if stuff is overdue and display a big burning icon ;) | 11:49 |
| asac | but thats nice to have ;) | 11:49 |
| ogra | cron gets that info ... (or whoever fires off a build manually) | 11:49 |
| ogra | its two lines per flavour | 11:50 |
| asac | right. so lets add that to the wanted feature list for shortlogs | 11:50 |
| persia | asac: That's less interesting, because of how it works. | 11:50 |
| ogra | build started on livebuilder <blah> at 12:34:56 etc | 11:50 |
| ogra | build succeeded on livebuilder <blah> at 15:34:56 etc | 11:51 |
| asac | 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. | 11:51 |
| ogra | thats what you get if you fire off a manual build | 11:51 |
| asac | or never even lead to a log | 11:51 |
| ogra | and these lines whould be in the logs if cron execs them | 11:51 |
| ogra | *should | 11:51 |
| asac | yeah. that thing could create a shortlog entry then | 11:51 |
| ogra | right | 11:52 |
| ogra | but i dont think we have access to the logs cron writes to | 11:52 |
| ogra | at least not the cdimage team | 11:52 |
| ogra | cjwatson would know | 11:52 |
| asac | yes. thats the other question. we need to get the logs we produce to a public location | 11:52 |
| * ogra checks on antimony | 11:52 | |
| asac | maybe it just publishes a full dir or something that is produced by the parts | 11:53 |
| asac | that would make things easy ;) | 11:53 |
| asac | if it just copies the log there needs some work done | 11:53 |
| ogra | nope, no access to syslog or messages on the builder machine | 11:54 |
| asac | i dont see why we want to access those logs | 11:54 |
| ogra | because they have the one line info you want from cron | 11:55 |
| asac | we would need to produce a log file wherever the main log goes | 11:55 |
| asac | ogra: right the hook should happen in whatever script is run rather than relying on that | 11:55 |
| ogra | its crond | 11:55 |
| asac | what script does that run? | 11:55 |
| asac | anyway, details. lets wait for persias eval ;) | 11:56 |
| persia | What eval? | 11:56 |
| ogra | ARCHES='armel+imx51 armel+dove' buildlive ubuntu-netbook && ARCHES='armel+imx51 armel+dove' for-project ubuntu-netbook cron.ports_daily-live | 11:56 |
| ogra | thats our cron line | 11:56 |
| asac | persia: checking what it would take to get shortlogs | 11:56 |
| asac | e.g. what needs to be done, how much time is it etc. | 11:56 |
| persia | Oh, sure. I was just going to bother a different member of the cdimage team. ogra is a fair candidate. | 11:56 |
| asac | thought you signed up for evaling that ;) | 11:56 |
| ogra | so you need to edit buildlive for putting the info into some place additionally to writing to stdout | 11:56 |
| asac | ogra: yep | 11:57 |
| asac | ogra: if you manually kick a build off it also runs buildlive? | 11:57 |
| ogra | additionaly you need to edit for-project | 11:57 |
| persia | ogra: That's just >&3 though. | 11:57 |
| asac | what about buildalternative etc.? do such scrpts exist? | 11:57 |
| ogra | which will be a lot more complicated | 11:57 |
| ogra | for-project is highly modular | 11:57 |
| ogra | asac, no, for-project does everything realted to image building ... that includes alterante and live | 11:58 |
| asac | right. but if there is an initial point of entry that feels like the right place to put the "started" log | 11:58 |
| asac | for-project might be a candidate? | 11:58 |
| ogra | buildlive just creates the livefs | 11:58 |
| asac | we also want to know about that ;) | 11:58 |
| ogra | you need to edit both if you want info for both+ | 11:58 |
| asac | yeah | 11:58 |
| asac | we want started for buldlive and started for for-project | 11:59 |
| ogra | buildlive should be easy to achive | 11:59 |
| asac | and whatever other variant might exist | 11:59 |
| asac | i think buildlive would be most essential | 11:59 |
| ogra | its only these two | 11:59 |
| asac | thats the starting point | 11:59 |
| ogra | persia, buildlive is in livecd-rootfs iirc | 11:59 |
| asac | then with the "exit" results for the livefs build and the image fs production scripts | 11:59 |
| asac | that would give us all we need i think | 11:59 |
| ogra | that should be the easiest | 12:00 |
| persia | asac: It's not really exit codes: it's more complex than that, but that's the idea. | 12:00 |
| persia | ogra: So, how much effort does this shortlog creation involve? | 12:00 |
| ogra | oh, buildlive isnt in livecd-rootfs, i lied :) | 12:02 |
| ogra | thats BuildLiveCD | 12:02 |
| * ogra checks on antimony | 12:02 | |
| NCommander | ogra: its there, its installed into /usr/share (and it was in the source package) | 12:30 |
| ogra | NCommander, hmm ? | 12:30 |
| NCommander | ogra: BuildLiveCD is in the livecd-rootfs package | 12:30 |
| ogra | sure | 12:30 |
| ogra | thats what i said above | 12:31 |
| NCommander | ogra: you just said it wasn't O_o; | 12:31 |
| * NCommander makes another interesting OOo discovery | 12:31 | |
| persia | Doesn't matter. | 12:31 |
| napster | Can anyone help me to install on hawkboard? | 12:32 |
| ogra | <ogra> oh, buildlive isnt in livecd-rootfs, i lied :) | 12:32 |
| ogra | <ogra> thats BuildLiveCD | 12:32 |
| persia | napster: That's an ARM920T, right? | 12:32 |
| ogra | NCommander, ^^^ | 12:32 |
| napster | persia, I think its OMAP L138 | 12:32 |
| NCommander | ogra: oh, I read that as you typoed on buildlive, and meant that BuildLiveCD isn't in livecd-rootfs | 12:33 |
| NCommander | EPARSERFAIL | 12:33 |
| ogra | heh | 12:33 |
| ogra | buildlive is part of debian-cd i think | 12:33 |
| persia | napster: OK. That can run Ubuntu Jaunty, but nothing newer, and requires a custom kernel. | 12:33 |
| persia | napster: So, do you have a known working kernel >= 2.6.28 ? | 12:34 |
| ogra | http://blog.binaerwelt.com/2010/02/ubuntu-on-the-hawkboard/ | 12:34 |
| persia | Even better :) | 12:34 |
| napster | persia, Not yet, (I'm new can you be a little bit simpler?) | 12:34 |
| * ogra slowly starts to know all the places where rootstock is mentioned :) | 12:35 | |
| ogra | (and they get more every day it seems :) ) | 12:35 |
| persia | napster: Try the link ogra referenced. There are no images, so that install is very much a do-it-yourself thing. | 12:35 |
| lool | ogra: No, of cdimage | 12:37 |
| ogra | oh, ok | 12:37 |
| persia | 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. | 12:38 |
| napster | persia, ok, will be back to you when I'm stuck :) | 12:41 |
| persia | napster: Good luck. | 12:41 |
| === asac_ is now known as asac | ||
| === dl9pf_ is now known as dl9pf | ||
| NCommander | dmart: ping? | 14:06 |
| NCommander | dmart: I need to poke a toolchain expert's brain | 14:07 |
| dmart | Hi... hang on, I'll see if Ramana's around. | 14:08 |
| NCommander | hey ramana | 14:10 |
| ramana | hi NCommander. I'm just about to go get a shower. Can I chat with you in about 10 minutes. | 14:11 |
| ramana | ? | 14:11 |
| NCommander | ramana: sure, I'm going to go then run towalmart, so I'll beback in 20 :-) | 14:11 |
| lool | I wonder whether we might be stripping .debug_frame and that would cause the unwind failures (oops) | 14:29 |
| lool | dmart: Do you know how to test/list .debug_frame presence/contents? | 14:31 |
| lool | or ramana ^ | 14:31 |
| dmart | lool: Probably best to wait for ramana to answer this one. | 14:31 |
| lool | If we have a bug in strip or dh_strip, we're in trouble I tell you | 14:32 |
| lool | We call strip --remove-section=.comment --remove-section=.note --strip-unneeded on shared libs | 14:32 |
| lool | and strip --remove-section=.comment --remove-section=.note on binaries | 14:33 |
| lool | (and strip --strip-debug on static libs) | 14:33 |
| persia | Do all of those get shoved into -dbgsym packages, or is it more complicated than that? | 14:33 |
| lool | I think it gets into -dbgsym | 14:34 |
| lool | sorry, these do in -dbg.debs | 14:34 |
| dmart | It sounds a bit broken if debug frame info is somehow essential for runtime exception handling... | 14:34 |
| ramana | hi . back again. | 14:35 |
| lool | the -dbgsym packages have the result of "objcopy --only-keep-debug" and objcopy -R .gnu_debuglink --add-gnu-debuglink=$1 on the same file | 14:35 |
| lool | dmart: I think there were two standards, and they picked the best one | 14:36 |
| lool | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521 | 14:36 |
| ubot4 | gcc.gnu.org bug 40521 in debug "[4.4/4.5 Regression] -g causes GCC to generate .eh_frame" [Critical,Resolved: fixed] | 14:36 |
| persia | OK. That's a little different, but that makes sense. | 14:36 |
| lool | ramana: So, how would one check whether a binary has a .debug_frame? | 14:37 |
| lool | I see .eh_frame in readelf -l, but not .debug_frame, not even on an unstripped binary I built with -g | 14:38 |
| ramana | readelf -w should tell you if there is a debug_frame | 14:38 |
| ramana | but why is there a .eh_frame in an ARM shared library ? There should only the .ARM.exidx and .ARM.extable sections. | 14:39 |
| lool | ramana: Indeed | 14:40 |
| lool | Contents of the .debug_frame section: | 14:40 |
| lool | [...] | 14:40 |
| lool | DW_CFA_def_cfa: r13 ofs 0 | 14:40 |
| lool | DW_CFA_advance_loc: 2 to 00008da2 | 14:41 |
| lool | etc. | 14:41 |
| lool | ramana: Well I think the .eh_frame stuff as due to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521 wasn't it? | 14:41 |
| ubot4 | gcc.gnu.org bug 40521 in debug "[4.4/4.5 Regression] -g causes GCC to generate .eh_frame" [Critical,Resolved: fixed] | 14:41 |
| ramana | Exactly. | 14:41 |
| ramana | But that's presumably been fixed . | 14:41 |
| ramana | 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. | 14:42 |
| lool | ramana: That was only fixed "recently" a lot of binaries might have been built before that | 14:42 |
| lool | ramana: Also, readelf -w libgtk-x11-2.0.so|grep .debug_frame => empty | 14:42 |
| lool | I see it on a self built binary built with -g | 14:42 |
| lool | But I suspect it's missing in pretty much all our shared libs if it gets stripped | 14:43 |
| NCommander | ramana: back | 14:43 |
| ramana | if it gets stripped that's fine. | 14:43 |
| lool | 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* | 14:43 |
| lool | ramana: Can you unwind without .debug_frame? | 14:43 |
| NCommander | lool: manually built OOo packages still show the same issue | 14:44 |
| NCommander | (that is to say, packages that haven't been stripped) | 14:44 |
| lool | NCommander: It's not just oo.o | 14:44 |
| lool | NCommander: it's all the libs they call | 14:44 |
| NCommander | lool: I manually built OOo from source end to end to get gdb traces, and still got the issue | 14:44 |
| ramana | The exception stack unwinder should use the .ARM.exidx and .ARM.extable implementations. It doesn't have anything to do with.eh_frame. | 14:44 |
| lool | 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... | 14:44 |
| lool | ramana: Ok; good to know, that pretty much kills the theory I was proposing | 14:45 |
| NCommander | ramana: is that an ARM specific quirk? I thought eh_frame was the standard location of exception handling information | 14:46 |
| ramana | Ncommander: Yes that is ARM quirk. | 14:46 |
| ramana | We prefer to call it the ARM exception handling ABI :) | 14:46 |
| NCommander | ramana: I thought ARM and ia64 shared an ABI | 14:47 |
| ramana | not really . | 14:47 |
| NCommander | ramana: so the difference in eh_frame information is nothing to be concerned about w.r.t. to determining our exception handling issues? | 14:47 |
| lool | all binaries I see do have a .ARM.exidx | 14:47 |
| ramana | Well it is something to be concerned about. I don't understand why there is a .eh_frame section in the first place. | 14:47 |
| NCommander | ramana: I built a little C++ program that does exception handling, and it has a *very* full .eh_frame | 14:48 |
| ramana | Is this with the lucid toolchain ? | 14:49 |
| asac | bug 532548 | 14:49 |
| ubot4 | Launchpad bug 532548 in ubuntu "[needs-packaging] [FFe] ubuntu-weboffice-zoho package for armel netbook (affects: 1)" [Wishlist,Confirmed] https://launchpad.net/bugs/532548 | 14:49 |
| NCommander | Manually built OOos have more info in the eh_frame regardless of distro | 14:49 |
| NCommander | ramana: I'm very confused then ... | 14:49 |
| NCommander | 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 | 14:51 |
| NCommander | ^) | 14:51 |
| ramana | I believe that to be the case. I'll have to ask someone else internally. | 14:51 |
| asac | JamieBennett: sponsored zoho | 14:53 |
| JamieBennett | asac: Cool, thanks | 14:53 |
| asac | StevenK: ^^ maybe check in NEW in a few minutes | 14:53 |
| asac | JamieBennett: the Exec command should open browser if %F is empty | 14:54 |
| asac | imo | 14:54 |
| NCommander | ramana: *grumble*, then the difference in eh_frame information was a red hairing | 14:54 |
| NCommander | *herring | 14:54 |
| asac | so if you click on it in the applications menu it opens xdg-open https://...zoho.com/... | 14:54 |
| NCommander | *fish | 14:54 |
| JamieBennett | asac: OK, that makes sense | 14:54 |
| ramana | I don't think it's a red herring yet. | 14:55 |
| JamieBennett | asac: let me finish this FTBFS then I'll take a look | 14:55 |
| asac | sure | 14:55 |
| JamieBennett | asac: what were the bugs you mentioned in your comment? | 14:56 |
| asac | JamieBennett: the bug from above ... and icons | 14:57 |
| asac | being wrong ... and apikey | 14:57 |
| asac | but we dont have anything better yet ;) | 14:57 |
| asac | also we need to verify that all the mime-types are ok somehow (or not) | 14:57 |
| JamieBennett | asac: ah, so known bugs, thats OK, thought you'd found some more :) | 14:57 |
| asac | nope | 14:57 |
| asac | JamieBennett: didnt know you had the menu not doing anything on your list ;) | 14:57 |
| asac | so somewhat new | 14:57 |
| asac | (one) | 14:57 |
| JamieBennett | :) | 14:58 |
| NCommander | 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 | 15:00 |
| ramana | Ah good that you found that. I had pointed that out to someone last week. | 15:01 |
| ramana | It skipped my mind to point you at it. | 15:01 |
| NCommander | ramana: yeah, on karmic, .ARM.exidx has 233 entries, and 52 of those are marked cantunwind | 15:02 |
| NCommander | ramana: jaunty has 332, no cantunwind | 15:02 |
| ramana | The CANTUNWIND generation happened between the jaunty and karmic toolchains. | 15:02 |
| NCommander | ramana: sounds like that may confirm the original theory that we're running into a CANTUNWIND where we shouldn't | 15:03 |
| ramana | and that's the comment by the author about us debugging to find out what the problem is there. | 15:03 |
| NCommander | ramana: but biulding with gcc 4.4 in a jaunty chroot works | 15:03 |
| ramana | NCommander : How many of the dependencies have you rebuilt with 4.4 ? Is it just ooo that you've rebuilt ? | 15:03 |
| NCommander | ramana: just OOo | 15:04 |
| NCommander | ramana: I did some tests with karmic and jaunty toolchain bits. Results are in the Lp bug | 15:04 |
| ramana | there is someone else looking at this internally I'll pass on this conversation and your comments on the LP bug. | 15:04 |
| ramana | s/looking at this/starting to look at this | 15:05 |
| NCommander | 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 | 15:06 |
| ramana | other than poking something in libgcc's unwinder. | 15:06 |
| NCommander | ramana: I tried that, and I felt my brain ooze | 15:07 |
| ramana | ok | 15:07 |
| NCommander | 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. | 15:09 |
| ramana | if you look at get_eit_entry in unwind-arm.c it's checking if the frame can't be unwound. | 15:11 |
| JamieBennett | asac: if your in an uploading mood theres Bug #535093 and Bug #535000 :P | 15:12 |
| ubot4 | Launchpad bug 535093 in kbuild (Ubuntu) "FTBFS: kbuild fails to build on armv7l hardware (affects: 1)" [Undecided,New] https://launchpad.net/bugs/535093 | 15:12 |
| ubot4 | JamieBennett: Bug 535000 on http://launchpad.net/bugs/535000 is private | 15:12 |
| JamieBennett | doh | 15:12 |
| JamieBennett | both are public according to launchpad | 15:13 |
| NCommander | 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() | 15:14 |
| lool | JamieBennett: looks good | 15:14 |
| NCommander | ramana: so at the risk of being dense, why are sectoins marked CANTUNWIND? | 15:15 |
| JamieBennett | lool: great | 15:15 |
| NCommander | ramana: http://sourceware.org/ml/binutils/2009-05/msg00048.html - nm, this seems to answer my question | 15:16 |
| lool | JamieBennett: uploaded; sent to Debian and/or upstream? | 15:16 |
| JamieBennett | lool: which one? | 15:16 |
| lool | JamieBennett: fio | 15:16 |
| JamieBennett | no, I'll submittodebian now | 15:16 |
| lool | JamieBennett: kbuild > looks like this will break every now and then; can't we support arm*? | 15:17 |
| ramana | Yes I was looking for that. | 15:17 |
| JamieBennett | 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) | 15:18 |
| lool | JamieBennett: Is there another bug on the generic solution? | 15:18 |
| NCommander | ramana: seems libgcc can actually unwind parts of the table that are marked CANTUNWIND | 15:18 |
| NCommander | which seems to mean that CANTUNWIND really should be SHOULDNTUNWIND :-) | 15:18 |
| JamieBennett | lool: yes | 15:18 |
| * JamieBennett hunts for a number | 15:18 | |
| lool | JamieBennett: just mention it in your bug | 15:19 |
| JamieBennett | OK | 15:19 |
| lool | uploaded | 15:19 |
| JamieBennett | lool: Thanks | 15:19 |
| dmart | JamieBennett: "dmart is looking into it": which package is this? | 15:19 |
| ramana | what gives you that idea ? | 15:19 |
| JamieBennett | dmart: the generic arm detection | 15:19 |
| JamieBennett | script | 15:19 |
| lool | JamieBennett: actually, please rename Vcs-* fields when you change a package from Debian | 15:19 |
| JamieBennett | lool: Oh, OK | 15:20 |
| dmart | JamieBennett: oh, right. I don't have a solution on that yet. | 15:20 |
| lool | JamieBennett: uploading a fix there too | 15:20 |
| JamieBennett | dmart: Yes, I had a simple fix for kbuild which can be done better when we have a more generic solution | 15:20 |
| NCommander | ramana: since if the CANTUNWIND entries aren't in the linker table, it seems unwinding successes | 15:20 |
| dmart | JamieBennett: I agree; probably best to go for a simple stopgap solution for now. | 15:21 |
| NCommander | *successes | 15:21 |
| NCommander | er | 15:21 |
| * NCommander spelt it right the first time | 15:21 | |
| lool | succeeds? | 15:23 |
| NCommander | lool: er *cough* | 15:24 |
| * NCommander goes to relearn basic English | 15:24 | |
| persia | NCommander: Don't do that. Odgen&Richards were smart, but there are many lost subtleties in such communication. | 15:25 |
| lool | I guess it matters more here that you can read ARM unwind sections | 15:25 |
| ramana | NCommander : I need to get into another meeting in a few minutes and need to finish something before that. | 15:27 |
| ramana | Before I disappear - I'll look out for the following bits of info. | 15:27 |
| ramana | 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. | 15:28 |
| ramana | 2. Look into unwind-arm.c for more about how CANTUNWIND entries are handled . | 15:28 |
| NCommander | ramana: for 2, it aborts the unwind | 15:29 |
| ramana | yes it should gracefully abort the unwind but you said something about unwinding "succeeding" | 15:29 |
| NCommander | ramana: oh, no, I said the unwind succeeds if the CANTUNWIND entries aren't there | 15:29 |
| NCommander | (as when we build the code in jaunty) | 15:29 |
| ramana | NCommander - ah ok . | 15:30 |
| NCommander | ramana: if we can determine how the linker determines if something should be CANTUNWIND would be most helpful | 15:31 |
| * 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 | 15:31 | |
| NCommander | or bug, not sure if this is a regression or not | 15:31 |
| ramana | well it's hard to say. | 15:31 |
| ramana | We'll have to look into it further. I'll pass this on to the guy who'll be looking at it. | 15:32 |
| NCommander | ramana: thanks. If you can point them my way, it would be appericated. | 15:32 |
| ramana | I have already pointed your LP comments to him . | 15:35 |
| NCommander | ramana: well, talking with him on IRC always helps :-) | 15:42 |
| NCommander | http://www.engadget.com/2010/03/09/freescales-7-inch-tablet-runs-android-chrome-os-or-linux-cost/ - I want :-) | 15:43 |
| persia | For too big :p | 15:46 |
| persia | That resolution would be fine at 3.5" | 15:47 |
| ramana | NCommander : are you around ? | 16:45 |
| NCommander | ramana: yup | 16:47 |
| ramana | mgretton has been looking at the LP bug and has some questions . | 16:48 |
| NCommander | mgretton: what can I do to help you? | 16:49 |
| mgretton | Hi, I'm interested in the functions privateSnippetExecutor and GetVersionInfo. I believe these are C functions, were they compiled with -fexceptions? | 16:49 |
| NCommander | mgretton: where are those functions? | 16:49 |
| NCommander | oh wait | 16:49 |
| NCommander | mgretton: privateSnippetExecutor is an ARM ASM stub | 16:50 |
| * NCommander looks for GetVersionInfo | 16:50 | |
| mgretton | 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 | 16:50 |
| ubot4 | 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 | 16:50 |
| NCommander | mgretton: I don't see GetVersionInfo | 16:51 |
| mgretton | NCommander: GetVersionInfo doesn't matter so much its privateSnippetExecutor I see in the call stack. | 16:52 |
| NCommander | mgretton: we're not building with -fexceptions | 16:53 |
| NCommander | mgretton: but thats an ARM ASM function (.s) thats build separately into a .o, and then linked in | 16:53 |
| NCommander | mgretton: .cantunwind is not within the .s file, so the linker shouldn't be marking it as CANTUNWIND | 16:54 |
| mgretton | NCommander: Are there any unwind directives at all in the .s file? | 16:55 |
| NCommander | mgretton: no | 16:55 |
| NCommander | mgretton: let me pastebin it | 16:56 |
| mgretton | NCommander: ld now explicitly marks code that it can't unwind through due to lack of unwind tables as CANTUNWIND. | 16:56 |
| NCommander | mgretton: http://paste.ubuntu.com/391906/ | 16:56 |
| NCommander | mgretton: that sounds like that might be the cause. How do we add unwind information? | 16:57 |
| mgretton | NCommander: You need to add .fnstart, .fnend, .save, and .setfp directives into the assembly... | 16:59 |
| Sarvatt | 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 | 17:00 |
| NCommander | mgretton: got a doc for me to look at? | 17:00 |
| mgretton | NCommander: Write a simple hello-world program compile with -fexceptions -S and look at the assembly file produced. | 17:00 |
| mgretton | The gas info pages have full info - I'll find a link. | 17:01 |
| Sarvatt | it sets the -mcpu=arm1136j-s CFLAG and tries asm("uqadd8 r1, r1, r2"); in the check to see if it should enable it | 17:01 |
| lool | Sarvatt: I see that in the code, but I don't have any clue why it would fail either | 17:02 |
| mgretton | NCommander: See http://sourceware.org/binutils/docs-2.20/as/ARM-Directives.html#ARM-Directives | 17:02 |
| lool | Hmm it's prepended to CFLAGS though | 17:02 |
| NCommander | mgretton: how'd you determine that there was no unwind info for privateSnippetExecutor out of curiosity? | 17:02 |
| lool | but we dont pass anything fancy, so shouldn't matter | 17:02 |
| lool | So that would be a v6 instruction hmm | 17:05 |
| mgretton | 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. | 17:06 |
| NCommander | mgretton: ah! | 17:07 |
| mgretton | NCommander: I then checked the call frame and privateSnippetExecutor became the immediate suspect. | 17:07 |
| lool | Sarvatt: /tmp/cciD0vDI.s:37: Error: selected processor does not support `uqadd8 r1,r1,r2' | 17:08 |
| lool | configure:12379: gcc -c -mcpu=arm1136j-s -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden conftest.c >&5 | 17:08 |
| lool | Sarvatt: Could it be that uqadd8 is a vfp instructions which we dont turn on by default? Or perhaps a NEON one? | 17:08 |
| lool | I didn't find it in the ARM reference manual | 17:08 |
| NCommander | mgretton: test building my first try | 17:09 |
| ramana | 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 . | 17:09 |
| lool | mgretton: Ah, could it be it's an ARM only instruction, and isn't available under Thumb? | 17:09 |
| lool | err s/mgretton/Sarvatt | 17:10 |
| NCommander | mgretton: well, for my first attempt, the program just blows up versus reaching std::terminate :-) | 17:11 |
| * NCommander guesses he didn't quite get everything right | 17:12 | |
| mgretton | NCommander: Do you mind binpasting your attempt and I'll take a quick look as well? | 17:13 |
| NCommander | mgretton: sure, let me just try one other thing before I post it | 17:13 |
| lool | Sarvatt: checking whether to use ARM SIMD assembler... yes | 17:14 |
| lool | Sarvatt: That's with CFLAGS=-marm | 17:14 |
| Sarvatt | if -mcpu is prepended is the gcc default that gets added at the end overriding the first one? | 17:14 |
| lool | Sarvatt: No, the gcc defaults isn't added at the end; it's the default CPU mode which causes it | 17:15 |
| lool | We switched to -mthumb by default in lucid, and -mthumb lacks uqadd; only -marm has it | 17:15 |
| lool | Sarvatt: Mind opening a bug on that? | 17:15 |
| NCommander | mgretton: http://paste.ubuntu.com/391919/ - if I remove the saves, I don't get a crash, but it just hangs | 17:17 |
| lool | Sarvatt: Quick workaround for you: add CFLAGS+=-marm in debian/rules | 17:17 |
| NCommander | mgretton: with this, I get the terminate message again (phase2 unwind error) | 17:17 |
| mgretton | 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. | 17:19 |
| NCommander | mgretton: I admit my ARM ASM isn't so good :-/ | 17:20 |
| mgretton | NCommander: If that doesn't work change the .setfp ip, #4 to .setfp ip, #-4 | 17:20 |
| NCommander | mgretton: .setfp needs two arguments | 17:20 |
| NCommander | I think that has to be .setfp fp, ip, #4 | 17:21 |
| mgretton | NCommander: Sorry .setfp fp, ip, #4 (or .setfp fp, ip, #-4) | 17:21 |
| lool | mgretton: According to the binutils doc you pointed at earlier, #4 seems correct | 17:21 |
| Sarvatt | sure thing lool, can we just patch configure.ac to add -marm to the check? | 17:21 |
| mgretton | NComamnder: Yes but its the opposite of what GCC produces... | 17:21 |
| lool | Sarvatt: I need to dive a bit in where that's actually used | 17:22 |
| lool | Sarvatt: Adding -marm in configure is probably not a good idea | 17:22 |
| Sarvatt | https://bugs.edge.launchpad.net/ubuntu/+source/pixman/+bug/535183 | 17:22 |
| NCommander | mgretton: no luck with either one. with .setfp ip, #4, I get to std::terminate | 17:22 |
| ubot4 | Launchpad bug 535183 in pixman (Ubuntu) "pixman doesn't autodetect SIMD support at build time on arm. (affects: 1)" [Undecided,New] | 17:22 |
| NCommander | mgretton: with #-4, it just quits, no message | 17:22 |
| lool | Sarvatt: So I had a look, and it's used in the middle of pixman/pixman-cpu.c | 17:23 |
| napster | Where I can get a uImage file? | 17:23 |
| lool | Sarvatt: Hmm sorry, apparently for libpixman-arm-simd.la only | 17:23 |
| Sarvatt | thats the runtime autodetection code I think? | 17:24 |
| lool | Which has pixman-arm-simd.c only | 17:24 |
| lool | Sarvatt: So it would appear to be ok to pass -marm in pixman-arm-simd.c | 17:24 |
| lool | Sarvatt: However note that this means that the code will be switching to arm-mode whenever it's jumped to | 17:24 |
| lool | Sarvatt: Would it be possible to rewrite the functions in thumb instead? | 17:25 |
| ogra | wasnt pixman on the thumb2 porting page ? | 17:25 |
| mgretton | 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) | 17:25 |
| * ogra cant remember but i thought i saw it | 17:26 | |
| NCommander | mgretton: not explicately | 17:26 |
| ogra | https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList yep | 17:26 |
| dmart | I think pixman was on the list, but flagged as done | 17:26 |
| NCommander | mgretton: I'd have to rebuild OOo from scratch to force -fexceptions to be built, but thats going to take days | 17:26 |
| ogra | https://bugs.launchpad.net/ubuntu/+bug/514237 | 17:26 |
| ubot4 | Launchpad bug 514237 in pixman (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] | 17:26 |
| ogra | invalid | 17:27 |
| lool | was marked as invalid though | 17:27 |
| lool | ogra: it was listed for something else | 17:27 |
| mgretton | NCommander: All files need to have exception unwind information added to them. Sorry - that sound horrible. | 17:27 |
| ogra | yeah for mov | 17:27 |
| dmart | Our greps couldn't tell the difference between broken and non-broken asm, but pixman has been under recent maintenance and should work fine. | 17:27 |
| lool | dmart: Problem is that it uses uqadd which isn't available in thumb mode | 17:28 |
| mgretton | NCommander: You'll also need the right fix for privateSnippetExecutor that we might have worked out above :-) | 17:28 |
| lool | dmart: Do you have a suggestion on replacing it, or should we just build the arm_composite_add_8000_8000() routine in arm mode? | 17:28 |
| lool | (and others) | 17:28 |
| lool | Basically the whole pixman/pixman-arm-simd.c file | 17:29 |
| NCommander | mgretton: ugh, that seems broken. | 17:29 |
| NCommander | mgretton: we shouldn't need -fexceptions on ARM where no other architecture requires it | 17:29 |
| ogra | NCommander, if it makes it work its still a better workaround than shipping a jaunty binary .so though | 17:30 |
| NCommander | ogra: that's true | 17:30 |
| NCommander | mgretton: at the risk of being dense, main.c isn't part of the UNO library that has the issue | 17:30 |
| NCommander | mgretton: so I'm not sure that being built with -fexceptions would change anything | 17:31 |
| mgretton | NCommander: Agreed. | 17:31 |
| lool | dmart: Also, I'm thinking perhaps we should grep for uqadd? | 17:31 |
| NCommander | 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) | 17:31 |
| mgretton | NCommander: Where are we expecting this exception to be caught? | 17:31 |
| NCommander | mgretton: er, you haven't seen the code, have you? | 17:31 |
| mgretton | NCommander: Grab and build a trunk binutils and use readelf... | 17:32 |
| NCommander | mgretton: I already have a patched version, just not sure what to look for in the output :-) | 17:32 |
| dmart | lool: possibly; I hadn't previously been aware of that one. | 17:32 |
| NCommander | mgretton: we're bypassing throw(), and calling __cxa_throw directly :-/ | 17:32 |
| NCommander | mgretton: it should end up landing in deleteException in UNO before being rethrown | 17:32 |
| dmart | The quickest solution is simply to build the affected parts of pixman for ARM (or all of it) | 17:32 |
| lool | dmart: Yes; but Sarvatt is upstream apparently; what would the proper upstream fix be? | 17:32 |
| lool | dmart: They have a separate file and separate CFLAGS for it, so -marm doesn't sound too bad | 17:33 |
| mgretton | NCommander: readelf -u will dump the unwind tables. Look for PrivateSnipperExecutor in the tables | 17:33 |
| NCommander | mgretton: ok, so I have an unwind table entry for it | 17:34 |
| NCommander | woo | 17:34 |
| NCommander | (not sure its correct, but its close enough that we're not breaking the stack over it) | 17:34 |
| mgretton | NCommander: I'm afraid I've got to go. I'll have a think about this and come back tomorrow with any other thoughts. | 17:34 |
| lool | Sarvatt: At least for now, s/ARM_SIMD_CFLAGS="-mcpu=arm1136j-s"/ARM_SIMD_CFLAGS="-mcpu=arm1136j-s -marm"/ would be fine | 17:34 |
| NCommander | mgretton: fair enough. Is there a way to get the old linker behavior back? | 17:34 |
| NCommander | (some sorta LDFLAG or something?) | 17:34 |
| dmart | lool: Is the build log on launchpad? uqadd8 is available in Thumb-2 | 17:35 |
| lool | 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 | 17:35 |
| lool | dmart: I can reproduce here | 17:35 |
| lool | dmart: Yes, it's on launchpda | 17:35 |
| dmart | Can you paste me a log? | 17:35 |
| mgretton | NCommander: No - you need to revert the original patch that added the functionality. | 17:35 |
| lool | dmart: http://launchpadlibrarian.net/38024749/buildlog_ubuntu-lucid-armel.pixman_0.16.4-1_FULLYBUILT.txt.gz | 17:35 |
| lool | dmart: (was looking it up) | 17:35 |
| lool | dmart: checking whether to use ARM SIMD assembler... no | 17:36 |
| NCommander | mgretton: I'm going to guess we want this cantunwind functionality? | 17:36 |
| lool | dmart: I can reproduce with ./configure in an arm qmeu chroot here, and CFLAGS=-marm passes! | 17:36 |
| NCommander | 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) | 17:36 |
| dmart | Can you paste me your failing log? | 17:36 |
| dmart | lool: ^ | 17:36 |
| lool | dmart: the launchpad log is the failing one | 17:36 |
| lool | dmart: Oh you mean config.log? | 17:36 |
| mgretton | NCommander: Yes - its better than the alternative - that we unwind using a different function's unwind table. | 17:36 |
| NCommander | mgretton: *grumble* :-/ | 17:37 |
| lool | dmart: 18:08 < lool> Sarvatt: /tmp/cciD0vDI.s:37: Error: selected processor does not support `uqadd8 r1,r1,r2' | 17:37 |
| lool | 18:08 < lool> configure:12379: gcc -c -mcpu=arm1136j-s -g -O2 -Wall -fno-strict-aliasing -fvisibility=hidden conftest.c >&5 | 17:37 |
| lool | (above) | 17:37 |
| NCommander | mgretton: I have no good ideas where to go from here, hopefully you'll get a brainwave later today | 17:37 |
| lool | dmart: Ah I know, they force a CPU which has an older thumb2 implementation -- could that explain? | 17:37 |
| mgretton | NCommander: Original change here: http://sourceware.org/ml/binutils/2009-05/msg00048.html | 17:37 |
| * mgretton is back | 17:37 | |
| * mgretton is back | 17:37 | |
| NCommander | mgretton: that was quick | 17:38 |
| mgretton | NCommander: I'm really going this time :-) | 17:38 |
| dmart | 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? | 17:38 |
| NCommander | mgretton: heh | 17:38 |
| lool | dmart: I guess earliest CPU adding quadd | 17:38 |
| ogra | NCommander, thats ARMs "instant on" function :) | 17:39 |
| ogra | gets you such quick suspend/resume cycles | 17:39 |
| NCommander | 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 :-) | 17:39 |
| dmart | 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. | 17:40 |
| lool | dmart: Testing CFLAGS=-mcpu=cortex-a8 right now | 17:40 |
| dmart | lool: that should work, yes | 17:40 |
| lool | dmart: The thing is that they likely want to turn it on under Debian for instance | 17:40 |
| lool | dmart: It's a separate function which only gets called if auxv says v6 is preesnt | 17:41 |
| lool | It passes | 17:41 |
| dmart | lool: I think you need two tests for this: | 17:41 |
| lool | Sarvatt: So the bug is in that -mcpu= you're setting, it's incompatble with Ubuntu's -mthumb default; let's find something | 17:42 |
| dmart | lool: echo '... uqadd8 blah ...' | gcc => if OK then turn on this file and build it with default opts | 17:42 |
| dmart | otherwise | 17:42 |
| lool | dmart: Well AC_TRY_COMPILE, but right | 17:43 |
| dmart | lool: echo '... uqadd8 blah ...' | gcc -mcpu=arm1136j-s => if OK then turn on this file and build it the overridden opts | 17:43 |
| dmart | (I know, but it's pseudocode anyway) | 17:43 |
| dmart | ...if neither works, turn off that file. | 17:43 |
| lool | dmart: I would like you to please talk autoconf on this chan | 17:43 |
| lool | pseuco-code is not an acceptable conduct! | 17:44 |
| lool | :-P | 17:44 |
| dmart | meh | 17:44 |
| lool | dmart: Ok will try cooking some autofoo for Sarvatt if he like | 17:44 |
| lool | s | 17:44 |
| dmart | anyway, I think that's the answer; you need 2 tests to determine the right options | 17:45 |
| dmart | NCommander: fork: Resourse temporarily unavailable | 17:46 |
| dmart | ;) | 17:46 |
| NCommander | dmart: thats not a valid error code from fork() :-) | 17:47 |
| NCommander | dmart: sounds like your having some issues with too many threads touching errno | 17:47 |
| dmart | fork(8) | 17:47 |
| dmart | ... | 17:48 |
| dmart | ERRORS | 17:48 |
| dmart | EAGAIN fork() cannot allocate sufficient memory to copy the parent's ... | 17:48 |
| dmart | Cygwin does this to me a lot for no reason... | 17:48 |
| dmart | ...but I digress... | 17:48 |
| NCommander | dmart: I thought EAGAIN translated to a different strerror() message ... | 17:51 |
| * NCommander might be wrong | 17:51 | |
| dmart | ah, maybe. It wasn't a good joke anyway... | 17:52 |
| NCommander | dmart: yes, but we're geeks for understanding it anyway :-) | 17:54 |
| lool | Sarvatt, dmart: http://paste.ubuntu.com/391944/ | 17:54 |
| lool | (untested) | 17:54 |
| dmart | I think the second test needs ARM_SIMD_CFLAGS="-mcpu=arm1136j-s -marm" | 17:55 |
| dmart | ...if the toolchain might default to Thumb | 17:56 |
| dmart | (may not be an issue for Debian though?) | 17:56 |
| lool | dmart: good point | 17:57 |
| lool | http://paste.ubuntu.com/391946/ | 17:58 |
| dmart | Makes sense, I guess. | 17:59 |
| * dmart has to disappear... | 18:01 | |
| lool | Sarvatt: checking whether to use ARM SIMD assembler... yes | 18:12 |
| lool | with the second patch | 18:12 |
| lool | Sarvatt: Could you merge that upstream? | 18:12 |
| ssvb | 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 | 18:35 |
| === mcasadevall is now known as NCommander | ||
| === jamie is now known as Guest26145 | ||
| === Guest26145 is now known as JamieBennett | ||
| === Guest77043 is now known as |nfecteD | ||
| Sarvatt | sure thing, sorry I'm at work at the moment and missed all that earlier. I will upstream it, no problems :) | 19:43 |
| Sarvatt | thanks for looking into it and fixing it, I wasn't having any luck | 19:45 |
| lool | Sarvatt: I just subscribed to the pixman list; shall I send it here, or will you just pick it up from the bug report? | 19:51 |
| lool | ssvb: thanks for the pointer ^ btw | 19:51 |
| Sarvatt | ah that works, was just about to ask you for attribution info and such :) | 19:52 |
| lool | Sarvatt: sent there | 19:58 |
| lool | JamieBennett: https://launchpad.net/ubuntu/+source/kbuild/1:0.1.98svn2318-4ubuntu1/+build/1552 | 19:58 |
| lool | 656/+files/buildlog_ubuntu-lucid-armel.kbuild_1:0.1.98svn2318-4ubuntu1_BUILDING. | 19:58 |
| lool | txt.gz | 19:58 |
| lool | kbuild failed to build on armel | 19:58 |
| lool | and mutt ate my link | 19:58 |
| lool | JamieBennett: Actually: * State: Failed to upload | 19:59 |
| lool | JamieBennett: It seems this was retried, so don't worry | 19:59 |
| JamieBennett | lool: so what was the problem? | 19:59 |
| lool | Sarvatt: Sorry for the lack of proper From: | 20:00 |
| lool | JamieBennett: Dunno, transient buildd upload failure | 20:00 |
| lool | e.g. connection reset or something | 20:00 |
| lool | JamieBennett: apparently it reached the archive | 20:00 |
| JamieBennett | lool: OK | 20:00 |
| pdxspork_ | Anyone got experience with the OMAP2 hsmmc driver? | 20:02 |
| DanaG | weird... the rcn-ee 2.6.33 kernel doesn't get any input from the "twl4030_powerbutton" input device. | 20:04 |
| lool | apw: I guess you saw -dove failed to build due to perf trying to include/link libelf | 20:31 |
| guilhem | hi all | 20:42 |
| lool | hi | 20:42 |
| * lool wnders off | 20:43 | |
| guilhem | 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 ? | 20:45 |
| guilhem | I have tried to make deb-dpkg but when it arrives at dpkg-gencontrol it tels me gcc arm-eabi uncnown :/ | 20:47 |
| lool | guilhem: rootstock should fetch the kernel that it needs itself | 20:47 |
| lool | guilhem: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/versatile/netboot/ this kernel works with rootstock AFAIK | 20:47 |
| guilhem | yeah I know that in fact i need to make it clean to be able to share with others | 20:47 |
| guilhem | in fact i need to build my own kernel | 20:49 |
| guilhem | what i'm doing is that i'm building ubuntu on nvidia platform | 20:50 |
| guilhem | 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 | 20:51 |
| guilhem | I have managed to boot the memory stick and mount the ext3 filesystem | 20:52 |
| guilhem | but now I want to put ubuntu on top of that | 20:52 |
| guilhem | and it's a litle bit dark for me | 20:52 |
| guilhem | I have understand that i should build my rootfs with rootstock and then put my vmlinuz & modules on the rootfs | 20:55 |
| guilhem | but when i try to boot this i get a kernel panic after mounting the filesystem | 20:57 |
| guilhem | [42949392.430000] PC is at setup_arg_pages+0x28/0x20c | 20:57 |
| guilhem | [42949392.440000] LR is at load_elf_binary+0x3fc/0x1268 | 20:57 |
| guilhem | anyone knows ? :| | 20:57 |
| apw | lool ... dove should have that turned off ... hrm | 21:32 |
| === mcasadevall is now known as NCommander | ||
| rcn-ee | guilhem, just catching up on the irc log, did you solve your create deb image problem? | 23:45 |
| Bre | hi | 23:55 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!