| twb | lilstevie: hey, you around? | 01:14 |
|---|---|---|
| twb | lilstevie: I'm trying to use your menu doodad from OLiFE 1.2, it isn't happy about something | 01:15 |
| twb | nvflash configuration file error: partition/ filesystem_type invalid | 01:15 |
| twb | lilstevie: it gets farther if I pick dualboot, so I think there's a typo in your configs/linux.cfg, investigating now | 01:21 |
| === doko__ is now known as doko | ||
| lilstevie | yeah, there is :p | 02:03 |
| lilstevie | twb: I need to fix it but there is a misplaced c | 02:03 |
| lilstevie | sed -i 's/ext3c/ext3/g' ./configs/* | 02:04 |
| twb | Ah, I saw that and thought it looked suspicious :-) | 02:10 |
| lilstevie | yeah, was a typo, but haven't really gotten around to fixing it because I cbf, I don't want that script to be around for much longer | 02:18 |
| lilstevie | and the more I fiddle around with trying to fix it the less time I have to work on the gui | 02:18 |
| lilstevie | oh btw, interesting thing, someone else came across the same issue you were having with u-boot | 02:19 |
| twb | Hooray | 02:25 |
| twb | Did they fix it? | 02:25 |
| lilstevie | well, | 02:25 |
| lilstevie | no | 02:25 |
| lilstevie | I did | 02:25 |
| lilstevie | they were a little more helpful | 02:25 |
| * twb looks guilty | 02:26 | |
| lilstevie | turns out; not following instructions to the letter doesn't work | 02:26 |
| twb | What did I fuck up? | 02:26 |
| lilstevie | did you apply ARCH=arm on the same command line, or were you doing it from env vars | 02:26 |
| twb | IIRC no because I was compiling on the device itself | 02:26 |
| lilstevie | ok | 02:26 |
| lilstevie | well the guy who also had the problem; if ARCH=arm was not supplied, it produced the same non working image you had | 02:27 |
| twb | I've lost most of that when my netbook exploded yesterday | 02:27 |
| lilstevie | fair enough | 02:27 |
| twb | Interesting and annoying, tho | 02:27 |
| twb | Do you know if he was cross-compiling? | 02:27 |
| lilstevie | yeah | 02:27 |
| twb | k | 02:28 |
| lilstevie | he was, but I supply ARCH=arm when I compile on device | 02:28 |
| twb | Hum | 02:28 |
| lilstevie | cause I use the same script to build | 02:28 |
| lilstevie | and supply the cross compiler in envvars | 02:28 |
| twb | scripts/flash.sh: line 108: return: can only `return' from a function or sourced script | 02:46 |
| twb | FYI you also appear to have done + ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg.cfg --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync | 02:49 |
| lilstevie | I always call the other scripts with source 0.o | 03:03 |
| twb | OK my fault then | 03:07 |
| twb | Also when flashing it gets to "Device needs to be put back into APX mode" but doesn't pause | 03:11 |
| lilstevie | odd | 03:38 |
| lilstevie | it should | 03:38 |
| twb | Why does linux.cfg say USP instead of UBT? | 03:45 |
| twb | nm, UBT is further up | 03:45 |
| twb | When I boot it, it coms up with the eeepad/asus/nvidia logos, and just sits at that screen | 03:47 |
| twb | I am using your olife prime edition, maybe the asus bootloader that ships with that is wrong for the 32G | 03:48 |
| lilstevie | no | 03:50 |
| lilstevie | there is one bootloader | 03:50 |
| twb | OK | 03:52 |
| twb | I asked because now when I do boot+voldn, it gives me only "wipe data" and no second icon, last time IIRC there were two icons and volup switched between them | 03:52 |
| lilstevie | newer versions doesn't | 03:54 |
| lilstevie | don't* | 03:54 |
| twb | ah ok | 03:54 |
| lilstevie | you may need to put the kernel in recovery position and write recovery-boot to msc | 03:55 |
| twb | ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg --create --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --go | 03:56 |
| twb | ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg.cfg --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync && ./bins/nvflash -r --download 8 ./images/ubuntu.img | 03:56 |
| twb | ...those were the commands that ran | 03:56 |
| lilstevie | yeah | 03:57 |
| lilstevie | there has been some wierd condition though with decompressing the initrd | 03:57 |
| lilstevie | in main boot | 03:57 |
| lilstevie | where quite frankly, it dies on its ass and has a kernel panic | 03:58 |
| twb | I don't think that's what's happening to me | 03:58 |
| lilstevie | what is happening to you | 03:58 |
| twb | 14:47 <twb> When I boot it, it coms up with the eeepad/asus/nvidia logos, and just sits at that screen | 03:58 |
| twb | If it was oopsing in the ramdisk I would expect it to say so onscreen | 03:59 |
| lilstevie | yeah it does | 03:59 |
| lilstevie | incomplete write | 03:59 |
| lilstevie | ./bins/nvflash --bct ./images/transformer.bct --setbct --configfile ./configs/linux.cfg --bl ./images/bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync && ./bins/abootimg-$(uname -m) --create ./tmp/linux.img -f ./boot/purelinux.cfg -k ./kernels/2636-zImage -r ./kernels/initrd-2.6.36.img && ./bins/nvflash -r --download 6 ./tmp/linux.img | 04:05 |
| twb | 6 not 8 ? | 04:05 |
| lilstevie | why would you write the kernel over the rootfs :p | 04:05 |
| twb | Well because 8 is what you're doing in olife script | 04:06 |
| lilstevie | yeah but that is writing the rootfs | 04:06 |
| twb | oh right | 04:06 |
| twb | That didn't seem to help | 04:09 |
| lilstevie | what happened | 04:09 |
| lilstevie | same thing, or something else | 04:10 |
| twb | same thing | 04:10 |
| lilstevie | hm | 04:11 |
| lilstevie | do it to 5 and boot recovert | 04:18 |
| lilstevie | recovery* | 04:18 |
| twb | wtf I hit reboot and it just displayed linux for a second | 04:18 |
| twb | So it had booted the kernel but not drawn anything onscreen | 04:18 |
| twb | yeah, it was oopsing | 04:18 |
| lilstevie | ah | 04:19 |
| lilstevie | ^^ | 04:19 |
| twb | somethign about not syncing VFS | 04:20 |
| twb | unable to mount root filesystem | 04:21 |
| twb | if I pick dualboot and ubuntu default, then I get the thing you described where linux starts and oopses onscreen | 04:33 |
| twb | Then if I bounce it again it comes up normally, and resize2fs's and everything | 04:34 |
| lilstevie | hm | 04:34 |
| twb | my guess is config/linux.cfg and boot/purelinux.cfg don't line up somehwere | 04:35 |
| TheMuso | I wonder whether Linux would still boot if some of the fat was trimmed from the initramfs when in the default boot configuration. | 04:35 |
| twb | TheMuso: strictly the ramdisk isn't needed at all | 04:35 |
| TheMuso | twb: I know that. | 04:36 |
| TheMuso | twb: But the initramfs sets up framebuffer stuff, runs jasper bits, etc. | 04:36 |
| twb | haha, it's been in D for >120 seconds, the kernel guard just said | 04:38 |
| twb | "kinteractiveup" has | 04:38 |
| lilstevie | TheMuso: have you written anything up yet for that blueprint | 04:39 |
| twb | TheMuso: if you want to remove plymouth from ramdisk I won't object ;-) | 04:39 |
| twb | lilstevie: during oem, what is the username and password? It used to be oem/oem, but this doesn't appear to be the case here | 04:42 |
| lilstevie | stuffed if I know | 04:42 |
| twb | (I need to know so I can run "ip a" and find out the wifi MAC address, since wifi here pegs PSKs to MACs) | 04:42 |
| twb | hum | 04:42 |
| lilstevie | ubiquity is autorun | 04:42 |
| twb | yeah but ubiquity prompts for a PSK without telling me what the MAC address is, so I can't give it the PSK | 04:43 |
| twb | I just skipped wifi for now | 04:44 |
| lilstevie | well then do wifi once booted :p | 04:44 |
| lilstevie | like post ubiquity | 04:44 |
| twb | I'm used to network installs where you can't :-) | 04:44 |
| TheMuso | lilstevie: Beyond actually adding the blueprint, not yet. Hopefully this weekend. Why whats up? | 04:55 |
| lilstevie | was just wondering :p | 05:04 |
| twb | lilstevie: how do you get keyboard repeat working? | 05:38 |
| twb | lilstevie: ok, excitingly even though I was happily running ubuntu and did ubiquity and rebooted and such, after I switched into prime and back, ubuntu kernel detected the ramdisk was an incomplete write, and then oopsed | 05:57 |
| twb | lilstevie: THAT makes me think that maybe the ramdisk is wider than the partition its on, but it happens to work until you run android which overwrites some of the overlapping blocks. or something. | 05:57 |
| lilstevie | no | 06:04 |
| lilstevie | it is bootloader space | 06:04 |
| lilstevie | it works if kernel is in recovery position but not in main | 06:04 |
| twb | That hurts my brain | 07:23 |
| twb | If I pick the first option (dual boot, prime default), jasper seems to want to resize the root filesystem *every* boot | 07:57 |
| twb | lilstevie: I'm going home now. I'm a hard-code bash-fu weenie, so feel free to ping me if you want someone to wangle those olife scripts | 08:37 |
| === zyga is now known as zyga-afk | ||
| ogra_ | doko, someone in #ac100 just complained that python2.7 segfaults on armhf, is that known ? | 12:37 |
| doko | ogra_, extension or core code? | 12:39 |
| ogra_ | he claims the package cant execute bytecode compilation from its postinst | 12:40 |
| ogra_ | seems core code | 12:40 |
| ogra_ | he said that 1.5h ago, i only saw it now, i pinged him | 12:40 |
| ogra_ | i'm also not sure if he doesnt use a chroot or if thats the hf ac100 image | 12:41 |
| ogra_ | (hf chroots seem to behave weird if /proc is mounted ... ) | 12:42 |
| infinity | Err. | 12:47 |
| infinity | No. | 12:47 |
| infinity | They don't. | 12:47 |
| ogra_ | they did here | 12:47 |
| ogra_ | several times | 12:47 |
| infinity | You mean procps upgrades killing your system? | 12:48 |
| infinity | That's not "hf chroots misbehaving with proc mounted". | 12:48 |
| ogra_ | that too, i had two other incidents where it affectzed the host | 12:48 |
| infinity | Well, any chroot can affect the host through proc. | 12:48 |
| infinity | Not an hf thing. | 12:48 |
| ogra_ | sure, but usually that doesnt mean i need to reboot :) | 12:48 |
| infinity | The procps thing is not hf-specific either, I suspect. | 12:49 |
| infinity | I just haven't cared to look at it. | 12:49 |
| ogra_ | well, i have never seen that on other setups | 12:50 |
| infinity | Anyhow, python not being able to execute its postinst is pretty clearly not true, since it happens on nearly every build on the buildds.. | 12:50 |
| infinity | So, there's something more subtle going on there. | 12:50 |
| ogra_ | for 2.7 ? | 12:50 |
| infinity | 2.7 is our default python. | 12:51 |
| infinity | So, yeah. | 12:51 |
| ogra_ | hmm, intresting | 12:51 |
| infinity | Any package that build-deps on python (which is, well, lots of them), python2.7 gets installed. | 12:51 |
| ogra_ | well, then i guess that guy simply has a broken setup or some such | 12:51 |
| ogra_ | i asked him to file a bug | 12:51 |
| infinity | Or a dying machine. | 12:51 |
| infinity | If he can reproduce the same segv every time, then it's worth looking into. | 12:52 |
| infinity | But still might be something with the ac100 kernel or some such. | 12:52 |
| ogra_ | well, i installed ubiquity b-deps yesterday in my chroot ... that should definitely install 2.7 alongside then | 12:53 |
| ogra_ | and i had no errors | 12:53 |
| ogra_ | its likely that he uses one of the early -core tarballs or some such | 12:53 |
| ogra_ | and didnt upgrade | 12:53 |
| infinity | Should have been fine back then too. | 13:05 |
| infinity | If python had been broken at any point in the bootstrap, I would have known. | 13:05 |
| infinity | Well, broken to that extent. | 13:06 |
| ogra_ | k | 13:06 |
| infinity | I'm sure it's slightly broken somewhere. ;) | 13:06 |
| infinity | All software is. | 13:06 |
| ogra_ | well, we'll see what he says (if he answers or writes the bug) | 13:06 |
| === zyga-afk is now known as zyga | ||
| === zyga is now known as zyga-afk | ||
| === zyga-afk is now known as zygaq | ||
| === zygaq is now known as zyga | ||
| === jrp-afk is now known as shirgall | ||
| MMlosh | How does one use the USB OTG port on ubuntu oneiric? (device mode) | 18:02 |
| jjardon | Hi, I have problems compiling eglibc in my ARM board. This is the error message: http://paste.ubuntu.com/765163/ | 18:05 |
| jjardon | I already set CFLAGS="-fno-stack-protector -U_FORTIFY_SOURCE" Any another idea? | 18:05 |
| infinity | jjardon: I suppose asking why you don't use the packaged version would be a stupid question? | 18:09 |
| infinity | jjardon: (And your CFLAGS pretty clearly aren't making it there) | 18:10 |
| jjardon | infinity: mmm, strange, I export the CFLAGS environment var and I get the same result | 18:13 |
| infinity | I assume they're being reset by the Makefiles. | 18:14 |
| infinity | Still, why are you building eglibc at all? | 18:14 |
| jjardon | infinity: playing with lfs | 18:16 |
| infinity | Ahh, so not really an Ubuntu question. ;) | 18:16 |
| infinity | Anyhow, in the eglibc packages, we work around the upstream Makefiles being draconian about CFLAGS by cheating. | 18:17 |
| infinity | We set CC="gcc-4.6 -fno-stack-protector -U_FORTIFY_SOURCE" CXX="g++-4.6 -fno-stack-protector -U_FORTIFY_SOURCE" | 18:17 |
| jjardon | infinity: no, not really ;) . I was wondering if the ubuntu-linaro compiler was setting any special flag or something | 18:17 |
| infinity | (ie: passing the flags as part of the compiler name instead) | 18:18 |
| jjardon | oo, I'll try that | 18:18 |
| ogra_ | janimo, could you take a look if we could get teh fix for bug 861296 into the ac100 oneiric package ? | 18:19 |
| ubot2 | Launchpad bug 861296 in linux-ti-omap4 "mmap fails to allocate 2030Mb heap on ARM" [Undecided,Fix committed] https://launchpad.net/bugs/861296 | 18:19 |
| shadeslayer | lilstevie: no luck on getting ubuntu to boot on the transformer? :( | 18:21 |
| shadeslayer | ( SBK v2 ) | 18:21 |
| MMlosh | How does one use the pandaboard's USB OTG port on ubuntu oneiric? (device mode) Loading g_ether does not seem to be enough | 18:28 |
| GrueMaster | infinity: Any progress onlibc6 | 18:34 |
| infinity | GrueMaster: The netisnt issue? Haven't had a chance to test yet. | 18:34 |
| GrueMaster | well, last build still failed libc6-udeb | 18:35 |
| GrueMaster | uInitrd was fine though. | 18:35 |
| infinity | Yeah, I know. Getting to it. | 18:35 |
| === dduffey is now known as dduffey_afk | ||
| doko | infinity, did you see my message about happy being unhappy? | 18:44 |
| infinity | doko: Yeahp, it's building. | 18:45 |
| doko | thanks | 18:46 |
| infinity | GrueMaster: Oh, FFS. | 18:52 |
| GrueMaster | ? | 18:52 |
| * infinity looks... | 18:52 | |
| infinity | -rw-r--r-- root/root 93484 2011-12-06 16:45 ./lib/arm-linux-gnueabihf/ld-2.13.so | 18:53 |
| infinity | Lack of executable bits. | 18:54 |
| infinity | I could just back out my path change from eglibc, since I fixed that in d-i anyway... | 18:55 |
| parin1 | i just got a pandaboard what should be the status of LED1 and LED2 when you boot? | 18:59 |
| * infinity tries to sort out how that's happening... | 18:59 | |
| parin1 | i am not getting anything on console neither on display | 18:59 |
| parin1 | SD card booting from ubuntu 11/05 netbook prebuilt image | 18:59 |
| parin1 | 11.04 | 18:59 |
| infinity | parin1: Nothing on serial? Wiggle the card or try another. | 19:00 |
| infinity | parin1: It very unhelpfully does precisely nothing if it doesn't think there's an SD in the slot. | 19:00 |
| parin1 | nope nothing on serial | 19:00 |
| parin1 | i am using eclipse Terminal plugin not the minicom | 19:00 |
| parin1 | whish should not matter i think | 19:01 |
| parin1 | i am trying other card | 19:01 |
| parin1 | but what should be the stutus of LEDs in a normal situation? | 19:01 |
| === dduffey_afk is now known as dduffey | ||
| infinity | I don't recall what they do initially on boot. | 19:05 |
| infinity | Looks like both come on. | 19:05 |
| infinity | If there's no card in, only 2 comes on. | 19:05 |
| parin1 | ok now i insetred the card, plugged the power in and pressed the power on button but still nothing | 19:07 |
| parin1 | LED2 comes on and goes off | 19:08 |
| parin1 | LED1 isnt turning on | 19:08 |
| parin1 | i pressed power button one more time no LED2 is on | 19:09 |
| parin1 | LED1 is off | 19:09 |
| parin1 | but not getting anything | 19:09 |
| parin1 | any idea? | 19:09 |
| infinity | You don't even need to press the power button. Just card then plug is enough. | 19:14 |
| infinity | If LED2 is blinking out like that, I suspect it thinks there's nothing worth looking at on the card. | 19:15 |
| janimo | ogra_, we do not have it yet, I pinged upstream about it too | 19:15 |
| infinity | janimo: Locally patch it into your upcoming 3.x release? :) | 19:15 |
| janimo | I think we only need it for precise though? | 19:15 |
| janimo | infinity, that too if upstream does not put it in their 3.0 tree :) | 19:16 |
| infinity | janimo: I don't think it's dreadfully necessary to backport it for a "community" kernel, but we did do so for all the supported ones. | 19:16 |
| janimo | infinity,I figured it is not that important a bug to have another oneiric upload for it | 19:18 |
| infinity | janimo: No, but maybe queue it up if there are other things that need SRUing. | 19:18 |
| infinity | janimo: But, really, I supect you're not even doing security support on that kernel, so... | 19:18 |
| janimo | I not so secretly hope we no longer upload SRU for ac100 kernel, unless critical security issues | 19:19 |
| janimo | it works ok so far and people are not complainig | 19:19 |
| janimo | the thing which do not work are minor (headphone mic etc) but those are not working upstream either yet | 19:19 |
| janimo | the last SRU did not get even one tester even though there was a call or two asking for it, so I think people are ok with what they have and not falling over to get new hotness | 19:20 |
| infinity | I don't much care, as long as things kinda work. | 19:21 |
| infinity | Security support would be nice, but I also plan to replace oneiric on my ac100 with precise really soon now. | 19:21 |
| infinity | So... Will I get security support from you on precise? ;) | 19:22 |
| janimo | infinity, heh, let me think before I decide if this is a trap question or not ok? | 19:24 |
| infinity | (It is) | 19:24 |
| janimo | if we get the port in good shape to be more than a community thing, we should probably have SRUs for it | 19:24 |
| infinity | "More than a community thing" meaning? | 19:24 |
| infinity | It'll never be more than a community thing. :P | 19:25 |
| janimo | although since this is a space of arm/netbook tablets where the ac100 will look stone age in 2 years I am not sure people will care about updates for too long | 19:25 |
| infinity | Canonical's not gong to put any official support behind a subarch aimed at hardware that isn't available. | 19:25 |
| infinity | Although. | 19:25 |
| janimo | well, more than it is now, a bit more poliesh and with more users, in that regard | 19:25 |
| infinity | lilstevie and I were saying the other day that changing the ac100 subarch to a tegra subarch might not be an awful idea, if we can make the same kernel boot on a few devices. | 19:26 |
| janimo | that would indeed make a lot of sense | 19:26 |
| infinity | (Might be limited to tegra2, which still makes it DOA, but just maybe a unified tegra2/3 thing is possible?) | 19:26 |
| janimo | the 'One ARM kernel to boot them all' is still far away I guess. Not sure what subarchs linaro is targetting with that (if still the plan indeed) | 19:27 |
| infinity | Well, it relies on two things. | 19:27 |
| infinity | The first being Devicetree/ACPI on all target devices. | 19:27 |
| janimo | no idea how the tegra3 differs from t2 for such a kernel to be possible. Would be nice of course | 19:27 |
| infinity | The second being no more driver conflicts between all the source trees. :P | 19:27 |
| infinity | (ie: so you can have one source tree) | 19:27 |
| infinity | Given nvidia's engineering practices with GPUs, I'd be shocked if tegra3 couldn't boot on tegra2 kernels. | 19:28 |
| infinity | But then again, it's probably a whole different set of engineers. | 19:28 |
| infinity | (I still love that the same drivers work from Riva TNT all the way to GeForce FancyPants 2011) | 19:28 |
| infinity | Well, except for bitrot. | 19:29 |
| janimo | infinity, same drivers? I thought there were about 3 deb packages for different eras of NV chipsets? But as usual I may misremember | 19:29 |
| infinity | janimo: There are, but that's only because they drop "official" support for old GPUs every once in a while so they don't have to keep testing and tweaking for dead hardware they don't care about. | 19:31 |
| infinity | janimo: The oldest driver will still init the newest card (if you jam in the PCI IDs), just won't know all the extensions, and the newest driver will still drive the oldest card, it just might be buggy due to bitrot and lack of testing/caring. | 19:31 |
| janimo | I'd like to think the lack of love for L4T is because they work on tegra3 support and will release together, and not just because they couldn't care less for linux | 19:32 |
| janimo | infinity, that is impressive if so, had no idea | 19:32 |
| janimo | but I do not want to image how that code must look like | 19:33 |
| janimo | imagine | 19:33 |
| infinity | The code's reasonable, except for the TNT compat (which they did actually drop completely at one point). | 19:33 |
| MMlosh | ogra_, I am not sure if you're the right one to ask.. who might know how to use the pandaboard as a usb device? loading g_ether is not enough. and I apologize again for the highlight.. | 19:33 |
| infinity | So, I suppose I should say GeForce GTS -> GeForce now (but that's still 11 years of GPUs?) | 19:33 |
| infinity | janimo: When they come up with shiny new ways to do old things, they often toss in a bit of a translation layer in microcode instead of in the drivers. One of the things that happens when they drop support for old GPUs is dropping support for those translation interfaces and writing to the newer instructions. | 19:35 |
| infinity | janimo: But, like I said, the core ISA never changes much. Think of it like x86-for-graphics (which actually isn't far off, sadly). | 19:35 |
| infinity | janimo: Stupidly complex, very extensible, and remarkably backward-compatible. | 19:35 |
| janimo | hmm, they do not change the core ISA even with such changes in hw? impressive too | 19:35 |
| infinity | janimo: They took a very Intel approach to the whole thing. Think of the Riva128 and RivaTNT as the 8088 and 80286 (ish). The GeForce was their "80386", and much like Intel, they decided that was good enough, and just kept extending the ISA after that instead of breaking it. | 19:41 |
| === dduffey is now known as dduffey_test | ||
| infinity | janimo: Which was pretty different from how most other video chip vendors were doing things at the time. And probably led to their rapid iterations and World Domination(tm) in the space for a while until ATI caught on and started doing similar things. | 19:42 |
| infinity | GrueMaster: Found and fixing your bug. Needs yet another eglibc upload. FML. | 19:46 |
| GrueMaster | Figrues. Thanks. Let me know when it goes through. | 19:47 |
| GrueMaster | I thought it might have something to do with the udeb change you had made earlier. | 19:48 |
| infinity | Sort of, yeah. All passes do a find | chmod +x run to make sure ld.so is excutable. | 19:49 |
| infinity | For the normal passes, that find was fixed to scan subdirectories. For udebs, no one made that change. | 19:49 |
| infinity | So, no +x on ld.so. | 19:49 |
| infinity | GrueMaster: Fixing a couple of other eglibc bugs while I'm in there. And it takes forever to build anyway, so you wouldn't have it by EOD even if I uploaded now. But you should have working netinst by Monday. | 19:58 |
| GrueMaster | Ok. Cool. | 19:58 |
| mksh | hi, can someone who has precise/arm{el,hf} run a test for me? | 20:44 |
| mksh | i've read the mksh build logs and am not fully sure about the regression testsuite results | 20:45 |
| mksh | (or just gimme a shell) | 20:45 |
| mksh | or if there’s something like debian’s porterboxen, tell me where ☺ | 20:49 |
| === mksh is now known as lynx | ||
| infinity | lynx: The test suite seemed to have run fine...? | 21:46 |
| infinity | lynx: Anyhow, I can help a bit later today. I'm in the middle of fixing my clutch right now. :P | 21:47 |
| lynx | it actually did not run at all, for mksh-static | 22:00 |
| lynx | thanks, if I'm still around later tell me | 22:01 |
| lilstevie | janimo: Tegra2 and Tegra3 are very similar at a core level, just the Tegra3 has 4 of them, | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!