**** BEGIN LOGGING AT Tue Apr 20 03:00:04 2010 Apr 20 03:03:58 * DanaG sticks with ubuntu. Angstrom is a pain. Ubuntu on my beagle matches my host system's development environment perfectly. =þ Apr 20 03:05:39 hmm, is the GPU on that a PCI device, or a "platform" device (a.k.a. not PCI)? Apr 20 03:06:09 And can it run compiz? =þ Apr 20 03:07:24 hmm, which of the two slots is "external" MMC/SD? Apr 20 03:09:08 It's times like this that one wishes vendor spec sheets came with dmesg output and lspci -vvn and lsusb -v :) Apr 20 03:10:52 yeah. I'd hardly call that too much to ask. Apr 20 03:23:38 I think we need generic booting kernels first. Apr 20 03:23:55 Most of the other architectures have them, so now we just look silly. Apr 20 03:24:24 Mind you, powerpc seems to be moving in the multi-kernel direction, but I hope that's just a short-term thing. Apr 20 03:47:57 error: expected type-specifier before ‘boost’ Apr 20 03:47:58 ARGH Apr 20 03:48:28 er, wrong tab... off-topic for this channel. Apr 20 08:33:38 who can point me a cross compiling friendly debian package as an example? Apr 20 08:34:37 ericm: You mean to cross debuild it? Apr 20 08:34:59 ericm: You could try the x-loader or u-boot packages in lucid, I fixed them to be cross-buildable Apr 20 08:35:32 lool, thanks - I'll take a look Apr 20 08:37:24 lool, are they tracked with bzr? Apr 20 08:37:41 ericm: All packages are nowadays :) Apr 20 08:37:46 well almost all Apr 20 08:38:09 ericm: try bzr branch lp:ubuntu/x-loader Apr 20 08:38:17 https://launchpad.net/ubuntu/lucid/+source/x-loader, I'm seeing it might be managed with git? Apr 20 08:38:47 ericm: the git you see there is in the version because it's coming from git upstream Apr 20 08:38:55 So the version mentions this is a git snapshot Apr 20 08:39:17 lool, ok - so it's actually managed by git and synced on lp with bzr? Apr 20 08:40:08 ericm: The way to retrieve exactly what's in the archive locally is "apt-get source", when you actually want to commit to the *packaging* vcs of some package, you can check whether the package has Vcs-* headers, or simply use "debcheckout" which will checkout the relevant Vcs (or just apt-get source if no Vcs was found) Apr 20 08:40:18 ericm: *Upstream* uses git Apr 20 08:40:30 lool, ah I see Apr 20 08:40:55 ericm: For instance, I uploaded a snapshot of valgrind 3.6.0 from SVN and used: Version: 1:3.6.0~svn20100212-0ubuntu4 Apr 20 08:41:06 Just to reflect that I took the snapshot on 20100212 Apr 20 08:41:37 lool, so the bzr only tracks the snapshots, not exactly sync'ed with upstream in full history? Apr 20 08:42:21 ericm: We have automated imports of what reaches the archive into bzr Apr 20 08:42:29 ericm: So the history is only that of the Ubuntu uploads Apr 20 08:42:37 lool, btw - it looks to me x-loader/debian/rules is strange, no binary target? Apr 20 08:42:46 ericm: we have another import for the debian upload, and these are done in a compatible way so that you can merge between them Apr 20 08:42:54 and dh_auto_build seems to do the magic of cross compiling? Apr 20 08:43:10 ericm: However if we were to track upstream history (which we do relatively rarely), we'd have to setup a git import in Launchpad first Apr 20 08:43:36 ericm: That's the new style "dh" rules, it basically say "do the standard thing unless I write an override" Apr 20 08:44:30 ericm: You could try cross-building zlib Apr 20 08:45:02 it's more standard-style Apr 20 08:45:34 lool, ok let me take a look Apr 20 08:49:07 hi Apr 20 08:49:33 hi Apr 20 08:49:35 lool, well it looks like zlib doesn't specify --host in its configure, just with a CC assignment before ./configure, which will work in most cases? Apr 20 08:49:46 ericm: zlib is not using autoconf IIRC Apr 20 08:50:02 ericm: So its configure doesn't support --host and --build Apr 20 08:50:15 ericm: Yes, the package should cross-build, I cross-built it recently Apr 20 08:50:37 and CC="$(DEB_HOST_GNU_TYPE)-gcc" doesn't work with codesourcery toolchain and others Apr 20 08:50:49 ericm: To cross-build it, try something like DEB_BUILD_OPTIONS=nocheck dpkg-buildpackage -B -us -uc -aarmel -d Apr 20 08:51:00 might need some way to specify the toolchain if it's not using the standard gcc naming convention Apr 20 08:51:04 ericm: Yes, that's the first problem you'll encounter Apr 20 08:51:32 ericm: then your package will also fail to build near dh_shlibdeps because codesourcery doesn't include debian specific shlibs information Apr 20 08:51:47 lool, :-( Apr 20 08:51:54 ericm: I'm afraid it's not possible to switch triplet, many many upstreams expect $triplet-gcc Apr 20 08:52:01 lool: OE has patch to make zlib more autotools Apr 20 08:52:07 ericm: What you need is debian/ubuntu cross-building training :-) Apr 20 08:52:20 hrw: Wont help dh_shlibdeps I'm afraid Apr 20 08:52:21 lool, yes - any references? Apr 20 08:52:27 lool, I'm a slack Apr 20 08:52:27 ericm: Let me email you the slides Apr 20 08:52:37 lool, that will be nice Apr 20 08:52:37 we remove configure, makefile.in and place configure.ac + makefile.am + zlib.pc.in Apr 20 08:52:51 lool: probably not Apr 20 08:52:52 ericm: You're not going into safe and nicely working territory, this is pushing the limits of our current systems a bit :-) Apr 20 08:52:54 lool: Would it be possible to gain a copy of those slides? Apr 20 08:53:23 lool: We are working with the same issues here. Apr 20 08:53:35 ericm: sent Apr 20 08:53:41 lool, thanks Apr 20 08:54:24 nosse1: It would, but I'd have to strip them slightly and double-check internally Apr 20 08:54:50 lool: Please do. I'd be grateful. Apr 20 08:54:52 nosse1: Sorry, what's your real name again? Apr 20 08:55:04 nosse1: will check Apr 20 08:55:05 lool: My name is Svein Seldal Apr 20 08:56:11 nosse1: People who I need to check with are sleeping still; I'll check later today, if I forget, please remind me Apr 20 08:56:32 lool, time for an #ubuntu-classroom session ;) Apr 20 08:56:43 lool: FYI I've finally installed Lucid on AM3517 eval kit from TI. And I'm using the CS toolchain to cross the kernel, qt and our application while running "mainstream" ubuntu on the rest Apr 20 08:56:46 ericm: I'm afraid you'll miss the '[ DEMO ]' parts :) Apr 20 08:56:55 ericm: xbuild.txt has notes on what I'd actually be typing there Apr 20 08:57:06 nosse1: Nice Apr 20 08:57:25 lool, I went roughly through the first several slides, and decided to native build in my chroot :-) Apr 20 08:57:33 ericm: lol Apr 20 08:57:53 ericm: I think you're doing the right thing Apr 20 08:58:19 ericm: For people with very slow hardware, or generally resource-constrained hardware or no hardware I'd advocate trying qemu-user Apr 20 08:58:53 I think I should fix our cross-build tool to not care about build-dep loops when converting pre-built packages from the archive Apr 20 08:59:04 lool, indeed Apr 20 08:59:29 Since it is possible to mix host and target binaries in a chroot environment I played with the idea to inject the CS cross compiler into the chroot env to use host native tools for building. Apr 20 08:59:47 If I were to fix it, we'd have a single tool one step way of cross-building any package which can be cross-built *if* you have a dpkg-cross compatible toolchain Apr 20 08:59:49 I don't know if it's even possible or if it's just an crazy idea... :o Apr 20 09:00:13 nosse1: It's definitely possible, I cover this in my slides, well I mention the idea Apr 20 09:00:30 nosse1: it's possible in three ways Apr 20 09:00:54 nosse1: a) real hardware + icecc to move the actual compilation from your slow hardware to a remote intel host running a cross toolchain Apr 20 09:01:10 Point is target native compilation, qemu/chroot is all very slow. That is the one reason you would want to use the CS cross compiler Apr 20 09:01:10 b) QEMU machine emulation (emulating hardware), just like a) Apr 20 09:01:49 c) qemu-user emulation or sb/sb2 like emulation and actual intel binaries in your chroot; "croco" which suihkulokki maintains upstream on gitorious does this Apr 20 09:02:23 nosse1: the compilation isn't the only slow point though Apr 20 09:02:42 that's typically the case for large C++ apps like Qt, but there are other issues Apr 20 09:03:09 lool: You asked about my name. Here's my lauchpad profile: https://launchpad.net/~sveinse Apr 20 09:04:01 wow, the netbook installer looks really nice Apr 20 09:05:38 nosse1: Yup found it googling your name Apr 20 09:05:41 lool: Are you planning to drop clean croco support into maverick? Apr 20 09:05:54 persia: drop? you mean provide/upload? Apr 20 09:06:08 Yes. Apr 20 09:06:12 drop into :) Apr 20 09:06:17 persia: I'd love to Apr 20 09:06:44 lool: I need to go to a meeting. I'll remind you later if doesnt hear anything ;) Thanks! Apr 20 09:06:55 Lovely. Will this be something that has to be installed on both the chroot and the host, or just the chroot? Apr 20 09:07:37 persia: Just the chroot Apr 20 09:07:53 persia: it's qemu-user style emulation Apr 20 09:09:33 So how does it get to the non-chroot binaries, or does one have to install both architectures in the chroot? Apr 20 09:09:41 persia: exactly Apr 20 09:09:48 Oh :) Apr 20 09:10:23 There are various approaches to this kind of hack; in croco, you have a croco.map file which is used when intercepting exec() calls Apr 20 09:10:41 I don't suppose there's some way we could adjust the binfmt-misc wrapper to catch some stuff and execute that natively without adding to the chroot, is there? Apr 20 09:10:52 not really Apr 20 09:11:06 I mean, the kernel/binfmt will do the right thing and run the proper binaries Apr 20 09:11:24 That is, it will see that's for intel and just run them without qemu-arm-static Apr 20 09:11:32 or see it's for arm and run them with it Apr 20 09:11:34 RIght. I was kinda hoping for a way to get croco acceleration out of a Souyz chroot, but I don't think that's feasible. Apr 20 09:11:49 What the kernel doesn't do is remap what you really want to run depending on the path Apr 20 09:11:59 Needs a special crocoised chroot. Apr 20 09:12:14 I personally think security tools might be a better fit for this, but I'm not technical enough to look into it yet Apr 20 09:12:43 persia: Well you typically want your apps to run chroot-ed as to limit their view on files to the ones you have in your build env Apr 20 09:13:15 If they run chrooted, then you need chrooted binaries and their libraries; you could run them from the outside and then chroot, but many of them fork() to run other apps Apr 20 09:13:23 such as gcc calling cc1 or so Apr 20 09:13:28 Oh, certainly. I just wanted to reuse the same chroots for native and non-native. Apr 20 09:13:48 But I don't think that this will work with croco. Apr 20 09:13:48 persia: That works Apr 20 09:13:52 binfmt should catch that Apr 20 09:14:14 but you will effectively end up with two full environments in one Apr 20 09:14:30 persia: When you enter the chroot with croco turned on, it intercepts calls to e.g. /usr/bin/gcc, but if you enter it normally, it doesn't Apr 20 09:14:48 ogra: Not related to binfmt really Apr 20 09:15:16 ogra: Indeed, and it works well, so I can just `pull-soyuz-chroot lucid armel; sbuild -d lucid-armel-soyuz foo.dsc`, but that's not as fast as it could be. Apr 20 09:16:04 lool: Right, but the chroot needs to be multi-arch for croco to work, which the soyuz chroots aren't (and shouldn't be). Apr 20 09:16:23 persia: What do you mean multi-arch? Apr 20 09:16:37 having e.g. i386 *AND* armel binaries. Apr 20 09:16:43 persia: What I mean is that once you've included croco in your chroot (currently in /croco) you can still use it as before Apr 20 09:16:50 Right. Apr 20 09:17:31 So we can have a script that adds croco to a chroot, but we can't expect to install something on the host that automatically does croco-acceleration for all chroots. Apr 20 09:22:39 persia: Well unless you make it part of your build tool, e.g. mount --bind /host/croco /build-chroot/croco Apr 20 09:23:09 And all the native stuff would live under /croco ? Apr 20 09:23:17 Yes Apr 20 09:24:49 Oh, suddenly that looks a lot nicer. Apr 20 09:31:08 Right. I think I have an idea how to do that, at least for schroots. pbuilder will require more investigation. Apr 20 09:31:32 (or rather pbuilder-dist integration: pbuilder has hooks that make it easy for folks that know how to use pbuilder) Apr 20 09:34:27 #define DEFAULT_DEVICE "/dev/fb" Apr 20 09:34:32 /* FIXME: We don't really want to do it like this... */ Apr 20 09:34:44 * ogra grumbles about the omapfb xserver Apr 20 09:35:03 they could at least have picked fb0 Apr 20 09:36:08 So, XorA suggested we could (temporarily) ship a udev rule in the xserver package that would add the symlink. Apr 20 09:36:24 XorA also suggested that he expected to be directed to fix it in the near future. Apr 20 09:37:05 well, given that we're in hard freeze it wont happen for lucid anyway Apr 20 09:37:16 and for maverick we should just fix it properly Apr 20 09:50:57 Can't we fix this omap specific package instead? Apr 20 09:51:02 How does Debian do it? Apr 20 09:51:37 lool, thast what i was saying :) Apr 20 09:52:11 fix it properly by adding a routine that detects the device instead of hardcoding it Apr 20 09:52:31 ogra: switching to fb0 would be good enough for lucid Apr 20 09:52:45 sure Apr 20 09:53:08 It's not terribly difficult to fix, but if XorA plans to fix it, I'm not sure of the value of trying to fix it before him. Apr 20 09:53:50 persia: Having the package in lucid work? :) Apr 20 09:54:25 That's trivially done by shipping a udev rule to create the node the software wants. Apr 20 09:54:32 * ogra checks the other omapfb package as well ... i bet it uses the same hack Apr 20 09:54:56 Could add a s/fb/fb0/ patch, but I had the impression from the discussion this weekend there was some reason this was complex. Apr 20 09:55:53 .BI "Option \*qfbdev\*q \*q" string \*q Apr 20 09:55:53 The framebuffer device to use. Default: /dev/fb0. Apr 20 09:55:57 From man/fbdev.man Apr 20 09:57:23 apparently this is a xorg default for options named "fbdev" -- couldn't find any actual default in xorg-fbdev Apr 20 09:57:24 persia, given that we only support one board atm and in the light that fb0 is usually the default i think its safe to just take fb0 Apr 20 09:57:58 for maverick we should add some detection code though Apr 20 09:58:03 XorA|gone: When you get back, please explain why this is a good/not good idea in some detail. Apr 20 09:58:21 fbdevHWInit(pScrn,NULL,xf86FindOptionValue(fPtr->pEnt->device->options,"fbdev")) Apr 20 09:58:34 ogra: My fear is that the hardcoding is more complex and deeper than you think. Apr 20 09:58:42 persia, not really Apr 20 09:59:00 but i'll test it as soon as this netbook install is done Apr 20 09:59:21 (if that finishes before the volcano stops spitting ash :P ) Apr 20 09:59:23 OK. All I can advise is to check the weekend backscroll. If it trivially works, go ahead. If it doesn't, let's work around it for lucid. Apr 20 10:01:44 persia, ogra: So apparently, xorg-server/hw/xfree86/fbdevhw/fbdevhw.c does the default on fb0 Apr 20 10:01:54 It can be overriden with FRAMEBUFFER in the env Apr 20 10:02:03 or in the config obviously Apr 20 10:02:07 yeah Apr 20 10:02:16 so omapfb should just do the same Apr 20 10:02:26 lool: Indeed. THis is an omapfb-specific bug. Apr 20 10:02:31 (and known to be a bug) Apr 20 10:03:04 fbdevHWInit() calls fbdev_open() which open()s the fbdev, and that's pretty much it; I think src/omapfb-driver.c could do the same Apr 20 10:03:39 Uh plus it checks for fd > 0 ohw ugly Apr 20 10:05:55 There's some trickiness in omapfb because it makes assumptions that certain fbX devices have certain special features/functions. Apr 20 10:06:18 And this needs massive cleanup (upstream), which is why I believe the lucid-timeframe answer is a udev rule. Apr 20 10:06:18 these are in different source files Apr 20 10:06:32 xv has its separate source and uses fb1 Apr 20 10:07:03 root@babbage2:/xf86-video-omapfb-0.1.1# grep -r /dev/fb * Apr 20 10:07:03 src/omapfb-driver.c:#define DEFAULT_DEVICE "/dev/fb" Apr 20 10:07:03 src/omapfb-xv.c:#define OMAP_FBDEV1_NAME "/dev/fb1" Apr 20 10:07:23 in that light src/omapfb-driver.c should just be hardcoded to fb0 Apr 20 10:07:46 plars and GrueMaster, could you please guys to help look at bug #567157 Apr 20 10:07:48 unless lool wants to add the proper fbdev_open() calls :) Apr 20 10:07:48 Launchpad bug 567157 in linux-fsl-imx51 (Ubuntu) "regulators enabled at boot and also print error messages at boot. (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/567157 Apr 20 10:08:14 ogra: I'll do it in my CFT Apr 20 10:08:20 CFT ? Apr 20 10:08:32 * ogra wonders what C means Apr 20 10:08:32 copious free time Apr 20 10:08:35 ah Apr 20 10:08:52 hi, anybody knows about netbook-launcher-efl? Would the XV window get damage info again after it redraws application GUI (e.g. totem)? Now it seems destroys the colorkey background so video cannot be shown correctly. Apr 20 10:10:37 bah, crap flash-kernel fails in ubiquity Apr 20 10:17:08 eggonlea: Sorry no idea Apr 20 10:17:46 Who's maintaining netbook-launcher-efl here? Apr 20 10:17:57 JamieBennett: is that you? Apr 20 10:18:09 lool: mterry Apr 20 10:19:16 Isn't mterry upstream? Apr 20 10:19:38 persia: he is now but not the original upstream Apr 20 10:19:41 eggonlea: Try pinging mterry on #ubuntu-devel or so, he's upstream and is easter time Apr 20 10:19:44 *eastern Apr 20 10:19:53 he is looking after n-l-efl Apr 20 10:20:08 lool: great, thanks! Apr 20 10:21:05 Yeah, well, teams have member turnover, but an upstream contact is an upstream contact :) Apr 20 10:21:15 persia: :) Apr 20 11:55:58 lool: I hope I wasn't rude or anything about requesting the presentation earlier on. I was kind of in a hurry, so I threw myself into the discussion Apr 20 12:01:04 nosse1: Oh not at all Apr 20 12:01:18 nosse1: I wouldn't have mentionned it here if there was no chance of publishing it Apr 20 12:08:25 * sveinse got his beloved old nick back. *nosse1* is now known as *sveinse* Apr 20 12:13:42 Is #ubuntu-arm logged anywhere? Apr 20 12:14:05 sveinse, http://irclogs.ubuntu.com/ but usually an hour behind.. ;) Apr 20 12:14:11 irclogs.ubuntu.com Apr 20 12:14:44 rcn-ee: np, I'm looking for something weeks old Apr 20 12:15:20 ogra, so i was playing around with different methods... The NetInstall really doesn't like it when i force nand to read only.. ;) Apr 20 12:15:34 indeed Apr 20 12:16:01 file a bug on flash-kernel so we can cancel the installation properly with a clean error message Apr 20 12:17:40 i will, after some more testing.. its weird since early in the flash-kernel script it calls the one /etc/flash*.conf so it shoudl exit. (well it works on an already built image) but the NetInstall still runs it.. Apr 20 12:18:11 while its sourced, the omap code doesnt use anything from it Apr 20 12:18:34 actually we only introduced it for imx51 since that has an awful setup Apr 20 12:18:53 yeah i saw that, awful bootloader mess you had to work thru... Apr 20 12:19:33 after using it for three releases i really like redboot more than uboot Apr 20 12:19:35 :) Apr 20 12:19:39 ogra: can you tell more about that 'awful setup'? Apr 20 12:19:44 the easy thing, would be a variable in that config to please leave the nand alone Apr 20 12:19:57 hrw, abusing your install media as "bootfloppy" Apr 20 12:20:04 ah Apr 20 12:20:14 truncating it at the end of the install ... Apr 20 12:20:22 the babbage board can only boot from SD Apr 20 12:20:37 but you cant easily install to the installation media you run from Apr 20 12:21:26 so babbage requires you to install to USB and to keep the SD you installed from as boot media, carrying a special non-data partition that holds redboot, kernel, initramfs and the redboot config (simulating a flash) Apr 20 12:32:25 ough Apr 20 12:34:57 sveinse: Did you find what you needed in the logs? They are (up to) an hour out of date, but they should go back to within a couple weeks of when I opened the channel. Apr 20 12:37:38 persia: yes, thank you Apr 20 12:45:22 Anyone here with openocd and kernel debug experience? Apr 20 12:46:48 I use openocd only to reboot sheevaplug Apr 20 12:47:30 ogra: when you use a non-hacked up u-boot, your opinion will likely change Apr 20 12:47:41 NCommander, nope Apr 20 12:47:49 i like fast boots ... Apr 20 12:47:53 ogra: ouch. Apr 20 12:47:55 uboot cant achieve that Apr 20 12:48:00 by design Apr 20 12:48:05 ogra: u-boot can do raw reads just like redboot. Apr 20 12:48:11 I just like having a filesystem for my files Apr 20 12:48:13 But thats just me. Apr 20 12:48:54 ogra: what you use for that 'fast boot'? Apr 20 12:49:24 nand read? Apr 20 12:49:56 NCommander: redboot supports filesystems as well Apr 20 12:50:21 lool: upstream does, but no vendor fork of Redboot I've seen has it :-/ Apr 20 12:51:36 It's not really a problem with redboot though, but with the vendors :-/ Apr 20 12:52:18 lool: indeed. If we had a modern redboot, I suspect my ability to complain about imx51 booting would be severaly reduced Apr 20 12:52:32 indeed i like its flexibility Apr 20 12:52:33 it still needs to convert from uImage to raw, no ? Apr 20 12:52:33 and copy it around in ram Apr 20 12:53:28 ogra: u-boot can do XIP Apr 20 12:54:03 Do you know if there a host graphical debugger (ddd or insight) which can debug arm code for target? (Probably it's a generic host for the GUI part and gdb-arm for the target) Apr 20 12:54:42 sveinse: ddd should be able to use a cross-debugger, but its been awhile since I tried it Apr 20 12:54:53 * NCommander just got used to using gdb directly; less painful Apr 20 12:54:59 * sveinse is about to embark on some kernel driver development, and need eyes into the running kernel... Apr 20 12:55:30 hrw, redboot ... fast boot paid with zero flexibility Apr 20 12:55:39 I'm going to use JTAG tool + OpenOCD, but I need a GUI frontend for gdb on host Apr 20 12:55:57 ******* reminder ubuntu mobile meeting in 5 min in #ubuntu-meeting ******* Apr 20 12:57:51 hi, all! Apr 20 12:59:03 I try to rebuild gtk+2.0 on my SheevaPlug, and it uses -mfpu=vfp for it, is it ok? I could'nt find that Sheeva supports any floating point unit... Apr 20 12:59:37 slapin: We require vfp nowdays Apr 20 12:59:41 in Ubuntu that is Apr 20 13:00:45 where could I change that globally in my build environment? Apr 20 13:01:00 slapin: You'd need to rebuild all of Ubuntu Apr 20 13:01:05 slapin: This is encoded in the toolchain defaults Apr 20 13:02:38 lool: is there some automated way to build all ubuntu (at least base system plus some packages)? Apr 20 13:02:57 lool: I mean cross-compile Apr 20 13:03:15 slapin: Cross-compile, not really Apr 20 13:03:59 there are various tools available to rebuild Ubuntu as a whole, but they are not too clever, so you might have to do that multiple times Apr 20 13:04:26 lool: what device is used to build lots of packages reasonably fast for ARM architecture? Apr 20 13:05:20 lool: I think it is ok with me, I just want to know which tool is mainstream one Apr 20 13:05:37 lool: and what setup is needed. Apr 20 13:06:49 slapin: We currently build continously Apr 20 13:06:56 slapin: using real ARM hardware Apr 20 13:07:11 using launchpad/soyuz as builder system on top Apr 20 13:07:14 We tried using both dove and imx51 boards, but I think our build system is mostly imx51 atm Apr 20 13:08:33 is it possible to build locally? Apr 20 13:09:40 slapin: Yes Apr 20 13:10:16 slapin: In theory you can setup launchpad, albeit that's heavy, or you can use the Debian tools such as wanna-build and dak, but these are a bit hard to setup as well; finally there are some ad hoc rebiuld tools like rebuildd Apr 20 13:11:54 lool: 'heavy' is fine with me, is there any docs on how to set up launchpad? Apr 20 13:13:43 slapin: There's some (limited) docs as a side effect of https://dev.launchpad.net/Getting Apr 20 13:19:19 thanks a lot! Apr 20 14:05:32 ogra: omap image didn't build last night, I assume because of RC (which it is not really included in at the moment). Any way to force just that one to rebuild? Apr 20 14:06:12 plars, we need the livecd-rootfs fix anyway, so i prefer to wait Apr 20 14:07:05 ogra: ok Apr 20 14:07:20 assuming you refer to netbook Apr 20 14:07:28 ogra: yes Apr 20 14:40:32 lool: Thanks! If you are interested, I can keep you posted on how we solve cross compilation into Ubuntu. Currently it seems that apps built in the cross compiler works directly on target, but I think that's a coincidence that both libc and libstc++ has the same version on the cross and on the native system. Apr 20 14:44:28 sveinse: Correct; I don't expect too many incompatibilities there, because we try hard to have working binaries, but it's bad for other reasons (you actually want to know aganst what piece everything is built, and wihch features it uses -- toolchain flags and such) Apr 20 14:58:39 lool: Where is the default compile flags (for the native compiler defined)? In the spec file? Apr 20 15:00:22 The toolchain default to what you compiled it with Apr 20 15:01:12 Ah right, so it adopts its CFLAGS automatically Apr 20 15:28:43 NCommander: does OOo build at the moment? I've been trying to get a build tree for a few days, but I've hit problems Apr 20 15:28:57 dmart, it should Apr 20 15:28:59 dmart: Yes I think so Apr 20 15:29:03 dmart: Well it's *building* I think Apr 20 15:29:24 and it did as well before that minor change upload Apr 20 15:29:28 dmart: in theory. Apr 20 15:29:33 after NCommander fixed it Apr 20 15:29:43 there was one finished build afaik Apr 20 15:29:47 ogra: you mean blundened it Apr 20 15:29:59 It's definitely building ATM Apr 20 15:30:13 yeah, there was a recent upload Apr 20 15:30:21 dmart: we forced it to -marm. Not a real fix, but works for now Apr 20 15:31:23 http://pastebin.ubuntu.com/419326/ Apr 20 15:31:36 I always get this, whether the -marm workaround is present or not. Apr 20 15:31:43 My filesystem should be up to date Apr 20 15:31:44 ../unxlngr.pro/bin/makedepend: symbol lookup error: ../unxlngr.pro/bin/makedepend: undefined symbol: cppsetup Apr 20 15:31:48 hmm Apr 20 15:31:58 dmart, how far into the build was that ? Apr 20 15:32:20 https://edge.launchpad.net/ubuntu/+source/openoffice.org/1:3.2.0-7ubuntu3/+build/1698510 says its running since 19th Apr 20 15:32:22 Pretty early - no more than 1h in Apr 20 15:32:24 Incorrect build-deps (or my filesystem in a mess) Apr 20 15:32:25 ? Apr 20 15:32:54 This is a lucid chroot running on top of Jaunty in babbage1 Apr 20 15:33:19 heh Apr 20 15:33:35 thats a pretty unpredictable env Apr 20 15:34:06 our buildfarm is completely bbg3 on lucid now Apr 20 15:34:26 I've encountered a number of odd failures running pbuilder in jaunty to build lucid: I've had significantly better success with using qemu-user mode (although that's not a good basis for this specific issue) Apr 20 15:34:53 OK, maybe I ought to be careful about this Apr 20 15:34:53 surely not for OO.o, no :) Apr 20 15:34:59 I've been presuming it's due to missing thumb2 support int he jaunty kernel, although I have no basis for this presumption. Apr 20 15:34:59 I have loads of babbage1 doing not much :/ Apr 20 15:35:17 dmart: Can you get a 2.6.32 kernel running on them? Apr 20 15:35:25 persia: the jaunty kernel should support Thumb-2, but there might be some unfixed issues Apr 20 15:35:29 if so, you have the basis of a lovely build farm :) Apr 20 15:35:43 persia, bbg1 was pre-production HW Apr 20 15:35:50 I can maybe run the build on babbage3 and use the babbage1s as distcc slaves Apr 20 15:35:55 there can be plenty of silicon issues Apr 20 15:36:09 a pretty dumb board can run distccd Apr 20 15:36:34 yeah, for distcc that might work Apr 20 15:36:39 or icecc Apr 20 15:36:47 icecc? Apr 20 15:36:58 next gen distcc :) Apr 20 15:37:14 * dmart googles Apr 20 15:37:18 oh, right :) Apr 20 15:37:35 NCommander had a setup for his OO.o tests Apr 20 15:37:52 For massive C++ compiles distcc can provide quite a boost Apr 20 15:38:08 ogra: dmart: icecc doesn't help much, since then it tries to parallize the things that icecc doesn't do, and the then it goes bad Apr 20 15:38:21 ?? Apr 20 15:38:38 which of the icecc should be distcc now ? Apr 20 15:38:47 ogra: basically, theres no way to tell OOo you only want to parallize the building only the C/C++ builds Apr 20 15:38:51 so it works great for C/C++ modules Apr 20 15:38:58 it gets really bad when it gets to running javac Apr 20 15:39:43 * ogra still doesnt get what things icecc does that icecc doesnt do Apr 20 15:39:50 that sentence made no sense Apr 20 15:40:11 ogra: oh, I fail Apr 20 15:40:38 ogra: basically, the OOo build system is stupid, and can't properly parallize the build so only the C bits are build in parallel Apr 20 15:40:39 ofcourse, distcc/icecc don't parallilze javac. just c/c++ Apr 20 15:40:58 right Apr 20 15:41:17 i got *that* part Apr 20 15:42:50 the initial sentence was just very confusing Apr 20 17:07:38 ogra: ping Apr 20 17:13:27 hey guys is UDS still going ahead as planned considering the chances of airflight being allowed by then seem to be minimal? Apr 20 17:14:35 XorA|gone: minimal? according to whom? Apr 20 17:14:54 lool: the volcano doesnt seem to be emitting any less ash Apr 20 17:15:04 Actually it does Apr 20 17:15:17 lool: not according to news this afternoon when scotland closed again Apr 20 17:15:35 I heard at lunch that ashes emissions went significantly down Apr 20 17:15:52 XorA|gone: hey bud Apr 20 17:15:59 XorA|gone: So, isn't that why the chunnel was dug? Apr 20 17:16:09 XorA|gone: ugh, saw the new dr.who last saturday :( Apr 20 17:16:14 XorA|gone: very disappointed Apr 20 17:16:17 persia: yeah thats easy enough for me, I just dont want to be the only guy there :-) Apr 20 17:16:42 Those of us from far away can fly to somewhere within train distance one way or another Apr 20 17:17:04 persia: just checking people are still planning to attend and not move to somewhere more reliable like spain Apr 20 17:17:14 as Ill need to book tickets ASAP Apr 20 17:17:21 it's definitely still planned :-) Apr 20 17:17:22 We did spain too recently to repeat Apr 20 17:17:56 BBC news if quite defineate on increasing volcano ash again today Apr 20 17:18:33 (and actually, twice: once andalucia and once catalunya) Apr 20 17:19:01 * XorA|gone thinks we need an Edinburgh to Holland tunnel Apr 20 17:31:56 The airspace here in Norway has been reopened today. And according to the news, the volcano has gone over to a lava-production phase where the ash production is significantly reduced Apr 20 17:34:01 sveinse: Thank goodness Apr 20 17:34:19 sveinse: But unfortunately the second volcano is starting to swell .. so we're likely going to see a second blast Apr 20 18:14:47 eggonlea: you around? Apr 20 18:27:40 XorA|gone: going for UDS? Apr 20 18:28:25 XorA|gone: would be great to see at least one known face ;D Apr 20 18:31:41 hrw|gone, we're not *that* ugly, don't be scared :) Apr 20 18:31:46 prpplague, hey Apr 20 18:31:57 (just here for a few mins) Apr 20 18:31:58 ogra_cmpc: I did not said that. Apr 20 18:32:24 though all the hugging might scare you probably *g* Apr 20 18:33:12 ogra_cmpc: but when I will arrive at ~21:00 on sunday it would be easier to just call xora and go for a beer then catch someone on irc and then wonder which of guys in lobby was that one Apr 20 18:34:19 * ogra_cmpc doesnt actually knoe when he arrives (driving by car) but i'm surely up for a beer then :) Apr 20 18:34:28 ogra_cmpc: during uds I will meet some familiar faces but connecting faces to irc nicks etc takes time Apr 20 18:34:35 indeed Apr 20 18:34:41 * ogra_cmpc knows what you mean Apr 20 18:34:58 and XorA|gone is easy to memorize :) Apr 20 18:35:12 guadec 2007 was great for me - I finally met OpenedHand people after working with them for nearly half year Apr 20 18:35:27 you will meet some again at UDS Apr 20 18:35:36 ogra_cmpc: I first met him in 2006 iirc Apr 20 18:35:51 * ogra_cmpc met him about a month ago in nice Apr 20 18:36:34 ogra_cmpc: so far I do not see ex-OH people on list Apr 20 18:36:44 but there is still time - I am not on a list yet too Apr 20 18:36:57 waiting for some mails first Apr 20 18:37:04 not sure they did their paperwork yet ... Apr 20 18:37:39 bts got my papers yesterday Apr 20 18:37:43 but i'm sure neil is coming Apr 20 18:40:33 ogra_cmpc: hey bud Apr 20 18:56:10 asac: so libgphoto2 successed in public devirtualized PPA Apr 20 18:56:13 asac: care to sponsor? Apr 20 18:56:59 I can if you pass me the dsc url Apr 20 18:59:11 asac: crimsun: https://bugs.edge.launchpad.net/ubuntu/+source/libgphoto2/+bug/567422 Apr 20 18:59:12 Launchpad bug 567422 in libgphoto2 (Ubuntu) "ARM FTBFS fix for libgphoto2 on lucid (affects: 1)" [Undecided,New] Apr 20 19:03:57 NCommander: could you check with -release ... i guess this wont be before RC? Apr 20 19:04:13 asac: already did check with release yesterday on fixing this problem this way Apr 20 19:04:20 asac: not sure on uploading it now though Apr 20 19:09:33 asac: we're in pre-release freeze now though, so you can upload now, and if its problematic, it will just sit in the queue until after RC Apr 20 19:16:23 NCommander: ok. let me test build at least ;) Apr 20 20:30:04 hello Apr 20 20:30:58 I'm trying to set an USB camera on the beagle board and I have some problems **** ENDING LOGGING AT Wed Apr 21 02:59:56 2010