| infinity | cvanvliet_: Using them from where? | 00:23 |
|---|---|---|
| === unknown|2 is now known as yangster | ||
| === gildean_ is now known as gildean | ||
| === rsalveti` is now known as rsalveti | ||
| === cvanvliet_ is now known as cvanvliet | ||
| cvanvliet | infinity, http://elinux.org/BeagleBoardUbuntu#SGX_armel.2Farmhf_v3.4.x.2B | 06:38 |
| LetoThe2nd | hm. tried the omap4 netboot installer, but board does not boot afterwards. 12.10's boot.img-serial.gz should be right? | 06:39 |
| LetoThe2nd | or rather boot.img-fat-serial? | 06:40 |
| 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:44 |
| 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:45 |
| 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? | 06:47 |
| cvanvliet | infinity, I have asked in #beagle as well, I will let you know if I get any follow up, (afk) | 07:04 |
| LetoThe2nd | hm, netinstall with precise also did not result in a bootable sd card. :( | 07:55 |
| 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 | 08:59 |
| 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:00 |
| 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:01 |
| 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:02 |
| LetoThe2nd | ogra_: something like creating a 60M fat16 partition on the blockdevice and then zcatting to that? | 09:03 |
| ogra_ | right | 09:03 |
| LetoThe2nd | will do. report back in some minutes | 09:04 |
| ogra_ | thx | 09:04 |
| LetoThe2nd | using the automagic partitioning afterwards is ok? | 09:05 |
| ogra_ | yes | 09:05 |
| 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:06 |
| 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:07 |
| 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:08 |
| LetoThe2nd | np, will be ready after lunch i guess. | 09:09 |
| === zyga is now known as zyga-afk | ||
| === zyga-afk is now known as zyga | ||
| LetoThe2nd | ogra_: back with the sd card :) | 11:05 |
| ogra_ | so what does it show ? | 11:05 |
| 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:06 |
| LetoThe2nd | http://paste.ubuntu.com/1098130/ | 11:07 |
| 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:08 |
| ogra_ | oh, wait, you installed *to* the SD ? | 11:09 |
| 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:10 |
| ogra_ | hmm | 11:11 |
| ogra_ | i assume /dev/sdd1 contains /boot ? | 11:11 |
| LetoThe2nd | ogra_: i guess so, its what installer automagic created. | 11:12 |
| ogra_ | right | 11:12 |
| 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:13 |
| 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:14 |
| 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:15 | |
| TheMuso | ogra_: What was the reason for changing the panda images from preinstalled to live? | 11:17 |
| 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:18 |
| * TheMuso nods. | 11:19 | |
| ogra_ | which reminds me ... | 11:19 |
| * 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| janimo | ogra_, \o/ for the final tegra graphics drivers! | 11:34 |
| ogra_ | well, lets see if they work :) | 11:34 |
| 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:35 |
| janimo | I'll do a new rebase or cherry-picking for the changes you have added since sometimes soon | 11:36 |
| 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) | 11:37 |
| LetoThe2nd | ogra_: nope, does not help | 12:04 |
| ogra_ | ok | 12:04 |
| 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:05 |
| 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:06 |
| 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:07 |
| ogra_ | janimo, now it prints a message: "rcu_sched_state detected stall on CPU 1 (t=6000 jiffies)" | 12:08 |
| ogra_ | janimo, hmm second try works (still the same issue with lightdm constantly respawning though) | 12:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| ogra_ | *console | 12:15 |
| * ogra_ purges the nvidia driver | 12:16 | |
| 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:19 |
| 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:20 |
| ogra_ | Xorg.0.log only has a segfault, no further errors | 12:21 |
| ogra_ | janimo, for whatever reason my syslog is full of "fuse.ko: Invalig Argument" | 12:32 |
| ogra_ | *invalid | 12:32 |
| ogra_ | oh, i just noticed the new driver ships new udev rules and an upstart init script | 12:50 |
| ogra_ | SHRIEK !!!!!!!!!!!!!!!!!!!!!!!1111 | 12:50 |
| ogra_ | first command in that initscript is: chmod 0666 /sys/power/state | 12:51 |
| ogra_ | oh, intresting ... all hardcoded sysfs paths in there have tegra3 in their pathname | 12:52 |
| ogra_ | seems even though it is a ventana package it expects tegra3 devices | 12:54 |
| ogra_ | janimo, hmm something is definitely weird with the fuse module | 13:03 |
| ogra_ | it complains that fuse is loaded already if gvfs tries to load it on desktop startup ... but lsmod disagrees | 13:04 |
| 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:10 |
| 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:11 |
| 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:12 |
| 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:13 |
| 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:14 |
| 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 | 13:15 |
| marvin24 | <ogra_> "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:15 |
| 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:16 |
| 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:17 |
| 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:18 |
| * marvin24 didn't tried the new driver yet | 13:20 | |
| marvin24 | I only heard of troubles so far ... | 13:20 |
| ogra_ | so lets see how well hrw did his job ... | 13:23 |
| * ogra_ installs gcc-arm-linux-gnueabihf for the first time evar | 13:23 | |
| 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:25 |
| 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:29 |
| ogra_ | thats enough for me :) | 13:30 |
| janimo | ogra_, you mean to build full debs not just zImages? | 13:30 |
| 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:31 |
| janimo | you can make the parallel much more I guess | 13:32 |
| 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:33 |
| ogra_ | yeah | 13:37 |
| ogra_ | hmm, so our kernel doesnt have NVHDCP enabled | 13:48 |
| 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:49 |
| ogra_ | hmm, building definitely doesnt work as advertised | 13:56 |
| ogra_ | (cross building that is) | 13:56 |
| ogra_ | nope, cant make it build | 13:57 |
| 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:58 |
| janimo | ogra_, CROSS_COMPILE needs setting in env when doing simple make zImage | 13:59 |
| 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:00 |
| 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:01 |
| ogra_ | right, that works here too (despite the fact that i dont like debuild and use dpkg-buildackage) | 14:02 |
| ogra_ | wow, that was fast (failed in tools since i didnt suppress them) | 14:04 |
| ogra_ | wow, i actually got all four cpu cores at 50°C ... havent seen them above 30 since i built that thing | 14:09 |
| hrw | ;) | 14:10 |
| hrw | curse m4 for lack of ifndef | 14:12 |
| 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:27 |
| ogra_ | oh CRAP ! | 14:40 |
| ogra_ | so debian.linaro overrides all defaults ? | 14:40 |
| ogra_ | *SIGH* | 14:40 |
| ogra_ | real5m49.016s | 14:48 |
| ogra_ | user13m47.740s | 14:48 |
| ogra_ | sys1m23.897s | 14:48 |
| ogra_ | nice ! | 14:48 |
| janimo | ogra_, did you only use parallel=3? user/real suggests something like that | 15:26 |
| ogra_ | =8 | 15:26 |
| 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:27 |
| 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:28 |
| ogra_ | yep | 15:29 |
| === Ursinha` is now known as Ursinha | ||
| === npitre_ is now known as npitre | ||
| === gildean_ is now known as gildean | ||
| infinity | ahs3`: *poke* | 21:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| ahs3` | infinity: i don't believe this will hurt armel; this only shows up in armhf | 21:25 |
| ahs3` | (the bug, that is) | 21:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| 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:32 |
| 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:33 |
| infinity | Nope, and Debian's still at 0.3.3 as well. | 21:34 |
| 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:35 |
| 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:37 |
| 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:38 |
| infinity | I don't have any mips machines to test on, and I can't see obvious breakage at a glance. | 21:39 |
| infinity | Can I just go on the record as saying that python modules with hand-tuned assembly are a bit of a giggle? | 21:40 |
| zul | ahs3`: 3.3 | 21:41 |
| ahs3` | lol. absolutely. it is one of the more amusing bits of code i've seen | 21:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| ahs3` | infinity: ah. then you should be able to enable it again; that's what was used to test the patch | 21:45 |
| 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:04 |
| ahs3` | infinity: fair enough. testing we can do. | 22:05 |
| === TheMuso` is now known as TheMuso | ||
| === wgrant_ is now known as wgrant | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!