**** BEGIN LOGGING AT Thu Jul 19 02:59:59 2012
Jul 19 12:20:29 <janimo> ogra_, you really should change that 30min estimation to 5min in the tarball unpacking message :)
Jul 19 12:21:21 * janimo is installing today's ac100 image
Jul 19 12:22:13 <ogra_> janimo, heh, ok
Jul 19 12:23:03 <janimo> getting into X in the installer is noticably slower than in precise
Jul 19 12:23:20 <janimo> at one poits it's at console login as if no X is gonna start
Jul 19 12:23:23 <ogra_> the initrd somewhat takes longer
Jul 19 12:23:44 <ogra_> ubiquity-dm was always slow though
Jul 19 12:23:46 <janimo> this was after starting userland on root, not sure it was the initrd
Jul 19 12:23:51 <ogra_> lightdm is fine
Jul 19 12:24:00 <janimo> X seemed slow to paint
Jul 19 12:24:07 <ogra_> well, the time it takes from booting to the fsck messages
Jul 19 12:24:23 <ogra_> thats significantly longer ...
Jul 19 12:24:27 <ogra_> and i fear on all arches
Jul 19 12:25:04 <janimo> getting to fsck took longer a bit, but then another 2 min until X
Jul 19 12:25:19 <janimo> installer enocuntered unrecoverable error :(
Jul 19 12:25:22 * janimo checks logs
Jul 19 12:26:54 <janimo> I wish there was a way of logging in/starting a shell to debug when this installer crashes
Jul 19 12:27:35 <janimo> 'a desktop session will be run so that you may investigate' but that too crashes
Jul 19 12:30:31 <ogra_> wow, my install worked fine OOTB here
Jul 19 12:30:40 <ogra_> which image did you use ? todays ?
Jul 19 12:30:58 <janimo> ogra_, today's yes
Jul 19 12:35:43 <ogra_> weird
Jul 19 12:35:53 <ogra_> no installer issues at all here
Jul 19 12:36:17 <ogra_> the screen doesnt wake up properly after DPMS kicked in though
Jul 19 12:36:21 <ogra_> (just noticed)
Jul 19 12:48:24 <ogra_> janimo, bug 1026577 ?
Jul 19 12:48:26 <ubot2> Launchpad bug 1026577 in ubiquity "ubiquity crashed with TypeError in _execute_child(): Can't convert 'list' object to str implicitly" [Critical,Fix released] https://launchpad.net/bugs/1026577
Jul 19 12:48:42 <ogra_> even though i didnt see it here, it is obviously in these images)
Jul 19 12:49:22 <ogra_> ah, no, ubi-partman
Jul 19 12:49:25 <ogra_> ignore me
Jul 19 12:58:40 <janimo> ogra_, how hacky/hard would it be to provide a login shell before the install is complete? Ubuntu has a live desktop with ubuntu user where you can look around at will
Jul 19 12:58:58 <ogra_> pretty hackish and hard
Jul 19 12:59:29 <ogra_> (and really nothing i want to invest time in)
Jul 19 12:59:30 <janimo> ogra_, what caused the crash last time was trying to use wifi, let's see what happens this time when I skip that
Jul 19 12:59:43 <ogra_> weird, worked all fine here
Jul 19 12:59:52 <janimo> ogra_, I agree then, if there is time to invest it should be towards unifying with the ubuntu live installer
Jul 19 13:00:03 <ogra_> the only issue i currently see is DPMS and plymouth
Jul 19 13:00:03 <janimo> I kept pushing connect and it did not
Jul 19 13:00:14 <janimo> if I connected from the NM icon in the panel it worked
Jul 19 13:00:18 <janimo> but then crashed
Jul 19 13:00:19 <ogra_> weird
Jul 19 13:00:37 <ogra_> the page doesnt automatically move forward after it connected
Jul 19 13:00:47 <janimo> oh now it went ahead did not even ask about wifi
Jul 19 13:00:51 <ogra_> but the button changes
Jul 19 13:00:59 <marvin24> ogra_: that's a tegrafb bug
Jul 19 13:01:13 <marvin24> switch to X and back may help
Jul 19 13:01:24 <ogra_> janimo, is that a freshly unpacked tarball or just the failed install rebooted
Jul 19 13:01:33 <janimo> ogra_, failed install rebooted
Jul 19 13:01:44 <ogra_> if its the failed one, debconf definitely keeps your input
Jul 19 13:01:56 <ogra_> so thats normal ...
Jul 19 13:02:06 <janimo> ok, now it installs
Jul 19 13:02:22 <ogra_> marvin24, thx, it does indeed
Jul 19 13:02:22 <janimo> still a bug but maybe it's in the logs somewhere
Jul 19 13:02:27 <ogra_> yeah
Jul 19 13:02:35 <ogra_> might be HW though
Jul 19 13:02:45 <marvin24> the nv guy seems to have given upon the console problems as it seem
Jul 19 13:02:57 <marvin24> I got no reply from him for a few days
Jul 19 13:03:00 * ogra_ just built an lzma compressed kernel ... curious if that will work
Jul 19 13:03:43 <ogra_> marvin24, do you know of any source for a README or HOWTO what needs to be switched on in the kernel to make the binary driver work ?
Jul 19 13:04:15 <ogra_> i suspect our kernel still doesnt have everything needed and would like to find out if its a config prob
Jul 19 13:05:17 <marvin24> nv added a lot of options, yes
Jul 19 13:05:31 <marvin24> I guess some tegra_defconfig should be sufficient
Jul 19 13:05:35 <ogra_> is that documented anywhere ?
Jul 19 13:05:42 <ogra_> hmm, k
Jul 19 13:05:45 <marvin24> arch/arm/configs/...
Jul 19 13:05:45 <janimo> ogra_, maybe getting the kernel image from the L4T package and seeing what config it has enabled would help?
Jul 19 13:05:57 <ogra_> janimo, i would, if i could :)
Jul 19 13:06:08 <marvin24> is there a new l4t release?
Jul 19 13:06:11 <ogra_> nvidia downloads are completely shut down since the hack
Jul 19 13:06:21 <ogra_> marvin24, only R15 final
Jul 19 13:06:24 <janimo> marvin24, L4T 15 final of a week or so ago
Jul 19 13:06:34 <ogra_> i think you know about it
Jul 19 13:06:44 <janimo> lilstevie, said the actual download links still work, just the site frontend/logins is stopped
Jul 19 13:06:47 <ogra_> we already have it in quantal, but x fails
Jul 19 13:06:52 <janimo> it's just that we don't know the link URLs :)
Jul 19 13:07:06 <ogra_> janimo, well, doesnt help if i want to lok for a readme
Jul 19 13:07:14 <ogra_> i know the url
Jul 19 13:07:28 <janimo> ogra_, if there's a kernel image in the URL that may have configs already
Jul 19 13:07:31 <ogra_> but the README contained doesnt talk about kernels at all
Jul 19 13:07:35 <janimo> which we can compare with ours
Jul 19 13:07:45 <lilstevie> ogra_: I have most of the documentation on hand
Jul 19 13:07:52 <lilstevie> what is it about the kernel that you are interested in
Jul 19 13:07:55 <ogra_> yes, it might be in the softfloat package
Jul 19 13:08:12 <lilstevie> yeah
Jul 19 13:08:14 <lilstevie> itttt is
Jul 19 13:08:24 <lilstevie> but I also have the documentation package that is just the docs
Jul 19 13:08:39 <ogra_> lilstevie, on ac100 lightdm gots in a crash loop ... killing lightdm and running startx gets me a desktop but as soon as i click something it crashes
Jul 19 13:08:53 <ogra_> *goes
Jul 19 13:08:55 <lilstevie> quantal only?
Jul 19 13:08:58 <ogra_> yep
Jul 19 13:09:00 <ogra_> ABI12
Jul 19 13:09:00 <marvin24> ogra_: so we are left with tegra_android_defconfig
Jul 19 13:09:04 <lilstevie> hm
Jul 19 13:09:18 <ogra_> marvin24, hmm, android doesnt use the xerver, do they ?
Jul 19 13:09:35 <lilstevie> well as far as the docs say as long as you are using l4t-r15-rc tag it should be fine
Jul 19 13:09:45 <marvin24> no, but that's the only tegra2 config I found
Jul 19 13:10:04 <ogra_> is our kernel at that tag ?
Jul 19 13:10:32 <lilstevie> as of r15 they rolled the DC code to be a common base
Jul 19 13:11:24 <marvin24> ogra_: no, we are further in the future ;-)
Jul 19 13:12:02 <marvin24> rel-15r7
Jul 19 13:12:14 <marvin24> (branch)
Jul 19 13:12:16 <marvin24> tegra-15r7.1-android-4.0
Jul 19 13:12:17 <marvin24> tag
Jul 19 13:13:39 <janimo> marvin24, lilstevie actually with the last update we are at origin/l4t/l4t-r15
Jul 19 13:14:13 <janimo> I rebased on what I learned was very latest and recommended with L4T drivers by nvidia
Jul 19 13:14:27 <marvin24> janimo: so you stepped back?
Jul 19 13:14:34 <janimo> marvin24, is that back??
Jul 19 13:14:38 <marvin24> rel15r7 is 4 weeks old
Jul 19 13:14:54 <marvin24> l4t/l4t-r15 is 7 weeks old
Jul 19 13:14:57 <janimo> I hate nvidia tag/branch naming scheme
Jul 19 13:15:01 <marvin24> http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git
Jul 19 13:15:10 <marvin24> janimo: yes, this is very confusing
Jul 19 13:15:33 <janimo> marvin24, so 15r7 is the one that goes with L4T final?
Jul 19 13:15:35 <marvin24> I think they have different l4t and android branches
Jul 19 13:15:37 <lilstevie> they seem to maintain these things in parallel and not talk to eachother
Jul 19 13:15:47 <janimo> I thought from the most recent discussion with lilstevie that the branch I used was
Jul 19 13:15:48 <lilstevie> janimo: technically no
Jul 19 13:15:49 <janimo> oh well
Jul 19 13:16:16 <marvin24> l4t and android may have different branches, yes
Jul 19 13:16:30 <marvin24> I used the android one because it seemed to me that it has more fixes
Jul 19 13:16:32 <janimo> I tried avoiding the android branch for that reason
Jul 19 13:16:43 <janimo> by that reason being - it goes with L4T
Jul 19 13:16:49 <janimo> no idea what the diffs are
Jul 19 13:16:50 <marvin24> works fine here ...
Jul 19 13:17:16 <janimo> marvin24, this branch of yours is newer that what we had last week in ubuntu?
Jul 19 13:17:49 <lilstevie> I haven't seen the new hdmi stuff in the newer rel-15r7 code from android
Jul 19 13:17:50 <marvin24> mine is based on tegra-15r7.1-android-4.0
Jul 19 13:18:22 <marvin24> while you seem to have used tegra-l4t-r15-rc
Jul 19 13:23:27 <janimo> ogra_, so ac100 install finished just as usual the first thing it does is crashes and invokes apport
Jul 19 13:30:14 <ogra_> lol
Jul 19 13:30:37 <ogra_> well, if you had a ubiquity crash there is a core dump in /var/crash on first start
Jul 19 13:30:46 <ogra_> apport just picks that up
Jul 19 13:44:30 <ogra_> WOW !!!!!!
Jul 19 13:44:50 <ogra_> building the kernel lzma compressed saves 1MB !
Jul 19 13:45:39 <ogra_> if that actually works, i could leave plymouth ion the initrd and drop all the ugly diversion hackery
Jul 19 13:45:44 <ogra_> and it does !
Jul 19 13:46:23 <lilstevie> ogra_: I have been building my kernel lzma'd for a while now for size reasons
Jul 19 13:46:49 <ogra_> lilstevie, right, it was never clear if the ac100 fastboot can handle that
Jul 19 13:47:04 <marvin24> kernel decompresses the initrd
Jul 19 13:47:11 <ogra_> i had mixed results in the past (though testing initrds, not kernels)
Jul 19 13:47:16 <lilstevie> well the kernel decompressor code does it
Jul 19 13:47:19 <marvin24> fastboot only has the 2MB limit
Jul 19 13:47:35 <marvin24> so you may have ran into this problem
Jul 19 13:47:44 <ogra_> i had initrds failing with the old kernels when trying out other methods than gzip
Jul 19 13:47:49 <ogra_> (2.6.29 etc)
Jul 19 13:48:14 <marvin24> you need to select the decompressor in the kernel config
Jul 19 13:48:30 <ogra_> for the initrd it just needs to be enabled
Jul 19 13:48:31 <marvin24> older kernels didn't support so many (only gz and bz2 I think)
Jul 19 13:49:02 <ogra_> and we always had lzma available as inbitrd compression method
Jul 19 13:49:18 <ogra_> even in the kernels where iot didnt work
Jul 19 13:50:12 <ogra_> lilstevie, do you use any special cmdline options on your tablets to work with the r15 driver ?
Jul 19 13:50:27 <ogra_> vram or something alike
Jul 19 13:52:05 <lilstevie> no more than usual
Jul 19 13:52:20 <ogra_> hmm, k
Jul 19 13:52:39 <lilstevie> http://paste.ubuntu.com/1100098
Jul 19 13:52:53 <ogra_> vmalloc=128M video=tegrafb
Jul 19 13:52:58 <ogra_> do you use these normally ?
Jul 19 13:53:02 <lilstevie> but that is what the bootloader passes up
Jul 19 13:53:04 <lilstevie> yes
Jul 19 13:53:17 <lilstevie> almost the entire commandline is from the bootloader
Jul 19 13:54:36 <ogra_> i assume that doesnt fix the DPMS issues i see here "no_console_suspend=1" ...
Jul 19 13:56:22 <lilstevie> DPMS issues?
Jul 19 13:56:58 <ogra_> i need to switch to console after waking up from DPMS to get X back
Jul 19 13:57:09 <ogra_> els i end up with a black screen
Jul 19 13:57:31 <lilstevie> oh
Jul 19 13:57:34 <lilstevie> no I don't have that
Jul 19 13:58:06 <lilstevie> in fact switching to any tty means I don't come back :/
Jul 19 13:58:47 <ogra_> ah
Jul 19 13:59:36 <ogra_> janimo, oh, i get a crash massage as well, seems its plymouthd
Jul 19 13:59:41 <lilstevie> but I wake from DPMS fine
Jul 19 14:04:11 <janimo> ogra_, no coming back from suspend either here, can't seem to switch to any VT
Jul 19 14:07:19 <ogra_> yep
Jul 19 14:16:41 <janimo> ogra_, my initial ubi crash was indeed due to failing to connect NM, which crashed before that
Jul 19 14:16:52 <janimo> so this is clearly a bug unrelated to ac100 installer
Jul 19 14:18:14 <ogra_> yeah
Jul 19 14:19:15 <janimo> unfortunately not enough info in the coredump
Jul 19 14:19:46 * ogra_ is more intrested in the plyouth segfaults though
Jul 19 14:20:28 <ogra_> though it seems that my diversions are so good that i cant properly revert them :(
Jul 19 15:59:35 <janimo> marvin24, I was just about to tell you to skip moving the framebuffer as it causes the toshiba logo to scroll uglily up
Jul 19 15:59:44 <janimo> but I see you have a change already there
Jul 19 16:00:03 <janimo> would be good to skip it even if not using uboot for above aesthetic issue
Jul 19 16:00:17 <ogra_> uglily eh ?
Jul 19 16:00:18 <ogra_> :)
Jul 19 16:00:32 <janimo> well, it does not scroll smoothly enough
Jul 19 16:00:35 <ogra_> ++ btw
Jul 19 16:00:40 <janimo> either we fix that or remove the scroll :)
Jul 19 16:00:47 <ogra_> yeah, it shouldnt move at all
Jul 19 16:00:57 <ogra_> it didnt in the past
Jul 19 16:01:11 <janimo> it's a new change in 3.1 kernels only, needed for nvidia devboards apparently, but maybe not at all for us
Jul 19 16:01:19 <ogra_> yeah
Jul 19 16:23:05 <LetoThe2nd> howdy! is there some "official" ubuntu arm kernel git tree? like what goes into the omap4 images?
Jul 19 16:55:49 <marvin24> janimo: I don't know why they did it
Jul 19 16:55:56 <marvin24> maybe to see the bootloader output
Jul 19 16:56:10 <marvin24> I can disable it
Jul 19 16:56:35 <marvin24> and re-enable when we have u-boot *and* some bl framebuffer addresss
Jul 19 16:58:37 <janimo> marvin24, probably disabling it completely makes sense for us indeed
Jul 19 18:02:03 * janimo is wondering how hard it is reflashing the ac100 to have the original layout where it had an SOS partition
Jul 19 18:02:13 <janimo> debugging kernels would be easier that way
Jul 19 18:05:18 <infinity> janimo: Mine still has an SOS partition.  I guess you could clone mine?
Jul 19 18:05:48 <janimo> infinity, I even had the full factory dump of the ssd on my disk, but the process itself seemed convoluted
Jul 19 18:06:04 <janimo> involving lots of nvflash calls
Jul 19 18:06:13 <infinity> Everything involves lots of nvflash calls...
Jul 19 18:06:16 <janimo> or hadn editing of some files
Jul 19 18:06:26 <janimo> yes, but this with weired argas thatn usual
Jul 19 18:06:43 <janimo> of course it may have just been the regular Ncommander fearmongering at work and all is easy-peasy
Jul 19 18:08:12 * janimo just remembers that ad-ridden wiki where the process was confusingly written down
Jul 19 18:08:49 <janimo> also ramconsole is great, that prompted me to think of having it available easily on the ac100
Jul 19 18:09:28 <janimo> infinity, also I'd probably need the exact model I have for the factory images
Jul 19 18:10:30 <janimo> infinity, which is the easiest out of the archive solution for creating arm rootfs from c86? Anything better than deprecated rootstock?
Jul 19 18:10:38 <janimo> but higher level than debootstrap
Jul 19 18:12:04 <janimo> I don't seem to see an easy (as in linaro-media-create) tool for saying make an armhf root tarball corresponding to xubuntu-desktop optionally including other packages or kernel packages
Jul 19 18:12:51 <infinity> janimo: live-build, though we have no nice wrappers to make it brain-dead.
Jul 19 18:13:12 <janimo> infinity, oh does it do cross-builds too?
Jul 19 18:13:29 <infinity> It can.  I've not tested it much, but I know Linaro uses it.
Jul 19 18:13:54 <janimo> hmm, I should probably ask them what they use to create the l-m-c tarballs
Jul 19 18:14:17 <infinity> Then again, you can just untar ubuntu-core, toss in /usr/bin/qemu-arm-static, and tailor it yourself quickly too. :P
Jul 19 18:14:42 <janimo> yes, the qemu + taylor it yourself bits what I hate
Jul 19 18:14:44 <janimo> :)
Jul 19 18:15:32 <janimo> I wonder if I am such a niche person with uncommon needs when I keep complaining about our build tools in general :)
Jul 19 18:18:10 <infinity> janimo: Well, what you want can be done with live-build, I just don't find it "easy" to quickly tailor up something non-standard.
Jul 19 18:18:36 <infinity> janimo: But, then again, I don't think any tool is easier than "chroot in and make it how you want it".  Scripting that it only worth it if you do the same thing over and over.
Jul 19 18:18:46 <infinity> s/it only/is only/
Jul 19 18:18:50 <janimo> infinity, well not very non-standard mind you, getting a xubuntu-desktop is quite a common use case I'd say
Jul 19 18:19:25 <infinity> Well, then you also said "optionally including other packages". ;)
Jul 19 18:19:39 <infinity> But, anything that isn't a base image set is "custom" in my mind.
Jul 19 18:19:47 <janimo> infinity, well what I did today was a chroot indeed, via mk-sbuild just because that seems a nice enough wrapper that handles cross arch without me knowing what the hell is exactly going on behind the scenes
Jul 19 18:20:11 <janimo> the whole debootstrap --foreign and 2 stages stuff is not something I want to learn about right now
Jul 19 18:20:21 <infinity> The only problem with mk-sbuild is that it does a few schroot-specific things to your chroot, plus adding some buildd cruft you don't need.
Jul 19 18:20:24 <infinity> Otherwise, yeah, that works.
Jul 19 18:20:41 <infinity> (But you could have started with core, which would save you from the --foreign business)
Jul 19 18:20:48 <janimo> infinity, well yes, extra packages is custom but well within what an apt call can do and common enough to warrant a tool. But yes, I am whining
Jul 19 18:21:40 <infinity> I suppose I just don't see how "chroot foo/ apt-get -y install xubuntu-desktop^" is any harder than trying to convince a tool to do that for you.
Jul 19 18:21:48 <janimo> as always, I would be content with good docs if tools are lacking, but somehow those too are non-existent, too dense or hard to find
Jul 19 18:22:08 <janimo> infinity, the cross-build part is where I am lost as I never did that
Jul 19 18:22:40 <janimo> and having read of xapt, dpkg-cross and a few other tools that in my mind overlap in functionality I got non-the-wiser
Jul 19 18:23:01 <infinity> There's no cross involved in the above.
Jul 19 18:23:04 <infinity> Just emulation.
Jul 19 18:23:13 <infinity> Which is also how live-build and higher level tools work.
Jul 19 18:23:25 <janimo> infinity, where does qemu-arm-static get involved?
Jul 19 18:23:28 <infinity> And mk-sbuild, for that matter.
Jul 19 18:23:38 <infinity> janimo: You just copy it into the chroot to /usr/bin
Jul 19 18:23:40 <janimo> yes, I saw ps whosing qemu while running mk-sbuild
Jul 19 18:24:01 <janimo> hmm, and then everything just gets ran by it?
Jul 19 18:24:07 * janimo must try
Jul 19 18:24:30 <infinity> So, "untar core chroot/ && cp /usr/bin/qemu-arm-static chroot/usr/bin/ && chroot chroot su -"
Jul 19 18:25:09 <infinity> janimo: If you install qemu-user-static on the host, binfmt_misc gets magically configured to throw all your non-native binaries at emulators.
Jul 19 18:25:20 <infinity> janimo: So, as long as your current root has the emulator, you win.
Jul 19 18:25:44 <janimo> yes, it has it, let's see
Jul 19 18:25:45 <infinity> (since interpreters are found by path, whether it's an emulator, ld.so, /bin/sh, etc)
Jul 19 18:28:54 <janimo> infinity, ok, running now in the chroot. I needed to create and chroot into it as sudo since it would not untar /dev nodes otherwise
Jul 19 18:29:15 <infinity> janimo: Well, yes.  The above assumed you were root.
Jul 20 00:50:43 <TheMuso> So... I think I tracked down why omap*/panda aren't bootable after a net install in quantal... The omap and omap4 keywords are missing from the flash-kernel-installer sub-architecture package field.
Jul 20 00:50:58 <TheMuso> So the package doesn't get installed into the d-i environment when net-retriever/anna is run.
Jul 20 00:52:21 <TheMuso> Now... To work out how I can test my theory without uploading. I only want to do a flash-kernel upload if I *know* that is the fix. Hrm.
Jul 20 00:58:08 <infinity> TheMuso: You could tear apart the d-i initrd and make your changes to f-k-i manually.
Jul 20 01:02:35 <infinity> TheMuso: Though, I'm not sure you're right in this case.  f-k-i in 3.0 doesn't seem to have ANY board logic at all, it just calls flash-kernel in the target.
Jul 20 01:02:49 <infinity> TheMuso: And it apparently works for other boards (like highbank and armadaxp).
Jul 20 01:02:55 <TheMuso> infinity: I was thinking along those lines, but that doesn't really test whether anna will end up installing the package into d-i.
Jul 20 01:03:27 <TheMuso> Looking at a syslog from a precise d-i install, flash-kernel-installer gets installed. Quantal, it doesn't. So the package doesn't even get installed into d-i for flash-kernel to be run in the first place.
Jul 20 01:03:34 <infinity> TheMuso: Oh!, you're talking XB-Subarchitecture:
Jul 20 01:03:38 <TheMuso> Yes.
Jul 20 01:03:51 <infinity> Right, sorry, I thought you were talking board logic, like in the 2.0 f-k-i.
Jul 20 01:04:10 <TheMuso> No, sorry I should probably have been slightly clearer with which package field I meant.
Jul 20 01:04:17 <infinity> I'd say that the XB-Subarchitecture: change would be correct even if it doesn't fix your bug, so upload away.
Jul 20 01:04:34 <TheMuso> Thats what I'm thinking too. The worst that will happen is that it doesn't work.
Jul 20 01:06:41 <infinity> TheMuso: While you're there, feel free to steal https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/1026780 from ogra too. :P
Jul 20 01:06:42 <ubot2> Ubuntu bug 1026780 in flash-kernel "3.0~rc.4ubuntu4 doesn't honor bootargs from /boot/boot.script anymore" [Undecided,New]
Jul 20 01:06:50 <infinity> TheMuso: And welcome to ARM porting!  (sucker)
Jul 20 01:07:52 <TheMuso> Sure, will take care of it. :)
Jul 20 01:08:33 <TheMuso> And since powerpc is not really going anywhere any more, I need another non-x86 architecture to sink my teath into.
Jul 20 01:09:00 <infinity> BenC might disagree with you.
Jul 20 01:09:04 <TheMuso> ...and Jason my manager got pandaboards for all desktop team members, so I want to get quantla set up.
Jul 20 01:09:17 <TheMuso> Well, for desktop use. Thats all I cared about for powerpc.
Jul 20 01:09:32 <TheMuso> quantal even
Jul 20 01:09:51 <infinity> I think Ben's company is targetting desktop use as well as server.
Jul 20 01:09:57 <TheMuso> Oh ok.
Jul 20 01:10:02 <infinity> He certainly wastes a lot of time fixing FTBFS issues in desktop stuff.
Jul 20 01:10:20 <infinity> So, there must be a reason for that. :P
Jul 20 01:11:30 <TheMuso> True.
Jul 20 01:11:39 <infinity> Or maybe he's just doing it to prove the port is healthy.
Jul 20 01:11:40 <infinity> Which is fair.
Jul 20 01:11:44 <TheMuso> Well I still ahve a love of non-x86 stuff.
Jul 20 01:12:04 <infinity> Since every time some part of ubuntu-desktop is broken, someone screams "oh god, the port is shit, we should drop it", and I say "but, but, I run several powerpc servers, and that stuff all works fine."
Jul 20 01:12:47 <infinity> If you've given up on it, though, you can send me your powerstation. ;)
Jul 20 01:13:36 <TheMuso> heh
Jul 20 01:13:55 <TheMuso> Dunno, I am still undecided.
Jul 20 01:14:03 <infinity> I'd use mine for desktop stuff, but I've been too lazy to buy a sound card for it.
Jul 20 01:14:28 <infinity> (And by 'desktop stuff', I mean I'd keep using it as a server, but also watch movies on it, hence the need for sound)
Jul 20 01:15:17 <infinity> I wonder if anyone still makes decent but cheap PCI sound cards, or if I'm stuck buying some professionally overengineered whizbang thing because every new computer ships with onboard sound that's "good enough".
Jul 20 01:16:13 <TheMuso> My problem is that its too noisy.
Jul 20 01:16:25 <TheMuso> So I only run it when I want to do powerpc work.
Jul 20 01:16:45 <infinity> It is a bit of a wind tunnel, as designed.  That could be fixed.
Jul 20 01:17:18 <TheMuso> I know its as designed.
Jul 20 01:18:06 <infinity> Say, did you ever try out SATA drives in yours to see if the SAS controller in there was nearline SATA friendly?
Jul 20 01:18:21 <infinity> I need to try that sometime, but I don't really want to buy a drive just to find out it doesn't work.
Jul 20 01:19:38 <TheMuso> No, haven't tried, as I don't have any caddies suitable for mounting another drive. I could remove the existing drive, but whats the point in only having one drive when I could have more.
Jul 20 01:19:53 <infinity> I bought a bunch of rails from an eBay vendor for 3 bucks a pop.
Jul 20 01:20:05 <TheMuso> Are they generic drive rails?
Jul 20 01:20:10 <infinity> It's a standard IBM part, and they make clones of the part.
Jul 20 01:20:14 <TheMuso> Ah ok.
Jul 20 01:20:46 <infinity> 13-051054
Jul 20 01:20:52 <TheMuso> Anyway as to the bug above, would the user's /boot/boot.script overwrite the flash-kernel boot script wholesale, or are we wanting to do some funky stuff to encorporate both of them?
Jul 20 01:21:10 <infinity> Googling that part number should to the trick.  Or eBaying it.
Jul 20 01:21:17 <TheMuso> Yep.
Jul 20 01:21:41 <infinity> boot.scr should be generated from a combination of flash-kernel's internal logic and the user's boot.script.  Ish.
Jul 20 01:21:49 <infinity> That's more or less how it worked in 2.0, IIRC.
Jul 20 01:22:49 <infinity> Anyhow, I was going to fix it later (or let Oli get to it), so don't stress about it being a prerequisite for uploading your 2-word fix or anything. :P
Jul 20 01:22:51 <TheMuso> Hrm ok.
Jul 20 01:24:27 <infinity> I need to do some mangling in the same general area (cmdline args) to make f-k-i play nicely with d-i in the same way grub-installer does.
Jul 20 01:24:35 <infinity> So, you can just pretend we never had this conversation, if you prefer.
Jul 20 01:26:45 <TheMuso> I'm just looking at flash-kernel from precise to see how it handled this usecase...
Jul 20 01:27:33 <infinity> Have fun with that.  I think I might shower, and go remind myself what women look like.
Jul 20 01:27:43 <TheMuso> Heh ok.
Jul 20 01:36:03 <TheMuso> infinity: Meh I'm not going to worry about that bug, I have other things I want to do and I want to get my board up for some pulse 2.1 testing...
Jul 20 01:36:16 <TheMuso> Doesn't scratch my itch. :p
**** ENDING LOGGING AT Fri Jul 20 02:59:59 2012