[02:21] <arinel> is this a good channel to ask about the ARM architecture?
[02:21] <twb> If it's ubuntu-related, sure
[02:22] <twb> If not, maaaybe
[02:22] <arinel> I'll take my chances then. I was wondering if the carry_out from the shifter is fed into the ALU?
[02:23] <arinel> in ARM v1-v5 (or so)
[02:23] <twb> Way above my head
[02:23] <arinel> I can't find a diagram that would show details on this
[02:24] <twb> ##workingset might know of an appropriate channel, also recommend you lurk here
[02:25] <arinel> aha, thx!
[09:19] <doko> infinity, can you see what is wrong with exo?
[09:21] <infinity> doko: Well, the log just looks like bad quoting in variable assignment...
[09:22] <infinity> FOO=bar baz ./quux ; bash: bar: No such file or directory
[09:22] <infinity> Err, "baz: No such"... But you get the idea.
[09:22] <infinity> Should be FOO="bar baz" ./quux
[09:28] <doko> must have been blind ...
[09:32] <ogra_> WOAH !
[09:32] <ogra_> 0 upgraded, 1021 newly installed, 0 to remove and 0 not upgraded.
[09:32] <ogra_> Need to get 325 MB of archives.
[09:32] <ogra_> After this operation, 955 MB of additional disk space will be used.
[09:32] <ogra_> ....
[09:32] <ogra_> thats from apt-get install ubuntu-desktop in my hf chroot !
[09:33] <ogra_> doko, infinity, you guys rock !
[09:33] <ogra_> janimo, can i have an armhf ac100 kernel ? :)
[09:37] <infinity> ppisati: Any progress on ti-omap4 kernels for armhf?
[09:37] <infinity> ogra_: 1021 newly installed?  What was that the build-deps for? :)
[09:37] <ogra_> build deps ?
[09:38] <ogra_> thats just a plain apt-get install ubuntu-desktop
[09:38] <ogra_> no build deps :)
[09:38] <ogra_> on top of -core btw
[09:41] <ogra_> abh, abootimg hasnt been built yet
[09:41] <ogra_> *bah even
[09:42] <infinity> Ahh.
[09:42] <infinity> Can fix.
[09:42] <infinity> Anything else you need?
[09:43] <ogra_> can you trigger a build without uploading a build1 version ?
[09:43] <ogra_> else i'm happy to do that
[09:43] <infinity> There's nothing to trigger, I just had to score it up.
[09:43] <infinity> https://launchpad.net/ubuntu/+source/abootimg/0.6-1/+build/2960109
[09:43] <ogra_> oh, ok
[09:43] <sefokuma> hi, i have a ecafe slim netbook with a A8 freescale i.MX515
[09:44] <infinity> Can I have it?
[09:44] <sefokuma> i'm triying to change OS to Ubuntu from this way https://wiki.ubuntu.com/ARM/MX5/QuickStart
[09:44] <ogra_> infinity, stay with the qiockstart :)
[09:44] <sefokuma> but when i try to boot system dont boot from sd crad
[09:44] <sefokuma> *card
[09:45] <infinity> sefokuma: The uBoot on that card won't boot your system.
[09:45] <infinity> And the kernel may or may not.
[09:45] <ogra_> unlikely that the kernel works, but you should be able to boot with the exiting kernel and bootloader the device ships with
[09:45] <ogra_> you will need to do a bit of fiddling
[09:46] <sefokuma> infinity i select boot from external card with dip switch, i think that netbook must boot from it
[09:46] <sefokuma> if ubuntu armel for MX5 its prepared with uboot bootable... why dont work?
[09:46] <ogra_> sefokuma, the bootloader on the SD wont support that hardware
[09:46] <infinity> ^
[09:46] <sefokuma> ogra_ ok
[09:47] <ogra_> you need to find a u-boot binary that does and replace the one on the SD
[09:47] <ogra_> same goes for the kernel i guess
[09:47] <sefokuma> ogra_ aham ok
[09:47] <ogra_> these images are specifically built for the quickstart board
[09:47] <sefokuma> oh! ok now i understand
[09:47] <ogra_> userspace will work on your device
[09:48] <sefokuma> i will try install image on SD but overwrite uboot and ulinuximage with originals from guillemot
[09:49] <ogra_> right
[09:49] <ppisati> infinity: i'm starting it now
[09:50] <ppisati> janimo: off topic
[09:50] <infinity> ppisati: Awesome.
[09:50] <infinity> ppisati: I uploaded meta that assumes 1401 will build on armhf.  So, now I just need a kernel. ;)
[09:50] <ppisati> janimo: is mosh micolay (whatever is the name/pronunciation) today?
[09:52] <ppisati> janimo: Nicolai Mosh actually
[09:52] <infinity> ppisati: It should just be a question of "for i in `rgrep -l armel *`; do sed -i -e 's/armel/armel armhf/'; done && for i in find . -name \*armel\*; do (I can't be bothered to type a decent automated version of "cp foo-armel foo-armhf"); done
[09:52] <ppisati> infinity: somehow :)
[09:53] <infinity> ppisati: I fact, I can do that right now, if you like, and you can work on newer ABIs and shiny feature merges with 3.2? ;)
[09:54] <ppisati> infinity: i'm doing it manuallu right now
[09:54] <infinity> ppisati: I would have done it already, but I didn't want to step on your toes and make you grumpy if you were half done.
[09:54] <infinity> ppisati: Alright, cool.
[09:54] <infinity> ppisati: Just watch for both "rgrep armel *" and "find . -name \*armel\*"... The file copies was what bit apw when he did it. :P
[09:54] <infinity> (As in, he forgot)
[09:55] <apw> ppisati, very true, you need the d-i bits as well which are in files by arch name
[09:57] <infinity> ogra_: https://launchpad.net/ubuntu/+source/abootimg/0.6-1/+build/2960109/+files/abootimg_0.6-1_armhf.deb
[09:58] <ogra_> yay, thanks !
[09:58] <ogra_> now i just need a kernel
[09:58] <infinity> You have omap.  Break out a Beagle.
[09:58]  * ogra_ would change the existing one himself but i really really dont want to touch git 
[09:58] <infinity> But I can do ac100 on armhf, if you like.
[09:59] <ogra_> well, there is a 3.0 branch ready for testing
[09:59] <infinity> I wasn't going to touch git, I was just going to mangle the packaging and let jani sort it.  Not because I dislike git (I quite like it), but because I suspect I can't merge to whatever branch he's using anyway.
[09:59] <ogra_> i would assume that janimo is already on it and we get armhf with the next upload
[09:59] <infinity> 3.0 would be shiny, but any working kernel is good for now.
[09:59] <infinity> Though it's unsupported anyway, blah blha.
[09:59] <infinity> So.
[09:59] <ogra_> hmm, so you wouldnt touch git either
[09:59] <infinity> Wait for ppisati, and go armhf on your panda? :)
[09:59] <ogra_> then i can do it as well
[10:00] <ogra_> i want to upgrade my ac100 to precise anyway
[10:00] <ogra_> so i can as well try the adventurous cross grade :)
[10:02] <infinity> It won't even remotely work.
[10:02] <infinity> So, like.  Don't try.
[10:02] <ogra_> pfft
[10:02] <infinity> libc-bin makes the world explode.
[10:02] <infinity> Well, I guess you can try.  But be prepared to wipe and reinstall right after. :P
[10:02] <infinity> ogra_: Anyhow.  I'm about to do the ac100 armhf thing.  Unless you really want to.
[10:03] <ogra_> if i unpack -core over my rootfs and then do a simple desktop install ....
[10:03] <ogra_> no. do it if you feel like
[10:04] <infinity> Doing.
[10:04] <infinity> Build needed 45:44:37, 8327584k disk space
[10:04] <infinity> ^-- qt4-x11 on a babbage.
[10:04] <ogra_> nice
[10:04] <infinity> We can't get rid of those things fast enough...
[10:04] <infinity> It takes, like, 13 hours on a Panda.
[10:05] <ogra_> yeah
[10:05] <ogra_> and 10min on a calxeda :)
[10:05] <dmart> Build needed 45:44:37, 8327584k disk space> hah, I remember that.  Pretty painful
[10:06] <apw> ogra_, but do you have one
[10:06] <dmart> 10min> nice
[10:06] <apw> and indeed does anyone
[10:06]  * apw would like one to build kernels on
[10:06] <ogra_> apw, sadly not yet
[10:06] <ogra_> in a year from now though ....
[10:06] <ogra_> *g*
[10:07] <apw> then build time ->infinity right now on one ;/
[10:07] <xranby> yesterday i started a armhf deboostrap... http://paste.ubuntu.com/761449/   for some reason it stalled and have now been stuck for 12h I: Configuring console-setup...
[10:07] <dmart> Sure 1 year + 10 mins ?
[10:07] <xranby> am i the only one hitting this?
[10:07] <infinity> xranby: I've not seen it.
[10:08] <ogra_> xranby, did you mount /proc and /sys ?
[10:08] <ogra_> i had it doing weird things to my host when it configured procps
[10:08] <infinity> The procps madness only happens on upgrade.
[10:08] <infinity> Not on debootstrap.
[10:08] <xranby> ogra_: no i simply crated the precise-hf foler and executed sudo debootstrap --verbose --arch armhf precise /media/dh0/chroot/precise-hf
[10:08] <infinity> xranby: Ctrl-C and try harder? :P
[10:09] <ogra_> oh, right mine was an upgrade
[10:09] <infinity> xranby: Although, I haven't tried a full debootstrap yet.  I'm only using --variant=buildd and --variant=minbase
[10:09] <infinity> xranby: (I'd recommend one of those)
[10:09] <xranby> ok i have now used ctrl-c
[10:09] <xranby> will chroot into it and see if it are usable
[10:09] <infinity> It won't be.
[10:10] <infinity> Just wipe it and use --variant=buildd.
[10:10] <xranby> heh ok
[10:33] <soren> Would Ubuntu work on the new Eee Transformer Prime (including graphics support)?
[10:39] <infinity> soren: Graphics are a big "maybe, but not sure yet".  The bigger issue right now will be locked bootloaders.
[10:39] <infinity> soren: So, uhh.  We'll see.
[10:39] <infinity> soren: But I suspect a number of people will be buying them to make it happen. :P
[10:41] <soren> infinity: What will I need to keep an eye on? Is there a tegra X.org driver where this is likely to land (for the graphics stuff, obviously)?
[10:42] <soren> infinity: ...or is this all kernel-side these days, so keeping an eye on LKML will suffice?
[10:43] <infinity> soren: Oh, we'll probably have non-accelerate video out of the gate.  It's binary drivers that will be iffy.
[10:43] <xranby> infinity:  --variant=buildd = works for me
[10:43] <xranby> thanks
[10:43] <infinity> xranby: Figured it would.
[10:43] <infinity> soren: But, until we get past the bootloader, I make no promises about... Well... Anything. ;)
[10:44] <soren> infinity: Oh, cool. Is there a generic graphics sort of thing for ARM as well (akin to VESA)?
[10:44] <infinity> There are a few framebuffer drivers.
[10:44] <infinity> For some large value of "few".
[10:49] <infinity> ogra_: Running a test-build of linux-ac100...
[10:49] <infinity> ogra_: If it's good, I'll upload before bed.
[10:54] <soren> infinity: Using one of these framebuffer drivers instead of proper accelerated drivers, will that drain the battery with normal use, or only if I try to do a lot of OpenGL stuff, for instance?
[10:55] <infinity> soren: Who knows.  The hardware's still a mystery to me until I have one.
[10:55] <soren> infinity: Alright. I just thought that was the sort of thing you could answer based on past experience. No worries.
[10:56] <infinity> soren: Well, on the Tegra2 netbook I use, I don't use binary drivers, and I get insanely good battery life.  Not sure how useful that data point is, but I imagine Tegra3 stuff will play out similarly.
[10:57] <soren> infinity: Wicked. Thanks.
[11:09] <ogra_> infinity, awesome !
[11:09]  * infinity taps foot.
[11:10] <infinity> My Panda needs some go-faster juice.
[11:51] <ppisati> infinity: i want to do another thing to P/omap4 before i upload, but if you want i can give you an omap4 armhf kernel now
[11:51] <ogra_> ppisati, we need it in the archive
[11:51] <ogra_> to build images
[12:19] <sefokuma> hi again
[12:19] <sefokuma> i have now a ubuntu-core running on my arm
[12:19] <sefokuma> but.. i dont know default password of ubuntu-core fs lol
[12:19] <sefokuma> any idea?
[12:19] <ogra_> there is none
[12:19] <sefokuma> and user¿
[12:19] <ogra_> nor is there a user or any networking config
[12:19] <ogra_> you need to configure that by hand
[12:20] <ogra_> -core is to build images on top of it, not for plain usage
[12:21] <sefokuma> yes i know
[12:21] <sefokuma> but i need first boot and login
[12:21] <sefokuma> to continue making system
[12:21] <ogra_> if you want to use it you need to make a bunch of adjustments before using it (create a user, install the networking bits, configure the system etc
[12:21] <ogra_> (before booting into it)
[12:21] <sefokuma> ok
[12:21] <sefokuma> i was following his steps
[12:22] <sefokuma> https://wiki.ubuntu.com/Core - Deploying Ubuntu Core
[12:22] <ogra_> yeah, thats not complete yet
[12:22] <sefokuma> oh ok
[12:22] <ogra_> we have a task to update the documentation for precise
[12:25] <sefokuma_> sorry coniecction time out
[12:41] <sefokuma> ok works
[12:42] <sefokuma> but im thinking on copy armel MX5 rootfs directly to SD cardroot filesystem
[13:08] <lool> hey folks, does someone know whether someone still cares for the "mobile" packageset?
[13:08] <ogra_> nobody does
[13:08] <ogra_> same for netbook
[13:09] <ogra_> though i'm not sure kubuntu-mobile didnt migrate to just be called mobile
[13:09] <ogra_> better ask them :)
[13:11] <infinity> I'm not sure what mobile is anymore.
[13:11] <infinity> It has xfce stuff in it..
[13:12] <doko> xfce should build now, unless the desktop team hates xfce even more ...
[13:12] <lool> is there a web ui to check packagesets contents and upload permissions?
[13:12] <lool> I figure launchpadlib might expose it
[13:12] <infinity> lool: No idea.  I'm pretty packageset ignorant.
[13:13] <infinity> lool: I know that creating/managing them is still an annying by-hand affair with some voodoo.
[13:17] <Daviey> lool: edit_acl.py
[13:17] <lool> Daviey: I'm not an archive admin
[13:17] <Daviey> lool: neither am i, but you can use it to check who has upload access where
[13:17] <Daviey> and packageset contents
[13:18] <lool> Daviey: where is it?
[13:19] <lool> oh wow, lp:ubuntu-archive-tools is public and I never used it
[13:19] <Daviey> $ edit_acl.py -P mobile -S precise query
[13:19] <lool> worked fine, thanks
[13:20] <Daviey> groovy
[13:20] <infinity> hildon and xfce and other bits.
[13:20] <infinity> That's so painfully obsolete.
[13:20] <ogra_> kill it !
[13:21] <lool> it seems we don't have a process for removing sources from packagesets
[13:21] <lool> I mean binaries from packagesets when we remove sources
[13:21] <ogra_> but you should be able to remove the whole packageset
[13:21] <ogra_> which in this case would be proper
[13:22] <infinity> lool: Eh?  Binaries aren't in packagesets.
[13:22] <infinity> lool: Package set define archive rights, it's source-level ganularity.
[13:22] <lool> ah right
[13:23] <lool> indeed these are used for source upload rights
[13:27] <lool> Ok; going to lie down a bit, I feel too sick
[13:56] <infinity> top - 13:55:57 up  7:18,  0 users,  load average: 12.08, 10.66, 9.29
[13:56] <infinity> And they said the Panda wasn't server hardware...
[14:02] <ogra_> ha ha
[14:03] <Daviey> infinity: did you do mdad raid via partitions on a single sdcard?
[14:03] <Daviey> redundancy++
[15:04] <S0NiC> hi
[15:05] <S0NiC> can anyone help me to change some values for this tutorial https://wiki.ubuntu.com/ARM/BuildEABIChroot? because http://ports.ubuntu.com/ubuntu-ports/dists/karmic/Release doesnt exist
[15:13] <ogra_> S0NiC, that howto i sreally really outdated
[15:14] <ogra_> S0NiC, if you feel like, please delete it ....
[15:15] <ogra_> (else we will delete it along woth the rootfs from scratch page etc)
[15:15] <ogra_> *with
[15:21] <S0NiC> ogra_ can you tell me another howto?
[15:22] <ogra_> not yet, we will rework all this with the switch to live-build
[15:22] <ogra_> currently the existing howtos refer to obsolete tools adn the new tools arent properly documented yet
[15:22] <S0NiC> hmm shit i have to crosscompile a programm for amr7
[15:23] <ogra_> as for building a chroot, install qemu-user-static, run qemu-debootstrap
[15:23] <S0NiC> mom
[15:23] <ogra_> that will create an arm chroot on an x86 machine
[15:23] <ogra_> at least on systems newer than lucid
[15:24] <ogra_> for lucid ask in #linaro for the lucid PPA of qemu
[15:24] <S0NiC> i am useing maverick
[15:24] <S0NiC> -.e
[15:24] <ogra_> might be ok ...
[15:24] <S0NiC> have i to specifiy a target-arch=
[15:25] <S0NiC> http://nopaste.info/cae429e70f.html
[15:25] <S0NiC> because i get this error?
[15:25] <ogra_> i think aemu-debootstrap defaults to armel ... if not, the same options debootstrap uses apply
[15:25] <ogra_> *qemu
[15:26] <ogra_> yeah, try --arch armel
[15:26] <ogra_> beyond that, all other debootstrap options apply
[15:28] <S0NiC> ogra_ i tried... http://nopaste.info/4493dfff57.html but doesnt work ;(
[15:29] <ogra_> well, it tells you what you are missing
[15:29] <ogra_> just follow the suggestion the "usage" line gives you
[15:30] <ogra_> suite is the release name i.e. oneiric, maverick etc ...
[15:30] <ogra_> target is the dir relative to the dir you run the command in
[15:33]  * ogra_ hugs infinity 
[15:33] <ogra_> so tomorrow is the image day :)
[15:34] <ogra_> ndec, before end of the week we should have armhf images for panda, beagle and ac100 ...
[15:35] <ndec> ogra_: hey! cool.
[15:35] <ogra_> ndec, an armhf  recompiled gles driver for panda would rock soooo hard :)
[15:40] <S0NiC> sorry i was away
[15:43] <S0NiC> ogra_ now it works. thanks
[15:43] <ogra_> :)
[15:44] <ogra_> S0NiC, does your project have heavy dependencies ? else you could just use the cross compiler
[15:44] <S0NiC> ogra_ i have a question for my understanding: if its finished i change to the directory and can compile there my program?
[15:44] <S0NiC> what do you mean by heavy depndencies?
[15:44] <ogra_> you can run: sudo chroot <path to your target dir>
[15:45] <ogra_> that will switch your filesystem root to the chroot
[15:45] <ogra_> well, libraries etc
[15:45] <S0NiC> ogra_ iam new to this ;D thanks, i read this already
[15:45] <S0NiC> i try to compile a qtwebkit program
[15:45] <S0NiC> i think, thats heavy? ;)
[15:45] <ogra_> ah, k, then the chroot approach is probably better
[15:46] <S0NiC> i did some tries but the conclusion was not soooooooooo good ;)
[15:46] <ogra_> if it would have been a cmdline thing that only needs libc that would be lightweight enough to not use a chroot
[15:47] <S0NiC> e.g. with make i can compile my program on my target (pandaboard) and on my desktop machine. i tried it with g++ and it doesnt work (its a little c++ program)
[15:47] <S0NiC> i see thx
[15:48] <ndec> ogra_: are armel PPA building for armhf by default as well?
[15:48] <ogra_> ndec, not yet
[15:48] <ogra_> all that armhf stuff went way faster than expected (after massive probs in the bringup phase we're suddenly far ahead of the plan)
[15:49] <ogra_> ndec, but whats there should be enough to re-roll the binary blob in preparation
[15:49] <ogra_> i'll take care for PPAs soon
[15:50] <ogra_> (i hope we can just make them dual build for both arm arches and be done)
[15:50] <S0NiC> ogra_ wow that needs a lot of time... to build the chroot
[15:50] <ogra_> S0NiC, well, it downloads all packages from the archive
[15:50] <S0NiC> yes
[15:50] <ogra_> then it unpacks them without using dpkg ...
[15:51] <ogra_> and then it configures them by running the maintainer scripts ... in a qemu chroot each process is wrapped by a qemu call ...
[15:51] <ogra_> so while thats a lot faster than running an actual qemu machine, its indeed a lot slower than if you would build an x86 chroot
[15:51] <S0NiC> sounds deep in the system ;D
[15:52] <ogra_> it is deep in the system ... actually on kernel level (for the wrapping of the processes)
[15:53] <S0NiC> okay finished no i try to chroot
[15:53] <S0NiC> okay i chrooted an now i can try to compile my program ?
[15:54] <ogra_> you will want to install some bits to actually be able to compile
[15:54] <infinity> ogra_: "dual build for both arches"?
[15:54] <ogra_> a chroot like this is a virgin system
[15:54] <ogra_> infinity, armel and armhf
[15:54] <ogra_> in two runs
[15:54] <ogra_> would that be very complex ?
[15:54] <infinity> ogra_: Yeah, I didn't quite get what you were driving at, though.
[15:54] <S0NiC> orga tahn apt-get updaten and so on?
[15:54] <infinity> ogra_: PPAs get armel and armhf build records.  Just like every other arch.
[15:54] <ogra_> S0NiC, apt-get update; apt-get install build-essential
[15:55] <ogra_> that should get you the very basics
[15:55] <S0NiC> ah thanks
[15:55] <ogra_> infinity, well, the armel ones are currently limited (artificailly i think) to build armel only
[15:55] <infinity> ogra_: Not entirely true.
[15:55] <ogra_> S0NiC, and then indeed the -dev packages for the libs your app needs
[15:55] <infinity> ogra_: There's been plenty of armhf PPA activite.
[15:55] <ogra_> infinity, ah, cool, i didnt know
[15:56] <S0NiC> orga thanks
[15:56] <infinity> ogra_: It's only the "virtual" ones that have that strange limitation (and they're not actuall virtual, obviously)
[15:56] <infinity> ogra_: It's... Messy.
[15:56] <ogra_> infinity, well, we need to enable ndec's PPA for hf then so he can build us the shiny for panda :)
[15:57] <infinity> Which team/ppa is that again?
[15:57] <ogra_> that has a physical builder attached
[15:57] <ogra_> TI
[15:57] <S0NiC> ogra_ sorry for interrupt your conversation but i get an E: Unable to locate package build-essential
[15:57] <infinity> ogra_: That was remarkably unhelpful.
[15:57] <ogra_> ti-omap-dev is teh team iirc
[15:57] <infinity> 404.
[15:57] <infinity> I'm thinking not. ;)
[15:57] <ogra_> S0NiC, hmm, did you apt-get update ?
[15:58]  * infinity asks his panda.
[15:58] <S0NiC> yes
[15:58] <S0NiC> nopaste.info/e869c03242.html
[16:00] <infinity> ogra_: Oh, I can't tell from looking at it what kind of PPA it is.  But it might just magically get armhf build records on the next upload.  Dunno.
[16:02] <infinity> ogra_: Oh, I can't tell from looking at it what kind of PPA it is.  But it might just magically get armhf build records on the next upload.  Dunno.
[16:03] <ogra_> infinity, https://launchpad.net/~tiomap-dev/+archive/release
[16:03]  * ogra_ had a crash here 
[16:03] <ogra_> chromium actung up usually leads to OOM at some point
[16:04] <ogra_> i'll better buy a bucket to stop the leaking
[16:04] <ogra_> *acting
[16:04] <infinity> Or open fewer tabs.
[16:04] <S0NiC> ogra_ i have to leave now, it possible to talk later to you=?
[16:04] <ogra_> luckily i dont use a laptop ... so it doesnt leak on my lap ...
[16:04] <ogra_> a netbook must leak to the net, right ?
[16:06] <S0NiC> cu guys and thanks for the help
[16:06] <ogra_> ciao
[16:50] <doko> infinity, can you apply the mmap patch to the ac100 image too?
[16:50] <ogra_> doko, i guess thats rather a task for janimo
[16:51] <ogra_> (he maintains the git tree)
[16:51] <doko> ok
[16:51] <infinity> doko: Yeah, I was just enabling armhf in the packaging, jani's working on 3.x source mangling.
[16:51] <ogra_> and he doesnt seem around today
[16:51] <ogra_> (probably a holiday in romania)
[16:51] <infinity> I believe someone said it was, yeah.
[16:52] <infinity> Anyhow..
[16:52] <infinity> ogra_: You have an ac100 kernel.
[16:52] <ogra_> done already ?
[16:52] <ogra_> geez, these pandas are so fast
[16:52] <infinity> ogra_: Can't make images with it yet, cause I can't publish it until the librarian is recovered. :P
[16:52] <infinity> ogra_: But you can download it from LP and install it locally and such.
[16:52] <ogra_> right, i plan to roll manual builds tomorrow
[16:53] <ogra_> and will then test the full image
[16:53] <infinity> Builds should Just Work.
[16:53] <infinity> Unless I screwed up. ;)
[16:53] <ogra_> sure
[16:53] <infinity> But what are the odds, right?
[16:53] <ogra_> else i'll fix them
[16:54] <ogra_> if they all work fine i wonder how to make them autobuild ... i fear we are getting to a point where a full set of images will take 24h :)
[16:54] <ogra_> i guess we should just do some selected areches for the start
[16:54] <ogra_> ac100 and omap4 or so
[16:55] <infinity> Well, it's on a different machine.
[16:55] <ogra_> sure sure
[16:55] <infinity> And post-processing doesn't take long at all.
[16:55] <Xase> How do I mount the preinstalled image again to replace the kernel, i cant seem to find it on the wiki.
[16:55] <ogra_> Xase, just re-plug the card after writing it
[16:55] <infinity> I bet all 4 flavours on armhf will build in about the same time as they do on armel over two buildds.
[16:55] <ogra_> right
[16:56] <Xase> Oh lol..
[16:56] <ogra_> thats 4h per build and flavour
[16:56] <Xase> Never thought about tbhat
[16:56] <Xase> it's not even dd'd yet
[16:56] <Xase> klol
[16:56] <Xase> brb
[16:56] <ogra_> so 8h for two flavours of the same subarch
[16:56] <infinity> ogra_: Yes, but arches build in parallel.
[16:56] <ogra_> 16 for 4 etc etc
[16:56] <infinity> ogra_: My point is that armhf should be about the same speed as armel, so adding it slows nothing down.
[16:56] <ogra_> it fuills the few time gaps we have öeft
[16:57] <ogra_> *left
[16:57] <infinity> ...?
[16:57] <infinity> What?
[16:57] <infinity> Parallel.
[16:57] <infinity> Same time.
[16:57] <aquadran> hi, i'm sure it's good place to ask here. i have issue with hdmi audio working on pandabaord with ubuntu 11.10. analog audio works. for hdmi i get 0,5 sec proper sound then it cut and nothing and only some low clicks. worked fine on 10.10
[16:57] <ogra_> you can only build two in paralell
[16:57] <infinity> What are you talking about? :)
[16:57] <ogra_> omap4 is always built on the same builder
[16:57] <infinity> armel+omap4 is.
[16:57] <ogra_> we build at least four flavours of omap4 images atm
[16:57] <infinity> armhf+omap4 is another machine.
[16:58] <ogra_> we have new live builders ?!?
[16:58] <infinity> Adding armhf slows nothing.
[16:58] <infinity> Yes...
[16:58] <aquadran> is there know issue for hdmi audio, i know for some it works fine
[16:58] <ogra_> OH !
[16:58] <infinity> Lamont and I have been debugging the armhf builder for the last two days. :P
[16:58]  * ogra_ humps infinity's leg
[16:58] <ogra_> i DIDNT KNOW !
[16:58] <ogra_> whoops
[16:59] <ogra_> i would say disregard the caps but they somehow feel appropriate :)
[17:00] <lilstevie> haha
[17:05] <GrueMaster> Erm, ogra_, infinity.  Kernel panic with the omap armhf netinstall kernel.
[17:06] <ogra_> :(
[17:06] <ogra_> when ? did you get to any console or directly on boot
[17:07] <infinity> GrueMaster: Output of the panic would be nice.
[17:07] <GrueMaster> Working on it now.
[17:07] <infinity> GrueMaster: To see if it's the kernel's fault, or a userspace fuckup.
[17:08] <ogra_> or the bootloader probably :)
[17:08] <ogra_> on omap you never know
[17:08] <infinity> My bet's on userspace (well, the initramfs), but I'm blindly guessing. ;)
[17:08] <infinity> I haven't actually done a by-hand install yet.
[17:08] <ogra_> thats why i asked about console :)
[17:09] <infinity> I guess with the ti-omap4 kernel rolling, I can replace armel on my Panda with armhf.
[17:09] <ogra_> yeah
[17:09] <ogra_> how do we go forward btw
[17:09] <ogra_> do we concentrate all efforts on armhf and leave el be el ?
[17:10] <ogra_> given the state of it i would actually be in favour of that
[17:10] <GrueMaster> Hmmm.  Not finding init.
[17:10] <ogra_> OTOH, if we find a hard blocker we might be screwed
[17:11] <GrueMaster> http://paste.ubuntu.com/761820/
[17:11] <infinity> ogra_: I don't see why they're mutually exclusive.  99% of the work I've done for armhf was duplicating armel.
[17:12] <Xase> will renaming uInitrd to uRamdisk be the same thing or is it different?
[17:12] <infinity> ogra_: In rare cases, you need an entry for each in a rules file or something (a package that cares about float-abi), but that's 5 seconds of your time.
[17:12] <ogra_> well, i wouldnt like to duplicate testing efforts etc
[17:12] <infinity> ogra_: For testing efforts, that's tougher, I agree.
[17:12] <Xase> Because the u-boot on the nook color looks for uRamdisk
[17:12] <GrueMaster> Xase: ???
[17:12] <Xase> not uInitrd
[17:12] <GrueMaster> Ah.  Should
[17:12] <infinity> ogra_: Testing effectively 8 arches instead of 4 is daunting.
[17:12] <rcn-ee> GrueMaster, i'm seeing that same with Debian Sid armhf with mainline.. ;)
[17:12] <ogra_> infinity, plus the work janimo does on live images :) thats one more
[17:12] <GrueMaster> rcn-ee: ouch.
[17:13] <ogra_> and likely really slow
[17:14] <infinity> GrueMaster: Okay, I'll replace armel with armhf on my Panda today and figure out WTF that's all about.
[17:14] <GrueMaster> ogra_: I thought the live images were manually built for the moment.
[17:14] <infinity> GrueMaster: It's almost certainly userspace.
[17:14] <ogra_> GrueMaster, yes, currently
[17:15] <ogra_> infinity, i'm not sure
[17:15] <GrueMaster> As to image testing, I am working hard to get a lot of it automated.  All the headless testing should be automated by EOY.  That leave me with desktop to manually muck about.
[17:15] <infinity> ogra_: I did say "almost".
[17:15] <ogra_> "Trying to unpack rootfs image as initramfs..."
[17:15] <Xase> Lessee if udev crashes like crazy this time.
[17:15] <ogra_> thats usually the line before "freeing init memory"
[17:15] <GrueMaster> Although I will be short non-omap4 platforms for automated installs.
[17:15] <ogra_> i dotn see it in tobins paste
[17:16] <Xase> Nope... it seems to be working :D
[17:16] <Xase> YAY
[17:16] <Xase> Mouse
[17:16] <Xase> ubuntu on Nook Color with a mouse :p
[17:16] <ogra_> GrueMaster, well, omap4 should soon be netinstallable on hf too
[17:16] <Xase> Nothing else so far =/
[17:16] <Xase> Probably something else broke...
[17:16] <GrueMaster> Or equally broken.  :P
[17:17] <infinity> GrueMaster: Does current omap netinstall work on armel?
[17:17] <infinity> GrueMaster: Cause the kernel's identical.
[17:17] <Xase> but if it got past the kernel loading, I should now be able to retrieve some sort of log from the SDCard right?
[17:17] <Xase> Oh wait
[17:17] <GrueMaster> I wonder if the switch to no initrd has anything to do with this breakage?
[17:17] <Xase> Its still doing its thing
[17:17] <ogra_> Trying to unpack rootfs image as initramfs...
[17:17] <infinity> GrueMaster: That should be the nail in the coffin.
[17:17] <ogra_> hmm
[17:17] <Xase> Guest Session login ;)
[17:17] <GrueMaster> Will try armel.
[17:17] <ogra_> no error though
[17:17] <Xase> Hmmm. Ghetto. The touchscreen is nil working
[17:17] <GrueMaster> Xase: You have an ubuntu image on nook color????  COOL!!!
[17:18] <GrueMaster> Well, aside from touch.
[17:18] <Xase> Yeah, it needs cypress truetouch...
[17:18] <Xase> Hmm
[17:18] <Xase> I'm using Dalingrin CM sources plus some patches from a  mer developer.
[17:18] <Xase> But mer dies while loading udev.
[17:19] <Xase> Figured it'd continue on the Ubuntu image
[17:19] <Xase> Because the suspect in the Mer case is bad dding
[17:19] <Xase> However now it's time to see if I can recompile with TrueTouch in menuconfig :D
[17:19] <ogra_> GrueMaster, "switch to no initrd" ? do you refer to my spec ? nothing has been done for that yet
[17:20] <ogra_> so no worries
[17:20] <Xase> make ARCH=arm menuconfig right?
[17:20] <ogra_> i guess apw will explicitly tell us if he (potentially) breaks the world
[17:20] <GrueMaster> Ok, something broken on the hf image.  I'm in netinstall on armel on omap.
[17:21] <ogra_> k
[17:21] <ogra_> lets wait for omap4
[17:21] <ogra_> and see if thats omap3 specific
[17:21] <Xase> GrueMaster: the ubuntu image doesn't seem to see battery... something having to do with Kernel?
[17:21] <ogra_> rcn-ee, you dont happen to know a workaround ?
[17:22] <apw> GrueMaster, odd indeed as the armel and armhf should basically be the same bits
[17:22] <GrueMaster> Xase: Possibly.  Not sure, since I haven't had time to muck about on my NC.
[17:22] <Xase> also I  need SGX530, can I chroot into the ARM image from my machine and apt-get install that way?
[17:22] <ogra_> apw, well, compiled differently
[17:22] <ogra_> (theoretically that shouldnt have any impact indeed .... theoretically ...)
[17:22] <apw> ogra_, well not really the only change is the float interfaces, and they kernel doesn't use float ever
[17:22] <rcn-ee> ogra_, nope, debugging it too right now..  what's weird, it worked fine with the "debian unstable armhf" (sep time frame) repo's.. so something changed between that timeframe and the current sid repo.
[17:23] <ogra_> yeah
[17:23] <apw> kernel normally panics if you do use float as the fpu isn't available
[17:23] <ogra_> well, it doesnt seem to be the kernel
[17:23] <ogra_> and by the looks of it even the initrd is fine
[17:24] <apw> ogra_, well that is something at least
[17:24] <ogra_> it just chokes on "no init found"
[17:24] <apw> hmmm ... maybe we have no upstart
[17:24] <Xase> Hrmmm...
[17:25] <rcn-ee> GrueMaster, if it helps, my old armhf image is still available: http://elinux.org/BeagleBoardDebian#armhf_Demo_Image
[17:25] <Xase> Truetouch is enabled in my kernel already...
[17:25] <Xase> but I'm getting no response from the screen.
[17:25] <ogra_> i dont think d-i uses upstart
[17:25] <ogra_> (unless it has been ported recently)
[17:26] <apw> oh alternative cds are they, i was assuming live
[17:26] <ogra_> netinstall
[17:26] <ogra_> easiest to test :)
[17:27] <apw> could be a heap of things, do you have the network drivers in your initrd for instance
[17:27] <ogra_> it loads all fine, see the paste of the dmesg output
[17:27] <GrueMaster> What (if any) config changes to the kernel are in the armhf rev?
[17:27] <ogra_> GrueMaster, none
[17:27] <GrueMaster> apw: See my pastebin.
[17:27] <ogra_> its just a rebuilds for armhf
[17:28] <ogra_> *rebuild
[17:28] <apw> its configuration is identicle between armel and armhf
[17:28] <infinity> The kernels should be almost literally identical.
[17:28] <GrueMaster> ok
[17:28] <infinity> I'm sure the issue is userspace.
[17:28] <ogra_> probably d-i's init uses floating point :P
[17:28] <infinity> No.
[17:28] <ogra_> yeah, i know
[17:29] <infinity> My bet's on initramfs-tools, and possibly the interpreter not landing in the initramfs.
[17:29] <ogra_> well, lets see how desktop images behave tomorrow, could as well be a d-i issue
[17:29] <infinity> I haven't actually built an initramfs on armhf yet.
[17:29] <ogra_> d-i doesnt use initramfs-tools, does it ?
[17:30] <GrueMaster> I think it does.
[17:30]  * ogra_ thought it uses cpio and whatever compressor directly 
[17:31] <ogra_> as it doesnt use upstarts init
[17:31] <infinity> It might do.
[17:31] <ogra_> so i would rather like to wait until we have desktop images and compare with that
[17:32] <GrueMaster> We have core, right?  I could muck something together that way.
[17:32] <infinity> 	initramfs) \
[17:32] <infinity> 		  (cd ./tmp/omap_netboot/tree && find . | cpio --quiet -o -H newc) >  ./tmp/omap_netboot/initrd; \
[17:32] <infinity> 		gzip -v9f ./tmp/omap_netboot/initrd; \
[17:32] <ogra_> yeah
[17:32] <infinity> So, how it's populating that will be interesting.
[17:32] <ogra_> from udebs indeed
[17:33] <ogra_> intresting would also be what init it uses
[17:33] <infinity> My bet's still on the linker.
[17:33] <GrueMaster> Could it be busybox?  How do I differentiate between armel and armhf versions?
[17:33] <infinity> Let me tear apar this initrd.
[17:34] <ogra_> hmm. good question, the file command doesnt know the difference
[17:34] <ogra_> at least not with std output
[17:35] <infinity> adconrad@cthulhu:~/ung$ cat initrd | cpio -t | grep ld-linux
[17:35] <infinity> lib/ld-linux.so.3
[17:35] <infinity> And that's the problem.
[17:35] <infinity> I figured.
[17:36] <infinity> Now to see if that's the udeb's fault, or d-i's build process.
[17:36] <GrueMaster> diff initrd/bin/busybox busybox/usr/lib/initramfs-tools/bin/busybox
[17:36] <GrueMaster> Binary files initrd/bin/busybox and busybox/usr/lib/initramfs-tools/bin/busybox differ
[17:36] <infinity> GrueMaster: Of course they differ.
[17:36] <ogra_> indeed
[17:36] <infinity> GrueMaster: But the problem is above.
[17:36] <infinity> Linker in the wrong place.
[17:37] <GrueMaster> Where should it be?
[17:38] <infinity>  /lib/arm-linux-gnueabihf/ld-linux.so.3
[17:38] <GrueMaster> in the initrd?
[17:38] <GrueMaster> Seems odd.
[17:38] <infinity> Yes.
[17:38] <infinity> And it's my fault.
[17:39] <infinity> The udeb has it in the wrong location.
[17:39] <GrueMaster> Ok.
[17:39] <infinity> eglibc upload incoming. :/
[17:39]  * GrueMaster points blame.
[17:39] <GrueMaster> :P
[17:39] <GrueMaster> In the meantime, I'll reassemble this and tally forth.
[17:39] <ogra_> awesome, that means desktop images wont be affected :D
[17:40] <infinity> Can you manually mangle the initrd to move ld-2.13.so and ls-linux.so.3 to that path?
[17:40] <ogra_> why not
[17:40] <ogra_> you can cat cpio archives together, the one you append acts like an overlay
[17:40] <infinity> I meant to be asking GrueMaster to try that. :P
[17:41] <infinity> Not asking if it was possible.
[17:41] <GrueMaster> I have a couple of scripts for exploding and reassembling initrd.img
[17:41] <infinity> GrueMaster: If you can move those two files (and make sure the symlink still resolves), and try again?
[17:41] <ogra_> so just pull both files out, roll a cpio archive witgh them in the right place, and just cat it at the end of the existing cpio initrd ... then compress it again
[17:42] <GrueMaster> ogra_: Don't over-complicate things.
[17:42] <ogra_> GrueMaster, huh ?
[17:42] <GrueMaster> Easier for me to reroll with my existing scripts.
[17:42] <Xase> So... I have my touch driver enabled in kernel... however, I don't know how to get xorg to use it.
[17:42] <ogra_> thats way faster than unpacking everything and re-rolling the whole thing
[17:43] <GrueMaster> ogra_: On a Core2Quad running at 3ghz?  Speed is not the issue.
[17:43] <ogra_> k
[17:43] <GrueMaster> (actually takes longer for this discussion).
[17:44] <GrueMaster> infinity: Not seeing ld-2.13.so.
[17:44] <ogra_> grab it from a -core image ?
[17:44] <infinity> GrueMaster: It's in lib...
[17:44] <infinity> GrueMaster: I see it here.
[17:44] <infinity> Oh.
[17:44] <infinity> No.
[17:44] <infinity> I'm looking at the udeb.
[17:45] <ogra_> IT SHOUDL ALSO BE IN /LIB/TRIPLET/
[17:45] <ogra_> argh
[17:45] <ogra_> sorry
[17:45] <GrueMaster> No /lib/triplet directory.
[17:45] <infinity> Yeah, nevermind.  d-i canonicalises the paths, so no ld-2.13.so
[17:45] <ogra_> lib/arm-blah-foo-bar
[17:45] <infinity> ld-linux.so.3 is a real file, not a symlink.
[17:45] <infinity> So just move that.
[17:45] <Xase> Bah.
[17:45] <infinity> GrueMaster: You have to create the directory, it's not there. :P
[17:46] <infinity> GrueMaster: /lib/arm-linux-gnueabihf/ld-linux.so.3 is where that one file needs to live.
[17:46] <ogra_> GrueMaster, lib/arm-linux-gnueabihf/ that is :)
[17:46] <GrueMaster> I know that part.  I was just looking for the other file.
[17:46] <infinity> Yeah, the other file isn't on the initrd.
[17:47] <infinity> On a real system, ld-linux.so.3 is a symlink to ld-2.13.so, in the initrd, ld-linux.so.3 *is* ld-2.13.so.
[17:47] <GrueMaster> Had me worried.  find was returning nothing in the initrd.
[17:47] <GrueMaster> Thought this was horribly broken.
[17:48] <infinity> Also, glibc's udeb building is making my eyes cross.
[17:48] <GrueMaster> ogra_: time pack-initrd initrd.img initrd
[17:48] <GrueMaster> real    0m1.341s
[17:48] <GrueMaster> user    0m1.340s
[17:48] <GrueMaster> sys     0m0.076s
[17:48] <GrueMaster> Just fyi.
[17:49] <ogra_> yeah yeaqh
[17:50] <GrueMaster> :P
[17:50] <ogra_> :)
[17:51] <GrueMaster> Much better.
[17:51] <ogra_> boots through `
[17:51] <ogra_> ?`
[17:51] <GrueMaster> I'm in the installer.
[17:51] <ogra_> yay
[17:51] <infinity> \o/
[17:52]  * ogra_ goes afk for an hour or so
[17:53] <GrueMaster> grrrr.
[17:54] <GrueMaster> I'm being hit by bug 838200 (not an armhf issue).
[17:54] <ubot2> Launchpad bug 838200 in u-boot-linaro "No network support on Beagle XM" [High,Confirmed] https://launchpad.net/bugs/838200
[17:55] <GrueMaster> Ok, moving forward again.
[17:55] <Xase> o.o
[17:56] <GrueMaster> Yea.  seems to only affect me, as I have a rev B beagleXM.  Rest of the world is on rev C.
[18:06] <GrueMaster> Hrm.  "No installable kernel was found in the defined APT sources."  Might need to fix this in d-i.
[18:06]  * GrueMaster can preseed around it for now.
[18:06] <infinity> That sounds like an oops.
[18:07] <GrueMaster> I think d-i has hardcoded arches.
[18:10] <infinity> It does.
[18:10] <infinity> I suspect Colin just missed a spot or something.
[18:10]  * GrueMaster facepalms
[18:11] <infinity> Let me guess, it's using archive instead of ports?
[18:11] <GrueMaster> No, actually it is using my local mirror.
[18:12] <GrueMaster> But it is updated every 2h, so that shouldn't be the issue.
[18:15] <GrueMaster> I think I had to do the same thing for omap4.  I know I have the linux-omap4 meta listed there.
[18:17] <rcn-ee> sweet, the /lib/ld-linux.so -> /lib/arm-linux-gnueabi fixes debian sid armhf.. ;)
[18:17] <infinity> rcn-ee: Yeah.  Working on fixing eglibc now, will push to Debian too.
[18:18] <rcn-ee> thanks infinity! was about to just figure out where to submit the bug.. ;)
[18:30] <Xase> is there a sample xorg.conf or some way of telling xorg to use evtouch?
[18:36] <Xase> No one? :(
[18:37] <GrueMaster> Xase: You might be better asking that in #ubuntu-desktop.  I think all the xorg guys hang out there.
[18:38] <Xase>  ok
[18:47] <GrueMaster> infinity: Rebooting into armhf.  Fingers crossed.
[18:48] <infinity> GrueMaster: If it installed, I'm confident it'll boot. ;)
[18:48] <infinity> (eglibc uploaded and building)
[18:50] <GrueMaster> Grr.  I hate that it sits and spins waiting for a network.  On this broken system, means I have to manually unplug/plug in the cable for link detect to work.
[18:51] <GrueMaster> Still waiting on something in init to finish.
[18:53] <GrueMaster> It is pingable, but no getty so far.  Will need to enable console logging in the boot.scr to see what is borked.
[19:00] <GrueMaster> Do I need the updated eglibc or something?  It is hanging after "Starting configure network device".  System is pingable, but no login.
[19:00] <infinity> Nope.  Not eglibc's fault there.
[19:00] <GrueMaster> ssh appears to work, but no shell.
[19:00] <infinity> No shell sounds ominous.
[19:01] <GrueMaster> ssh logs in, lays out the welcome mat, then closes.
[19:02] <GrueMaster> Hrm.  Appears there is no /bin/bash
[19:02] <infinity> That seems rather unlikely...
[19:06] <GrueMaster> Nothing stands out in syslog.
[19:06] <GrueMaster> I have the rootfs drive on my PC now, so I can root arount.
[19:06] <GrueMaster> *around
[19:13] <Xase> Well that's pretty useless no one helpful with X seems to be in #ubuntu at the moment
[19:14] <GrueMaster> Xase: Some of them may be on vacation.
[19:14] <Xase> just my luck.
[19:14] <Xase> I'm unsure why the already there evdev rules don't catch the screen
[19:18] <GrueMaster> It could need to be updated with your device info, and an xorg.conf file could work around it.  I am just not sure how to do that.
[19:19] <Xase> Well if I even try to add anything to a new rules file or an xorg.conf ubuntu fails to boot.
[19:26] <Xase> meh.
[19:34] <GrueMaster> Hmmm.
[19:35] <GrueMaster> Do you get an Xorg.0.log when you change the config or rules?
[19:35] <Xase> Well I have to change it on the sdcard but I'll check, I have no other way to input besides the non working touch screen ;)
[19:36] <Xase> Where would it exactly be located?
[19:36] <GrueMaster> Yea, I know (I have a Nook Color as well).
[19:36] <GrueMaster> Should be in /var/log
[19:37] <Xase> Nope it's blank.
[19:37] <Xase> I'm sure I'm editing them wrong anyways.
[19:37] <GrueMaster> Odd.
[19:37] <Xase> It gives me a very specific error
[19:37] <GrueMaster> It should at least complain.  Anything in /var/log/sysog?
[19:39] <Xase> When I mess with xorg it gives this during boot.
[19:39] <Xase> (stk) :line disc installation timed out
[19:39] <Xase> ti_st_open: st_register failed -22
[19:39] <GrueMaster> That looks like a bluetooth error.
[19:40] <Xase> Ah.
[19:40] <Xase> So I'm seeing something normally hidden by x
[19:40] <Xase> Then boot isn't crashing
[19:40] <Xase> X just isn't loading
[19:40] <Xase> I'm definitely editing things wrong :D
[19:41] <Xase> Nothing in syslog about x11 or xorg
[19:41] <GrueMaster> I just got a link from one of our devs.  https://help.ubuntu.com/community/EloTouchScreen
[19:41] <Xase> o.o
[19:41] <GrueMaster> Although he also says evtouch is obsolete.
[19:42] <Xase> yeah apparently just evdev is used
[19:42] <Xase> So try evtouch?
[19:42] <GrueMaster> I can't really answer.  But the link has some good pointers at least.
[19:42] <Xase> well I have no clue how to do that. as I have no idea how to chroot into this sdcard since it's arm.
[19:44] <GrueMaster> What are you using for a base image?
[19:44] <Xase> Ubuntu Preinstalled Omap3
[19:46] <GrueMaster> I don't know if the gadget port can be enabled or not, but if you could figure that out, you might be able to get a serial console working.
[19:46] <Xase> Someone else I'm working with had issues...
[19:46] <GrueMaster> Also, the preinstalled image will be a bit more difficult, as it resizes the rootfs and launches oem-config.
[19:47] <Xase> Hmm
[19:48] <GrueMaster> but if you are able to boot this far, there is a lot that can go forward.  I don't know how to do it, but I'm sure you could use qemu to chroot into the image for adding packages and such.
[19:48] <janimo> infinity, thanks for the armhf/ac100 bits, I'll add them to the packaging git tree (also I'll check if zinc is still alive in the meantime for user kernels trees)
[19:50] <Xase> would... syslog show what devices were detected at startup GrueMaster ?
[19:51] <GrueMaster> I would think so.  You could also edit one of the init scripts (/etc/init.d) to execute some discovery commands that pipe to a log file.
[19:52] <Xase> alright
[19:52] <Xase> sort of lshal >> /var/log/lshal
[19:52] <Xase> ?
[19:52] <GrueMaster> Can you give me a link to your kernel?  I'll try to muck with it a bit here in my spare time this week.
[19:53] <GrueMaster> Yea, something like that.
[19:53] <Xase> Sure, just my uImage?
[19:53] <GrueMaster> Actually, I would need that and any modules.  Or are they all built-in?
[19:54] <GrueMaster> Better still, if you can give me a dd of your sd boot partition, that would give me everything I need.
[19:55] <Xase> All bubuilt in sure
[19:55] <GrueMaster> dd bs=4M if=/dev/mmcblk0p1 |gzip boot.img.gz
[19:56] <Xase> ok I was just about to ask.
[19:58] <Xase> o.o
[19:58] <Xase> gzip: boot.img.gz: No such file or directory
[19:59] <GrueMaster> Oops.  dd bs=4M if=/dev/mmcblk0p1 |gzip >boot.img.gz
[19:59] <GrueMaster> Missed the >
[19:59] <GrueMaster> my bad
[20:01] <GrueMaster> infinity: Any hints for what to look for as to why the beaglexm won't boot all the way in armhf?
[20:01] <infinity> GrueMaster: Not sure off the top of my head.
[20:01] <GrueMaster> I can chroot into the image (using a preinstalled-server image).
[20:01] <infinity> GrueMaster: But I'm going to fiddle on my panda in a bit.
[20:03] <GrueMaster> Fiddler on the Root.
[20:03]  * GrueMaster is in a weirdish mood today.
[20:06] <Xase> Hold on.
[20:06] <janimo> infinity, do you know what's with many FTBFS (today at least) not having build logs available?
[20:08] <Xase> GrueMaster:  data.excloo.com/~jase/boot.img.gz
[20:09] <GrueMaster> Cool, got it.
[20:10] <Xase> Fack I can't remember how to add a host to known_hosts
[20:10] <GrueMaster> On your desktop?  Which release?
[20:11] <Xase> I have debian to be honest =/
[20:11] <Xase> I'm trying to ssh into my ipod
[20:11] <Xase> ad it's omplaining about it... probably because I downgraded its firmware
[20:13] <GrueMaster> I usually just delete the offending key entry.
[20:14] <Xase> Yeah
[20:14] <Xase> That's what I just did.
[20:21] <Xase> man sftp is frustrating
[20:21] <infinity> janimo: The librarian is down.
[20:21] <infinity> janimo: Or, rather, was.  It's being recovered.
[20:21] <janimo> infinity, I had moments today when it worked so I was not sure if it is down or just being flakey atm
[20:22] <janimo> it being LP, I do not know of intricacies such as the 'librarian'
[20:22] <infinity> janimo: The librarian is the massive back-end filesystem where large things that aren't database bits are kept.
[20:22] <infinity> janimo: packages, logs, etc.