| twb | lilstevie: OK wifi problem solved -- I mis-transcribed the *MAC* address into the AP | 00:01 |
|---|---|---|
| twb | Problem was obvious when running hostapd by hand: wlan0: STA 74:2f:68:23:46:8d WPA: no PSK configured for the STA | 00:01 |
| twb | Sorry to trouble you with my fat fingers | 00:01 |
| TheMuso | twb: Good to hear you got it solved. | 00:03 |
| === Ursinha is now known as Ursinha-lunch | ||
| === Ursinha-lunch is now known as Ursinha | ||
| twb | OK, so apparently to set the keyboard rate, you run something like "kbdrate -d 500 -r 5". | 00:16 |
| twb | I run that as root on tty1, and it says "set rate to 0, delay to 0. Was rate 0, delay 0" | 00:17 |
| twb | Grr! | 00:17 |
| twb | Is it supposed to fail to set CPU frequency | 00:28 |
| twb | lilstevie: /etc/fstab ends up with two / mount entries in it; UUIDs corresponding to p8 and p2; the latter is all but empty; I think it's wrong. | 00:42 |
| twb | lilstevie: uboot-mkimage is a stub and doesn't need to be installed. | 00:43 |
| twb | Likewise uboot-envtools | 00:45 |
| TheMuso | twb: Yeah they are transitional packages I guess. | 00:53 |
| twb | Right | 01:00 |
| twb | Wow, modern ubuntu has a huge hard-on for dpkg triggers, huh. | 01:03 |
| GrueMaster | twb: Sometimes it makes sense, like with the kernels. much easier to apt-get install linux-omap4 than linux-image-2.6.35-903-omap4 for example. Also, the meta will always require the latest version of the main package, so easier to check updates. | 01:07 |
| twb | GrueMaster: it's not a metapackage, it's a transitional package. There are no rdeps installed. This suggests that lilstevie asked for it by the old name, and could profitably update his script to ask for the new name. | 01:10 |
| lilstevie | twb: huh | 01:21 |
| lilstevie | I did not install uboot-mkimage or uboot-envtools | 01:21 |
| lilstevie | they are probably reminants left over from the fact that it is the omap base image | 01:22 |
| twb | lilstevie: ah, that makes sense | 01:22 |
| * twb is having fun ripping out all the useless GUI packages | 01:23 | |
| twb | lilstevie: btw any idea what to do about the keyboard repeat rate? | 01:24 |
| lilstevie | no idea | 01:24 |
| twb | bugger | 01:24 |
| lilstevie | my keyboard repeat is fine in GUI userland, but non existant in ttys | 01:24 |
| twb | Yeah, that's what <guy next to me> reported as well | 01:25 |
| twb | I wonder what X is doing differently | 01:25 |
| twb | lilstevie: does ubuntu on tf101 still have a problem where it doesn't shut down all the way? | 03:56 |
| twb | I think that's why I was having that problem where I couldn't do Power+VolDn, because that seems to only work if I power off / reboot from android -- if I power off / reboot from ubuntu, it won't let me, which I think is because it wasn't "off" as far as the bootloader is concerned | 03:57 |
| twb | Ignore that, I managed to do it after shutting down from ubuntu | 04:25 |
| twb | lilstevie: might be my fault, but it looks like I have /lib/firmware/BCM4329.hcd but it's looking for /lib/firmware/bcm4329.hcd | 04:43 |
| twb | lilstevie: can I flash a new kernel+ramdisk into the SOS partition, from within ubuntu? | 05:03 |
| twb | lilstevie: using the olife-prime default setup (dual boot, ubuntu default). | 05:04 |
| twb | lilstevie: AFAICT the answer is no, because the LNX/SOS partitions are outside the mmcblk "visible" area of the partition table | 05:05 |
| TheMuso | twb: Yes you should be able to, but you will need to build it into a blob. | 05:05 |
| twb | TheMuso: yeah I understand the abootimg part | 05:05 |
| twb | Oh, it might be partitions 5 and 6, file -s doesn't recognize those! | 05:05 |
| twb | abootimg -i /dev/mmcblk0p5 isn't encouraging, it says it's not an android boot image | 05:07 |
| TheMuso | twb: I don't think you can access the SOS and LNX partitions from within android/Ubuntu. Once you dd them to mmcblk0p4, they then get flashed elsewhere, outside of what Android/Ubuntu can physically access on the MMC> | 05:18 |
| TheMuso | They get flashed by the Asus bootloader. | 05:18 |
| twb | Oh | 05:18 |
| twb | Because in the uboot world you just make those parts of the emmc directly visible and dd straight to them | 05:19 |
| TheMuso | Yes, in teh case of Ubuntu and uBoot on the tf101, there is a uBoot aprtition where you copy your kernel, initramfs, and boot.cmd/boot.scr files. | 05:19 |
| twb | So what you're saying is that I should use abootimg to create a blob, then copy that as a file onto the /dev/mmcblk0p4 ext partition? | 05:20 |
| TheMuso | twb: So if you want to flash a new image for the SOS partition, you need to use abootimg to pack it, then you need to use Blobtools to pack that image into a blob. | 05:20 |
| twb | OH | 05:20 |
| twb | What a pain in the arse | 05:20 |
| TheMuso | Yup, thank Asus and their bootloader. :) | 05:20 |
| twb | You'd think it'd be easy to just move GP1 further up so that LNX and SOS can be dd'd directly | 05:21 |
| twb | There is probably some stupid reason why you can't | 05:21 |
| TheMuso | Yeah, and I'm sure lilstevie has a better idea why, I happen to agree with you though. | 05:21 |
| TheMuso | But it could be Asus being nasty. :) | 05:22 |
| twb | Can you just back the SOS abootimg into the blob, or do you need to blow away prime and the LNX partition as well? | 05:23 |
| twb | Bsaically I'm slightly annoyed because it's trying to resize my filesystem EVERY boot, and every two minutes it pesters me about kinteractiveup hanging, and the "simple" solution is just to update the ramdisk to the current version that's in the root filesystem -- the one built post-oem | 05:23 |
| TheMuso | No, you can pack a blob with SOS in it on its own, or you could pack a blob with SOS, APP, UDA, and LNX if you wanted to. | 05:23 |
| twb | Cool | 05:24 |
| TheMuso | The ASUS blobs have SOS, LNX, and APP in them. | 05:24 |
| twb | And then I drop it in the mmcblk0p4 partition as a file called ./blob ? | 05:24 |
| TheMuso | It doesn't matter what the file is called. Just dd if=blobfilename of=/dev/mmcblk0p4 | 05:25 |
| TheMuso | And on next reboot, the ASUS bootloader will flash it for you. | 05:25 |
| twb | Ah, overwrite the block device entirely | 05:25 |
| twb | I was led astray because mmcblk0p4 currently have an empty ext filesystem on it | 05:25 |
| TheMuso | Yes, thats right, which I also find weird, but yeah you just dd the blob file onto mmcblk0p4 | 05:26 |
| twb | OK, no worries | 05:26 |
| twb | Grr, unmetered local mirror only has 10.10 (ftp://mirror.internode.on.net/pub/ubuntu-ports/) | 05:32 |
| TheMuso | Thats a bummer. I know aarnet also mirrors ubuntu-ports, but thats probably not unmetred for node customers. | 05:34 |
| twb | probably faster than ports.u.c tho | 05:34 |
| lilstevie | TheMuso: twb no not boot img blob | 05:34 |
| lilstevie | :p | 05:34 |
| * TheMuso used to be on internode till the alure of cable, combined with Telstra having deacent plans lured me away. | 05:34 | |
| lilstevie | and that isn't an asus feature, it is an nvidia thing | 05:35 |
| twb | Well SOMEONE is to blame :P | 05:36 |
| TheMuso | Ah makes sense. | 05:36 |
| lilstevie | the reason it is outside the GP1 is because asus don't want you to have access to it :) | 05:36 |
| lilstevie | moving it isn | 05:36 |
| lilstevie | moving the gp1 is a bit of a pita | 05:36 |
| twb | Makes using abootimg -u a PITA | 05:37 |
| lilstevie | you need to move the actual partitions to the end of flash, which I will be reintroducing with 1.3 | 05:37 |
| lilstevie | I need to set up some stuff for android first though | 05:37 |
| lilstevie | because asus blobs include the tegraparts partition table | 05:37 |
| lilstevie | which will in effect break the whole system | 05:37 |
| TheMuso | Ah. | 05:38 |
| twb | Well unless that includes OTA stuff, who cares | 05:38 |
| TheMuso | lilstevie: BTW have you been able to work out how to get your 2.6.38 kernel to read the stock partition table? | 05:38 |
| twb | Just tell the users not to dl stock asus updates | 05:38 |
| lilstevie | twb: that IS OTA stuff | 05:38 |
| twb | Ah, fuck, OK | 05:38 |
| lilstevie | TheMuso: no :/ | 05:38 |
| TheMuso | Ok, good to know it wasn't just me running round in circles trying to get it to work. :) | 05:39 |
| lilstevie | TheMuso: I am trying to figure out WTF is wrong | 05:39 |
| lilstevie | but the GPT driver in that sense is identical | 05:40 |
| TheMuso | RIght. | 05:40 |
| lilstevie | it is just being a slippery whore | 05:40 |
| lilstevie | but with what I am working on at the moment that may not be an issue anymore | 05:40 |
| lilstevie | well, I mean I still want to go up | 05:40 |
| lilstevie | but less of an issue | 05:40 |
| lilstevie | nvidia released the L4T beta1 drivers | 05:40 |
| lilstevie | and they use 2.6.36 | 05:40 |
| TheMuso | Yeah I saw that. | 05:40 |
| lilstevie | just the interface is different | 05:41 |
| lilstevie | so i am porting the nvhost interface | 05:41 |
| TheMuso | Right. | 05:41 |
| lilstevie | into our tree | 05:41 |
| TheMuso | Nice. | 05:41 |
| lilstevie | which will relieve that stress for a little while | 05:41 |
| lilstevie | so I can work on a more stable u-boot/new kernel | 05:41 |
| TheMuso | Right. | 05:41 |
| lilstevie | cause as it stands u-boot is not configuring the clocks correctly | 05:41 |
| TheMuso | In other news, my trimslice shipped over night. :) | 05:41 |
| TheMuso | Ah ok. | 05:42 |
| lilstevie | and as such asus kernels won't run on it | 05:42 |
| TheMuso | Yup. | 05:42 |
| lilstevie | even with a machine_start block using the boardid | 05:42 |
| lilstevie | cause asus bootloader/uboot have different boardids | 05:42 |
| TheMuso | Yeah I saw that. | 05:42 |
| lilstevie | asus shows ventana | 05:43 |
| lilstevie | uboot shows tf101 | 05:43 |
| lilstevie | :) | 05:43 |
| TheMuso | lilstevie: Does the NVHost stuff include the interfaces needed for their drivers? | 05:44 |
| lilstevie | the nvhost stuff is the interface | 05:44 |
| TheMuso | right | 05:44 |
| lilstevie | good news for ics tablets though | 05:45 |
| lilstevie | as the L4T and android binary interface is now unified | 05:45 |
| lilstevie | also | 05:46 |
| lilstevie | expect your trimslice monday | 05:46 |
| TheMuso | Yeah thought it would be about a week. | 05:46 |
| lilstevie | well by monday I should say | 05:46 |
| lilstevie | mine took 4 days from shipped | 05:46 |
| TheMuso | Nice. | 05:46 |
| lilstevie | yeah, thats why shipping is so expensive I guess :p | 05:46 |
| TheMuso | What git tree has the latest l4t nvhost code? | 05:47 |
| lilstevie | nv-tegra mainline | 05:47 |
| * infinity almost bought a Trimslice, but figures his desk has enough random ARM devices littering it. | 05:47 | |
| TheMuso | ah ok | 05:47 |
| lilstevie | I've cloned it, but didn't get time to look at the interface properly yet, another proj is taking up a little bit more of my time :) | 05:47 |
| lilstevie | infinity: did you see what I said the other day | 05:48 |
| infinity | lilstevie: About unified tegra kernels madness? | 05:48 |
| lilstevie | yeah | 05:48 |
| infinity | Yeah, I read it at the time, and promptly forgot whatever it was because I've been sick all weekend. ;) | 05:48 |
| lilstevie | with a little bit of modularization and a bit of heuristic madness we could probably get it working | 05:49 |
| lilstevie | arch have a "tegra" kernel | 05:49 |
| twb | infinity: want me to send you some vegemite or something? | 05:49 |
| infinity | twb: *glare* | 05:49 |
| lilstevie | that is built for all board-* in mach-tegra | 05:49 |
| twb | It's good for you! | 05:49 |
| twb | You think: shit, I'd better get up, or they'll give me another slice of vegemite toast | 05:50 |
| infinity | lilstevie: ac100/tf101/tf202/trimslice would be a lovely set of things to support with a single kernel. | 05:50 |
| lilstevie | infinity: yeah | 05:50 |
| infinity | lilstevie: Though we'd still have boot-loader/boot-method messes to contend with. | 05:50 |
| lilstevie | infinity: I mean it would be a little bit of work | 05:50 |
| lilstevie | and yeah bootloader wise you have like you do now with the flash-kernel config | 05:50 |
| infinity | lilstevie: Little bit of work, perhaps, but ultimately less work than supporting 4 kernel trees for 4 devices. | 05:50 |
| lilstevie | yeah | 05:51 |
| lilstevie | I mean the tf101 is going to be a bit of pain | 05:51 |
| twb | lilstevie: the tf202 is better? | 05:51 |
| lilstevie | things liek the EC driver are tied in with the battery | 05:51 |
| lilstevie | twb: tf201 is going to be a c*** | 05:51 |
| infinity | And I suppose we really should get Trimslice support into universe at some point. The part where they actually ship with Ubuntu kinda makes it look bad if we don't support it out of the archive. | 05:51 |
| twb | hahaha | 05:51 |
| lilstevie | T3 with its new security | 05:51 |
| lilstevie | and the fact that nvblobs are now signed | 05:51 |
| infinity | Has anyone talked to them about working with us to get their bits in our archive? | 05:51 |
| lilstevie | even with local root, no kernel changes | 05:52 |
| TheMuso | infinity: DOn't think so... I looked at how they installed Ubuntu the other day... I shuddered. | 05:52 |
| lilstevie | infinity: yeah, but their ubuntu installer is CRAP | 05:52 |
| infinity | TheMuso: Yeah, I haven't looked at their custom installer. Can't be drastically worse than some weird stuff we do, can it? | 05:52 |
| lilstevie | I actually hope that beta L4T drivers work with ubiquity and the hdmi | 05:52 |
| lilstevie | infinity: OEM-CONFIG is a hell of a lot more sane | 05:52 |
| TheMuso | infinity: Shell scripts + a partimage image, and zenity to prompt the user. | 05:53 |
| lilstevie | infinity: they pretty much dd the image in place | 05:53 |
| infinity | TheMuso: Oh dear. | 05:53 |
| lilstevie | and set it up with the user trim and password 111111 | 05:53 |
| lilstevie | FROM THE INSTALLER | 05:53 |
| lilstevie | like what | 05:53 |
| lilstevie | you could at least configure a damn user | 05:53 |
| infinity | TheMuso: I'd like to think that if our community stepped up and offered to re-roll their bits as a proper Ubuntu image, they'd be happy to stop maintaining their own. | 05:53 |
| twb | That's because they're doing it for a job rather than because they care | 05:53 |
| lilstevie | infinity: I want to | 05:53 |
| TheMuso | I'd think so too. | 05:54 |
| infinity | TheMuso: And with the joy of packagesets, they could maintain their own kernel and uBoot and such in universe. | 05:54 |
| TheMuso | And yes I want to help too. | 05:54 |
| lilstevie | I really want to manage the timslice in a more sane way | 05:54 |
| lilstevie | it would certainly help anyway | 05:54 |
| twb | And "they" is probably just one guy anyway | 05:54 |
| twb | And he's an intern | 05:54 |
| TheMuso | lilstevie: Hell yeah it would certainly help | 05:54 |
| lilstevie | my trim was a donation from someone because my method of installing on the tf101 is more sane :p | 05:54 |
| infinity | Is it more or less sane than the whacky way we do ac100? | 05:55 |
| infinity | (your tf101 installer, that is) | 05:55 |
| infinity | The Trimslice thing just sounds vile. | 05:55 |
| lilstevie | I even got the trim working with nvflash but compulabs are stonewalling me when it comes to getting the trim | 05:55 |
| lilstevie | infinity: more and less | 05:55 |
| TheMuso | lilstevie: Getting the trim as in obtaining one? | 05:55 |
| lilstevie | more because it uses the prebuilt image setup like omap | 05:55 |
| infinity | But, actually, the "tarball installer" method we use for ac100 would take one or two tweaks and work great on the Trim. | 05:56 |
| TheMuso | But the tarball installer doesn't make sense for the trim. | 05:56 |
| infinity | Since their own installer basically just blats an FS to one of two target devices. | 05:56 |
| TheMuso | Particularly the SATA models. | 05:56 |
| twb | lilstevie: if you really wanted you could abuse live-build to generate new images from scratch, but it's icky | 05:56 |
| lilstevie | TheMuso: the information I need for it | 05:56 |
| infinity | TheMuso: Makes perfect sense for SATA. That's what it was written for. To install from SD to internal storage. | 05:56 |
| TheMuso | Sure you could do it that way, but it would be perfectly possible to use ubiquity. | 05:56 |
| lilstevie | twb: actually TheMuso and I were looking at generating prebuilts | 05:56 |
| infinity | TheMuso: It does use ubiquity (in the form of oem-config). | 05:56 |
| lilstevie | once the kernel is properly packaged | 05:57 |
| lilstevie | infinity: trimslice does not | 05:57 |
| TheMuso | infinity: I'm aware of that, but I am thinking of things like partitioning a SATA hard drive etc. | 05:57 |
| infinity | TheMuso: The reason we don't use ubiquity (in the form of a live system) is because it's effin' slow. | 05:57 |
| twb | live-build is nicer image builder than anything else I've looked at | 05:57 |
| lilstevie | trim never uses ubiquity | 05:57 |
| infinity | lilstevie: No, I realise that. | 05:57 |
| lilstevie | TheMuso: was that method we spoke about with live-build | 05:57 |
| TheMuso | lilstevie: Yes. | 05:57 |
| lilstevie | infinity: I mean like the trim is a terrible install setup | 05:58 |
| lilstevie | even archlinux with its horrid install is a little more comfortable | 05:58 |
| TheMuso | As to what infinity said, if we had community people helpign to maintain a trim image, extending livecd-rootfs/live-build for the trim would be feesable, even if a community member built images. | 05:58 |
| infinity | Extending livecd-rootfs to add a subarch is about 20 seconds of effort. | 05:59 |
| TheMuso | Yup. | 05:59 |
| infinity | And I'm including the time it takes me to type my GPG passhprase 4 times because I suck. | 05:59 |
| TheMuso | lol | 05:59 |
| lilstevie | I wouldn't mind something like a universal image for arm devices :p | 06:00 |
| infinity | lilstevie: Ask again in ~5 years. | 06:00 |
| lilstevie | gaga | 06:00 |
| lilstevie | haha* | 06:00 |
| lilstevie | infinity: just out of curiousity.... why | 06:00 |
| TheMuso | The kernel... | 06:00 |
| lilstevie | I use the same rootfs image on the SGT7" as I do on the tf | 06:00 |
| infinity | lilstevie: No unified boot loaders, and no unified kernels. | 06:00 |
| TheMuso | yeah and the bootloader. | 06:00 |
| infinity | We have the same userspace on everything, that's a non-issue. | 06:01 |
| lilstevie | given how different devices handle the kern and bootloader part, flash-kernel is the only thing that needs to deal with that | 06:01 |
| twb | lilstevie: haha, I looked at "SGT" as "StG" and was thinking "a seven inch assault rifle?" | 06:01 |
| lilstevie | thats the part I mean | 06:01 |
| lilstevie | like the userspace part | 06:01 |
| infinity | But bootloaders and kernels are a mess, and until ACPI and/or DeviceTree is everywhere, we're screwed. | 06:01 |
| lilstevie | heh | 06:01 |
| twb | øw3m | 06:02 |
| TheMuso | lilstevie: Ok the linux-2.6 tree on nv-tegra.nvidia.com hasn't been touched for 3 weeks or so, and I can't find a tree on kernel.org that looks like it is the tree you pulled from... Where is it? | 06:02 |
| infinity | lilstevie: Err. No, flash-kernel is great post-install, but how do you propose booting the installer? | 06:02 |
| twb | Gah, stupid keyboard | 06:02 |
| infinity | lilstevie: Until one image can contain one bootload and one kernel that boots everything, a unified image just can't work. | 06:02 |
| lilstevie | infinity: well that part would need to be tweaked per device, but a universal rootfs.img sort of thing | 06:02 |
| infinity | Well, even that needs to change. | 06:03 |
| infinity | You can have a rootfs minus kernel and bootloader (hey, we ship one of those...) | 06:03 |
| infinity | But a proper system needs the kernel and bootloader installed to the rootfs so flash-kernel has something to, well, flash. | 06:03 |
| infinity | Hence, no longer a universal root. | 06:04 |
| twb | infinity: well, you could fiddle-fart around with unioned kernel/ramdisk overlays on the common base rootfs | 06:05 |
| twb | infinity: but atm that would be more effort than it's worth | 06:05 |
| infinity | Not if you value your sanity. | 06:05 |
| infinity | unions and overlays are great as installer tricks, running them in production is pain. | 06:05 |
| * twb looks shifty | 06:06 | |
| lilstevie | lol | 06:06 |
| twb | I'm not running 600 seats that way, in prisons, oh no | 06:06 |
| infinity | :P | 06:06 |
| lilstevie | I still think at least one device with it would be good | 06:06 |
| lilstevie | like tegra | 06:07 |
| twb | But yeah it's a fucking pain, especially since aufs is buggy as at LTS | 06:07 |
| infinity | Everyone has their curious use-cases. | 06:07 |
| lilstevie | as a start | 06:07 |
| infinity | Yup. | 06:07 |
| infinity | I intend to unify mx51/mx53 in my spare time too. | 06:07 |
| infinity | But that requires two bootloaders and some SERIOUS VOODOO that makes me vomit a little. | 06:07 |
| twb | Man, I should've been a lot more impressed back when I got my sheeva and it had u-boot OOTB | 06:08 |
| infinity | (Basically, I'm jamming one bootloader in unpartitioned post-MBR space, and one bootloader on the first VFAT partition, since the Quickstart will look at the unpartitioned one, and the Efika systems will ignore it and hit up the VFAT one) | 06:08 |
| infinity | You can now cry a little. | 06:08 |
| infinity | I did. | 06:08 |
| twb | At least these bootloaders dpom "DOS-6 like" | 06:09 |
| twb | At least these bootloaders don't claim to be "DOS-6 like" and have a "mouse-based UI" | 06:09 |
| twb | Like the bloody EFI servers I've had to deal with lately | 06:09 |
| infinity | You can look forward to EFI on ARM systems soon. :P | 06:09 |
| lilstevie | infinity: bootloaders are going to be a whore | 06:09 |
| twb | infinity: PLEASE tell me you are joking | 06:10 |
| lilstevie | twb: no, UEFI is the spec coming to arm | 06:10 |
| infinity | twb: About EFI on ARM? Well, UEFI. But no, not joking. | 06:10 |
| twb | Oh FFS | 06:10 |
| lilstevie | the one bootloader to unify them all | 06:10 |
| twb | EFI is so bad | 06:10 |
| twb | What was wrong with OF | 06:10 |
| infinity | Politics. | 06:11 |
| twb | You go into the EFI repl and type "if" and it says "sorry, if only valid in batch scripts" | 06:11 |
| twb | Stupid crack monkeys... | 06:11 |
| lilstevie | MS are probably the driving force here, they only need to maintain one bootlaoder | 06:11 |
| twb | EFI was only built because intel couldn't run 16-bit protected BIOSes on their shitty itaniums | 06:11 |
| TheMuso | lilstevie: Afaik MS have settled on only one SoC vendor for all their ARM related software. | 06:12 |
| twb | And now we're going to end up with thawte-type signing companies for EFI drivers... | 06:12 |
| TheMuso | So I don't think uefi would have been a driver, but I could be wrong. | 06:12 |
| lilstevie | TheMuso: interesting | 06:12 |
| lilstevie | TheMuso: I heard that QC also have an SoC running win8 | 06:12 |
| twb | TheMuso: could be intel | 06:12 |
| TheMuso | Ah right | 06:12 |
| TheMuso | twb: Afaik Intel don't even have their XScale license an more. | 06:12 |
| lilstevie | TheMuso: no they don't they sold it | 06:13 |
| infinity | lilstevie: I would hope Qualcomm is running Win8, or Nokia would be sad pandas. | 06:13 |
| lilstevie | infinity: heh | 06:13 |
| TheMuso | lilstevie: Yeah thought as much. | 06:13 |
| twb | Ah, I couldn't remember who had announced they were making ARM blades now, whether it was AMD or Intel | 06:13 |
| infinity | twb: Intel sold XScale to Marvell eons ago and washed their hands of competing against themselves. | 06:13 |
| lilstevie | TheMuso: AFAIK it is Tegra3 and QC running win8 so far | 06:13 |
| twb | Yeah but like a month ago some mob poppe dup and went "ARM on servers wooo!" | 06:14 |
| twb | I think with HP and ARM Inc. | 06:14 |
| lilstevie | twb: HP | 06:14 |
| twb | Ah, OK. I assumed there was a semi fab company in there too somewhere | 06:14 |
| infinity | twb: HP/Calxeda and *mumbleNDAmumble* other vendors. | 06:14 |
| lilstevie | also intel put all their eggs x86 basket | 06:14 |
| infinity | I'd be curious to see what AMD could do with an ARM license, but I suspect they're being as x86-centric as Intel. | 06:17 |
| infinity | Or they just don't have the cash flow to experiment. | 06:17 |
| infinity | The latter seems more likely. :/ | 06:17 |
| lilstevie | yeah | 06:17 |
| lilstevie | and damn it why is q so close to tab | 06:17 |
| lilstevie | :/ | 06:17 |
| TheMuso | heh | 06:17 |
| lilstevie | I just cmd+q'd irc | 06:17 |
| twb | Obviously the problem there is you aren't using emacs | 06:18 |
| twb | Whree it would be ^X^C | 06:18 |
| TheMuso | Yeah an AMD based SoC with a Radeon/similar derrived GPU would be nice. | 06:18 |
| TheMuso | derived | 06:18 |
| TheMuso | It would possibly mean an open GPU... | 06:18 |
| twb | TheMuso: radeon as in r600 or what | 06:18 |
| twb | I don't even know what they're up to these days | 06:18 |
| twb | My last non-intel GPU was an r200 | 06:19 |
| lilstevie | TheMuso: in theory arm core + GeForce would be kinda nice too, in the real world though it failed :p | 06:19 |
| twb | Which translates to... "radeon 9000" IIRC | 06:19 |
| lilstevie | heh | 06:19 |
| lilstevie | my last non ATI/AMD GPU was a GeFORCE 5200 or smthn like that | 06:19 |
| twb | At least the intel ones Just Worked without any fucking about | 06:20 |
| lilstevie | I vowed never to nvidia again | 06:20 |
| lilstevie | then I got two tegra devices :p | 06:20 |
| lilstevie | hmm | 06:21 |
| lilstevie | $600 for an iconia A501 on telstra prepaid | 06:21 |
| lilstevie | :p | 06:21 |
| TheMuso | How open are the Aconias? | 06:23 |
| TheMuso | In terms of flashing. | 06:23 |
| lilstevie | less than the tf | 06:23 |
| lilstevie | per device SBK | 06:23 |
| twb | lilstevie: you can get the HP tablet on ebay for like A$60 I hear | 06:23 |
| lilstevie | and Chip UID salted hash of kernel and recovery images | 06:24 |
| twb | The downside of the vendor monkeys learning how to actually do crypto properly, is they actually lock us out :-/ | 06:24 |
| lilstevie | yes | 06:24 |
| twb | It'd be nice if the ACCC had a clue | 06:24 |
| lilstevie | asus monkeys still haven't figured out crypto | 06:25 |
| lilstevie | the signed blobs of the tf201 is just because nvidia offer it as a standard | 06:25 |
| twb | So I could write to them and say "please tell h/w vendors to fuck off with their software lock-in" | 06:25 |
| twb | get iphones banned in .au and so on | 06:25 |
| lilstevie | heh | 06:26 |
| lilstevie | we would lose a lot | 06:26 |
| TheMuso | Oh lovely re the aconia. | 06:26 |
| lilstevie | cause under that definition the xoom is locked too | 06:26 |
| lilstevie | even with fastboot oem unlock | 06:26 |
| twb | Suits me | 06:26 |
| infinity | The problem is that people still view these devices as embedded (when they're not), rather than general-purpose computers (which they are). | 06:26 |
| lilstevie | NI adam isn't though :p | 06:26 |
| twb | s/embedded/appliances/ | 06:26 |
| infinity | No one screams about vendor lock-in with the software running on their printer or microwave oven. | 06:26 |
| lilstevie | yeah | 06:26 |
| twb | infinity: well, I would if it had a browser in it | 06:27 |
| lilstevie | these tablets are not embedded really | 06:27 |
| TheMuso | Hell no. | 06:27 |
| twb | Actually the goddamn MFD does | 06:27 |
| lilstevie | they are fully functional computing devices | 06:27 |
| TheMuso | Yup, and I'll bet for lots of people out there, they will be just fine for a computer, given that the user only does light browsing/video watching.email. | 06:27 |
| twb | HP printer/mfc here is running linux and wpasupplicant and so on | 06:27 |
| TheMuso | s/./// | 06:27 |
| lilstevie | I want arm laptops :p | 06:28 |
| twb | lilstevie: my gods, yes | 06:28 |
| TheMuso | Heh me too. :) | 06:28 |
| lilstevie | like an ultrabook | 06:28 |
| lilstevie | but with arm | 06:28 |
| twb | lilstevie: do you remember back when ASUS demoed a 9" EeePC ARM running ubuntu 9.04 or so ? | 06:28 |
| lilstevie | twb: not really | 06:28 |
| twb | lilstevie: I was all "FUCK YEAH" and then "OK next month they will come out" for the next three years | 06:29 |
| lilstevie | twb: however the tf101 was a last minute switch to android | 06:29 |
| lilstevie | I have heard rumour that they initially wanted ubuntu | 06:29 |
| twb | It was demoed like a week before Microsoft said "hey ASUS here is a big bag of money please stop shipping linux netbooks" | 06:29 |
| lilstevie | and were running 10.10 | 06:29 |
| TheMuso | I think we are only now getting to the point where ARM CPUs are fast enough for most general use tasks that require CPU intensive ops. | 06:29 |
| lilstevie | but ofc android won out | 06:30 |
| lilstevie | TheMuso: hells yeah | 06:30 |
| lilstevie | I use my tf101 as a netbook | 06:30 |
| lilstevie | as in a daily use netbook | 06:30 |
| twb | TheMuso: especially since the DSP and AES and friends are done elsewhere on the chip | 06:30 |
| lilstevie | I browse the web, do a bit of programming | 06:30 |
| twb | lilstevie: that's what I bought mine for | 06:30 |
| TheMuso | lilstevie: DO you have to do anything funky to get headphones out working when running uboot Ubuntu 2.6.38? | 06:31 |
| lilstevie | TheMuso: no | 06:31 |
| twb | tf101 = netbook with longer battery life and SSD by default | 06:31 |
| TheMuso | I haven't really tried yet, but couldn't get audio working with the ASUS kernel when I tried. | 06:31 |
| TheMuso | Ok, will try again. | 06:31 |
| twb | TheMuso: if you go into alsamixer there are about 60 different things to fiddle with | 06:31 |
| lilstevie | TheMuso: it works once oem-config does its magic | 06:31 |
| TheMuso | twb: Yes I know. | 06:32 |
| twb | TheMuso: might be one of them is "work without headphones" and is off by default | 06:32 |
| lilstevie | also, just saw aldi have an android tablet now too :p | 06:32 |
| lilstevie | TheMuso: originally I thought sound was busted, turned out just the media board came unplugged | 06:32 |
| TheMuso | ah ok | 06:32 |
| lilstevie | aldi tablet, tegra2 running hc 3.2 3G/wifi, 32GB | 06:33 |
| lilstevie | 499 | 06:33 |
| TheMuso | Interesting... I wonder how locked down it is. | 06:33 |
| TheMuso | Although for tablets I won't go past the transformer purely because of the dock. | 06:33 |
| lilstevie | TheMuso: hahaha that was exactly my first thought | 06:33 |
| lilstevie | yeah | 06:34 |
| lilstevie | I have a 7" SGT for a tablet | 06:34 |
| lilstevie | my tf is a netbook :p | 06:34 |
| lilstevie | netbook in tablet clothing | 06:34 |
| TheMuso | heh | 06:34 |
| lilstevie | and infinity actually I do, I would love to get my hands dirty with my microwaves firmware | 06:35 |
| twb | FCC probably won't let you | 06:36 |
| twb | despite not having any power in .au | 06:36 |
| twb | TheMuso: you know what <coworker> suggested that was clever? | 06:36 |
| twb | TheMuso: when the dock is unplugged, speak to it over bt | 06:37 |
| TheMuso | twb: Yeah, but you may as well use a general bluetooth KB then. :) | 06:37 |
| twb | TheMuso: but it has a battery and such | 06:38 |
| lilstevie | well the iconia dock is bt | 06:39 |
| twb | home time | 06:39 |
| lilstevie | :p | 06:39 |
| twb | yabbut not just bt | 06:39 |
| twb | only as a fallback | 06:39 |
| TheMuso | lilstevie: Why would you want to use nvflash on the trim when its as open as one can get in terms of getting an OS to run on it? | 06:51 |
| lilstevie | TheMuso: thats complicated to explain :) | 06:56 |
| TheMuso | ah ok | 06:59 |
| infinity | ogra_ / GrueMaster: FWIW, tested precise-desktop-armhf+omap4, and it installed flawlessly. Yay. | 09:09 |
| ogra_ | infinity, yeah, i had some people in #ac100 testing the workaround on the old images already | 09:09 |
| ogra_ | (that channel is usually more active than here) | 09:10 |
| infinity | Heh. | 09:10 |
| infinity | ogra_: Well, I knew the procps fix would work. I just wanted to see an official image actually complete an install. And it just did. | 09:10 |
| ogra_ | just doing a manual ac100 build, since that ran into the gtk3 out-of-sync-ness | 09:10 |
| infinity | So, we're just a few libreoffice porting fixes away from a complete desktop. | 09:10 |
| ogra_ | yeah | 09:11 |
| ogra_ | though we dont seed LO | 09:11 |
| ogra_ | wich makes it non-fatal | 09:11 |
| infinity | Oh, so we don't. | 09:13 |
| infinity | So, our desktop is actually complete right now? | 09:13 |
| infinity | Shiny. | 09:13 |
| ogra_ | we didnt use to at least :) i must admit i havent a local branch of the precise seeds | 09:13 |
| infinity | desktop: * (libreoffice-writer) [i386 amd64 powerpc] | 09:13 |
| infinity | Etc. | 09:13 |
| infinity | We still don't. | 09:13 |
| ogra_ | well, we should take care that it works even if we dont seed it | 09:14 |
| ogra_ | else david will cry :) | 09:14 |
| * infinity nods. | 09:14 | |
| infinity | My plan is to make sure everything works. :P | 09:14 |
| infinity | But priority is on seeded stuff, for obvious reasons. | 09:14 |
| ogra_ | i like to see it as part of the desktop .... it just doesnt break our images ;) | 09:14 |
| * ogra_ gives back vte3 on armel | 10:14 | |
| lilstevie | libre is the only reason I am not testing hf presice on the tf101 | 10:16 |
| ogra_ | hmm, looking at the alure buildfailure it looks like libmpg123 is missing a shlibs file for armhf | 11:00 |
| ogra_ | heh, funny ... | 11:04 |
| ogra_ | the mpg123 source has a ton of identical symbols files for each possible arch | 11:04 |
| * ogra_ copies armel to hf | 11:06 | |
| ogra_ | i wonder how many other packages are missing symbols files for hrf | 11:14 |
| ogra_ | *hf | 11:14 |
| ogra_ | WTF ! | 11:26 |
| * ogra_ shakes his head about debian/alure-dynload-shlibdeps | 11:27 | |
| ogra_ | why the heck cant they just use dpkg | 11:27 |
| ogra_ | indeed there is no multiarch support at all in that script | 11:27 |
| ogra_ | oh my | 11:27 |
| ogra_ | bug 831192 | 11:39 |
| ubot2 | Launchpad bug 831192 in alure "alure version 1.2-1 failed to build in oneiric" [High,Fix released] https://launchpad.net/bugs/831192 | 11:39 |
| ogra_ | hmm, i wonder where that fix went | 11:40 |
| ogra_ | ah, its there but omits mpg123 multiarch | 11:41 |
| LeslieLi | Hi, what is the login name and password of ubuntu for beagleboard? | 11:45 |
| ogra_ | the one you gave it in the installer | 11:46 |
| LeslieLi | ogra_: I built it with setup_sdcard.sh? then insert sdcard to beagle... | 11:48 |
| ogra_ | no idea what that is | 11:48 |
| ogra_ | the official ubuntu images run the installer | 11:48 |
| ogra_ | if you used something else, talk to the author of whatever tool you used | 11:48 |
| ogra_ | infinity, any idea why i see "WARNING: The following packages cannot be authenticated!" in some of the armhf buildlogs ? that doesnt seem right | 14:10 |
| === Ursinha is now known as Ursinha-nom | ||
| soren | ogra_: We see those on all arches. Always have, I believe. | 15:26 |
| ogra_ | hmm, yeah, they dont seem to do any harm | 15:27 |
| ogra_ | i find it still weird since the buildd should run apt-get update before even starting | 15:27 |
| soren | ogra_: They do. | 15:28 |
| soren | "Authentication warning overridden. | 15:28 |
| soren | " | 15:28 |
| ogra_ | ah | 15:28 |
| ogra_ | k | 15:28 |
| ogra_ | thats explains it | 15:28 |
| === Ursinha-nom is now known as Ursinha | ||
| infinity | ogra_: No gnupg in the chroots, we trust our path to ftpmaster. | 15:59 |
| infinity | ogra_: (And if we don't, we have big problems) | 15:59 |
| ogra_ | yeah, understood | 15:59 |
| ogra_ | fatal error: curl/types.h: No such file or directory | 16:01 |
| ogra_ | heh, another one | 16:01 |
| ogra_ | it is funy how many packages still include that ... given that curl upstream claims its unused since 2004 | 16:02 |
| ogra_ | (in thir removal message from 2011) | 16:02 |
| ogra_ | *their | 16:02 |
| doko_ | eukleides (1.5.4-1ubuntu2) precise; urgency=low | 16:39 |
| doko_ | * add build-dep on libncurses5-dev to fix ftbfs on armhf | 16:39 |
| doko_ | ogra_, ^^^ no, not just armhf | 16:39 |
| ogra_ | doko_, well, the upload was specifically to fix this ftbfs ... but yeah | 16:40 |
| ogra_ | i'm surprised how many packages havent been built since natty | 16:40 |
| doko_ | jonmasters, are you using arm-linux-gnueabihf as the ARM hf triplet as well? | 17:41 |
| infinity | doko_: Last I checked, he was, but he hasn't switched the linker location yet. | 17:41 |
| infinity | jonmasters: Confirm/deny? | 17:41 |
| doko_ | anyway, afk now | 17:42 |
| jonmasters | infinity, doko_: we're going to support that triplet but not switch to it yet | 19:38 |
| jonmasters | (we'll do symlinking) | 19:38 |
| === Quintasan_ is now known as Quintasan | ||
| Quintasan | ogra_ ping | 19:43 |
| infinity | jonmasters: That won't work for compatibility at all. | 19:56 |
| jonmasters | infinity: I realize that only works for stuff built on Ubuntu running on Fedora | 20:18 |
| infinity | jonmasters: Not really an ideal situation... | 20:19 |
| jonmasters | infinity: I'll re-raise the triplet. I suspect we'll look at switching during our upcoming transition to rawhide, which is fine because nobody is going to deploy on Fedora 15 :) | 20:19 |
| infinity | jonmasters: Unless the intent is to promote Fedora as a platform to build stuff on that won't work for competitors. ;) | 20:19 |
| jonmasters | Fedora 15 is officially going to support Xfce and a few other bits. We're punting on a full build to skip to rawhide (devel) builds in time for F17. | 20:19 |
| infinity | jonmasters: If all you're moving is the linker (which can still be a symlink, if you don't want to change eglibc packaging), it's just a 3-line diff to GCC to move the PI in the ELF headers. | 20:20 |
| * jonmasters needs to get an Ubuntu install going again to track this stuff. I'll make that a todo. | 20:20 | |
| jonmasters | yea, I think we could do it whenever really but given we're basically done with F15 I'd rather push that for rawhide | 20:21 |
| infinity | I'd just prefer to see it happen somewhere other than Debian/Ubuntu to give weight to our talks (and agreement) at Plumbers. | 20:21 |
| infinity | Will make it easier for me to push it down Google's throats, etc. | 20:21 |
| jonmasters | We should talk LSB, too. How about this. How about we actually spend some time reading through the LSB reqs and schedule a call in the new year? Like first week of Jan? | 20:21 |
| infinity | (Which is on my TODO) | 20:22 |
| jonmasters | I'm getting a lot of resistance to multi-arch from our tools group btw :) | 20:22 |
| infinity | Yeah, I'm back from vacation on the third of January, and in the air on the seventh. Somewhere in between there might work. ;) | 20:22 |
| jonmasters | ok, or the following week? | 20:22 |
| infinity | I'd love to see multi-arch all over. But this isn't m-a, this is just a sane linker location. | 20:23 |
| infinity | Where you put your libraries is your business. :) | 20:23 |
| infinity | The following week, I'm in Budapest. So, it's either between the 3rd and 7th, or a week later. | 20:23 |
| jonmasters | yea | 20:24 |
| jonmasters | I'll get this straightened out | 20:24 |
| infinity | jonmasters: For the record, the simple gcc patch we're using is: http://lucifer.0c3.net/~adconrad/arm-dynamic-linker.diff | 20:27 |
| infinity | jonmasters: Given that you don't care about sf/hf bi-arch, you could just hardcode the linker and be done with it, though, I suspect. | 20:27 |
| infinity | jonmasters: Unless your sf port is going to live on. | 20:28 |
| lborda | hi guys | 20:32 |
| lborda | what is the output for uname -a on arm processors running ubuntu? | 20:33 |
| infinity | lborda: If you're using uname to determine something in a build process, don't. | 20:34 |
| GrueMaster | lborda: Depending on the platform, it looks like this: Linux panda3 3.0.0-1206-omap4 #13-Ubuntu SMP PREEMPT Wed Nov 23 17:50:31 UTC 2011 armv7l armv7l armv7l GNU/Linux | 20:34 |
| infinity | lborda: uname doesn't tell you anything about the userspace. Which is probably what you actually care about. | 20:34 |
| lborda | i'm developing a bash script and i was looking for something to give the kernel architecture that is currently runnin | 20:34 |
| lborda | g | 20:35 |
| lborda | something like uname -a | grep -o x86_64 | 20:35 |
| infinity | Oh. Then you just want $(uname -m) ... Why reinvent the wheel? | 20:35 |
| lborda | any better ideas? | 20:35 |
| GrueMaster | lborda: Better to use dpkg --print-architecture. | 20:35 |
| infinity | echo "My kernel arch is $(uname -m)" | 20:35 |
| infinity | But userspace/debian/package arch is more interesting. | 20:36 |
| lborda | infinity: it does not work on cloud images for example | 20:36 |
| lborda | hum.... | 20:36 |
| infinity | So, "My Debian arch is $(dpkg --print-architecture)" | 20:36 |
| infinity | lborda: And, err, what? Why would uname not work on cloud images? | 20:36 |
| lborda | it is a bug... it says unknown | 20:37 |
| infinity | -m doesn't. | 20:38 |
| lborda | for i686 images | 20:38 |
| lborda | i386 | 20:38 |
| lborda | sorry | 20:38 |
| infinity | You're looking at -p or -i | 20:38 |
| infinity | -m will never print unknown. | 20:38 |
| lborda | infinity, let me see... | 20:38 |
| lborda | infinity, -m prints the machine hardware name, would that give me always the kernels architecture ? | 20:41 |
| lborda | infinity, i think i'm better of using dpkg --print-architecture thank you | 20:43 |
| GrueMaster | lborda: dpkg --print-architecture will give you the proper arch (armel, armhf, x86_64, i386, etc) that the system is compiled for. Much better than uname output for most things. | 20:45 |
| lborda | GrueMaster, agree thank you! | 20:46 |
| infinity | lborda: uname -m is the kernel arch, dpkg --print-architecture is the userspace arch. Two very different things. | 20:54 |
| infinity | lborda: (Say, for instance, running an i386 userspace on an amd64 kernel) | 20:54 |
| infinity | lborda: Both things are valuable to know, but usually when someone thinks they want the kernel arch, they're wrong (unless they're building kernel modules). | 20:55 |
| lborda | infinity, I see your point, essentially i need to know which kernel is installed so I believe dpkg --print-arch will help me | 21:06 |
| infinity | Two differnet things. Again. | 21:09 |
| janimo | ppisati, infinity do you know what SRU version is appropriate for the ac100 kernel oneiric upload that only has the mmap() fix? | 21:32 |
| janimo | Latest is 2.6.38-1001.1 | 21:32 |
| janimo | in oneiric | 21:33 |
| infinity | janimo: 1001.2, if it doesn't break ABI. Or did that version exist in precise? | 21:37 |
| infinity | If that version's been used, then 1001.1.0.1 or 1001.1.0.11.10 or some such. | 21:38 |
| janimo | we had 1002.1 in precise | 21:38 |
| infinity | Right, which was a new ABI. | 21:39 |
| infinity | If this doesn't break ABI, then 1001.2 is fine. | 21:39 |
| janimo | hmm I wonder if it breaks the ABI, I need to check the patch closer. It changes the order mmap()0-ed addresses are given to the apps | 21:39 |
| janimo | I think that is quite a change, but not sure if technically ABI change | 21:39 |
| infinity | Well, you can build it and use the handy abi-checker to see. | 21:39 |
| infinity | Not sure if you noticed, but I turned on ABI checking in the precise ac100 sources. | 21:40 |
| infinity | There seemed to be many attempts at disabling it. :P | 21:40 |
| janimo | infinity, I was going to ask you about that too :) | 21:40 |
| janimo | I noticed you DTRT | 21:40 |
| janimo | it was off as that is how _I think_ copied it from jcrigby 's debianization tree | 21:41 |
| janimo | so the whole ABI checking did nothing indeed | 21:41 |
| janimo | but with it I had the following issue today: bumping version to 3.0.8-1.1 it tries to look for prev_abi which should be in dir 3.0.8-0.0 and bails out | 21:42 |
| janimo | is there some blessed script to automate the whole ABI bump thing? | 21:42 |
| janimo | I just made a 3.0.8-0.0 by hand which I doubt is the best idea | 21:42 |
| === doko_ is now known as doko | ||
| infinity | janimo: You might want to ask in ubuntu-kernel how they deal with it. I tend to just ignore on a new ABI, and then fetch and populate for subsequent uploads. | 22:10 |
| infinity | janimo: (ie: if you know it's a new ABI and you've bumped the version) | 22:11 |
| janimo | infinity, ok. So in the case of bumping to 3.0 do you call the build with a sepcial skipabi or you make a dummy dir as I have? | 22:11 |
| janimo | it is still unclear to me which of those abi dirs are to be hand maintained and which created by scripts | 22:12 |
| janimo | as the build process creates some | 22:12 |
| janimo | and at least in the ac100 package there's this weird situation that the next to last version has an abi dir, but not the last | 22:12 |
| infinity | The build process creates a current dir. You want ignore files in that same directory on a fresh ABI. | 22:12 |
| infinity | To get the last, you need to use the fetch_abi script (or whatever it's called). | 22:13 |
| infinity | It grabs the last binary builds from the archive and extracts the ABI files. | 22:13 |
| infinity | If you're doing test-builds anyway, you can cheat and pre-populate. | 22:13 |
| janimo | /etc/getabis? | 22:13 |
| janimo | never used it, if that's the one | 22:13 |
| infinity | But the kernel team tends to just set the first upload as ignored, and then fetch. | 22:14 |
| infinity | Yeah, that one. | 22:14 |
| janimo | ah ok, so setting ignored once in a while is not that vile | 22:14 |
| infinity | Ignored is fine if it's versioned as a new ABI. | 22:14 |
| infinity | Ignored is bad and wrong on subsequent uploads of the same ABI (since you might be wrong). | 22:14 |
| janimo | indeed, so it is there to catch abi changes, but if you know for sure there is an ABI change it can be turned off as you bump anyway | 22:15 |
| infinity | Right. | 22:15 |
| janimo | thanks. I am weary of asking the kernel team because I almost always came away a bit more confused when asking | 22:16 |
| infinity | So, ignore on your first 3.0 upload, and then use getabis on the next upload to populate the directories with the right files. | 22:16 |
| infinity | (And remove the ignore semaphores) | 22:16 |
| infinity | Alternately, do a local build and use the abi output to populate the directories by hand before uploading. | 22:17 |
| infinity | Which works fine if you're building for a single arch (which you are). Just remember to cp the armel stuff to armhf (or vice versa). | 22:17 |
| janimo | single arch even if we have both armel and armhf, because they are identical for the kernel code? | 22:18 |
| infinity | Right. | 22:18 |
| infinity | The ABI files in my upload are identical on both. | 22:18 |
| infinity | As they should be. | 22:18 |
| infinity | If one of them breaks, that's a problem. :P | 22:19 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!