**** BEGIN LOGGING AT Wed Jul 18 02:59:59 2012 Jul 18 06:38:05 infinity, http://elinux.org/BeagleBoardUbuntu#SGX_armel.2Farmhf_v3.4.x.2B Jul 18 06:39:06 hm. tried the omap4 netboot installer, but board does not boot afterwards. 12.10's boot.img-serial.gz should be right? Jul 18 06:40:35 or rather boot.img-fat-serial? Jul 18 06:44:13 LetoThe2nd: boot.img-serial.gz should be fine if you zcat it to a card. If the installer ran all the way through, the image was fine. Jul 18 06:44:30 LetoThe2nd: But it's entire possible that it doesn't produce a bootable system in quantal. Jul 18 06:44:59 ogra_: Is flash-kernel-installer not doing nice things in quantal? I've heard a few reports of netboot not producing bootable systems. Jul 18 06:45:07 infinity: it ran all the way. ah, i see. will give it one more try with 12.04 for now Jul 18 06:45:20 LetoThe2nd: 12.04 should be just fine. We use it all the time. Jul 18 06:45:55 infinity: yeah, i just hoped i could already give 12.10 some testing Jul 18 06:47:57 ah, and one more thing - do the arm port repos also provide rt-enabled kernels like for x86, or is there opportunity for playing? Jul 18 07:04:29 infinity, I have asked in #beagle as well, I will let you know if I get any follow up, (afk) Jul 18 07:55:48 hm, netinstall with precise also did not result in a bootable sd card. :( Jul 18 08:59:14 ok, now i am pretty convinced that there is something fishy with the netboot installer taken from http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/boot.img-serial.gz Jul 18 09:00:01 tried now twice with different sd cards, two times system is not booting anymore after successfully completing the installer. Jul 18 09:00:06 file a bug, attach as many logs as you cnan find :) Jul 18 09:00:41 image was written to block device using zcat image > device... everything correct so farß Jul 18 09:01:33 right, but that image is a single partition image, flash-kernel doesnt know how to write to a device instead of to a partition Jul 18 09:01:56 ogra_: hence? Jul 18 09:01:57 well, at least for omap4 it expects to have mmcblk0p1 Jul 18 09:02:30 you could check if it still boots when you partition your SD first and then dd to the first partition Jul 18 09:02:52 ogra_: can do that. Jul 18 09:03:26 ogra_: something like creating a 60M fat16 partition on the blockdevice and then zcatting to that? Jul 18 09:03:45 right Jul 18 09:04:16 will do. report back in some minutes Jul 18 09:04:20 thx Jul 18 09:05:14 using the automagic partitioning afterwards is ok? Jul 18 09:05:53 yes Jul 18 09:06:05 it shouldnt care about the SD Jul 18 09:06:11 only flash-kernel will in the end Jul 18 09:06:56 ogra_: does not even boot. Jul 18 09:07:07 ah, sad Jul 18 09:07:27 indeed. Jul 18 09:07:27 i'll look into it Jul 18 09:07:48 thx Jul 18 09:07:57 thanks for telling me Jul 18 09:08:05 np. Jul 18 09:08:33 shall i walk though the process once more using the block directly for zcatting, so i can inspect the card afterwards? Jul 18 09:08:52 that would be helpful, yes Jul 18 09:09:35 np, will be ready after lunch i guess. Jul 18 11:05:11 ogra_: back with the sd card :) Jul 18 11:05:30 so what does it show ? Jul 18 11:06:21 ogra_: after the finished install process, the favorite symptoms of any pandaboard user: power on -> status led 2 solid on. Jul 18 11:06:37 hwo does the SD look like ? Jul 18 11:06:41 *how even Jul 18 11:07:45 http://paste.ubuntu.com/1098130/ Jul 18 11:08:19 besides that, black and on the front side is printed "micro sd card 4gb class 10", on the back side it has some copper coloured contacts. Jul 18 11:08:22 *SCNR* Jul 18 11:09:14 oh, wait, you installed *to* the SD ? Jul 18 11:10:33 janimo, ac100 images work fine now, thanks for all the help (the tegra driver in the archive makes lightdm end up in a restart loop though, i just uploaded the new tegra driver, lets see if that works) Jul 18 11:10:58 ogra_: roger that Jul 18 11:11:04 hmm Jul 18 11:11:50 i assume /dev/sdd1 contains /boot ? Jul 18 11:12:12 ogra_: i guess so, its what installer automagic created. Jul 18 11:12:21 right Jul 18 11:13:14 LetoThe2nd, bug 872525 Jul 18 11:13:16 Launchpad bug 872525 in partman-uboot "No option for u-boot partition on armel omap/omap4 platforms" [Medium,Triaged] https://launchpad.net/bugs/872525 Jul 18 11:14:14 ogra_: want me to try gruemasters suggestion? Jul 18 11:14:26 that would be helpful Jul 18 11:14:44 if that works i'll take a look at how we can default to that setting with a default preseed entry Jul 18 11:15:19 ogra_: will take some time, probably about an hour. gonna report back then. Jul 18 11:15:28 great, thanks Jul 18 11:15:40 * ogra_ will meanwhile take a look at the preinstalled server images Jul 18 11:17:41 ogra_: What was the reason for changing the panda images from preinstalled to live? Jul 18 11:18:03 TheMuso, bad user experience due to bad I/O on SD cards Jul 18 11:18:37 TheMuso, and the fact that it takes some effort to maintain the preinstalled stuff separately ... with the switch to live we just use what all other arches use Jul 18 11:19:14 * TheMuso nods. Jul 18 11:19:49 which reminds me ... Jul 18 11:20:16 * ogra_ needs to update the alsa UCM stuff for the pandaboard, seems they renamed the device *AGAIN* ! Jul 18 11:20:34 UCM stuff is still very much in development it seems. Jul 18 11:20:34 i hope they run out of names at some point Jul 18 11:21:08 well, it worked (kind of) in precise and oneiric on the panda and the ac100 Jul 18 11:21:22 Well I'll be able to help with testing at least... Jason got panda boards for all desktopt team members, so as soon as I get a USB drive box, my panda will be running quantal. Jul 18 11:21:33 yippie ! Jul 18 11:22:29 I probably still need to get extra bits, as I'd like to try and test 5.1 HDMI audio if possible. Got a stereo HDMI monitor, but I'd rather make sure everything works. Jul 18 11:22:52 ogra_: And are the gstreamer bits for omap4 available in precise? I see there is a driver via jockey, but what about the rest? Jul 18 11:23:17 no, TI didnt make them available for the kernel we have in precise Jul 18 11:23:28 Shame. Jul 18 11:23:34 there is a TI PPA that has them and an unsupported TI kernel package Jul 18 11:23:41 Ah ok. Jul 18 11:34:41 ogra_, \o/ for the final tegra graphics drivers! Jul 18 11:34:55 well, lets see if they work :) Jul 18 11:35:08 they already built, waiting for the publisher Jul 18 11:35:10 let's see how the new nvidia rebased kernel works, there may be regressions compared to precise Jul 18 11:35:25 there surely is an issue with the alsa parts Jul 18 11:35:32 i see a lot related messages Jul 18 11:35:38 marvin24, I went ahead and rebased our packaging tree (so your patches included in last package) on nvidia's l4t-15 branch Jul 18 11:36:11 I'll do a new rebase or cherry-picking for the changes you have added since sometimes soon Jul 18 11:37:00 I do not use the ac100 enough to know what kernel things still need fixing, so am a bit surprised to see new commits still being added as if there were actual issues :) Jul 18 11:37:27 "tegra-alc5632.0: only stereo is supported in I2S mode" is what i get over and over in dmesg Jul 18 11:37:47 (until i run sudo alsa force-unload to quieten it) Jul 18 12:04:31 ogra_: nope, does not help Jul 18 12:04:50 ok Jul 18 12:05:01 probably partman-uboot is completely missing or so Jul 18 12:05:09 i'll inspect it, as i said ... Jul 18 12:05:28 the choice item was labeled a bit different "use longest contiguous free space" or so, it didn't fix it. Jul 18 12:05:55 ogra_: I should have my USB box tomorrow, so plan to do a net install then, if I get the same problem I'll do some digging as well, that is if you don't get to it today. Jul 18 12:05:55 janimo, oh, disregard the moaning about alsa, i didnt run the new kernel yet, it was not on todays image Jul 18 12:06:10 TheMuso, great, thanks Jul 18 12:06:12 oh, so it may actually be much worse :) Jul 18 12:06:23 lets see ... rebooting Jul 18 12:06:26 I just ran a simple zImage to see it boot till tarbgall installer Jul 18 12:06:52 ogra_: TO confirm, in d-i, do I mark the first partition on the SD card as bootable? Jul 18 12:07:09 janimo, hmm, looks like it hangs in fsck Jul 18 12:07:23 TheMuso, doesnt matter we dont run DOS ;) Jul 18 12:07:32 janimo, yeah, definitely Jul 18 12:07:58 ogra_: So I just ignore the SD card at partitioning time? Jul 18 12:08:44 janimo, now it prints a message: "rcu_sched_state detected stall on CPU 1 (t=6000 jiffies)" Jul 18 12:10:53 janimo, hmm second try works (still the same issue with lightdm constantly respawning though) Jul 18 12:11:10 ogra_, is this after a successful install with the previous kernel and ext2? Jul 18 12:11:11 and the alsa messages are back as well Jul 18 12:11:19 janimo, right, todays image Jul 18 12:11:31 can lightdm respawning be related to l4t or is this with fbdev? Jul 18 12:11:43 then i installed the tegra driver, updated it ... and then pulled linux-ac100 Jul 18 12:11:55 well it started with l4t Jul 18 12:12:04 (before i upgraded the kernel) Jul 18 12:12:14 but it can indeed be a missing bit in our kernels Jul 18 12:12:21 which the final driver uses Jul 18 12:13:21 hmm, intresting, startx works Jul 18 12:13:52 and opening a terminal crashes it ... then it spills about 2000 alsa errors on the consile Jul 18 12:15:22 *console Jul 18 12:16:15 * ogra_ purges the nvidia driver Jul 18 12:19:07 janimo, ok, without the driver i get lightdm to work, but still have the alsa errors (sound works though, its just extremely niosy in dmesg) Jul 18 12:20:25 ogra_, so it worked with the newest tegra driver and the previous kernel? Jul 18 12:20:41 yes Jul 18 12:20:50 err, no Jul 18 12:20:52 sorry Jul 18 12:21:20 Xorg.0.log only has a segfault, no further errors Jul 18 12:32:19 janimo, for whatever reason my syslog is full of "fuse.ko: Invalig Argument" Jul 18 12:32:22 *invalid Jul 18 12:50:34 oh, i just noticed the new driver ships new udev rules and an upstart init script Jul 18 12:50:49 SHRIEK !!!!!!!!!!!!!!!!!!!!!!!1111 Jul 18 12:51:17 first command in that initscript is: chmod 0666 /sys/power/state Jul 18 12:52:04 oh, intresting ... all hardcoded sysfs paths in there have tegra3 in their pathname Jul 18 12:54:10 seems even though it is a ventana package it expects tegra3 devices Jul 18 13:03:47 janimo, hmm something is definitely weird with the fuse module Jul 18 13:04:10 it complains that fuse is loaded already if gvfs tries to load it on desktop startup ... but lsmod disagrees Jul 18 13:10:31 ogra_, I'll do an install myself today or tomorrow and look at the issues that piled up. Jul 18 13:10:48 k Jul 18 13:10:58 I need to start using the ac100 myself it has been just standing there doing nothing for a good while Jul 18 13:11:14 i'll try to find out why the tegra driver fails ... Jul 18 13:11:26 yeah, i moved to a shiny new desktop myself Jul 18 13:11:53 ogra_, so you're back on x86 again :) Jul 18 13:12:04 didnt touch the ac100's for a while, quad core, 16G and a super fast SSD somewhat spoiled me :) Jul 18 13:12:17 mumble, mumble, kernel cross-compilation, mumble mumble Jul 18 13:12:22 * ogra_ even started plaing games again in the evenings Jul 18 13:12:42 ya ya ... i'll set up a cross env some day Jul 18 13:13:07 I keep saying that for almost 2 years but I should probably get myself one of those fast systems too. I do too much building and that would help Jul 18 13:13:13 atm i try to fiull my 3TB HDD with images and a debmirror ... iÄ'll surely add several kvm's and cross chroots Jul 18 13:13:37 ogra_, it is not much of a cross env, no need for qemu and other junk for kernel. Just cross-gcc and you're done, so a single apt-get install :) Jul 18 13:14:06 well, i want to keem the host system completely clean and do all work in chroots Jul 18 13:14:10 *keep Jul 18 13:14:14 for full package builds yes, chroots and whatnot is needed, but kernel builds are really simple Jul 18 13:14:33 preferably having them tarred up and unpacking them on the fly to a tmpfs Jul 18 13:14:54 having fast ssd and lots of RAM allows such complicated setups I guess Jul 18 13:14:56 somehow i cant get the system to use more than 9-10G of the ram ... Jul 18 13:15:05 so i can eat the rest with tmpfses Jul 18 13:15:35 isn't there something like SETI at home but which eats RAM instead of CPU cycles? You should try that Jul 18 13:15:39 "tegra-alc5632.0: only stereo is supported in I2S mode" is what i get over and over in dmesg Jul 18 13:15:40 that should allow cross builds in minutes :) Jul 18 13:15:44 or pull ;-) Jul 18 13:16:19 marvin24, pull ? Jul 18 13:16:25 git pull? Jul 18 13:16:30 oh, a fix ! Jul 18 13:16:32 great Jul 18 13:16:44 i just blacklises all sound stuff for now ... Jul 18 13:16:49 *blacklisted Jul 18 13:17:01 concentrating on the xorg issue Jul 18 13:17:21 i wonder if that driver is supposed to work with this kernel at all Jul 18 13:17:43 startx actually gets me a full desktop but X crashes as soon as i click something Jul 18 13:18:22 marvin24, I tried cloning your tree again yesterday but gitorious would not let me. I'll try again these days Jul 18 13:18:25 and all info i can get is "Segfault at 0x86" Jul 18 13:18:33 in Xorg.0.log Jul 18 13:20:24 * marvin24 didn't tried the new driver yet Jul 18 13:20:34 I only heard of troubles so far ... Jul 18 13:22:59 so lets see how well hrw did his job ... Jul 18 13:23:09 * ogra_ installs gcc-arm-linux-gnueabihf for the first time evar Jul 18 13:25:02 ;) Jul 18 13:25:26 ogra_: if you want to build !kernel then also 'apt-get install libc6-dev-armhf-cross' Jul 18 13:25:34 will do Jul 18 13:29:40 ogra_, hmm I may have lied when telling you there's a single package needed. I remember hrw telling me I need that too but now I do not recall why it was needed for exactly Jul 18 13:29:57 http://marcin.juszkiewicz.com.pl/2012/03/26/ubuntu-12-04-precise-and-cross-compilation-of-arm-kernels/ Jul 18 13:30:16 thats enough for me :) Jul 18 13:30:50 ogra_, you mean to build full debs not just zImages? Jul 18 13:31:27 ogra_, this is what I usually use debuild -eDEB_BUILD_OPTIONS="parallel=3" -eskipabi=true -eskipmodule=true -eCROSS_COMPILE=arm-linux-gnueabihf- -b -aarmhf -us -uc -nc Jul 18 13:32:01 you can make the parallel much more I guess Jul 18 13:33:17 I also usually set tools=false in debian.*/rules.d/armhf so I don't have to cross install other deps for linux-tools Jul 18 13:33:39 but for quick testing I just build zImage Jul 18 13:37:33 yeah Jul 18 13:48:47 hmm, so our kernel doesnt have NVHDCP enabled Jul 18 13:49:08 and there seem to be a few new NVMAP options to play with Jul 18 13:49:52 oh, and we dont have /dev/nvram enabled at all Jul 18 13:56:14 hmm, building definitely doesnt work as advertised Jul 18 13:56:22 (cross building that is) Jul 18 13:57:39 nope, cant make it build Jul 18 13:58:10 aha, only works if CROSS_COMPILE is set Jul 18 13:58:50 janimo, i think there was something added to the linux package scripts to automatically set that in ubuntu kernels when cross building a package ... are we missing a merge ? Jul 18 13:59:47 ogra_, CROSS_COMPILE needs setting in env when doing simple make zImage Jul 18 14:00:00 janimo, it shouldnt for the package Jul 18 14:00:02 also in the debuild line I pasted above Jul 18 14:00:20 yes, but not in hrw's howto Jul 18 14:00:24 not sure if we are missing something, I did not work on other arm kernel packages Jul 18 14:00:48 and i think the kernel team enhanced the scripts to auto xport that var during package builds Jul 18 14:00:59 I know, no idea really I just stuck to what works and what I learned last year here: https://wiki.linaro.org/Resources/HowTo/PackageYourOwnKernel Jul 18 14:01:22 ogra_, they may have done that, in which case I did not know about it to incorporate in our scripts Jul 18 14:01:26 I will if I find out :) Jul 18 14:01:43 there was a ML discussion a while ago during precise Jul 18 14:01:45 I pasted that line to show what I used all the time and what worked for me for ac100 and armadaxp kernels too Jul 18 14:02:12 right, that works here too (despite the fact that i dont like debuild and use dpkg-buildackage) Jul 18 14:04:58 wow, that was fast (failed in tools since i didnt suppress them) Jul 18 14:09:43 wow, i actually got all four cpu cores at 50°C ... havent seen them above 30 since i built that thing Jul 18 14:10:03 ;) Jul 18 14:12:41 curse m4 for lack of ifndef Jul 18 14:27:24 grrr Jul 18 14:27:32 i cant get past the failing tools Jul 18 14:27:55 do_tools=false as documented everywhere doesnt seem to have any effect Jul 18 14:40:19 oh CRAP ! Jul 18 14:40:32 so debian.linaro overrides all defaults ? Jul 18 14:40:37 *SIGH* Jul 18 14:48:33 real 5m49.016s Jul 18 14:48:33 user 13m47.740s Jul 18 14:48:33 sys 1m23.897s Jul 18 14:48:35 nice ! Jul 18 15:26:33 ogra_, did you only use parallel=3? user/real suggests something like that Jul 18 15:26:45 =8 Jul 18 15:27:00 or maybe kernel builds is more deb packaging and linking that parallelizable compilation Jul 18 15:27:05 i thought 4 cores should be able to handle 8 threads :) Jul 18 15:27:41 ogra_, they do, but the last bits - the packaging ones - are likely only using 1 thread Jul 18 15:27:49 indeed Jul 18 15:27:59 probalby with plain make zImage you'd get a much better ratio :) Jul 18 15:28:21 but anyway, nice to have such fast turnaround now Jul 18 15:28:26 oh, definitely, but with 13min for a package build i wont complain :) Jul 18 15:28:41 13 user, real was 5 no? Jul 18 15:29:41 yep Jul 18 21:18:33 ahs3`: *poke* Jul 18 21:19:13 ahs3`: That python-greenlet patch probably shouldn't be using uname to set CFLAGS in setup.py, since that's depending on the buildd environment, rather than the target. Jul 18 21:20:09 ahs3`: (In our case, it'll just get set universally for armel/armhf, since all our machines have that uname, but it still seems sketchy in the case where that's not true) Jul 18 21:20:40 infinity: hrm. is that the part that adds -fomit-frame-pointer? Jul 18 21:20:46 ahs3`: Yeah. Jul 18 21:21:42 ahs3`: I could just as easily be building on an armv5 machine with -mcpu=armv7-a, and that flag then wouldn't get set, though it should be. Jul 18 21:22:02 ahs3`: Seems harmless for the SRU and for our current buildds, but still inappropriate (IMO) for upstreaming. Jul 18 21:22:28 ahs3`: Then again, upstream seems to suffer that issue elsewhere too, so.. Jul 18 21:23:09 infinity: right. latest upstream has already moved well past this version and it's not needed there. but, there are several other ARM patches in 0.3.4 Jul 18 21:23:34 ahs3`: Mmkay. Then it doesn't bug me *as* much. Jul 18 21:23:53 ahs3`: (I note that upstream makes the same mistake with a uname=i386 check, so at least it's consistently broken) Jul 18 21:23:56 infinity: well, and bumping versions for SRU is a no-no, yeah? Jul 18 21:24:10 ahs3`: I assume this omitting of frame pointeryness won't break armel while fixing armhf? Jul 18 21:24:20 infinity: lol. oh, goody, we're consistently broken :) Jul 18 21:24:40 ahs3`: Yeah, bumping upstream versions is a no-no unless absolutely needed. I'm much happier with the backported patch option, as long as it works. Jul 18 21:25:04 infinity: i don't believe this will hurt armel; this only shows up in armhf Jul 18 21:25:14 (the bug, that is) Jul 18 21:26:02 Except, wait... Jul 18 21:26:10 -fomit-frame-pointer is included by default in -O2 anyway. Jul 18 21:26:19 Is there somewhere else where this is being forced to -O0 or something? Jul 18 21:27:29 not that i ever found :(. the only reason that's there is that it was not showing up on the gcc line when building Jul 18 21:27:49 i presumed that was being echoed correctly Jul 18 21:28:14 Right, it's in the default set. Jul 18 21:28:24 You'd need to use -fno-omit-frame-pointer to explicitly ask for the inverse. Jul 18 21:28:29 So, that part of the patch is probably a no-op. Jul 18 21:29:07 probably so; re-running the tests would confirm Jul 18 21:29:21 Anyhow, it's harmless either way, I'm not going to make anyone retest and reupload, if you know this version works. Jul 18 21:29:33 And if upstream no longer has that bit of code, all the better. Jul 18 21:29:44 it does. tested on armadaxp, on precise Jul 18 21:30:12 yup, plus other ARM fixes that would be nice to have, but oh well Jul 18 21:30:48 Well, feel free to backport more fixes. :P Jul 18 21:31:06 Unless the new upstream is really just "nothing but more ARM fixes", then we can talk version bumps. Jul 18 21:31:23 ahs3`: For now, accepting this into proposed. Jul 18 21:31:46 infinity: thx. unfortunately, it's a bunch more than just ARM stuff Jul 18 21:32:15 Well, even if the new upstream is "nothing but bugfixes with no new features", we could perhaps talk about that. Jul 18 21:32:19 But it's not even in quantal yet, so... Jul 18 21:32:29 We'll cross that bridge if anyone feels the urge to later. Jul 18 21:32:38 actually, it's already in quantal Jul 18 21:33:05 Is it? I thought Q was 0.3.3... You were talking 0.3.4 Jul 18 21:33:52 hrm. lemme look. i thought zul had gone to 0.3.4... Jul 18 21:34:20 Nope, and Debian's still at 0.3.3 as well. Jul 18 21:35:06 Bah, and the mips ASM is broken too. Is that fixed in 0.3.4 as well? Jul 18 21:35:12 If so, I might just NMU the new upstream. :P Jul 18 21:35:19 d'oh. yup. 0.3.3. Jul 18 21:35:54 lemme check the changelog. i don't recall seeing mips fixes, but i wasn't looking for them Jul 18 21:37:11 platform/switch_mips_unix.h: In function 'slp_switch': Jul 18 21:37:11 platform/switch_mips_unix.h:43:1: error: $fp cannot be used in asm here Jul 18 21:37:12 error: command 'gcc' failed with exit status 1 Jul 18 21:37:25 It's so lovely when people write assembly blind. Jul 18 21:37:36 (I can only assume it was blind, since it's pretty obviously broken) Jul 18 21:38:42 looks like the last mips change (at least in the switcher code) was in 2010 :( Jul 18 21:38:51 Yeah, I'm seeing that. Jul 18 21:38:56 So, something externally broke it. Jul 18 21:38:58 Oh well. Jul 18 21:39:15 I don't have any mips machines to test on, and I can't see obvious breakage at a glance. Jul 18 21:40:03 Can I just go on the record as saying that python modules with hand-tuned assembly are a bit of a giggle? Jul 18 21:41:29 ahs3`: 3.3 Jul 18 21:41:36 lol. absolutely. it is one of the more amusing bits of code i've seen Jul 18 21:42:17 zul: nod. i got 0.3.4 stuck in my head for some reason Jul 18 21:42:48 Anyhow. I might NMU ARM fixes into Debian, which would bring us in line (except for the dh_python2 switch), but that won't actually help the RCness in Debian, due to the mips breakage. :/ Jul 18 21:43:06 And if ARM is fixed upstream in 0.3.4 anyway, that seems like it might be wasted effort on my part. Jul 18 21:43:50 Erk. Jul 18 21:44:04 ahs3`: Is the testsuite still disabled in precise due to this breakage? Jul 18 21:44:26 ahs3` / zul: I may prefer to see "turning the testsuite back on" as part of the SRU, to prove it's all better. Jul 18 21:44:28 infinity: dunno. i don't think it was ever ENabled Jul 18 21:44:53 ahs3`: It's enabled in Debian, it's disabled in our packages because it was segfaulting on ARM. Jul 18 21:45:31 infinity: ah. then you should be able to enable it again; that's what was used to test the patch Jul 18 22:04:23 ahs3`: Alternately, this package is too much of a mess for me to try to make sense of. :P Jul 18 22:04:39 ahs3`: If someone tests the output of the buildds, I'll just scream LA LA LA and ignore the testsuite still being off. Jul 18 22:05:21 infinity: fair enough. testing we can do. **** ENDING LOGGING AT Thu Jul 19 02:59:58 2012