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