**** BEGIN LOGGING AT Tue Dec 13 02:59:57 2011
Dec 13 04:01:03 <twb> lilstevie: does ubuntu on tf101 still have a problem where it doesn't shut down all the way?
Dec 13 04:01:58 <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
Dec 13 04:30:19 <twb> Ignore that, I managed to do it after shutting down from ubuntu
Dec 13 04:48:39 <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
Dec 13 05:08:33 <twb> lilstevie: can I flash a new kernel+ramdisk into the SOS partition, from within ubuntu?
Dec 13 05:09:23 <twb> lilstevie: using the olife-prime default setup (dual boot, ubuntu default).
Dec 13 05:09:53 <twb> lilstevie: AFAICT the answer is no, because the LNX/SOS partitions are outside the mmcblk "visible" area of the partition table
Dec 13 05:10:01 <TheMuso> twb: Yes you should be able to, but you will need to build it into a blob.
Dec 13 05:10:17 <twb> TheMuso: yeah I understand the abootimg part
Dec 13 05:10:37 <twb> Oh, it might be partitions 5 and 6, file -s doesn't recognize those!
Dec 13 05:11:51 <twb> abootimg -i /dev/mmcblk0p5 isn't encouraging, it says it's not an android boot image
Dec 13 05:23:08 <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>
Dec 13 05:23:22 <TheMuso> They get flashed by the Asus bootloader.
Dec 13 05:23:27 <twb> Oh
Dec 13 05:23:56 <twb> Because in the uboot world you just make those parts of the emmc directly visible and dd straight to them
Dec 13 05:24:20 <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.
Dec 13 05:24:56 <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?
Dec 13 05:25:01 <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.
Dec 13 05:25:13 <twb> OH
Dec 13 05:25:24 <twb> What a pain in the arse
Dec 13 05:25:35 <TheMuso> Yup, thank Asus and their bootloader. :)
Dec 13 05:25:59 <twb> You'd think it'd be easy to just move GP1 further up so that LNX and SOS can be dd'd directly
Dec 13 05:26:09 <twb> There is probably some stupid reason why you can't
Dec 13 05:26:36 <TheMuso> Yeah, and I'm sure lilstevie has a better idea why, I happen to agree with you though.
Dec 13 05:27:00 <TheMuso> But it could be Asus being nasty. :)
Dec 13 05:27:53 <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?
Dec 13 05:28:39 <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
Dec 13 05:28:43 <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.
Dec 13 05:28:52 <twb> Cool
Dec 13 05:29:30 <TheMuso> The ASUS blobs have SOS, LNX, and APP in them.
Dec 13 05:29:33 <twb> And then I drop it in the mmcblk0p4 partition as a file called ./blob ?
Dec 13 05:30:01 <TheMuso> It doesn't matter what the file is called. Just dd if=blobfilename of=/dev/mmcblk0p4
Dec 13 05:30:16 <TheMuso> And on next reboot, the ASUS bootloader will flash it for you.
Dec 13 05:30:18 <twb> Ah, overwrite the block device entirely
Dec 13 05:30:32 <twb> I was led astray because mmcblk0p4 currently have an empty ext filesystem on it
Dec 13 05:30:53 <TheMuso> Yes, thats right, which I also find weird, but yeah you just dd the blob file onto mmcblk0p4
Dec 13 05:31:04 <twb> OK, no worries
Dec 13 05:37:22 <twb> Grr, unmetered local mirror only has 10.10 (ftp://mirror.internode.on.net/pub/ubuntu-ports/)
Dec 13 05:39:16 <TheMuso> Thats a bummer. I know aarnet also mirrors ubuntu-ports, but thats probably not unmetred for node customers.
Dec 13 05:39:35 <twb> probably faster than ports.u.c tho
Dec 13 05:39:38 <lilstevie> TheMuso: twb no not boot img blob
Dec 13 05:39:39 <lilstevie> :p
Dec 13 05:39:43 * TheMuso used to be on internode till the alure of cable, combined with Telstra having deacent plans lured me away.
Dec 13 05:40:38 <lilstevie> and that isn't an asus feature, it is an nvidia thing
Dec 13 05:40:53 <twb> Well SOMEONE is to blame :P
Dec 13 05:40:54 <TheMuso> Ah makes sense.
Dec 13 05:41:10 <lilstevie> the reason it is outside the GP1 is because asus don't want you to have access to it :)
Dec 13 05:41:20 <lilstevie> moving it isn
Dec 13 05:41:30 <lilstevie> moving the gp1 is a bit of a pita
Dec 13 05:41:48 <twb> Makes using abootimg -u a PITA
Dec 13 05:41:49 <lilstevie> you need to move the actual partitions to the end of flash, which I will be reintroducing with 1.3
Dec 13 05:42:09 <lilstevie> I need to set up some stuff for android first though
Dec 13 05:42:24 <lilstevie> because asus blobs include the tegraparts partition table
Dec 13 05:42:34 <lilstevie> which will in effect break the whole system
Dec 13 05:42:50 <TheMuso> Ah.
Dec 13 05:43:13 <twb> Well unless that includes OTA stuff, who cares
Dec 13 05:43:25 <TheMuso> lilstevie: BTW have you been able to work out how to get your 2.6.38 kernel to read the stock partition table?
Dec 13 05:43:28 <twb> Just tell the users not to dl stock asus updates
Dec 13 05:43:38 <lilstevie> twb: that IS OTA stuff
Dec 13 05:43:44 <twb> Ah, fuck, OK
Dec 13 05:43:45 <lilstevie> TheMuso: no :/
Dec 13 05:44:19 <TheMuso> Ok, good to know it wasn't just me running round in circles trying to get it to work. :)
Dec 13 05:44:37 <lilstevie> TheMuso: I am trying to figure out WTF is wrong
Dec 13 05:44:49 <lilstevie> but the GPT driver in that sense is identical
Dec 13 05:44:55 <TheMuso> RIght.
Dec 13 05:44:56 <lilstevie> it is just being a slippery whore
Dec 13 05:45:12 <lilstevie> but with what I am working on at the moment that may not be an issue anymore
Dec 13 05:45:23 <lilstevie> well, I mean I still want to go up
Dec 13 05:45:27 <lilstevie> but less of an issue
Dec 13 05:45:37 <lilstevie> nvidia released the L4T beta1 drivers
Dec 13 05:45:41 <lilstevie> and they use 2.6.36
Dec 13 05:45:43 <TheMuso> Yeah I saw that.
Dec 13 05:45:47 <lilstevie> just the interface is different
Dec 13 05:45:57 <lilstevie> so i am porting the nvhost interface
Dec 13 05:46:01 <TheMuso> Right.
Dec 13 05:46:01 <lilstevie> into our tree
Dec 13 05:46:05 <TheMuso> Nice.
Dec 13 05:46:15 <lilstevie> which will relieve that stress for a little while
Dec 13 05:46:27 <lilstevie> so I can work on a more stable u-boot/new kernel
Dec 13 05:46:32 <TheMuso> Right.
Dec 13 05:46:45 <lilstevie> cause as it stands u-boot is not configuring the clocks correctly
Dec 13 05:46:47 <TheMuso> In other news, my trimslice shipped over night. :)
Dec 13 05:46:58 <TheMuso> Ah ok.
Dec 13 05:47:10 <lilstevie> and as such asus kernels won't run on it
Dec 13 05:47:22 <TheMuso> Yup.
Dec 13 05:47:23 <lilstevie> even with a machine_start block using the boardid
Dec 13 05:47:38 <lilstevie> cause asus bootloader/uboot have different boardids
Dec 13 05:47:45 <TheMuso> Yeah I saw that.
Dec 13 05:47:47 <lilstevie> asus shows ventana
Dec 13 05:47:53 <lilstevie> uboot shows tf101
Dec 13 05:47:56 <lilstevie> :)
Dec 13 05:48:57 <TheMuso> lilstevie: Does the NVHost stuff include the interfaces needed for their drivers?
Dec 13 05:49:11 <lilstevie> the nvhost stuff is the interface
Dec 13 05:49:26 <TheMuso> right
Dec 13 05:49:58 <lilstevie> good news for ics tablets though
Dec 13 05:50:10 <lilstevie> as the L4T and android binary interface is now unified
Dec 13 05:50:48 <lilstevie> also
Dec 13 05:50:55 <lilstevie> expect your trimslice monday
Dec 13 05:51:13 <TheMuso> Yeah thought it would be about a week.
Dec 13 05:51:14 <lilstevie> well by monday I should say
Dec 13 05:51:20 <lilstevie> mine took 4 days from shipped
Dec 13 05:51:25 <TheMuso> Nice.
Dec 13 05:51:45 <lilstevie> yeah, thats why shipping is so expensive I guess :p
Dec 13 05:51:53 <TheMuso> What git tree has the latest l4t nvhost code?
Dec 13 05:52:02 <lilstevie> nv-tegra mainline
Dec 13 05:52:19 * infinity almost bought a Trimslice, but figures his desk has enough random ARM devices littering it.
Dec 13 05:52:32 <TheMuso> ah ok
Dec 13 05:52:41 <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 :)
Dec 13 05:52:49 <lilstevie> infinity: did you see what I said the other day
Dec 13 05:53:07 <infinity> lilstevie: About unified tegra kernels madness?
Dec 13 05:53:15 <lilstevie> yeah
Dec 13 05:53:41 <infinity> Yeah, I read it at the time, and promptly forgot whatever it was because I've been sick all weekend. ;)
Dec 13 05:53:52 <lilstevie> with a little bit of modularization and a bit of heuristic madness we could probably get it working
Dec 13 05:54:03 <lilstevie> arch have a "tegra" kernel
Dec 13 05:54:04 <twb> infinity: want me to send you some vegemite or something?
Dec 13 05:54:13 <infinity> twb: *glare*
Dec 13 05:54:29 <lilstevie> that is built for all board-* in mach-tegra
Dec 13 05:54:31 <twb> It's good for you!
Dec 13 05:54:49 <infinity> lilstevie: ac100/tf101/tf202/trimslice would be a lovely set of things to support with a single kernel.
Dec 13 05:54:49 <twb> You think: shit, I'd better get up, or they'll give me another slice of vegemite toast
Dec 13 05:54:58 <lilstevie> infinity: yeah
Dec 13 05:55:03 <infinity> lilstevie: Though we'd still have boot-loader/boot-method messes to contend with.
Dec 13 05:55:11 <lilstevie> infinity: I mean it would be a little bit of work
Dec 13 05:55:32 <lilstevie> and yeah bootloader wise you have like you do now with the flash-kernel config
Dec 13 05:55:43 <infinity> lilstevie: Little bit of work, perhaps, but ultimately less work than supporting 4 kernel trees for 4 devices.
Dec 13 05:55:52 <lilstevie> yeah
Dec 13 05:56:01 <lilstevie> I mean the tf101 is going to be a bit of pain
Dec 13 05:56:12 <twb> lilstevie: the tf202 is better?
Dec 13 05:56:13 <lilstevie> things liek the EC driver are tied in with the battery
Dec 13 05:56:27 <lilstevie> twb: tf201 is going to be a c***
Dec 13 05:56:31 <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.
Dec 13 05:56:32 <twb> hahaha
Dec 13 05:56:36 <lilstevie> T3 with its new security
Dec 13 05:56:44 <lilstevie> and the fact that nvblobs are now signed
Dec 13 05:56:46 <infinity> Has anyone talked to them about working with us to get their bits in our archive?
Dec 13 05:56:54 <lilstevie> even with local root, no kernel changes
Dec 13 05:57:03 <TheMuso> infinity: DOn't think so... I looked at how they installed Ubuntu the other day... I shuddered.
Dec 13 05:57:16 <lilstevie> infinity: yeah, but their ubuntu installer is CRAP
Dec 13 05:57:30 <infinity> TheMuso: Yeah, I haven't looked at their custom installer.  Can't be drastically worse than some weird stuff we do, can it?
Dec 13 05:57:34 <lilstevie> I actually hope that beta L4T drivers work with ubiquity and the hdmi
Dec 13 05:57:45 <lilstevie> infinity: OEM-CONFIG is a hell of a lot more sane
Dec 13 05:57:53 <TheMuso> infinity: Shell scripts + a partimage image, and zenity to prompt the user.
Dec 13 05:57:57 <lilstevie> infinity: they pretty much dd the image in place
Dec 13 05:58:05 <infinity> TheMuso: Oh dear.
Dec 13 05:58:16 <lilstevie> and set it up with the user trim and password 111111
Dec 13 05:58:21 <lilstevie> FROM THE INSTALLER
Dec 13 05:58:24 <lilstevie> like what
Dec 13 05:58:30 <lilstevie> you could at least configure a damn user
Dec 13 05:58:32 <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.
Dec 13 05:58:43 <twb> That's because they're doing it for a job rather than because they care
Dec 13 05:58:45 <lilstevie> infinity: I want to
Dec 13 05:58:48 <TheMuso> I'd think so too.
Dec 13 05:58:49 <infinity> TheMuso: And with the joy of packagesets, they could maintain their own kernel and uBoot and such in universe.
Dec 13 05:58:53 <TheMuso> And yes I want to help too.
Dec 13 05:59:05 <lilstevie> I really want to manage the timslice in a more sane way
Dec 13 05:59:11 <lilstevie> it would certainly help anyway
Dec 13 05:59:11 <twb> And "they" is probably just one guy anyway
Dec 13 05:59:18 <twb> And he's an intern
Dec 13 05:59:20 <TheMuso> lilstevie: Hell yeah it would certainly help
Dec 13 05:59:28 <lilstevie> my trim was a donation from someone because my method of installing on the tf101 is more sane :p
Dec 13 05:59:51 <infinity> Is it more or less sane than the whacky way we do ac100?
Dec 13 05:59:58 <infinity> (your tf101 installer, that is)
Dec 13 06:00:04 <infinity> The Trimslice thing just sounds vile.
Dec 13 06:00:05 <lilstevie> I even got the trim working with nvflash but compulabs are stonewalling me when it comes to getting the trim
Dec 13 06:00:13 <lilstevie> infinity: more and less
Dec 13 06:00:34 <TheMuso> lilstevie: Getting the trim as in obtaining one?
Dec 13 06:00:39 <lilstevie> more because it uses the prebuilt image setup like omap
Dec 13 06:00:50 <infinity> But, actually, the "tarball installer" method we use for ac100 would take one or two tweaks and work great on the Trim.
Dec 13 06:01:04 <TheMuso> But the tarball installer doesn't make sense for the trim.
Dec 13 06:01:05 <infinity> Since their own installer basically just blats an FS to one of two target devices.
Dec 13 06:01:09 <TheMuso> Particularly the SATA models.
Dec 13 06:01:18 <twb> lilstevie: if you really wanted you could abuse live-build to generate new images from scratch, but it's icky
Dec 13 06:01:27 <lilstevie> TheMuso: the information I need for it
Dec 13 06:01:27 <infinity> TheMuso: Makes perfect sense for SATA.  That's what it was written for.  To install from SD to internal storage.
Dec 13 06:01:28 <TheMuso> Sure you could do it that way, but it would be perfectly possible to use ubiquity.
Dec 13 06:01:42 <lilstevie> twb: actually TheMuso and I were looking at generating prebuilts
Dec 13 06:01:42 <infinity> TheMuso: It does use ubiquity (in the form of oem-config).
Dec 13 06:01:50 <lilstevie> once the kernel is properly packaged
Dec 13 06:01:55 <lilstevie> infinity: trimslice does not
Dec 13 06:02:00 <TheMuso> infinity: I'm aware of that, but I am thinking of things like partitioning a SATA hard drive etc.
Dec 13 06:02:00 <infinity> TheMuso: The reason we don't use ubiquity (in the form of a live system) is because it's effin' slow.
Dec 13 06:02:06 <twb> live-build is nicer image builder than anything else I've looked at
Dec 13 06:02:10 <lilstevie> trim never uses ubiquity
Dec 13 06:02:36 <infinity> lilstevie: No, I realise that.
Dec 13 06:02:36 <lilstevie> TheMuso: was that method we spoke about with live-build
Dec 13 06:02:47 <TheMuso> lilstevie: Yes.
Dec 13 06:02:59 <lilstevie> infinity: I mean like the trim is a terrible install setup
Dec 13 06:03:18 <lilstevie> even archlinux with its horrid install is a little more comfortable
Dec 13 06:03:25 <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.
Dec 13 06:04:00 <infinity> Extending livecd-rootfs to add a subarch is about 20 seconds of effort.
Dec 13 06:04:06 <TheMuso> Yup.
Dec 13 06:04:25 <infinity> And I'm including the time it takes me to type my GPG passhprase 4 times because I suck.
Dec 13 06:04:45 <TheMuso> lol
Dec 13 06:04:54 <lilstevie> I wouldn't mind something like a universal image for arm devices :p
Dec 13 06:05:05 <infinity> lilstevie: Ask again in ~5 years.
Dec 13 06:05:09 <lilstevie> gaga
Dec 13 06:05:11 <lilstevie> haha*
Dec 13 06:05:25 <lilstevie> infinity: just out of curiousity.... why
Dec 13 06:05:34 <TheMuso> The kernel...
Dec 13 06:05:37 <lilstevie> I use the same rootfs image on the SGT7" as I do on the tf
Dec 13 06:05:40 <infinity> lilstevie: No unified boot loaders, and no unified kernels.
Dec 13 06:05:46 <TheMuso> yeah and the bootloader.
Dec 13 06:06:02 <infinity> We have the same userspace on everything, that's a non-issue.
Dec 13 06:06:03 <lilstevie> given how different devices handle the kern and bootloader part, flash-kernel is the only thing that needs to deal with that
Dec 13 06:06:11 <twb> lilstevie: haha, I looked at "SGT" as "StG" and was thinking "a seven inch assault rifle?"
Dec 13 06:06:13 <lilstevie> thats the part I mean
Dec 13 06:06:27 <lilstevie> like the userspace part
Dec 13 06:06:33 <infinity> But bootloaders and kernels are a mess, and until ACPI and/or DeviceTree is everywhere, we're screwed.
Dec 13 06:06:40 <lilstevie> heh
Dec 13 06:06:52 <twb> øw3m
Dec 13 06:06:56 <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?
Dec 13 06:06:57 <infinity> lilstevie: Err.  No, flash-kernel is great post-install, but how do you propose booting the installer?
Dec 13 06:06:59 <twb> Gah, stupid keyboard
Dec 13 06:07:38 <infinity> lilstevie: Until one image can contain one bootload and one kernel that boots everything, a unified image just can't work.
Dec 13 06:07:45 <lilstevie> infinity: well that part would need to be tweaked per device, but a universal rootfs.img sort of thing
Dec 13 06:08:15 <infinity> Well, even that needs to change.
Dec 13 06:08:25 <infinity> You can have a rootfs minus kernel and bootloader (hey, we ship one of those...)
Dec 13 06:08:43 <infinity> But a proper system needs the kernel and bootloader installed to the rootfs so flash-kernel has something to, well, flash.
Dec 13 06:08:49 <infinity> Hence, no longer a universal root.
Dec 13 06:09:53 <twb> infinity: well, you could fiddle-fart around with unioned kernel/ramdisk overlays on the common base rootfs
Dec 13 06:10:02 <twb> infinity: but atm that would be more effort than it's worth
Dec 13 06:10:06 <infinity> Not if you value your sanity.
Dec 13 06:10:29 <infinity> unions and overlays are great as installer tricks, running them in production is pain.
Dec 13 06:10:51 * twb looks shifty
Dec 13 06:10:58 <lilstevie> lol
Dec 13 06:11:11 <twb> I'm not running 600 seats that way, in prisons, oh no
Dec 13 06:11:34 <infinity> :P
Dec 13 06:11:44 <lilstevie> I still think at least one device with it would be good
Dec 13 06:11:48 <lilstevie> like tegra
Dec 13 06:11:48 <twb> But yeah it's a fucking pain, especially since aufs is buggy as at LTS
Dec 13 06:11:49 <infinity> Everyone has their curious use-cases.
Dec 13 06:11:50 <lilstevie> as a start
Dec 13 06:12:03 <infinity> Yup.
Dec 13 06:12:13 <infinity> I intend to unify mx51/mx53 in my spare time too.
Dec 13 06:12:27 <infinity> But that requires two bootloaders and some SERIOUS VOODOO that makes me vomit a little.
Dec 13 06:12:50 <twb> Man, I should've been a lot more impressed back when I got my sheeva and it had u-boot OOTB
Dec 13 06:13:09 <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)
Dec 13 06:13:26 <infinity> You can now cry a little.
Dec 13 06:13:27 <infinity> I did.
Dec 13 06:13:48 <twb> At least these bootloaders dpom "DOS-6 like"
Dec 13 06:14:01 <twb> At least these bootloaders don't claim to be "DOS-6 like" and have a "mouse-based UI"
Dec 13 06:14:17 <twb> Like the bloody EFI servers I've had to deal with lately
Dec 13 06:14:39 <infinity> You can look forward to EFI on ARM systems soon. :P
Dec 13 06:14:44 <lilstevie> infinity: bootloaders are going to be a whore
Dec 13 06:14:52 <twb> infinity: PLEASE tell me you are joking
Dec 13 06:15:07 <lilstevie> twb: no, UEFI is the spec coming to arm
Dec 13 06:15:12 <infinity> twb: About EFI on ARM?  Well, UEFI.  But no, not joking.
Dec 13 06:15:17 <twb> Oh FFS
Dec 13 06:15:26 <lilstevie> the one bootloader to unify them all
Dec 13 06:15:37 <twb> EFI is so bad
Dec 13 06:15:43 <twb> What was wrong with OF
Dec 13 06:15:59 <infinity> Politics.
Dec 13 06:16:02 <twb> You go into the EFI repl and type "if" and it says "sorry, if only valid in batch scripts"
Dec 13 06:16:05 <lilstevie> MS are probably the driving force here, they only need to maintain one bootlaoder
Dec 13 06:16:06 <twb> Stupid crack monkeys...
Dec 13 06:16:27 <twb> EFI was only built because intel couldn't run 16-bit protected BIOSes on their shitty itaniums
Dec 13 06:16:50 <TheMuso> lilstevie: Afaik MS have settled on only one SoC vendor for all their ARM related software.
Dec 13 06:16:54 <twb> And now we're going to end up with thawte-type signing companies for EFI drivers...
Dec 13 06:17:02 <TheMuso> So I don't think uefi would have been a driver, but I could be wrong.
Dec 13 06:17:02 <lilstevie> TheMuso: interesting
Dec 13 06:17:14 <lilstevie> TheMuso: I heard that QC also have an SoC running win8
Dec 13 06:17:22 <twb> TheMuso: could be intel
Dec 13 06:17:24 <TheMuso> Ah right
Dec 13 06:17:39 <TheMuso> twb: Afaik Intel don't even have their XScale license an more.
Dec 13 06:17:49 <lilstevie> TheMuso: no they don't they sold it
Dec 13 06:17:51 <infinity> lilstevie: I would hope Qualcomm is running Win8, or Nokia would be sad pandas.
Dec 13 06:18:00 <lilstevie> infinity: heh
Dec 13 06:18:01 <TheMuso> lilstevie: Yeah thought as much.
Dec 13 06:18:02 <twb> Ah, I couldn't remember who had announced they were making ARM blades now, whether it was AMD or Intel
Dec 13 06:18:24 <infinity> twb: Intel sold XScale to Marvell eons ago and washed their hands of competing against themselves.
Dec 13 06:18:41 <lilstevie> TheMuso: AFAIK it is Tegra3 and QC running win8 so far
Dec 13 06:18:50 <twb> Yeah but like a month ago some mob poppe dup and went "ARM on servers wooo!"
Dec 13 06:18:58 <twb> I think with HP and ARM Inc.
Dec 13 06:19:00 <lilstevie> twb: HP
Dec 13 06:19:15 <twb> Ah, OK.  I assumed there was a semi fab company in there too somewhere
Dec 13 06:19:18 <infinity> twb: HP/Calxeda and *mumbleNDAmumble* other vendors.
Dec 13 06:19:40 <lilstevie> also intel put all their eggs x86 basket
Dec 13 06:21:58 <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.
Dec 13 06:22:05 <infinity> Or they just don't have the cash flow to experiment.
Dec 13 06:22:09 <infinity> The latter seems more likely. :/
Dec 13 06:22:14 <lilstevie> yeah
Dec 13 06:22:26 <lilstevie> and damn it why is q so close to tab
Dec 13 06:22:27 <lilstevie> :/
Dec 13 06:22:32 <TheMuso> heh
Dec 13 06:22:39 <lilstevie> I just cmd+q'd irc
Dec 13 06:22:57 <twb>  Obviously the problem there is you aren't using emacs
Dec 13 06:23:01 <twb> Whree it would be ^X^C
Dec 13 06:23:02 <TheMuso> Yeah an AMD based SoC with a Radeon/similar derrived GPU would be nice.
Dec 13 06:23:14 <TheMuso> derived
Dec 13 06:23:22 <TheMuso> It would possibly mean an open GPU...
Dec 13 06:23:23 <twb> TheMuso: radeon as in r600 or what
Dec 13 06:23:38 <twb> I don't even know what they're up to these days
Dec 13 06:23:53 <twb> My last non-intel GPU was an r200
Dec 13 06:24:01 <lilstevie> TheMuso: in theory arm core + GeForce would be kinda nice too, in the real world though it failed :p
Dec 13 06:24:05 <twb> Which translates to... "radeon 9000" IIRC
Dec 13 06:24:09 <lilstevie> heh
Dec 13 06:24:32 <lilstevie> my last non ATI/AMD GPU was a GeFORCE 5200 or smthn like that
Dec 13 06:25:06 <lilstevie> I vowed never to nvidia again
Dec 13 06:25:06 <twb> At least the intel ones Just Worked without any fucking about
Dec 13 06:25:15 <lilstevie> then I got two tegra devices :p
Dec 13 06:26:14 <lilstevie> hmm
Dec 13 06:26:25 <lilstevie> $600 for an iconia A501 on telstra prepaid
Dec 13 06:26:26 <lilstevie> :p
Dec 13 06:28:23 <TheMuso> How open are the Aconias?
Dec 13 06:28:26 <TheMuso> In terms of flashing.
Dec 13 06:28:31 <lilstevie> less than the tf
Dec 13 06:28:36 <lilstevie> per device SBK
Dec 13 06:28:40 <twb> lilstevie: you can get the HP tablet on ebay for like A$60 I hear
Dec 13 06:29:12 <lilstevie> and Chip UID salted hash of kernel and recovery images
Dec 13 06:29:22 <twb> The downside of the vendor monkeys learning how to actually do crypto properly, is they actually lock us out :-/
Dec 13 06:29:33 <lilstevie> yes
Dec 13 06:29:39 <twb> It'd be nice if the ACCC had a clue
Dec 13 06:29:48 <lilstevie> asus monkeys still haven't figured out crypto
Dec 13 06:30:10 <lilstevie> the signed blobs of the tf201 is just because nvidia offer it as a standard
Dec 13 06:30:19 <twb> So I could write to them and say "please tell h/w vendors to fuck off with their software lock-in"
Dec 13 06:30:37 <twb> get iphones banned in .au and so on
Dec 13 06:30:48 <lilstevie> heh
Dec 13 06:31:00 <lilstevie> we would lose a lot
Dec 13 06:31:08 <TheMuso> Oh lovely re the aconia.
Dec 13 06:31:13 <lilstevie> cause under that definition the xoom is locked too
Dec 13 06:31:19 <lilstevie> even with fastboot oem unlock
Dec 13 06:31:20 <twb> Suits me
Dec 13 06:31:24 <infinity> The problem is that people still view these devices as embedded (when they're not), rather than general-purpose computers (which they are).
Dec 13 06:31:33 <lilstevie> NI adam isn't though :p
Dec 13 06:31:37 <twb> s/embedded/appliances/
Dec 13 06:31:38 <infinity> No one screams about vendor lock-in with the software running on their printer or microwave oven.
Dec 13 06:31:45 <lilstevie> yeah
Dec 13 06:31:48 <twb> infinity: well, I would if it had a browser in it
Dec 13 06:31:55 <lilstevie> these tablets are not embedded really
Dec 13 06:32:01 <TheMuso> Hell no.
Dec 13 06:32:02 <twb> Actually the goddamn MFD does
Dec 13 06:32:03 <lilstevie> they are fully functional computing devices
Dec 13 06:32: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.
Dec 13 06:32:37 <twb> HP printer/mfc here is running linux and wpasupplicant and so on
Dec 13 06:32:38 <TheMuso> s/.///
Dec 13 06:33:07 <lilstevie> I want arm laptops :p
Dec 13 06:33:15 <twb> lilstevie: my gods, yes
Dec 13 06:33:22 <TheMuso> Heh me too. :)
Dec 13 06:33:24 <lilstevie> like an ultrabook
Dec 13 06:33:28 <lilstevie> but with arm
Dec 13 06:33:31 <twb> lilstevie: do you remember back when ASUS demoed a 9" EeePC ARM running ubuntu 9.04 or so ?
Dec 13 06:33:44 <lilstevie> twb: not really
Dec 13 06:33:50 <twb> lilstevie: I was all "FUCK YEAH" and then "OK next month they will come out" for the next three years
Dec 13 06:34:02 <lilstevie> twb: however the tf101 was a last minute switch to android
Dec 13 06:34:21 <lilstevie> I have heard rumour that they initially wanted ubuntu
Dec 13 06:34:23 <twb> It was demoed like a week before Microsoft said "hey ASUS here is a big bag of money please stop shipping linux netbooks"
Dec 13 06:34:26 <lilstevie> and were running 10.10
Dec 13 06:34:45 <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.
Dec 13 06:34:51 <lilstevie> but ofc android won out
Dec 13 06:34:59 <lilstevie> TheMuso: hells yeah
Dec 13 06:35:04 <lilstevie> I use my tf101 as a netbook
Dec 13 06:35:09 <lilstevie> as in a daily use netbook
Dec 13 06:35:13 <twb> TheMuso: especially since the DSP and AES and friends are done elsewhere on the chip
Dec 13 06:35:35 <lilstevie> I browse the web, do a bit of programming
Dec 13 06:35:37 <twb> lilstevie: that's what I bought mine for
Dec 13 06:35:56 <TheMuso> lilstevie: DO you have to do anything funky to get headphones out working when running uboot Ubuntu 2.6.38?
Dec 13 06:36:10 <lilstevie> TheMuso: no
Dec 13 06:36:11 <twb> tf101 = netbook with longer battery life and SSD by default
Dec 13 06:36:11 <TheMuso> I haven't really tried yet, but couldn't get audio working with the ASUS kernel when I tried.
Dec 13 06:36:24 <TheMuso> Ok, will try again.
Dec 13 06:36:40 <lilstevie> TheMuso: it works once oem-config does its magic
Dec 13 06:36:40 <twb> TheMuso: if you go into alsamixer there are about 60 different things to fiddle with
Dec 13 06:36:52 <TheMuso> twb: Yes I know.
Dec 13 06:36:53 <twb> TheMuso: might be one of them is "work without headphones" and is off by default
Dec 13 06:36:55 <lilstevie> also, just saw aldi have an android tablet now too :p
Dec 13 06:37:17 <lilstevie> TheMuso: originally I thought sound was busted, turned out just the media board came unplugged
Dec 13 06:37:31 <TheMuso> ah ok
Dec 13 06:37:55 <lilstevie> aldi tablet, tegra2 running hc 3.2 3G/wifi, 32GB
Dec 13 06:38:03 <lilstevie> 499
Dec 13 06:38:28 <TheMuso> Interesting... I wonder how locked down it is.
Dec 13 06:38:43 <TheMuso> Although for tablets I won't go past the transformer purely because of the dock.
Dec 13 06:38:43 <lilstevie> TheMuso: hahaha that was exactly my first thought
Dec 13 06:38:56 <lilstevie> yeah
Dec 13 06:39:04 <lilstevie> I have a 7" SGT for a tablet
Dec 13 06:39:09 <lilstevie> my tf is a netbook :p
Dec 13 06:39:14 <lilstevie> netbook in tablet clothing
Dec 13 06:39:17 <TheMuso> heh
Dec 13 06:40:01 <lilstevie> and infinity actually I do, I would love to get my hands dirty with my microwaves firmware
Dec 13 06:40:52 <twb> FCC probably won't let you
Dec 13 06:41:02 <twb> despite not having any power in .au
Dec 13 06:41:42 <twb> TheMuso: you know what <coworker> suggested that was clever?
Dec 13 06:41:56 <twb> TheMuso: when the dock is unplugged, speak to it over bt
Dec 13 06:42:46 <TheMuso> twb: Yeah, but you may as well use a general bluetooth KB then. :)
Dec 13 06:43:13 <twb> TheMuso: but it has a battery and such
Dec 13 06:44:16 <lilstevie> well the iconia dock is bt
Dec 13 06:44:16 <twb> home time
Dec 13 06:44:17 <lilstevie> :p
Dec 13 06:44:28 <twb> yabbut not just bt
Dec 13 06:44:31 <twb> only as a fallback
Dec 13 06:55:50 <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?
Dec 13 07:01:27 <lilstevie> TheMuso: thats complicated to explain :)
Dec 13 07:04:03 <TheMuso> ah ok
Dec 13 09:14:04 <infinity> ogra_ / GrueMaster: FWIW, tested precise-desktop-armhf+omap4, and it installed flawlessly.  Yay.
Dec 13 09:14:35 <ogra_> infinity, yeah, i had some people in #ac100 testing the workaround on the old images already
Dec 13 09:14:56 <ogra_> (that channel is usually more active than here)
Dec 13 09:15:04 <infinity> Heh.
Dec 13 09:15:27 <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.
Dec 13 09:15:44 <ogra_> just doing a manual ac100 build, since that ran into the gtk3 out-of-sync-ness
Dec 13 09:15:45 <infinity> So, we're just a few libreoffice porting fixes away from a complete desktop.
Dec 13 09:16:00 <ogra_> yeah
Dec 13 09:16:07 <ogra_> though we dont seed LO
Dec 13 09:16:19 <ogra_> wich makes it non-fatal
Dec 13 09:17:55 <infinity> Oh, so we don't.
Dec 13 09:18:16 <infinity> So, our desktop is actually complete right now?
Dec 13 09:18:18 <infinity> Shiny.
Dec 13 09:18:22 <ogra_> we didnt use to at least :) i must admit i havent a local branch of the precise seeds
Dec 13 09:18:32 <infinity> desktop: * (libreoffice-writer) [i386 amd64 powerpc]
Dec 13 09:18:33 <infinity> Etc.
Dec 13 09:18:35 <infinity> We still don't.
Dec 13 09:18:50 <ogra_> well, we should take care that it works even if we dont seed it
Dec 13 09:18:56 <ogra_> else david will cry :)
Dec 13 09:18:57 * infinity nods.
Dec 13 09:19:08 <infinity> My plan is to make sure everything works. :P
Dec 13 09:19:17 <infinity> But priority is on seeded stuff, for obvious reasons.
Dec 13 09:19:22 <ogra_> i like to see it as part of the desktop .... it just doesnt break our images ;)
Dec 13 10:19:18 * ogra_ gives back vte3 on armel
Dec 13 10:21:13 <lilstevie> libre is the only reason I am not testing hf presice on the tf101
Dec 13 11:05:47 <ogra_> hmm, looking at the alure buildfailure it looks like libmpg123 is missing a shlibs file for armhf
Dec 13 11:08:51 <ogra_> heh, funny ...
Dec 13 11:09:14 <ogra_> the mpg123 source has a ton of identical symbols files for each possible arch
Dec 13 11:11:33 * ogra_ copies armel to hf
Dec 13 11:19:10 <ogra_> i wonder how many other packages are missing symbols files for hrf
Dec 13 11:19:14 <ogra_> *hf
Dec 13 11:31:42 <ogra_> WTF !
Dec 13 11:32:04 * ogra_ shakes his head about debian/alure-dynload-shlibdeps
Dec 13 11:32:12 <ogra_> why the heck cant they just use dpkg
Dec 13 11:32:38 <ogra_> indeed there is no multiarch support at all in that script
Dec 13 11:32:41 <ogra_> oh my
Dec 13 11:44:25 <ogra_> bug 831192
Dec 13 11:44:26 <ubot2> Launchpad bug 831192 in alure "alure version 1.2-1 failed to build in oneiric" [High,Fix released] https://launchpad.net/bugs/831192
Dec 13 11:45:40 <ogra_> hmm, i wonder where that fix went
Dec 13 11:46:45 <ogra_> ah, its there but omits mpg123 multiarch
Dec 13 11:50:39 <LeslieLi> Hi, what is the login name and password of ubuntu for beagleboard?
Dec 13 11:51:49 <ogra_> the one you gave it in the installer
Dec 13 11:53:01 <LeslieLi> ogra_: I built it with setup_sdcard.sh? then insert sdcard to beagle...
Dec 13 11:53:12 <ogra_> no idea what that is
Dec 13 11:53:20 <ogra_> the official ubuntu images run the installer
Dec 13 11:53:35 <ogra_> if you used something else, talk to the author of whatever tool you used
Dec 13 14:15:19 <ogra_> infinity, any idea why i see "WARNING: The following packages cannot be authenticated!" in some of the armhf buildlogs ? that doesnt seem right
Dec 13 15:31:47 <soren> ogra_: We see those on all arches. Always have, I believe.
Dec 13 15:32:06 <ogra_> hmm, yeah, they dont seem to do any harm
Dec 13 15:32:27 <ogra_> i find it still weird since the buildd should run apt-get update before even starting
Dec 13 15:33:01 <soren> ogra_: They do.
Dec 13 15:33:03 <soren> "Authentication warning overridden.
Dec 13 15:33:04 <soren> "
Dec 13 15:33:10 <ogra_> ah
Dec 13 15:33:12 <ogra_> k
Dec 13 15:33:15 <ogra_> thats explains it
Dec 13 16:04:35 <infinity> ogra_: No gnupg in the chroots, we trust our path to ftpmaster.
Dec 13 16:04:43 <infinity> ogra_: (And if we don't, we have big problems)
Dec 13 16:04:46 <ogra_> yeah, understood
Dec 13 16:06:29 <ogra_> fatal error: curl/types.h: No such file or directory
Dec 13 16:06:32 <ogra_> heh, another one
Dec 13 16:07:00 <ogra_> it is funy how many packages still include that ... given that curl upstream claims its unused since 2004
Dec 13 16:07:34 <ogra_> (in thir removal message from 2011)
Dec 13 16:07:35 <ogra_> *their
Dec 13 16:44:23 <doko_> eukleides (1.5.4-1ubuntu2) precise; urgency=low
Dec 13 16:44:23 <doko_>   * add build-dep on libncurses5-dev to fix ftbfs on armhf
Dec 13 16:44:31 <doko_> ogra_, ^^^ no, not just armhf
Dec 13 16:44:55 <ogra_> doko_, well, the upload was specifically to fix this ftbfs ... but yeah
Dec 13 16:45:15 <ogra_> i'm surprised how many packages havent been built since natty
Dec 13 17:45:56 <doko_> jonmasters, are you using arm-linux-gnueabihf as the ARM hf triplet as well?
Dec 13 17:46:34 <infinity> doko_: Last I checked, he was, but he hasn't switched the linker location yet.
Dec 13 17:46:38 <infinity> jonmasters: Confirm/deny?
Dec 13 17:47:38 <doko_> anyway, afk now
Dec 13 19:43:41 <jonmasters> infinity, doko_: we're going to support that triplet but not switch to it yet
Dec 13 19:43:48 <jonmasters> (we'll do symlinking)
Dec 13 19:48:22 <Quintasan> ogra_ ping
Dec 13 20:01:28 <infinity> jonmasters: That won't work for compatibility at all.
Dec 13 20:23:29 <jonmasters> infinity: I realize that only works for stuff built on Ubuntu running on Fedora
Dec 13 20:23:59 <infinity> jonmasters: Not really an ideal situation...
Dec 13 20:24:10 <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 :)
Dec 13 20:24:20 <infinity> jonmasters: Unless the intent is to promote Fedora as a platform to build stuff on that won't work for competitors. ;)
Dec 13 20:24:46 <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.
Dec 13 20:25:07 <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.
Dec 13 20:25:08 * jonmasters needs to get an Ubuntu install going again to track this stuff. I'll make that a todo.
Dec 13 20:26:07 <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
Dec 13 20:26:40 <infinity> I'd just prefer to see it happen somewhere other than Debian/Ubuntu to give weight to our talks (and agreement) at Plumbers.
Dec 13 20:26:48 <infinity> Will make it easier for me to push it down Google's throats, etc.
Dec 13 20:26:49 <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?
Dec 13 20:26:52 <infinity> (Which is on my TODO)
Dec 13 20:27:12 <jonmasters> I'm getting a lot of resistance to multi-arch from our tools group btw :)
Dec 13 20:27:27 <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. ;)
Dec 13 20:27:41 <jonmasters> ok, or the following week?
Dec 13 20:27:54 <infinity> I'd love to see multi-arch all over.  But this isn't m-a, this is just a sane linker location.
Dec 13 20:27:59 <infinity> Where you put your libraries is your business. :)
Dec 13 20:28:30 <infinity> The following week, I'm in Budapest.  So, it's either between the 3rd and 7th, or a week later.
Dec 13 20:29:14 <jonmasters> yea
Dec 13 20:29:29 <jonmasters> I'll get this straightened out
Dec 13 20:32:13 <infinity> jonmasters: For the record, the simple gcc patch we're using is: http://lucifer.0c3.net/~adconrad/arm-dynamic-linker.diff
Dec 13 20:32:48 <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.
Dec 13 20:32:57 <infinity> jonmasters: Unless your sf port is going to live on.
Dec 13 20:37:43 <lborda> hi guys
Dec 13 20:38:11 <lborda> what is the output for uname -a on arm processors running ubuntu?
Dec 13 20:38:55 <infinity> lborda: If you're using uname to determine something in a build process, don't.
Dec 13 20:38:56 <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
Dec 13 20:39:41 <infinity> lborda: uname doesn't tell you anything about the userspace.  Which is probably what you actually care about.
Dec 13 20:39:50 <lborda> i'm developing a bash script and i was looking for something to give the kernel architecture that is currently runnin
Dec 13 20:40:01 <lborda> g
Dec 13 20:40:16 <lborda> something like uname -a | grep -o x86_64
Dec 13 20:40:23 <infinity> Oh.  Then you just want $(uname -m) ... Why reinvent the wheel?
Dec 13 20:40:23 <lborda> any better ideas?
Dec 13 20:40:31 <GrueMaster> lborda: Better to use dpkg --print-architecture.
Dec 13 20:40:44 <infinity> echo "My kernel arch is $(uname -m)"
Dec 13 20:40:55 <infinity> But userspace/debian/package arch is more interesting.
Dec 13 20:40:58 <lborda> infinity: it does not work on cloud images for example
Dec 13 20:41:10 <lborda> hum....
Dec 13 20:41:18 <infinity> So, "My Debian arch is $(dpkg --print-architecture)"
Dec 13 20:41:28 <infinity> lborda: And, err, what?  Why would uname not work on cloud images?
Dec 13 20:42:46 <lborda> it is a bug... it says unknown
Dec 13 20:42:55 <infinity> -m doesn't.
Dec 13 20:42:55 <lborda> for i686 images
Dec 13 20:43:05 <lborda> i386
Dec 13 20:43:07 <lborda> sorry
Dec 13 20:43:27 <infinity> You're looking at -p or -i
Dec 13 20:43:31 <infinity> -m will never print unknown.
Dec 13 20:43:39 <lborda> infinity, let me see...
Dec 13 20:46:09 <lborda> infinity, -m prints the machine hardware name, would that give me always the kernels architecture ?
Dec 13 20:48:11 <lborda> infinity, i think i'm better of using dpkg --print-architecture thank you
Dec 13 20:50:19 <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.
Dec 13 20:51:42 <lborda> GrueMaster, agree thank you!
Dec 13 20:58:55 <infinity> lborda: uname -m is the kernel arch, dpkg --print-architecture is the userspace arch.  Two very different things.
Dec 13 20:59:08 <infinity> lborda: (Say, for instance, running an i386 userspace on an amd64 kernel)
Dec 13 21:00:08 <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).
Dec 13 21:11:36 <lborda> infinity, I see your point, essentially i need to know which kernel is installed so I believe dpkg --print-arch will help me
Dec 13 21:14:13 <infinity> Two differnet things.  Again.
Dec 13 21:37:24 <janimo> ppisati, infinity do you know what SRU version is appropriate for the ac100 kernel oneiric upload that only has the mmap() fix?
Dec 13 21:37:32 <janimo> Latest is 2.6.38-1001.1
Dec 13 21:37:56 <janimo> in oneiric
Dec 13 21:42:36 <infinity> janimo: 1001.2, if it doesn't break ABI.  Or did that version exist in precise?
Dec 13 21:43:03 <infinity> If that version's been used, then 1001.1.0.1 or 1001.1.0.11.10 or some such.
Dec 13 21:43:29 <janimo> we had 1002.1 in precise
Dec 13 21:44:07 <infinity> Right, which was a new ABI.
Dec 13 21:44:15 <infinity> If this doesn't break ABI, then 1001.2 is fine.
Dec 13 21:44:21 <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
Dec 13 21:44:31 <janimo> I think that is quite a change, but not sure if technically ABI change
Dec 13 21:44:43 <infinity> Well, you can build it and use the handy abi-checker to see.
Dec 13 21:45:01 <infinity> Not sure if you noticed, but I turned on ABI checking in the precise ac100 sources.
Dec 13 21:45:15 <infinity> There seemed to be many attempts at disabling it. :P
Dec 13 21:45:40 <janimo> infinity, I was going to ask you about that too :)
Dec 13 21:45:45 <janimo> I noticed you DTRT
Dec 13 21:46:05 <janimo> it was off as that is how _I think_ copied it from jcrigby 's debianization tree
Dec 13 21:46:17 <janimo> so the whole ABI checking did nothing indeed
Dec 13 21:46:58 <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
Dec 13 21:47:14 <janimo> is there some blessed script to automate the whole ABI bump thing?
Dec 13 21:47:34 <janimo> I just made a 3.0.8-0.0 by hand which I doubt is the best idea
Dec 13 22:15:41 <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.
Dec 13 22:16:00 <infinity> janimo: (ie: if you know it's a new ABI and you've bumped the version)
Dec 13 22:16:35 <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?
Dec 13 22:16:56 <janimo> it is still unclear to me which of those abi dirs are to be hand maintained and which created by scripts
Dec 13 22:17:04 <janimo> as the build process creates some
Dec 13 22:17:33 <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
Dec 13 22:17:34 <infinity> The build process creates a current dir.  You want ignore files in that same directory on a fresh ABI.
Dec 13 22:17:57 <infinity> To get the last, you need to use the fetch_abi script (or whatever it's called).
Dec 13 22:18:11 <infinity> It grabs the last binary builds from the archive and extracts the ABI files.
Dec 13 22:18:42 <infinity> If you're doing test-builds anyway, you can cheat and pre-populate.
Dec 13 22:18:43 <janimo> /etc/getabis?
Dec 13 22:18:49 <janimo> never used it, if that's the one
Dec 13 22:18:57 <infinity> But the kernel team tends to just set the first upload as ignored, and then fetch.
Dec 13 22:19:01 <infinity> Yeah, that one.
Dec 13 22:19:13 <janimo> ah ok, so setting ignored once in a while is not that vile
Dec 13 22:19:24 <infinity> Ignored is fine if it's versioned as a new ABI.
Dec 13 22:19:37 <infinity> Ignored is bad and wrong on subsequent uploads of the same ABI (since you might be wrong).
Dec 13 22:20:16 <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
Dec 13 22:20:24 <infinity> Right.
Dec 13 22:20:54 <janimo> thanks. I am weary of asking the kernel team because I almost always came away a bit more confused when asking
Dec 13 22:21:05 <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.
Dec 13 22:21:20 <infinity> (And remove the ignore semaphores)
Dec 13 22:22:33 <infinity> Alternately, do a local build and use the abi output to populate the directories by hand before uploading.
Dec 13 22:22:52 <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).
Dec 13 22:23:23 <janimo> single arch even if we have both armel and armhf, because they are identical for the kernel code?
Dec 13 22:23:28 <infinity> Right.
Dec 13 22:23:47 <infinity> The ABI files in my upload are identical on both.
Dec 13 22:23:52 <infinity> As they should be.
Dec 13 22:23:59 <infinity> If one of them breaks, that's a problem. :P
Dec 14 01:19:42 <twb> lilstevie: any idea what the trick is to make bluetooth work?  Specifically, http://paste.ubuntu.com/769608/
Dec 14 01:22:02 <lilstevie> twb: 1) make sure the bluetooth hcd is in /lib/firmware
Dec 14 01:22:14 <lilstevie> 2) service bsp-tf101 start
Dec 14 01:22:29 <lilstevie> 3) cross your fingers and all extremities that it works properly
Dec 14 01:22:39 <lilstevie> bluetooth is a pita
Dec 14 01:22:50 <lilstevie> and does not always work
Dec 14 01:23:04 <twb> :-(
Dec 14 01:23:33 <lilstevie> oh main thing, make sure BCM4329.hcd is bcm4329.hcd
Dec 14 01:23:56 <lilstevie> reminant of the old method capitalizes it, when it needs to be lower case
Dec 14 01:24:01 <twb> Did that already
Dec 14 01:24:10 <lilstevie> ok
Dec 14 01:24:28 <lilstevie> check if brcm_patchram_plus is running
Dec 14 01:24:40 <twb> bsp-tf101 is configured to start by default, so why wouldn't it have worked already?
Dec 14 01:24:50 <twb> Yes, it's running
Dec 14 01:25:01 <lilstevie> just making sure
Dec 14 01:25:05 <lilstevie> now do you have x?
Dec 14 01:25:12 <twb> atm yes
Dec 14 01:25:31 <twb> but started from xinit, not a dm
Dec 14 01:25:43 <lilstevie> ok look at the bluetooth icon in the systray
Dec 14 01:25:51 <twb> ha ha, systray
Dec 14 01:26:05 <twb> I said I have X not unity :P
Dec 14 01:26:11 <lilstevie> haha :p
Dec 14 01:26:47 <twb> mainly I started X to get keyboard repeat, but it's being funny there too -- which is why I'm trying to get my bt kb working
Dec 14 01:26:54 <lilstevie> ok
Dec 14 01:27:17 <twb> Where "funny" means e.g. I hold Ctrl+p, and it types ^P over and over -- and keeps typing it if I release p, until I also release Ctrl
Dec 14 01:27:45 <lilstevie> well I know I can see the bt stuff from the gnome bluetooth manager
Dec 14 01:27:58 <lilstevie> but I also can from hcitool
Dec 14 01:28:10 <lilstevie> have you rebooted since fixing up the hcd?
Dec 14 01:28:13 <twb> I'll try restarting that bsp thing
Dec 14 01:28:18 <twb> Yeah, definitely restarted since
Dec 14 01:28:23 <lilstevie> that won't really help :/
Dec 14 01:28:33 <lilstevie> brcm_patchram is a pita
Dec 14 01:28:46 <lilstevie> and I haven't fully set the bsp package to handle restarting
Dec 14 01:29:01 <lilstevie> stop the bsp package
Dec 14 01:29:11 <twb> how?
Dec 14 01:29:13 <lilstevie> make sure brcm_patchram is killed
Dec 14 01:29:18 <twb> Righto
Dec 14 01:29:25 <lilstevie> service bsp-tf101 stop?
Dec 14 01:29:27 <twb> You know I could help yo make that an upstart job if you prefer
Dec 14 01:29:45 <lilstevie> it is brcm_patchram actually that is the problem
Dec 14 01:30:01 <lilstevie> brcm_patchram sometimes needs to be forcefully killed
Dec 14 01:30:37 <lilstevie> in fact those times when you shutdown the system, and it never seems to turn off, but just sit there.... thats brcm_patchram
Dec 14 01:30:38 <lilstevie> :p
Dec 14 01:30:49 <twb> Oh I wondered about that
Dec 14 01:30:56 <twb> When it sits as "killing all processes" ?
Dec 14 01:31:07 <lilstevie> yep
Dec 14 01:31:11 <twb> LAME
Dec 14 01:31:13 <lilstevie> thats it refusing to die
Dec 14 01:31:38 <lilstevie> now, once you have successfully killed the process, hopefully a kill -9 will do it
Dec 14 01:31:54 <lilstevie> you need to rfkill block it
Dec 14 01:32:17 <lilstevie> otherwise you can't reclaim the interface
Dec 14 01:32:32 <twb> Why not put the rfkill in the sto rule?
Dec 14 01:33:03 <lilstevie> thats fine, but I am not comfortable doing a -9 kill in the stop rule
Dec 14 01:33:15 <twb> OK, then I will do it locally :P
Dec 14 01:33:16 <lilstevie> and the rfkill must be done after the kill
Dec 14 01:33:24 <twb> after the kill -15 ?
Dec 14 01:33:31 <lilstevie> yes
Dec 14 01:33:31 <twb> That's fucked up
Dec 14 01:33:51 <lilstevie> otherwise the iface goes into some crazy land of fail
Dec 14 01:34:53 <TheMuso> Is this under the 2.6.38 kernel or the android derived kernel?
Dec 14 01:35:04 <lilstevie> both
Dec 14 01:35:19 <lilstevie> 2.6.38 is a little more forgiving
Dec 14 01:35:35 <lilstevie> but brcm_patchram trashes the interface on being killed
Dec 14 01:35:53 <lilstevie> I would like to redesign it to me more daemonish
Dec 14 01:35:54 <lilstevie> :p
Dec 14 01:36:04 <lilstevie> like something that will accept being asked to release
Dec 14 01:36:16 <lilstevie> rather than being shot in the head
Dec 14 01:36:49 <lilstevie> cause the problem is that you shoot brcm_patchram in the head, and leave its initialized interface behind
Dec 14 01:37:06 <lilstevie> brcm_patchram will not reinitialize an interface
Dec 14 01:37:24 <lilstevie> and an initialized interface will not be reinitialized again
Dec 14 01:37:40 <twb> So this is YOUR code?
Dec 14 01:37:44 <lilstevie> no
Dec 14 01:37:46 <twb> Not some crazy closed thing?
Dec 14 01:37:49 <lilstevie> this is broadcomm code
Dec 14 01:37:57 <lilstevie> but open broadcomm code
Dec 14 01:38:01 <twb> Ah, O
Dec 14 01:38:03 <twb> OK
Dec 14 01:38:06 <twb> Goddamn keyboard
Dec 14 01:38:54 <lilstevie> anyway, after killing brcm_patchram softblocking, and unblocking cause the interface to reset because brcm_patchram wasn't there to hold its hand
Dec 14 01:39:12 <twb> btw is rfill supposed to be unblocked when bsp thingo starts?
Dec 14 01:39:24 <lilstevie> should be yes
Dec 14 01:39:32 <twb> OK that is probably why it isn't working for me
Dec 14 01:39:44 <twb> Because whenever I look it's soft blocked, probably because it does that at boot
Dec 14 01:39:52 <lilstevie> hm
Dec 14 01:40:16 <lilstevie> maybe I put the old version of the init.d script in there then
Dec 14 01:40:22 <lilstevie> it should unblock it on boot
Dec 14 01:40:27 <lilstevie> but the old version didn't
Dec 14 01:40:43 <twb> I've trashd your version now so I can't check :P
Dec 14 01:40:48 <lilstevie> oh lol
Dec 14 01:41:11 <lilstevie> well anyway, brcm_patchram requires the interface be unblocked when it is invoked
Dec 14 01:43:41 <twb> Heh, now I have a dozen brcm_patchram_plus's running
Dec 14 01:44:18 <twb> I might also just patch the halt script to ignore if that proc is still running...
Dec 14 02:28:29 <twb> lilstevie: after reboot hcitool scan is working
Dec 14 02:28:44 <twb> lilstevie: I think you shipped the unblock-less version of the script
Dec 14 02:29:48 <lilstevie> oops
Dec 14 02:29:51 <lilstevie> sorry :p
Dec 14 02:30:11 <lilstevie> just so you know, the bluetooth is still very hit and miss
Dec 14 02:31:28 <twb> Understood
Dec 14 02:31:47 <lilstevie> just don't get your hopes up
Dec 14 02:32:00 <lilstevie> I have successfully synced my mouse to the bluetooth a grand total of once
Dec 14 02:32:29 <lilstevie> and used it that is
Dec 14 02:32:41 <lilstevie> I have synced the mouse many times
Dec 14 02:32:55 <lilstevie> only once was it usable
Dec 14 02:33:35 <twb> I'm gonna get a fucked up back if I can't get a kb workin
Dec 14 02:33:47 <twb> Still have my old USB one, might use that
Dec 14 02:33:55 <lilstevie> heh
Dec 14 02:34:02 <twb> s/fucked up/more fucked up/
Dec 14 02:36:08 <lilstevie> lol
Dec 14 02:46:01 <twb> wow bluetooth crashed
Dec 14 02:46:32 <twb> http://paste.ubuntu.com/769642/
Dec 14 02:48:44 <twb> http://paste.ubuntu.com/769644/ is the init script I'm using -- lilstevie do you think I should be blocking/unblocking only one of the two bt devices?
Dec 14 02:50:19 <lilstevie> shouldn't make a difference
Dec 14 02:51:13 <desrt> any word yet about the transformer prime?
Dec 14 02:51:48 <lilstevie> no
Dec 14 02:52:04 <lilstevie> it is not looking good though
Dec 14 02:52:11 <desrt> bootloader locked down?
Dec 14 02:52:20 <lilstevie> http://androidroot.mobi/2011/12/13/thoughts-on-android-tablet-security/
Dec 14 02:52:27 <lilstevie> well we haven't had one in our hands yet
Dec 14 02:52:45 <lilstevie> but the dlupdate shows that this time even the blobs are signed
Dec 14 02:54:29 <desrt> lame.
Dec 14 02:54:38 <desrt> have to wait for a better tegra3 system to come along, i guess
Dec 14 02:56:04 <twb> bluetoothd[4662]: input/server.c:connect_event_cb() Incoming connection from E8:06:88:52:C7:74 on PSM 17
Dec 14 02:56:05 <twb> bluetoothd[4662]: input/server.c:connect_event_cb() Incoming connection from E8:06:88:52:C7:74 on PSM 19
Dec 14 02:56:06 <twb> *** glibc detected *** bluetoothd: free(): invalid next size (fast): 0x2a7e6eb0 ***
Dec 14 02:56:32 <twb> So, uh, bluetoothd is doing a bad free() in oneiric?
Dec 14 02:59:30 <lilstevie> hm
**** ENDING LOGGING AT Wed Dec 14 02:59:57 2011