| === wgrant_ is now known as wgrant | ||
| === ApOgEE__ is now known as ApOgEE | ||
| 5EXAAEK4A | Hello ppl , Has any one tried building the ubuntu rootfs from sources ? | 07:37 |
|---|---|---|
| === 5EXAAEK4A is now known as bandwidthcrunch | ||
| persia | bandwidthcrunch: I don't know of any recent efforts to reconstruct it, but it's exclusively generated from uploaded sources. | 07:44 |
| bandwidthcrunch | Wanted to be able to regenerate it from uploaded sources at my end persia. Was wondering if there was a way i could rebuild the jaunty/karmic for armel without using rootstock | 07:46 |
| persia | Well, there's two steps involved. | 07:46 |
| persia | The first is converting sources to binaries, and the second assembling binaries into an image. | 07:47 |
| persia | Do you need to do both, or just one? | 07:47 |
| bandwidthcrunch | I wanted both . A build process like pbuilder (targetting armel) and the binaries in a rootfs populated automiatically | 07:47 |
| persia | OK. | 07:50 |
| persia | So the main issue is the bootstrap. | 07:50 |
| bandwidthcrunch | Wanted to comeup with a distribution targetting custom arm hardware. | 07:51 |
| persia | I don't think there's an easy way to do it. | 07:51 |
| persia | You'd probably want to build your toolchain against Ubuntu, and then rebuild Ubuntu against that toolchain. | 07:51 |
| persia | Which requires setting up your own archive environment (dak, soyuz, etc.) | 07:51 |
| persia | The pbuilder from lucid works on armel (either native or emulated) just fine, but won't scale to what you want. | 07:52 |
| persia | Once you have that, just use your rebuilt rootstock. | 07:52 |
| persia | Unless you have mountains of hardware, this process will probably take 3-4 months at a minimum. | 07:52 |
| bandwidthcrunch | Ok. and what are dak and soyuz ? | 07:52 |
| persia | dak is the tool used to manage the Debian archive. soyuz is the tool used to manage the Ubuntu archive. | 07:53 |
| bandwidthcrunch | i do have atleast 6 600mhz arm devices | 07:53 |
| persia | Getting it done in 4 months is optimistic then. | 07:53 |
| bandwidthcrunch | I will be getting grey hair by then :) . is there anyway to achieve the same on cross platform. Build it on i386 ? | 07:54 |
| persia | You can do it with emulated builds, but it's still a few months. | 07:55 |
| persia | (again, unless you have mountains of hardware) | 07:55 |
| persia | There are heaps of packages that don't cross-compile well, so trying to do cross-compilation would be it's own sort of pain. | 07:56 |
| bandwidthcrunch | Thanks persia. I dont see a way out of this one. Let me check up if openembedded guys have gotten a way of integrating ubuntu sources and churning it out | 07:59 |
| persia | bandwidthcrunch: I can't imagine you really need to do this. | 08:00 |
| persia | Simply because there chance that there's a good reason to provide 20,000 rebuilt binaries is vanishingly low. | 08:00 |
| persia | s/there/the/ | 08:00 |
| bandwidthcrunch | Sometimes i can wait for ubuntu to keep releasing armel builds but for for certain applications i will need source control. | 08:01 |
| bandwidthcrunch | Maybe i can just build those on ubuntu servers ? | 08:01 |
| persia | Do you need modified sources, or sources built over a modified toolchain? | 08:01 |
| bandwidthcrunch | Both . example openoffice doesnt fit well over my 7inch screen. need to hack the sources to trim it to a window and have our own toolchain bake it | 08:02 |
| bandwidthcrunch | ideally have our toolchain build all the packages but again as u mention it is going to take a while doing that | 08:03 |
| persia | OK. The application changes are easy. The toolchain is more fussy. Why do you need a special toolchain? | 08:03 |
| persia | On a separate note, the problem with openoffice isn't that your screen is 7", it's that your screen doesn't have enough pixels :) | 08:05 |
| bandwidthcrunch | Fr application developers we need to provide an SDK with a toolchain | 08:05 |
| persia | Can't you just tell the application developers to use Ubuntu and pbuilder? | 08:05 |
| persia | (or sbuild : doesn't really matter) | 08:05 |
| bandwidthcrunch | Would they be able to do that for armel ? create applications without me passing them my rootfs and a toolchain ? | 08:06 |
| persia | Yes. | 08:06 |
| persia | Well, under some constraints. | 08:07 |
| persia | So, let's assume you start from the Ubuntu archives. | 08:07 |
| persia | Then your developers either run pbuilder on native hardware or run pbuilder with emulation on foreign hardware. | 08:07 |
| persia | That's how we develop Ubuntu today. I don't see any reason that someone couldn't use the same procedure elsewhere | 08:08 |
| bandwidthcrunch | Is there a wiki somewhere where i can readup on howto go about the same ? | 08:08 |
| persia | (and, honestly, we don't always do the build on armel if it's not an arch-specific thing, and just trust the archive to build the armel binary from the single upload of source) | 08:08 |
| persia | !pbuilder | 08:08 |
| ubot4 | pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto | 08:08 |
| persia | You'd need to be running lucid to get the emulated pbuilder working, but that is created by running `pbuilder-dist lucid armel create` on i386 or amd64. | 08:09 |
| persia | (assuming ubuntu-dev-tools to be installed). | 08:09 |
| persia | So, the developers can do their testing / development using a combination of native i386/amd64, native armel, and emulated armel for development and testing (depending on the specific feature being changed). | 08:10 |
| bandwidthcrunch | I have most of the requirements , let me take it out for a spin and see what comes up ... I have 64bit lucid and a core i7. | 08:11 |
| persia | Where you find issues, you can modify sources. You can put the sources either in a PPA or in some other archive somewhere. | 08:11 |
| persia | If you put the modified sources in a PPA, you'll need to set up some armel devices to track the PPA, pull any new sources, build them, and stick the results somewhre. | 08:12 |
| persia | (because PPAs don't build armel). | 08:12 |
| persia | If you use some other archive, you'll need to build for each architecture you want to work. | 08:12 |
| persia | You'll probably want to put the entries for your modified packages in the sources.list for your pbuilder chroots and test devices. | 08:13 |
| bandwidthcrunch | what about thr toolchain ? How does pbuilder set that up ? | 08:13 |
| persia | It just downloads from the archives listed in sources.list | 08:13 |
| persia | So if you upload a modified toolchain, it uses that. | 08:13 |
| persia | But be careful: if you change the ABI, you end up needing to rebuild everything (which takes months). | 08:13 |
| bandwidthcrunch | pbuilder-dist lucid armel create | 08:14 |
| bandwidthcrunch | Error: «armel» is not a recognized argument. | 08:14 |
| bandwidthcrunch | Please use one of those: create, update, build, clean, login, execute | 08:14 |
| persia | You may have to modify rootstock to use your archive, but that modified rootstock would let you build rootfs images. | 08:14 |
| persia | This is lucid? | 08:14 |
| bandwidthcrunch | It is karmic | 08:15 |
| bandwidthcrunch | i will have to uprage it i guess | 08:15 |
| bandwidthcrunch | Let me get on with it.. | 08:16 |
| persia | Yeah. I didn't add the support to build emulated chroots until a few weeks ago, and the emulation stuff still ad lots of issues until near the end of last week. | 08:16 |
| persia | so you'll be working on the edge, but the idea is to create an environment so that nobody needs to traffic in big SDKs anymore, if they use Ubuntu. | 08:17 |
| bandwidthcrunch | Thanks persia, makes a lot of sense now.. | 08:17 |
| persia | bandwidthcrunch: If this works for you, and you end up with patches you think would be good for general application, please file them in launchpad. | 08:18 |
| persia | We'd really appreciate the help in making Ubuntu strong (and it reduces your future effort in merging your patches against the next release). | 08:19 |
| bandwidthcrunch | Done persia. I will push them to lauchpad | 08:19 |
| persia | Thanks :) | 08:19 |
| bandwidthcrunch | Appreciate the help. Will keep us posted on the happenings | 08:20 |
| persia | I don't know if you're planning to use bzr, but there's been a lot of work by the Distributed Development team to try to make working with Ubuntu sources in bzr extra easy. | 08:20 |
| persia | https://wiki.ubuntu.com/DistributedDevelopment has some links that might be interesting. | 08:21 |
| persia | (Depends on your team size, facility with operating debian-style archives, etc.) | 08:21 |
| bandwidthcrunch | I tried using bzr but that was a month two back .. Let me check them up.. | 08:21 |
| persia | There's no requirement to use bzr, but if you have a large team that plans to cooperate on a small number of packages, it may be helpful. | 08:22 |
| bandwidthcrunch | Ahh ok. We have a small team so i dont think we will really be more of a bzr ppl for the time being | 08:24 |
| persia | Fair enough. I just wanted to make sure you knew about the variety of tools available. | 08:24 |
| asac | heyho folks! | 08:25 |
| persia | Selfishly, I'd prefer to see your team working with Ubuntu and using Ubuntu tools, rather than building a derivative distribution :) | 08:25 |
| persia | (although I recognise that if you are targeting some specific device, there are probably commercial requirements that require some variation from the set of packages that have general application) | 08:25 |
| bandwidthcrunch | I agree in the uniformity concept rather than have fragmentations | 08:30 |
| bandwidthcrunch | Ours is a custom device and has a bit of changes that come in for the platfrom but otherwise we like sticking to vanilla ubuntu | 08:31 |
| persia | Excellent. | 08:31 |
| persia | Note that there are some restrictions on trademark usage. I forget the precise phrasing, but it comes down to not being able to call the OS "Ubuntu" if it has modified sources, especially in product marketing and branding, etc. | 08:33 |
| persia | I believe "based on Ubuntu" or similar is accepted. | 08:34 |
| persia | But I'm not qualified to give precise advice: you'd want to check with your counsel. | 08:34 |
| === hrw|gone is now known as hrw | ||
| ynezz | Where can I find modules for vmlinuz-2.6.31-rc3versatile1-cortex-a8 kernel? Seems like I need modules http://ynezz.true.cz/qemu.png | 11:09 |
| persia | From where did you get the kernel? | 11:10 |
| ynezz | I'm following steps here https://wiki.edubuntu.org/ARM/BuildArmPackages | 11:11 |
| ynezz | it's this URL http://people.canonical.com/~ogra//arm/qemu/vmlinuz-2.6.31-rc3versatile1-cortex-a8 | 11:11 |
| lool | ynezz: The modules aren't available | 11:12 |
| lool | ynezz: I recommend you use the lucid versatile kernel instead | 11:12 |
| lool | ynezz: http://ports.ubuntu.com/ubuntu-ports/pool/main/l/linux/linux-image-2.6.32-14-versatile_2.6.32-14.20_armel.deb | 11:13 |
| lool | ynezz: Unpack this with dpkg-deb -x, and you'll get a boot/vmlinuz and a lib/modules tree | 11:13 |
| asac | http://code.activestate.com/recipes/146306/ | 11:13 |
| ynezz | lool: thanks, trying now | 11:14 |
| asac | JamieBennett: ^^ (thats httplib though) | 11:14 |
| persia | ynezz: From where did you find instructions to use that kernel? I'd like to replace that documentation with what lool has just supplied. | 11:14 |
| ynezz | persia: that edubuntu link | 11:14 |
| lool | persia: I guess that's rootstock doc | 11:14 |
| lool | Did rootstock switch to pulling the lucid kernel now? | 11:15 |
| ynezz | persia: "If development machine is running Karmic" | 11:15 |
| asac | odd ... isnt there a soup python binding in the archive? | 11:15 |
| ynezz | persia: here https://wiki.edubuntu.org/ARM/BuildArmPackages | 11:15 |
| persia | ynezz: Found it. Thanks. | 11:15 |
| persia | lool: Do we have a good kernel for running karmic, or should one use the lucid kernel there as well? | 11:15 |
| lool | Gah who copied that page | 11:15 |
| persia | copied? | 11:16 |
| lool | Yeah | 11:16 |
| persia | from where to where? | 11:16 |
| persia | wiki.*buntu.com are just different themes on the same content (or so it is supposed to be) | 11:16 |
| lool | I know | 11:16 |
| lool | :) | 11:16 |
| persia | Oh, heh :) | 11:17 |
| lool | cooloney: Heya | 11:18 |
| lool | cooloney: Would you have some minutes for me? | 11:18 |
| hrw | morning | 11:18 |
| lool | cooloney: I'd like to discuss two things related to qemu/versatile kernels with you | 11:18 |
| lool | cooloney: First is: did you manage to find out what's breaking kexec? | 11:19 |
| lool | hrw: morning | 11:19 |
| lool | cooloney: The second is: I'm having issues with initramfses -- they don't work in qemu versatile, only initrds do; would you be able to help with that? | 11:19 |
| hrw | lool: versatile does not support >armv5te iirc | 11:20 |
| lool | hrw: We patched that | 11:20 |
| hrw | kernel simple patch? I had such one in old Poky days to run armv6 in qemu | 11:20 |
| lool | It works with qemu cortex a8 emulation in our case | 11:20 |
| lool | hrw: Yup, just basically select v7 instead of select arm11something | 11:21 |
| hrw | good choice | 11:21 |
| hrw | versatile is best arm qemu target | 11:21 |
| lool | I'm not sure anymore | 11:21 |
| hrw | scsi, usb, video, network | 11:22 |
| lool | network, usb and network are all related to PCI support IIRC | 11:22 |
| hrw | yep | 11:22 |
| hrw | and usb gives you working touchscreen emulation | 11:22 |
| lool | And actually realview versatile has gained PCI support upstream and... cortex a9! | 11:22 |
| lool | So I have a secret plan to move to this if time permits and people agree with it -- but it's secret, don't tell anyone on #ubuntu-arm | 11:23 |
| hrw | ;D | 11:23 |
| lool | Another good target seems to be omap3, but it's based on another qemu tree and probably works best with the linux-omap tree | 11:23 |
| hrw | yep | 11:23 |
| hrw | OpenEmbedded linux-omap recipes have lot of good patches added to get it better | 11:24 |
| ogra | yeah | 11:25 |
| ogra | angstrom too iirc | 11:25 |
| ogra | (for userspace) | 11:25 |
| hrw | ogra: angstrom uses OE | 11:25 |
| ogra | i know | 11:25 |
| ogra | i was referring to userspace :) | 11:25 |
| hrw | anyway many of our (OE) patches came from Debian or Gentoo | 11:26 |
| lool | hrw: So you're a poky and OE developer? | 11:26 |
| hrw | some from other distros etc | 11:26 |
| hrw | lool: yes, I am | 11:26 |
| hrw | nearly 6 years in OE | 11:27 |
| ogra | debian wont help with v7 or thumb2 specific stuff though | 11:27 |
| lool | hrw: Dump OE and come over here! | 11:27 |
| ogra | i would expect to find more intresting stuff for that in OE than in debian :) | 11:27 |
| ynezz | lool: hm, it boots now, but I can't get after "mountall: Could not connect to Plymouth" | 11:27 |
| hrw | lool: do you give free devboards? | 11:27 |
| lool | ynezz: That's just a warning | 11:27 |
| hrw | :D | 11:27 |
| ogra | ynezz, serial ? | 11:27 |
| lool | ynezz: How did you create your root fs? | 11:27 |
| ynezz | rootstock | 11:28 |
| ogra | do you use a monitor or a serial console ? | 11:28 |
| lool | hrw: If you sign to help us for the next 6 years, I'll ship you one of mine! | 11:28 |
| ogra | note that for serial you need to use the --serial option in rootstock else you wont get a login prompt | 11:28 |
| hrw | ogra: you use monitors? | 11:28 |
| ynezz | ogra: ah, I'm new to qemu, didn't know about it :) | 11:29 |
| hrw | I do not remember when last time I connected beagleboard to lcd | 11:29 |
| ogra | hrw, we build netbook live images, indeed i do :) | 11:29 |
| ynezz | ogra: was following probably wrong wiki page... | 11:29 |
| hrw | sim.one was never conencted to screen even ;D | 11:29 |
| ogra | ynezz, it might be, yeah, the above page you pasted is very confusing | 11:29 |
| cooloney | lool: yeah, we found ARMv7 does not support kexec as well as others | 11:29 |
| ogra | i wonder why that was duplicated from BuildARMRootfs | 11:30 |
| cooloney | lool: we got some patches from omap maintainer | 11:30 |
| ogra | err | 11:30 |
| ogra | RootfsFromScratch rather :) | 11:30 |
| cooloney | lool: eric tested them on dove, i plan to test them soon on imx51 and versatile | 11:30 |
| persia | Does anyone have a recommendation for a TFTP server? | 11:31 |
| * persia sees both atftpd and tftpd and is unsure which to use | 11:31 | |
| ogra | tptpd-hpa | 11:31 |
| lool | cooloney: Ok, thanks | 11:31 |
| ogra | *tf | 11:31 |
| persia | ogra: Heh. Neither of the ones I thought. Thanks :) | 11:32 |
| ogra | heh | 11:32 |
| lool | persia: I had an experience where both atftpd and tftpd failed working in a specific case and tftpd-hpa worked | 11:32 |
| cooloney | lool: so for the initramfs, is there any bug tracker for that. | 11:32 |
| ogra | its the one used in ltsp ... the one thats maintained most in ubuntu | 11:32 |
| ynezz | ogra: seems like that eLinux page is more up-to-date then those on Ubuntu :) | 11:32 |
| cooloney | lool: i can take a look at that | 11:32 |
| lool | cooloney: LP #524893 | 11:32 |
| ubot4 | Launchpad bug 524893 in linux (Ubuntu) "Can't boot initramfses (affects: 1)" [Undecided,New] https://launchpad.net/bugs/524893 | 11:32 |
| ogra | persia, another good choice seems to be dnsmasq | 11:32 |
| lool | Hmm right, never tried dnsmasq, but that's certainly a good tool -- it's used in libvirt to provide dhcp and DNS proxies I think | 11:33 |
| persia | ogra: I think dnsmasq is more than I need: I'm just trying to work around the lack of a soldering iron right now. | 11:33 |
| ogra | yeah, it does everything you need for a netboot | 11:33 |
| ogra | dhcp, dns, tftp | 11:33 |
| hrw | dnsmasq is nice | 11:33 |
| lool | cooloney: So I'm not sure whether it's a qemu or versatile kernel bug | 11:34 |
| ogra | and can work as proxy dhcp ... so you dont get races between dhcp servers if you have multiple ones and do netboot | 11:34 |
| lool | cooloney: Do you manage to get an initramfs to unpack on real boards? | 11:34 |
| cooloney | lool: no problem, assigned to me, will take a look, | 11:34 |
| lool | cooloney: Note that "junk in compressed archive" appears twice in the boot source code | 11:34 |
| cooloney | lool: i think we are using initramfs in imx51 board for a long time, | 11:34 |
| lool | cooloney: Note that we have CONFIG_CRAMFS=y in imx51 | 11:35 |
| lool | cooloney: So we might be using initrd instead, without noticing | 11:35 |
| lool | cooloney: If you have a recent dmesg, I could tell | 11:35 |
| lool | Anybody has a recent non-qemu dmesg? | 11:35 |
| lool | (with an initrd) | 11:35 |
| cooloney | lool: hold on | 11:36 |
| lool | dmesg | grep -i initramfs or something | 11:36 |
| cooloney | lool: http://pastebin.ubuntu.com/381535/ | 11:38 |
| cooloney | roc@babbage:~$ dmesg | grep -i initramfs | 11:38 |
| cooloney | Trying to unpack rootfs image as initramfs... | 11:38 |
| lool | cooloney: And the next line? | 11:40 |
| lool | cooloney: grep -A2 -i initramfs ;-) | 11:40 |
| lool | Also, grep for initrd, that might say: Freeing initrd memory: 8924k freed; that's also interesting, I'm not sure that's done for non-initramfs | 11:41 |
| lool | the dmesg in http://www.mail-archive.com/ubuntu-bugs@lists.ubuntu.com/msg1981259.html looks like it's working correctly (supports initramfs), so it's not arm specific, either versatile or qemu | 11:42 |
| lool | http://launchpadlibrarian.net/33211547/dmesg has another one | 11:43 |
| lool | cooloney: So I would suspect the qemu initrd loader is broken :-/ | 11:44 |
| lool | cooloney: it'd be nice to enable CONFIG_CRAMFS=y in the mean time | 11:44 |
| cooloney | lool: right, did you test a kernel with CONFIG_CRAMFS=y before? | 11:45 |
| cooloney | lool: for versatile, | 11:45 |
| ogra | lool, thats weird, i know it works in debian | 11:45 |
| ogra | vagrantc does arm based thin client development in qemu, initramfs support is essential for ltsp | 11:46 |
| lool | cooloney: I know CONFIG_CRAMFS=y works | 11:46 |
| ogra | so it must have regressed between our and debians qemu version | 11:46 |
| lool | cooloney: I tested a Debian kernel | 11:46 |
| lool | ogra: Was it initramfs or initrd? | 11:47 |
| ogra | initramfs | 11:47 |
| ogra | ltsp doesnt use initrd | 11:47 |
| lool | Note that it's the same format | 11:47 |
| ogra | and i know for sure he regulary tests client setups | 11:47 |
| lool | ogra: Was this on ARM? | 11:47 |
| ogra | yes | 11:47 |
| lool | ogra: How can he be sure that it didn't pick up an initrd? | 11:48 |
| ogra | he improves my proof of concept code for arm thin clients atm | 11:48 |
| ogra | he picks up whatever update-initramfs generates | 11:48 |
| lool | ogra: That will work as an initrd as well | 11:49 |
| ogra | i will ask him if he gets up what exactly he uses to test | 11:49 |
| ogra | (he's a portlander :) ) | 11:49 |
| lool | cooloney: Do you have a qemu tree? | 11:49 |
| cooloney | lool: sorry, no | 11:49 |
| cooloney | lool: i plan to clone one and test for a while | 11:50 |
| cooloney | heh | 11:50 |
| lool | cooloney: Either clone upstream or apt-get source qemu-kvm | 11:50 |
| lool | cooloney: The relevant file is hw/arm_boot.c | 11:50 |
| lool | It works the ATAG stuff and loads the initrd in RAM | 11:50 |
| cooloney | lool: ok, no problem. | 11:52 |
| lool | cooloney: http://ftp.debian.org/debian/dists/squeeze/main/installer-armel/current/images/versatile/netboot/ has a kernel + initrd with v5 kernel + v4 binaries which have CONFIG_CRAMFS=y along others and load properly in qemu with -initrd | 11:52 |
| lool | cooloney: Do you want me to send a patch for the versatile kernel configs? | 11:52 |
| cooloney | lool: yes, please. | 11:53 |
| cooloney | lool: i can test that on my side. | 11:53 |
| cooloney | guys, have to head out for dinner | 11:53 |
| cooloney | talk to you later | 11:53 |
| lool | Chers | 11:54 |
| lool | Cheers | 11:54 |
| lool | cooloney: sent | 11:59 |
| persia | ogra: So, tftpd-hpa didn't actually meet my need (because the documentation claiming that when DHCP failed, the device would use a specific address and *then* use TFTP didn't work), so I'm trying dnsmasq. This seems to have decided to only work with my virbr interfaces, but I'm having trouble finding where that is defined. Any ideas on how to add eth0 there? | 12:05 |
| ogra | lool, hmm, i thought all filesystems that can possibly be used for booting are supposed to be builtin not modules nowadays | 12:05 |
| * ogra just notes that there are a lot CONFIG_CRAMFS=m for non armel in lool's patch | 12:06 | |
| ogra | persia, can you start from the ground up ? what exactly are you doing ? :) | 12:07 |
| ogra | and whats your exact setup up to now | 12:07 |
| persia | I'm trying to get my kurobox working again. I last used it for an abortive install of jaunty the day the orion5x kernel was dropped. | 12:08 |
| ogra | whats a kurobox ? | 12:08 |
| persia | It appears that the current state of the device is that it's running the default firmware with a modified password. | 12:08 |
| persia | http://buffalo.nas-central.org/wiki/KuroBoxPro | 12:09 |
| lool | ogra: That's because CONFIG_CRAMFS=m was the default on all arches | 12:09 |
| ogra | lool, ah | 12:09 |
| ogra | i was just wondering ... | 12:09 |
| lool | So it was in the common config and is moving up in per-arch configs | 12:09 |
| ogra | i might even not be up to date wrt module/vs builtin | 12:09 |
| lool | persia: Don't add eth0 to virbr0 | 12:09 |
| persia | DHCP does work, and I should be able to TFTP boot. I ask here not because Ubuntu supports the target, but because I figured that folk here would have more experience with host/client connections than in other channels. | 12:09 |
| ogra | but i thought that was the decision for lucid | 12:10 |
| lool | persia: It's meant to be a proxy interface | 12:10 |
| lool | It's only bridging your vms together | 12:10 |
| persia | lool: My issue is that dnsmasq is *only* listening on virbr0, and I only want it to listen on eth0. | 12:10 |
| lool | and a place for dnsmasq to listen too | 12:10 |
| lool | persia: Is it the dnsmasq you launched? | 12:10 |
| * persia doesn't care about vms at the moment, as real hardware is the current toy | 12:10 | |
| lool | persia: Cause libvirt is spawning one with a non-default config too by default | 12:11 |
| persia | It started from /etc/init.d | 12:11 |
| persia | But I had libvirt installed and didn't have dnsmasq installed before. | 12:11 |
| * persia is now confused. | 12:11 | |
| lool | persia: libvirt-bin depends dnsmasq-base | 12:11 |
| * ogra doesnt get why you have libvirt at all | 12:12 | |
| persia | Aha! So I previously must have had dnsmasq-base and just installed dnsmasq. | 12:12 |
| ogra | dnsmasq works without it | 12:12 |
| persia | ogra: I have libvirt for entirely different reasons, completely unrelated to the current project. | 12:12 |
| lool | persia: dnsmasq-base has the binaries | 12:12 |
| ogra | right | 12:13 |
| persia | So the dnsmasq I see in ps is really the libvirt one, and I need to do something to create a default one? | 12:13 |
| lool | persia: In theory, dnsmasq listen on all interfaces by default, but you can set interface=eth0 | 12:13 |
| lool | persia: Yes | 12:13 |
| lool | Probably you see something like: | 12:13 |
| lool | nobody 1342 0.0 0.0 21404 888 ? S Feb20 0:00 dnsmasq --strict-order --bind-interfaces --pid-file=/var/run/libvirt/network/default.pid --conf-file= --listen-address 192.168.122.1 --except-interface lo --dhcp-range 192.168.122.2,192.168.122.254 --dhcp-lease-max=253 | 12:13 |
| persia | Right. | 12:13 |
| lool | that's the libvirt one | 12:13 |
| persia | And I'm unsure why I only see that one, because /etc/default/dnsmasq has "ENABLED=1" | 12:14 |
| lool | persia: Did it actually invoke-rc.d dnsmasq start upon install? | 12:14 |
| persia | (and that, like the init script, comes from dnsmasq, rather than dnsmasq-base) | 12:14 |
| lool | Just restart it | 12:14 |
| persia | Aha! "dnsmasq: failed to create listening socket: Address already in use" | 12:15 |
| lool | persia: That's because it tries listening on virbr0 too I guess | 12:15 |
| persia | That's my thought. | 12:15 |
| lool | persia: Try listing interface=eth0 explicitly, that might help | 12:15 |
| persia | I suspect we ought silence that :) | 12:15 |
| lool | Silence it? | 12:16 |
| ogra | no you shouldnt | 12:16 |
| lool | persia: except-interface= | 12:16 |
| persia | Patch the default configuration to ignore virbr by default. | 12:16 |
| persia | Right. | 12:16 |
| ogra | but it should report the interface its failing on like dhcpd does | 12:16 |
| lool | persia: Yup | 12:16 |
| persia | Actually, libvirt-bin should probably drop something in /etc/dnsmasq.d to achieve that. | 12:16 |
| * persia files a bug | 12:17 | |
| lool | persia: there's a catch: it will override any user-set except-interface, so it might actually break things to add this | 12:19 |
| lool | I prefer the approach in theory, but in practice it might work better to patch the default config | 12:19 |
| lool | So if someone had except-interface=virbr0,important-interface it will break badly | 12:20 |
| persia | Except that breaks user configurations where virbr is not libvirt managed. | 12:20 |
| lool | I find it less likely | 12:20 |
| persia | except-interface isn't additive if multiply defined? | 12:20 |
| lool | persia: The command-line flags are actually additive, I'm not sure about the .conf | 12:22 |
| persia | I think it is, from what documentation I'm finding | 12:22 |
| * persia looks harder before pressing "submit" on the bug | 12:22 | |
| persia | bug #231060 seems to imply that ttx thinks it ought get sorted with adding a file. | 12:23 |
| ubot4 | Launchpad bug 231060 in libvirt (Ubuntu) (and 1 other project) "packages dnsmasq and libvirt-bin conflict with each other (dups: 2)" [Low,Triaged] https://launchpad.net/bugs/231060 | 12:23 |
| ogra | NCommander, dyfet, are you guys working on the FTBFS list ? it seems a bunch of new stuff showed up there over the weekend and A3 is ahead | 12:24 |
| lool | persia: Ok, it's the same parsing for opts on cmdline and opts in the conffile | 12:25 |
| lool | persia: So additive as well, my bad | 12:25 |
| persia | No, it's better we check :) | 12:26 |
| lool | (one_file() calls one_opt() and getopt ultimately calls one_opt()) | 12:26 |
| persia | Right. | 12:26 |
| NCommander | ogra: looks like the breakage took place in universe/multiverse. Main doesn't look that much different thenI remember, but will investigate | 12:26 |
| ogra | NCommander, some indicator things and keyring stuff | 12:27 |
| ogra | is what i see on a first glance | 12:27 |
| NCommander | ugh | 12:27 |
| ogra | and pulse | 12:28 |
| ogra | please priorize work on that together with dyfet we need these packages for A3 | 12:28 |
| persia | pulse managed to segfault in a shell script. | 12:29 |
| persia | I believe StevenK was looking at it with crimsun | 12:29 |
| * persia remains unsure how to segfault a shell script | 12:29 | |
| ogra | err, sorry, i have given back pulse this morning | 12:29 |
| ogra | it built fine, ignore that :) | 12:29 |
| ogra | persia, thats the typical buildd hiccup we see randomly ... | 12:30 |
| persia | segfaults in bash scripts? | 12:31 |
| ogra | or anywhere else | 12:31 |
| persia | If you can ever reproduce locally, I want a stacktrace. | 12:31 |
| ogra | you cant reproduce it locally | 12:31 |
| ogra | thats the point | 12:31 |
| ogra | its a buildd HW issue | 12:31 |
| ogra | imho | 12:31 |
| persia | Ugh. | 12:32 |
| * persia wants nice reliable retail hardware in the DC. | 12:32 | |
| ogra | ++ | 12:32 |
| ogra | we'll get there | 12:32 |
| ogra | probably even before end of the cycle, who knows | 12:33 |
| persia | lool: You seem to have commented usefully in the bug before I finished dealing with the me too link and duplicate fixups. | 12:34 |
| persia | lool: Are you adding such a snippet, or shall I? | 12:34 |
| persia | (ttx already wrote it, in comment 7) | 12:34 |
| lool | persia: Do feel free to add it | 12:34 |
| lool | persia: I didn't think through about bind-interfaces | 12:34 |
| lool | It's not clear to me why libvirt doesn't pass a list of interfaces and doesn't set bind-interfaces too | 12:35 |
| lool | Actually it does set --bind-interfaces, sorry | 12:35 |
| persia | lool: I just didn't want to duplicate work :) I'll check with ttx about it, etc. and get it fixed. | 12:35 |
| lool | persia: I would personally wonder why libvirt-bin does --except-interface lo instead of --interface x,y,z | 12:35 |
| persia | lool: I suspect it's to catch all of virbr*, but given that it targets a specific address, it's a good question. | 12:37 |
| persia | Thanks for the hints: I'll see what can be sorted. | 12:37 |
| lool | It might target multiple devices,not sure | 12:38 |
| ynezz | ogra: still fighting with that serial console in qemu, I have /etc/init/ttyS2.conf in my image (added by rootstock, --serial ttyS2 option), then I have tried to put "console=ttyS2,115200n8" in qemu kernel boot option and I should have console in qemu monitor mode ctrl+alt+3 right? | 13:22 |
| ogra | if you use qemu the tty has a different name | 13:24 |
| ogra | ttyAMA0 or some such | 13:24 |
| ynezz | ah | 13:26 |
| === Meizirkki_ is now known as Meizirkki | ||
| ogra | you should see the actual name in the boot output of the kernel | 13:27 |
| ynezz | no, I don't have it backlog | 13:27 |
| ynezz | but it's working now, thanks | 13:27 |
| ogra | btw, didnt you say you wanted to build packages ? | 13:28 |
| ynezz | yes | 13:29 |
| ogra | using qemu-arm-static for that is wasy less effort and surely a little faster than running a full VM | 13:29 |
| ogra | *way | 13:29 |
| ogra | though the VM is indeed best for testing the results | 13:29 |
| ynezz | I've never used qemu before and seems, so exploring it and learning how it's working together | 13:30 |
| ynezz | s/and seems//g | 13:30 |
| ogra | qemu-arm-static just enables your x86 machine to execute armel binaries so you can create a chroot to build your packages inside | 13:31 |
| ynezz | ah | 13:32 |
| * ogra glares at 288 syslog 20 0 39196 6216 820 S 85.4 1.3 7:12.27 rsyslogd on his babbage board | 13:33 | |
| ogra | does anyone else see rsyslogd eating all CPU ? | 13:33 |
| lool | ogra: Sounds like your kernel is lacking the relevant options | 13:39 |
| lool | ogra: lp #523468 | 13:39 |
| ubot4 | Launchpad bug 523468 in rsyslog (Ubuntu Lucid) (and 1 other project) "rsyslogd gives 100%CPU (dup-of: 523610)" [High,Triaged] https://launchpad.net/bugs/523468 | 13:39 |
| ogra | there are kernel options syslog uses now ? | 13:39 |
| ubot4 | Launchpad bug 523610 in rsyslog (Ubuntu Lucid) (and 1 other project) "rsyslogd spins CPU on older kernels (affects: 34) (dups: 4)" [High,Triaged] https://launchpad.net/bugs/523610 | 13:39 |
| ogra | ah | 13:39 |
| ogra | apw, ^^^ i see that one with your imx51 testkernel | 13:40 |
| asac | ogra: i see that on the normal kernel too | 13:42 |
| asac | its everywhere | 13:42 |
| ogra | i dont see it on my laptop | 13:42 |
| ogra | 2.6.32-13-generic-pae | 13:44 |
| ogra | no messages in kern.log | 13:44 |
| ogra | well, at least gtk isnt broken on armel ... | 13:45 |
| ogra | unlike on i386 | 13:45 |
| ogra | my babbage is actually faster than my laptop atm when i use the new gtk libs :) | 13:46 |
| hrw | ogra: some of my devices are faster then my 2000y pc | 13:49 |
| ogra | rinning the same desktop ? :) | 13:49 |
| ogra | *running | 13:49 |
| hrw | ogra: I keep my devices headless most of time | 13:50 |
| ogra | right | 13:50 |
| ogra | thats different :) | 13:50 |
| hrw | ogra: and in 2000 I used gnome 1.4, then wmaker+roxfiler | 13:50 |
| ogra | we rarely do headless suff except for building packages here | 13:50 |
| ogra | one day we'll support the server flavour though ... | 13:51 |
| ogra | that might change it | 13:51 |
| hrw | ogra: one day I will connect video cables | 13:51 |
| ogra | heh | 13:51 |
| ogra | bah, pybootchartgui crashes again | 13:52 |
| ogra | File "/usr/lib/pymodules/python2.6/pybootchartgui/parsing.py", line 78, in _parse_proc_ps_log | 13:53 |
| ogra | userCpu, sysCpu, stime= int(tokens[13+offset]), int(tokens[14+offset]), int(tokens[21+offset]) | 13:53 |
| ogra | IndexError: list index out of range | 13:53 |
| ogra | GRRR ! | 13:53 |
| ogra | that was fixed already ! | 13:53 |
| * persia does headless stuff all the time, but only with ubuntu-minimal+pbuilder, which isn't actually useful for doing that much | 13:56 | |
| ogra | gah, who ever wrote pybootchartgui needs a training in python indendation | 14:07 |
| dmart | asac: Hi... were you going to send out a reminder on the ubuntu-mobile list about the proposed IRC sprint session on Thursday? | 14:25 |
| lool | dmart: Heya | 14:29 |
| lool | dmart: Thanks for following on the x264 NEON stuff; do you think you could write the NEON runtime detection in x264 based on /proc/self/auxv instead of SIGILL? | 14:30 |
| lool | dmart: I poked on #x264dev, and the person I was in contact with was receptive | 14:30 |
| dmart | I hadn't got that far yet, but I'll have a go. It didn't look too difficult. | 14:30 |
| lool | dmart: http://paste.ubuntu.com/381628/ | 14:31 |
| dmart | x264 does at least seem to run on my Babbage3 (but encoding /dev/zero is not a great test :P) | 14:31 |
| lool | dmart: They do care to have a portable fallback, so you probably want to keep SIGILL on !linux | 14:31 |
| lool | I have to say I have little sympathy for spending extra cycles supporting chips where NEON is plain broken in hardware with no possible kernel workaround, so I would personally not bother supporting that | 14:32 |
| lool | But that should work by default if you move to auxv | 14:32 |
| lool | dmart: The ARM x264 maintainer upstream if Yuvi | 14:32 |
| suihkulokki | /proc/self/auxv bad. why not read /proc/cpuinfo ? | 14:33 |
| lool | suihkulokki: Why is /proc/self/auxv bad? | 14:33 |
| dmart | cpuinfo: contents more volatile than auxv, and also requires parsing | 14:33 |
| lool | Yeah | 14:33 |
| dmart | lool: Agreed--- it shouldn't be too much work to have both. | 14:33 |
| lool | dmart: Thanks | 14:33 |
| suihkulokki | qemu linux-user :> | 14:34 |
| lool | dmart: sirestart is reviewing my x264 packaging changes; I think they should be enough for us for now, modulo the SIGILL stuff | 14:34 |
| lool | suihkulokki: So linux-user emulates cpuinfo now? | 14:34 |
| apw | ogra, what we seeing there? | 15:00 |
| ogra | ApOgEE, rsyslogd eating up my CPU | 15:01 |
| ogra | but apparently thats not armel specific (though i dont see it on my -pae kernel heer on my laptop) | 15:02 |
| apw | ogra, depends if they have fixed that bug with rsyslogd to not use dd ... | 15:02 |
| ogra | weird | 15:03 |
| * ogra checks versions on armel vs x86 | 15:03 | |
| ogra | same versions | 15:04 |
| apw | yeah i think we may be being hurt by the fix for bug #517773 | 15:05 |
| ubot4 | Launchpad bug 517773 in rsyslog (Ubuntu Lucid) (and 1 other project) "Drop the dd process (affects: 4)" [Medium,Fix released] https://launchpad.net/bugs/517773 | 15:05 |
| apw | let me confirm that ... | 15:06 |
| apw | ogra, ok it looks like they have applied the fix for that to userspace, that means that the kernel requires a fix which is only in the .32 kernels; distro and mvl-dove both have it, but not imx51 ... i'm looking at a backport now, should have a test kernel for you shortly ... | 15:11 |
| ogra | ah, sweet | 15:11 |
| apw | fingers crossed that is the cause ... its building now | 15:12 |
| ogra | did i say already, you rock !! | 15:12 |
| dmart | asac, are patches we add against e.g., mono automatically pinged to Debian? | 15:13 |
| ogra | nope | 15:13 |
| asac | dmart: no. debian will complain ;) | 15:14 |
| asac | dmart: but we are trying to push all patches to them | 15:15 |
| ogra | we need to file bugs | 15:15 |
| lool | apw, ogra: Right that's what I suspected, kernel fix missing; thanks for looking into it | 15:15 |
| asac | dmart: at best our patch would work for them | 15:15 |
| ogra | lool, thanks for saving me to search LP for the issue :) | 15:15 |
| apw | versions skew sucks ... at least the dove kernels get these fixes for free via rebase | 15:16 |
| apw | makes life > 2x harder | 15:16 |
| lool | dmart: usually, we either send them on the spot or during merges (beginning of a cycle), sometimes we send them straight to upstream, that works well too | 15:16 |
| * apw sorly wishes that arm kernels would build as fast on the buildds as they do on his hoover | 15:16 | |
| ogra | just send your hoover to the DC ? | 15:17 |
| lool | apw: True; TBH I'm slightly worried that we're building our userspace against 2.6.32 headers and then running a 2.6.31 kernel on top | 15:17 |
| ogra | lool, we had plenty discussions about that already :) | 15:17 |
| lool | e.g. eglibc picked up pselect() support thanks to it landing upstream, and that exposed the fact that it was missing in qemu -- not a big deal, but it's also missing in linux-fsl-imx51 for instance | 15:17 |
| ogra | (sprint discussions) | 15:17 |
| apw | yeah ... its not in the least bit idea | 15:17 |
| apw | i wish the arm vendors would just to the sensible thing, and track mainline | 15:17 |
| lool | apw: Marvell isn't too bad here though | 15:18 |
| ogra | lool, cooloney does what he can to backport features we find | 15:18 |
| hrw | apw: ha! who would not... | 15:18 |
| ogra | but what we dont find wont be backported | 15:18 |
| apw | lool, indeed they are most enlightened | 15:18 |
| hrw | I have device here with .27.2 kernel as production one | 15:18 |
| apw | i only have to rebase their kernel and i don't hit this issue | 15:18 |
| ogra | hrw, would have issues with recent ubuntu :) | 15:19 |
| ogra | our userspace often ties deeply into kernel features | 15:20 |
| dmart | asac: not sure if you saw my message earlier--- was someone going to send out a reminder about the IRC porting sprint on Thursday? | 15:20 |
| lool | ogra: similarly with epoll and plymouth | 15:20 |
| lool | Did you folks backport epoll_create(0 and friends to linux-fsl-imx51? | 15:20 |
| lool | *epoll_create() | 15:20 |
| lool | dmart: Sprinting on Thursday sounds bad | 15:21 |
| lool | A3 this Thursday | 15:21 |
| lool | We will likely be stuck in the European morning | 15:21 |
| apw | but everything we are doing has to be done by tommorrow | 15:21 |
| ogra | lool, i dont think so, but i dont see the issue i see in qemu on imx51 | 15:21 |
| apw | so one would expect anyone not on the release team to be lying by the pool (obviously) | 15:21 |
| lool | ogra: It might have been part of the pselect support patch | 15:22 |
| ogra | ah | 15:22 |
| asac | dmart: yes, i have to | 15:22 |
| apw | i thought pselect was one of those which was dynamicaly selected at runtime | 15:22 |
| dmart | Sounds from lool that it might be better to move it? | 15:22 |
| ogra | apw, not generally, but just for A3, no ? i mean kernel freeze is still a bit or not ? | 15:22 |
| apw | kernel freeze is march the 11th officially, which means i need it by the 8th | 15:23 |
| lool | oh yeah kernel freeze is march 11 | 15:23 |
| ogra | so there is still a week past A3 | 15:24 |
| ogra | for bad stuff we identify | 15:24 |
| ogra | and beyond that if its a bug it should still be fixable post-freeze, no ? | 15:24 |
| lool | Hmm I don't see pselect support in fsl-imx51, am I reading this wrong? | 15:24 |
| apw | after freeze we move to an sru style bug fix policy | 15:24 |
| ogra | uuh | 15:25 |
| apw | lool i don't think i expect it to be there no | 15:25 |
| apw | i thought it was fakes (badly) in libc | 15:25 |
| ogra | yes | 15:25 |
| apw | you'ld surly know by now if it was an issue | 15:25 |
| apw | as you are testing with those kernels ... today | 15:26 |
| lool | (I'm not testing imx51) | 15:26 |
| apw | you as in mobile | 15:26 |
| lool | Ack, just clarifying | 15:26 |
| apw | and anyone changing libc better be testing with mvl-dove and fsl-imx51 ... lest we have to send boys with big cluebats round to visit them | 15:26 |
| * lool whistles and notes not to touch libc | 15:27 | |
| apw | :) | 15:28 |
| apw | ogra, ok some new kernels with that additional patch, apw2 kernels here: http://people.canonical.com/~apw/fsl-imx51-lucid/ | 15:42 |
| * ogra wgets | 15:42 | |
| apw | feedback appreciated as soon as you can :) | 15:42 |
| ogra | 504 syslog 20 0 33280 1296 828 S 0.3 0.3 0:00.12 rsyslogd | 15:49 |
| ogra | apw, looks fine | 15:49 |
| apw | ogra, awsome, good catch ... | 15:49 |
| apw | i'll get that puppy uploaded now | 15:49 |
| ogra | kern.log is quiet too | 15:49 |
| ogra | \o/ | 15:49 |
| apw | ogra, would i be right in saying we don't really have any out of tree drivers for mvl-dove (indeed any arm branches) | 16:13 |
| ogra | no idea, NCommander does dove | 16:15 |
| * NCommander points apw to ericm as the dove kernel guy | 16:16 | |
| NCommander | apw: as far as I know, we don't aside from any DKMS'ed kernel modules a user may install (although I'm not sure any would work for ARM) | 16:16 |
| ogra | virtualbox on dove ! | 16:17 |
| apw | yeah ... eric isn't available in the timeframe for this decision. i am trying to avoid uploading the mvl-dove kernel just for a compiler bump ... if there arn't any out of tree drivers then i don't need to bother and can save 6 hours of buildd time | 16:17 |
| ogra | plars, can you check if go-home-applet works on your babbage ? | 16:19 |
| ogra | its a no-op on mine | 16:19 |
| ogra | and seems to cause the system to crawl | 16:19 |
| plars | ogra: did they fix the dependency stuff with it? | 16:19 |
| ogra | well, it depends on netbook-launcher | 16:19 |
| plars | ogra: it used to depend on the 3d launcher, which removed efl launcher | 16:19 |
| ogra | since we install netbook-launcher by default now in the images it is installable | 16:20 |
| ogra | the dep was solved | 16:20 |
| ogra | but i doubt that fixes anything | 16:20 |
| ogra | at least it doesnt for me here | 16:20 |
| plars | ogra: ah, I'll check it out | 16:20 |
| plars | ogra: trying it a dove live image at the moment | 16:23 |
| plars | ogra: it seems to come up, but doesn't work well | 16:23 |
| ogra | go-home or the image ? | 16:23 |
| plars | ugh | 16:23 |
| plars | it looks like it actually restarts the launcher when you click it | 16:23 |
| ogra | yeah | 16:24 |
| plars | doesn't bring it to the foreground | 16:24 |
| NCommander | apw: then assume we don't have an out of tree module; if there are, theres nothing critical as I've booted systems without any external modules before | 16:24 |
| ogra | i saw multiple launcher processes here | 16:24 |
| * NCommander is 99% sure we don't | 16:24 | |
| plars | ogra: yes, that's exactly what it's doing - starting a new netbook-laucnher-efl each time you click it | 16:24 |
| apw | yeah NCommander i tend to agree i cannot imagine there are any | 16:24 |
| ogra | plars, sick ! | 16:25 |
| plars | ogra: I'll put a bug in on it, unless you care to | 16:26 |
| ogra | no, feel free :) | 16:26 |
| plars | ogra: I wonder if that's how it foregrounds it with the 3d launcher, but the 3d one is smarter about checking to see if there's already a process and just foregrounds it instead of starting a new one | 16:26 |
| ogra | m,ight be | 16:27 |
| ogra | it doesnt minimize anything though | 16:27 |
| ogra | what i always wonder is what go-home gains us over show-desktop | 16:27 |
| ogra | we should probably just use a modified show-desktop | 16:27 |
| plars | ogra: it does interact with webfav | 16:28 |
| ogra | do we use anything like that in the 2D image ? # | 16:28 |
| plars | ogra: you should be able to drag a url to gha and have it add the favorite to the desktop | 16:28 |
| ogra | ah, right | 16:28 |
| plars | presently, it does not seem to work | 16:29 |
| ogra | plars, log out doesnt work for me either it seems | 16:33 |
| ogra | i get an apport report | 16:33 |
| plars | ogra: there's a bug about that | 16:33 |
| plars | ogra: I just asked for more information on it | 16:33 |
| ogra | yes, i just saw your comment and clicked it :) | 16:33 |
| ogra | (clicked log out here) | 16:33 |
| plars | ah, ok | 16:33 |
| plars | worked when I tested it, hmm | 16:33 |
| ogra | the efl window pops up, i click log-out and the launcher dies | 16:33 |
| ogra | are you up to date with the latest ? | 16:34 |
| plars | ogra: I'm running off the dove live image at the moment, so it should be close if not absolutely current | 16:34 |
| plars | I did not update from there though | 16:34 |
| plars | oh wait | 16:34 |
| ogra | 0.2.2-0ubuntu3 | 16:34 |
| plars | which logout did you click? | 16:34 |
| ogra | the one of the launcher | 16:34 |
| plars | ogra: the one in the... yeah | 16:34 |
| plars | I don't think that one should exist | 16:35 |
| ogra | right | 16:35 |
| plars | I filed a separate bug about that | 16:35 |
| ogra | but as long as it does thats indeed a bug :) | 16:35 |
| plars | the correct logout using indicator-applet-session does work though | 16:35 |
| plars | ogra: certainly | 16:35 |
| ogra | it makes the launcher commit suicide | 16:35 |
| === hrw is now known as hrw|gone | ||
| zul | hi, If possible can someone look at this for me? http://launchpadlibrarian.net/39001967/buildlog_ubuntu-lucid-armel.squid_2.7.STABLE7-1ubuntu5_FAILEDTOBUILD.txt.gz | 19:22 |
| persia | zul: Related to what I was saying in -mobile, have you tried with an emulated pbuilder or sbuild locally? | 19:24 |
| zul | persia: trying it now | 19:24 |
| zul | persia: heh still broken | 19:32 |
| persia | zul: emulated, or give-back? | 19:36 |
| zul | give-back | 19:37 |
| persia | OK. Next best test (assuming you don't have hardware) is to try an emulated build. | 19:40 |
| persia | There's a few syscalls that don't work, so this doesn't work for everything (e.g. gh6 can't be built), but generally with lucid one can build an emulated chroot that works fairly well. | 19:40 |
| persia | There's also some support in karmic, but that doesn't support as many syscalls, so one ends up with massive build logs. | 19:41 |
| persia | Do you have a lucid install available for i386 or amd64? | 19:41 |
| zul | yep | 19:42 |
| persia | OK. Do you prefer pbuilder or sbuild? | 19:42 |
| zul | sbuild | 19:44 |
| * persia checks the current ubuntu-dev-tools for the tool name | 19:44 | |
| persia | OK. So run `mk-sbuild-lv --arch=armel ${VG} lucid`, and you should end up with an emulated build chroot. | 19:45 |
| persia | After that, running `sbuild -d lucid-armel *dsc` should try to build you armel binaries. | 19:46 |
| zul | persia: cool thanks | 19:46 |
| persia | Thanks for helping out with the porting. Please come back if you get stuck. | 19:46 |
| persia | Some people have various hardware and can test various things, but hardware is variable and thin on the ground right now. | 19:46 |
| ynezz | linux-image-2.6.32-14-versatile_2.6.32-14.20_armel.deb should work with karmic qemu image? Seems like it hates me http://ynezz.true.cz/qemu.png | 20:19 |
| ynezz | and lucid image with that kernel ends with http://ynezz.true.cz/qemu-lucid.png | 20:22 |
| lool | ynezz: Which image is that? | 20:22 |
| ynezz | rootstock's | 20:22 |
| lool | I'm not sure what rootstock does for karmic and /dev; in theory, it should be possible to start a karmic userspace with this kernel | 20:23 |
| lool | In fact I think I did last week | 20:23 |
| lool | With a slightly older kernel and slighlty older karmic userspace | 20:23 |
| lool | Concerning lucid, I suspect you're not getting to the network up state, so gettys aren't spawned | 20:23 |
| lool | Usually this is due to lack of etc/network/interfaces or NetworkManager | 20:24 |
| lool | ynezz: For karmic, I'd try loop mounting your fs and checking what's in /dev | 20:24 |
| ynezz | this is command for karmic http://pastebin.com/f3f1b0023 | 20:24 |
| ynezz | lool: I tried that, /dev seems ok and populated | 20:25 |
| lool | ynezz: Does /dev have a /dev/pts dir? | 20:25 |
| ynezz | yep | 20:25 |
| lool | Ok, probably a tmpfs gets mounted instead of /dev and isn't filled properly | 20:26 |
| lool | You could probably workaround by poking at /lib/init/fstab in the image, but that's only a hack | 20:26 |
| ynezz | looks so | 20:26 |
| lool | I would need to reproduce, but I don't have an up-to-date rootstock here | 20:26 |
| lool | I'll leave that one with a more recent environment that mine | 20:27 |
| ynezz | I can upload that image if it helps you | 20:28 |
| lool | ynezz: What you can do is look into the early boot scripts, these are etc/init/mount*.conf | 20:29 |
| lool | ynezz: They have dependencies between each other | 20:29 |
| lool | I usually start by changing the mountall.conf one to be a task instead of a job and to not daemonize and to be verbose | 20:30 |
| lool | ynezz: something like http://ynezz.true.cz/qemu.png | 20:31 |
| lool | err sorry http://ynezz.true.cz/qemu.png | 20:31 |
| lool | Uh | 20:31 |
| lool | my paste buffer is broken | 20:31 |
| ynezz | happens to me all the time | 20:31 |
| lool | How anoying, I can't paste into that xterm | 20:32 |
| lool | ynezz: http://paste.ubuntu.com/381816/ | 20:32 |
| lool | ynezz: For your lucid one, either add NM or add a etc/network/interfaces with the lo interface, e.g. "auto lo" and "iface lo inet loopback" | 20:33 |
| ynezz | lool: will try, thanks | 20:49 |
| === tomg2 is now known as [g2] | ||
| lool | zul: Only happens in -O2 builds, does not happen with -O0 | 21:23 |
| lool | zul: You have a bug? | 21:23 |
| zul | lool: sure gimme a sec | 21:32 |
| zul | lool: #519897 | 21:33 |
| DanaG | hmm, are there any plans to provide official beagleboard kernels? | 21:35 |
| DanaG | RIght now, I get this issue: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/523610 | 21:35 |
| ubot4 | Launchpad bug 523610 in rsyslog (Ubuntu Lucid) (and 1 other project) "rsyslogd spins CPU on older kernels (affects: 34) (dups: 4)" [High,Triaged] | 21:35 |
| lool | Bah squid isn't dpkg-buildpackage -j safe :-( | 21:39 |
| lool | DanaG: Not yet, no | 21:39 |
| lool | DanaG: Your issue is fixed in newer kernels, but we should also fix it in userspace | 21:39 |
| DanaG | Are there any ubuntu-official beagleboard kernels? | 21:39 |
| DanaG | I'm using this kernel, for now: http://rcn-ee.net/deb/kernel/beagle/lucid/v2.6.32.8-l8.0/ | 21:40 |
| DanaG | (also, I keep getting "class suspend failed for cpu 0".) | 21:40 |
| DanaG | when I try to echo mem > /sys/power/state | 21:40 |
| lool | zul: I got it to crash under qemu as well, but I couldn't gdb from the qemu-arm-static env, so I ran a real vm and there gdb would work but had no debug info | 21:41 |
| lool | zul: Rebuilding with -O0 -g and it wouldn't crash | 21:41 |
| zul | lool: k thanks | 21:41 |
| lool | zul: Looks like a toolchain issue or a bug in the generator | 21:42 |
| lool | DanaG: These are the most officials one, but they are still unofficial ;-) | 21:42 |
| DanaG | ah. | 21:43 |
| DanaG | And the -33-rc ones seem to not exist. | 21:43 |
| lool | DanaG: Perhaps you can backport the relevant commit, or just wait for the userspace fix | 21:43 |
| DanaG | I can just wait for now. Or compile my own kernel, yeah. | 21:43 |
| lool | DanaG: Check with rcn; he might have some .33 kernels somewhere | 21:43 |
| lool | DanaG: You could also disable rsyslog or something | 21:44 |
| DanaG | What's weird is that, on my host, even 2.6.33-rc8 has the same cpu-spin (on my laptop). | 21:44 |
| lool | zul: I've sub-ed ~ubuntu-armel | 21:44 |
| lool | DanaG: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=e86296585519f091bb24b17f84950a8edcbf0cc1 | 21:46 |
| lool | that's the 2.6.31 backport | 21:47 |
| lool | DanaG: upstream commit is 002345925e6c45861f60db6f4fc6236713fd8847 | 21:48 |
| lool | Not sure from which tree though, apparently not torvalds | 21:50 |
| lool | http://lkml.org/lkml/2010/2/2/13 | 21:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
