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