| === ApOgEE__ is now known as ApOgEE- | ||
| === Stskeepie is now known as Sts|office | ||
| mne | Hi. Yesterday I played the whole day long to build a rootfs with the build-arm-rootfs script. I modified the script so that it stops right before running qemu so that I can run qemu-system-arm interactively to see whats going on. While everything seems to work I still have no working network inside qemu. Since I was running qemu inside a vmware image which might have caused network problems, I'm now running qemu natively on ubuntu hardy. The result is sti | 09:33 |
|---|---|---|
| mne | ll the same: Inside the arm image I get an IP address and nameserver from QEMU over DHCP. I can even connect to machines on the LAN and on the internet. However, DNS resolving does not work. On the guest image qemu's nameserver (10.0.2.3) is used for resolving. Interestingly it can resolve DNS names for the hosts on the LAN. However, external addresses (like www.google.com for example) are not resolvable. I also tried to use a real DNS server (by putting | 09:33 |
| mne | it into /etc/resolv.conf on the guest instead of the qemu DNS server), but the result is still the same: LAN DNS names are resolved, but internet DNS names are not. Any ideas ? | 09:33 |
| mne | Nice, I just got it working by using my ISPs DNS server instead of the LAN DNS server (which does DNS caching and forwarding to my ISPs DNS server). | 09:42 |
| persia | mne, Excellent to hear you got it working. Perhaps an issue with NAT and your local DNS server? | 09:46 |
| mne | Hmm, I don't know. I never had problems with it with vmware. However, since vmware's networking is completely different, it still might be some LAN DNS issue. Anyway, I'm happy now ;) It took me a whole day to figure it out :P | 09:50 |
| lool | mne: You might want to tcpdump the actual network traffic to see why the DNS answers work for internal hosts but not public ones | 10:02 |
| === Nicke_ is now known as Nicke | ||
| mne | tcpdump on the host running qemu ? or on the guest ? | 10:04 |
| ogra | i guess the DNS forwarder in vmware simply doesnt DTRT | 10:07 |
| lool | mne: On the host would work better | 10:19 |
| lool | mne: ah you're running qemu in vmware? that's heavey | 10:19 |
| ogra | yes he does :) | 10:20 |
| mne | not now. But that's what I tried yesterday. Sure it brings heavy performance issues, but the idea was to have an embedded vmware development image which contains everything necessary. qemu is only used to create the rootfs anyway | 10:22 |
| ogra | mne, so just build a qemu image natively and convert it | 10:58 |
| Stskeeps | morning persia | 10:58 |
| persia | Hey Stskeeps | 10:59 |
| Stskeeps | how is it going? | 10:59 |
| persia | I'm *way* behind on documentation, but at least I think I know what needs writing at this point. | 11:01 |
| persia | And I've discovered the drawback with attaching a computer directly to one's brain: it takes a whlie for the brain to understand how to use it :) | 11:02 |
| persia | For you? | 11:02 |
| Stskeeps | hehe.. i'm playing with my newly donated freerunner and being amazed at how effective chinese gadget lovers are in finding 3rd party firmware for their devices :> | 11:02 |
| persia | heh. | 11:02 |
| Stskeeps | 12 hours after a silent notice of a smartq5 firmware image on the mer list, it ends up with it's own blurry phots and huge rumours etc | 11:03 |
| Stskeeps | :> | 11:03 |
| persia | The language barrier is significant, but there's a lot of good hackers there. | 11:03 |
| Stskeeps | yeah | 11:03 |
| Stskeeps | but anyway, if there's more you'd like to discuss regarding the mer-karmic idea, i'm around the next 4 hours :) | 11:06 |
| persia | I think we covered the basics. Basically, Mer needs lots of packaging review, Ubuntu needs lots of patches, and we both need to have a good understanding of the definition of "upstream" for some of the components. | 11:08 |
| Stskeeps | yep | 11:08 |
| persia | Until I can effectively document that, and get some traction on the packaging review, I'm not sure how much you guys can do. | 11:08 |
| Stskeeps | *nod* | 11:08 |
| persia | (unless you have some secret plan that gets a clean definition of "upstream") | 11:09 |
| Stskeeps | nop, as convulted as ever :P | 11:09 |
| Stskeeps | +u | 11:09 |
| persia | I'm hoping that with the packaging review, we can define some available blobs that can be "upstream", and then use that as a guideline. But I'm not sure how cleanly that will work... | 11:09 |
| Stskeeps | yeah. i'm meeting with the nokians at the end of the month and i hope to discuss things with them to | 11:11 |
| Stskeeps | o | 11:11 |
| persia | That'd be excellent. | 11:11 |
| Stskeeps | ( http://wiki.maemo.org/MozillaMaemoDanishWeekend ) | 11:11 |
| persia | Personally, I'd like to see Mer/Ubuntu be just a set of patches laid on top of what Nokia is providing for some of the core applications, and restricting that set to stuff that doesn't have another upstream, but I'm not sure how viable that is for them. | 11:12 |
| suihkulokki | persia, lool, you might want to drop someone from ubuntu there too ^ | 11:13 |
| ogra | suihkulokki, bad timing | 11:13 |
| Stskeeps | yeah, just after UDS? :P | 11:13 |
| === mcasadevall is now known as NCommander | ||
| Stskeeps | well, at least libhildon and other key components are developed in the open now so it's a good start | 11:13 |
| persia | Indeed. And I'm guessing that the output of the MID-is-Mer discussions can be input to that. | 11:14 |
| Stskeeps | we're basically getting some of the people making direction for mer together there (nokia has sponsored quite a fair bit of travel and such, which is very nice.) | 11:16 |
| Stskeeps | so yeah, using UDS as input for our discussions there could be good :) | 11:16 |
| persia | I don't suppose you'll be at UDS, will you? | 11:17 |
| Stskeeps | sadly i won't, i'm already booked enough out this month, cph meeting and a exam a week after that meeting | 11:17 |
| persia | Makes sense. | 11:18 |
| Stskeeps | we have completed our migration into OBS now so we can start cleaning up packages/finding .orig.tar.gz's and such more easily as well, and we'll do that in our 0.14 | 11:21 |
| persia | That's the May-June cycle? | 11:23 |
| Stskeeps | 3 weeks from monday, yeah | 11:23 |
| Stskeeps | we're releasing 0.13 on monday so :) | 11:23 |
| persia | Ah, so that's the same timeframe that I need to have everything documented (well, my deadline is the 24th), so there's an opportunity for parallelisation there :) | 11:24 |
| Stskeeps | hehe, alright | 11:24 |
| lool | Stskeeps, suihkulokki: I was aware of the event, but it conflicts with UDS for me :-/ | 12:39 |
| Stskeeps | was it in barcelona or how was it? | 12:39 |
| lool | I'm leaving my home for two weeks and returning the 30th, wouldn't want another event immediately after that, and I will be tired anyway | 12:39 |
| lool | Stskeeps: It's in barcelona in 10 days or so | 12:39 |
| Stskeeps | k | 12:39 |
| Stskeeps | curious, is UDS open? i think we might have a barcelona based guy | 12:42 |
| Stskeeps | ah, nevermind - madrid instead | 12:43 |
| persia | Stskeeps, UDS is completely open to the public, yes. | 13:00 |
| Stskeeps | k | 13:00 |
| persia | It's past the deadline to request subsidies for travel or lodging, but more people would *definitely* be welcome. | 13:01 |
| Stskeeps | i'll see what he says, might be useful to have a mer guy around if you're going to discuss mer & karmic | 13:05 |
| persia | Very much so. Even if nobody can get there physically, there's VoIP, and I'd hope that a couple people could attend the Mer session. | 13:07 |
| Stskeeps | *nod* | 13:07 |
| mne | Hi. Which arm cross compiler toolchain do you use ? I found various toolchains on the net, which one can you recommend ? | 13:14 |
| persia | mne, None. It's all native builds. | 13:14 |
| mne | you build natively on arm ? Isn't that terribly slow ? | 13:15 |
| mne | I found this on the ubuntu wiki: https://wiki.ubuntu.com/Toolchain/Crosscompilers/ARMEABIToolchain | 13:17 |
| persia | It's not so bad, if you have fairly fast build machines. | 13:18 |
| persia | And there's advantages to native build, like being able to build code-generating source, etc. | 13:19 |
| mne | Hmm ok. My board (at91sam9260 @ 200MHz) is definitely too slow :) | 13:19 |
| persia | heh, yeah, that might take a while to build something like openoffice :) | 13:20 |
| mne | btw, on ubuntu, is there a general config file for make or an environment variable so that make always uses a specified number of jobs (i.e. 4 for a quad core cpu) ? | 13:21 |
| persia | kinda. | 13:21 |
| persia | So, the build is always controlled by the debian/rules makefile. | 13:21 |
| persia | But most of the better debian/rules files support certain variables, like the number of parallel make jobs to run. | 13:21 |
| persia | In which case, they are built with numcpus+1 | 13:22 |
| persia | But it really depends on the package. | 13:22 |
| mne | cool. So if it doesn't work I'll just change the parameters in debian/rules. thanks. | 13:22 |
| === amitk_ is now known as amitk | ||
| ScriptRipper | NCommander: are you there? | 15:46 |
| ScriptRipper | persia ogra: hi | 15:47 |
| persia | Hey ScriptRipper | 15:48 |
| pro-rsoft | ScriptRipper, don't I know you from somewhere? | 15:48 |
| pro-rsoft | oh! right from opensuse build service | 15:48 |
| NCommander | ScriptRipper, yeah, I'm here | 15:49 |
| * NCommander has one MASSIVE migrane this morning ;.; | 15:50 | |
| ScriptRipper | due to ubuntu 9.04 *lol* | 15:50 |
| NCommander | ScriptRipper, actually, due to gcc-4.4 | 16:07 |
| NCommander | (and a few other nameless things :-/) | 16:08 |
| pro-rsoft | I dont seem to have /lib/modules ... what could possibly be wrong? | 20:14 |
| pro-rsoft | I mean its empty | 20:15 |
| persia | pro-rsoft, What kernel do you have installed? | 20:41 |
| pro-rsoft | I had 2.6.28-oer17 installed | 20:41 |
| pro-rsoft | but nvm I solved the issue | 20:42 |
| pro-rsoft | it installed modules.dep somewhere else so I just symlinked | 20:42 |
| pro-rsoft | next problem: lsmod shows empty | 20:42 |
| persia | Well, that just means no modules happen to be loaded. | 20:42 |
| pro-rsoft | hmm ok | 20:42 |
| pro-rsoft | so I need to load them using modprobe right? | 20:42 |
| pro-rsoft | persia, where can I get a list of available modules to insert? | 20:42 |
| persia | As much as I generally recommend finding a kernel somewhere, as the distro kernels support so few devices, you'll do well to find a kernel that matches the install layout, etc. of the Ubuntu kernels. | 20:43 |
| pro-rsoft | yeah | 20:43 |
| persia | Well, given that I know *nothing* about the kernel you're using, I don't have any answer. I'd start by looking at the files that came with the kernel. | 20:43 |
| pro-rsoft | ok | 20:43 |
| pro-rsoft | ah I see | 20:44 |
| pro-rsoft | thanks | 20:44 |
| === playya_ is now known as playya__ | ||
| === playya__ is now known as playya1 | ||
| === playya1 is now known as playya | ||
| mcm_ | is mplayer for arm already packaged? i find references to it but not the actual mplayer package.... | 22:01 |
| persia | mcm_, Looks like build failures. https://launchpad.net/ubuntu/+source/mplayer/2:1.0~rc2-0ubuntu19/+build/889104 is the latest build record. | 22:03 |
| persia | We don't tend to do arch-specific packages, so any package available for any architecture *should* be available for all architectures. | 22:03 |
| persia | There are some exceptions, but those often represent bugs needing to be fixed in the package, rather than a need for additional packaging. | 22:04 |
| mcm_ | indeed, the way it is as original debian. | 22:05 |
| persia | Precisely. | 22:05 |
| persia | The mechanisms are entirely parallel: use of Architecture in debian/control, and an override file. | 22:05 |
| mcm_ | but since 9.04 is released, a successful build of mplayer, will it get into the 9.04 rep? | 22:06 |
| suihkulokki | mcm_: you'll wat to build a mplayer specific for your hardware features | 22:06 |
| persia | suihkulokki, Is there a reason not to do multiple runs of the mplayer build, as is done for ffmpeg? | 22:07 |
| persia | I'd think that'd be more useful than everyone doing a custom build, or doesn't mplayer permit that sanely? | 22:08 |
| suihkulokki | persia: yes you could do that, but it doesn't exist yet, so mcm will need to compile it himself :) | 22:08 |
| persia | I guess. | 22:09 |
| mcm_ | suihkulokki: ok. | 22:09 |
| mcm_ | i was currently checking the failed build log of mplayer. to see where it failed... | 22:10 |
| mcm_ | persia: & suihkulokki: thanks... | 22:12 |
| persia | mcm_, If you do find out how to fix the build failure, please report a bug with a patch. While it's too late for Jaunty, it would be nice to get this into Karmic. | 22:13 |
| mcm_ | with my newbee knowledge on arm procs, it looks like build machine problem... | 22:15 |
| mcm_ | armv4l/dsputil_arm_s.S:79: Error: selected processor does not support `pld [r1]' | 22:15 |
| persia | Well, that's one way to describe it. Another might be that the capabilities detection leaves something to be desired. | 22:17 |
| persia | (or maybe we just need better buildds) | 22:17 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!