[12:20] <janimo> ogra_, you really should change that 30min estimation to 5min in the tarball unpacking message :)
[12:21]  * janimo is installing today's ac100 image
[12:22] <ogra_> janimo, heh, ok
[12:23] <janimo> getting into X in the installer is noticably slower than in precise
[12:23] <janimo> at one poits it's at console login as if no X is gonna start
[12:23] <ogra_> the initrd somewhat takes longer
[12:23] <ogra_> ubiquity-dm was always slow though
[12:23] <janimo> this was after starting userland on root, not sure it was the initrd
[12:23] <ogra_> lightdm is fine
[12:24] <janimo> X seemed slow to paint
[12:24] <ogra_> well, the time it takes from booting to the fsck messages
[12:24] <ogra_> thats significantly longer ...
[12:24] <ogra_> and i fear on all arches
[12:25] <janimo> getting to fsck took longer a bit, but then another 2 min until X
[12:25] <janimo> installer enocuntered unrecoverable error :(
[12:25]  * janimo checks logs
[12:26] <janimo> I wish there was a way of logging in/starting a shell to debug when this installer crashes
[12:27] <janimo> 'a desktop session will be run so that you may investigate' but that too crashes
[12:30] <ogra_> wow, my install worked fine OOTB here
[12:30] <ogra_> which image did you use ? todays ?
[12:30] <janimo> ogra_, today's yes
[12:35] <ogra_> weird
[12:35] <ogra_> no installer issues at all here
[12:36] <ogra_> the screen doesnt wake up properly after DPMS kicked in though
[12:36] <ogra_> (just noticed)
[12:48] <ogra_> janimo, bug 1026577 ?
[12:48] <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
[12:48] <ogra_> even though i didnt see it here, it is obviously in these images)
[12:49] <ogra_> ah, no, ubi-partman
[12:49] <ogra_> ignore me
[12:58] <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
[12:58] <ogra_> pretty hackish and hard
[12:59] <ogra_> (and really nothing i want to invest time in)
[12:59] <janimo> ogra_, what caused the crash last time was trying to use wifi, let's see what happens this time when I skip that
[12:59] <ogra_> weird, worked all fine here
[12:59] <janimo> ogra_, I agree then, if there is time to invest it should be towards unifying with the ubuntu live installer
[13:00] <janimo> I kept pushing connect and it did not
[13:00] <ogra_> the only issue i currently see is DPMS and plymouth
[13:00] <janimo> if I connected from the NM icon in the panel it worked
[13:00] <janimo> but then crashed
[13:00] <ogra_> weird
[13:00] <ogra_> the page doesnt automatically move forward after it connected
[13:00] <janimo> oh now it went ahead did not even ask about wifi
[13:00] <ogra_> but the button changes
[13:00] <marvin24> ogra_: that's a tegrafb bug
[13:01] <marvin24> switch to X and back may help
[13:01] <ogra_> janimo, is that a freshly unpacked tarball or just the failed install rebooted
[13:01] <janimo> ogra_, failed install rebooted
[13:01] <ogra_> if its the failed one, debconf definitely keeps your input
[13:01] <ogra_> so thats normal ...
[13:02] <janimo> ok, now it installs
[13:02] <janimo> still a bug but maybe it's in the logs somewhere
[13:02] <ogra_> marvin24, thx, it does indeed
[13:02] <ogra_> yeah
[13:02] <ogra_> might be HW though
[13:02] <marvin24> the nv guy seems to have given upon the console problems as it seem
[13:02] <marvin24> I got no reply from him for a few days
[13:03]  * ogra_ just built an lzma compressed kernel ... curious if that will work
[13:03] <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 ?
[13:04] <ogra_> i suspect our kernel still doesnt have everything needed and would like to find out if its a config prob
[13:05] <marvin24> nv added a lot of options, yes
[13:05] <marvin24> I guess some tegra_defconfig should be sufficient
[13:05] <ogra_> is that documented anywhere ?
[13:05] <ogra_> hmm, k
[13:05] <marvin24> arch/arm/configs/...
[13:05] <janimo> ogra_, maybe getting the kernel image from the L4T package and seeing what config it has enabled would help?
[13:05] <ogra_> janimo, i would, if i could :)
[13:06] <marvin24> is there a new l4t release?
[13:06] <ogra_> nvidia downloads are completely shut down since the hack
[13:06] <ogra_> marvin24, only R15 final
[13:06] <janimo> marvin24, L4T 15 final of a week or so ago
[13:06] <ogra_> i think you know about it
[13:06] <janimo> lilstevie, said the actual download links still work, just the site frontend/logins is stopped
[13:06] <ogra_> we already have it in quantal, but x fails
[13:06] <janimo> it's just that we don't know the link URLs :)
[13:07] <ogra_> janimo, well, doesnt help if i want to lok for a readme
[13:07] <ogra_> i know the url
[13:07] <janimo> ogra_, if there's a kernel image in the URL that may have configs already
[13:07] <ogra_> but the README contained doesnt talk about kernels at all
[13:07] <janimo> which we can compare with ours
[13:07] <lilstevie> ogra_: I have most of the documentation on hand
[13:07] <lilstevie> what is it about the kernel that you are interested in
[13:07] <ogra_> yes, it might be in the softfloat package
[13:08] <lilstevie> yeah
[13:08] <lilstevie> itttt is
[13:08] <lilstevie> but I also have the documentation package that is just the docs
[13:08] <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
[13:08] <ogra_> *goes
[13:08] <lilstevie> quantal only?
[13:08] <ogra_> yep
[13:09] <ogra_> ABI12
[13:09] <marvin24> ogra_: so we are left with tegra_android_defconfig
[13:09] <lilstevie> hm
[13:09] <ogra_> marvin24, hmm, android doesnt use the xerver, do they ?
[13:09] <lilstevie> well as far as the docs say as long as you are using l4t-r15-rc tag it should be fine
[13:09] <marvin24> no, but that's the only tegra2 config I found
[13:10] <ogra_> is our kernel at that tag ?
[13:10] <lilstevie> as of r15 they rolled the DC code to be a common base
[13:11] <marvin24> ogra_: no, we are further in the future ;-)
[13:12] <marvin24> rel-15r7
[13:12] <marvin24> (branch)
[13:12] <marvin24> tegra-15r7.1-android-4.0
[13:12] <marvin24> tag
[13:13] <janimo> marvin24, lilstevie actually with the last update we are at origin/l4t/l4t-r15
[13:14] <janimo> I rebased on what I learned was very latest and recommended with L4T drivers by nvidia
[13:14] <marvin24> janimo: so you stepped back?
[13:14] <janimo> marvin24, is that back??
[13:14] <marvin24> rel15r7 is 4 weeks old
[13:14] <marvin24> l4t/l4t-r15 is 7 weeks old
[13:14] <janimo> I hate nvidia tag/branch naming scheme
[13:15] <marvin24> http://nv-tegra.nvidia.com/gitweb/?p=linux-2.6.git
[13:15] <marvin24> janimo: yes, this is very confusing
[13:15] <janimo> marvin24, so 15r7 is the one that goes with L4T final?
[13:15] <marvin24> I think they have different l4t and android branches
[13:15] <lilstevie> they seem to maintain these things in parallel and not talk to eachother
[13:15] <janimo> I thought from the most recent discussion with lilstevie that the branch I used was
[13:15] <lilstevie> janimo: technically no
[13:15] <janimo> oh well
[13:16] <marvin24> l4t and android may have different branches, yes
[13:16] <marvin24> I used the android one because it seemed to me that it has more fixes
[13:16] <janimo> I tried avoiding the android branch for that reason
[13:16] <janimo> by that reason being - it goes with L4T
[13:16] <janimo> no idea what the diffs are
[13:16] <marvin24> works fine here ...
[13:17] <janimo> marvin24, this branch of yours is newer that what we had last week in ubuntu?
[13:17] <lilstevie> I haven't seen the new hdmi stuff in the newer rel-15r7 code from android
[13:17] <marvin24> mine is based on tegra-15r7.1-android-4.0
[13:18] <marvin24> while you seem to have used tegra-l4t-r15-rc
[13:23] <janimo> ogra_, so ac100 install finished just as usual the first thing it does is crashes and invokes apport
[13:30] <ogra_> lol
[13:30] <ogra_> well, if you had a ubiquity crash there is a core dump in /var/crash on first start
[13:30] <ogra_> apport just picks that up
[13:44] <ogra_> WOW !!!!!!
[13:44] <ogra_> building the kernel lzma compressed saves 1MB !
[13:45] <ogra_> if that actually works, i could leave plymouth ion the initrd and drop all the ugly diversion hackery
[13:45] <ogra_> and it does !
[13:46] <lilstevie> ogra_: I have been building my kernel lzma'd for a while now for size reasons
[13:46] <ogra_> lilstevie, right, it was never clear if the ac100 fastboot can handle that
[13:47] <marvin24> kernel decompresses the initrd
[13:47] <ogra_> i had mixed results in the past (though testing initrds, not kernels)
[13:47] <lilstevie> well the kernel decompressor code does it
[13:47] <marvin24> fastboot only has the 2MB limit
[13:47] <marvin24> so you may have ran into this problem
[13:47] <ogra_> i had initrds failing with the old kernels when trying out other methods than gzip
[13:47] <ogra_> (2.6.29 etc)
[13:48] <marvin24> you need to select the decompressor in the kernel config
[13:48] <ogra_> for the initrd it just needs to be enabled
[13:48] <marvin24> older kernels didn't support so many (only gz and bz2 I think)
[13:49] <ogra_> and we always had lzma available as inbitrd compression method
[13:49] <ogra_> even in the kernels where iot didnt work
[13:50] <ogra_> lilstevie, do you use any special cmdline options on your tablets to work with the r15 driver ?
[13:50] <ogra_> vram or something alike
[13:52] <lilstevie> no more than usual
[13:52] <ogra_> hmm, k
[13:52] <lilstevie> http://paste.ubuntu.com/1100098
[13:52] <ogra_> vmalloc=128M video=tegrafb
[13:52] <ogra_> do you use these normally ?
[13:53] <lilstevie> but that is what the bootloader passes up
[13:53] <lilstevie> yes
[13:53] <lilstevie> almost the entire commandline is from the bootloader
[13:54] <ogra_> i assume that doesnt fix the DPMS issues i see here "no_console_suspend=1" ...
[13:56] <lilstevie> DPMS issues?
[13:56] <ogra_> i need to switch to console after waking up from DPMS to get X back
[13:57] <ogra_> els i end up with a black screen
[13:57] <lilstevie> oh
[13:57] <lilstevie> no I don't have that
[13:58] <lilstevie> in fact switching to any tty means I don't come back :/
[13:58] <ogra_> ah
[13:59] <ogra_> janimo, oh, i get a crash massage as well, seems its plymouthd
[13:59] <lilstevie> but I wake from DPMS fine
[14:04] <janimo> ogra_, no coming back from suspend either here, can't seem to switch to any VT
[14:07] <ogra_> yep
[14:16] <janimo> ogra_, my initial ubi crash was indeed due to failing to connect NM, which crashed before that
[14:16] <janimo> so this is clearly a bug unrelated to ac100 installer
[14:18] <ogra_> yeah
[14:19] <janimo> unfortunately not enough info in the coredump
[14:19]  * ogra_ is more intrested in the plyouth segfaults though
[14:20] <ogra_> though it seems that my diversions are so good that i cant properly revert them :(
[15:59] <janimo> marvin24, I was just about to tell you to skip moving the framebuffer as it causes the toshiba logo to scroll uglily up
[15:59] <janimo> but I see you have a change already there
[16:00] <janimo> would be good to skip it even if not using uboot for above aesthetic issue
[16:00] <ogra_> uglily eh ?
[16:00] <ogra_> :)
[16:00] <janimo> well, it does not scroll smoothly enough
[16:00] <ogra_> ++ btw
[16:00] <janimo> either we fix that or remove the scroll :)
[16:00] <ogra_> yeah, it shouldnt move at all
[16:00] <ogra_> it didnt in the past
[16:01] <janimo> it's a new change in 3.1 kernels only, needed for nvidia devboards apparently, but maybe not at all for us
[16:01] <ogra_> yeah
[16:23] <LetoThe2nd> howdy! is there some "official" ubuntu arm kernel git tree? like what goes into the omap4 images?
[16:55] <marvin24> janimo: I don't know why they did it
[16:55] <marvin24> maybe to see the bootloader output
[16:56] <marvin24> I can disable it
[16:56] <marvin24> and re-enable when we have u-boot *and* some bl framebuffer addresss
[16:58] <janimo> marvin24, probably disabling it completely makes sense for us indeed
[18:02]  * janimo is wondering how hard it is reflashing the ac100 to have the original layout where it had an SOS partition
[18:02] <janimo> debugging kernels would be easier that way
[18:05] <infinity> janimo: Mine still has an SOS partition.  I guess you could clone mine?
[18:05] <janimo> infinity, I even had the full factory dump of the ssd on my disk, but the process itself seemed convoluted
[18:06] <janimo> involving lots of nvflash calls
[18:06] <infinity> Everything involves lots of nvflash calls...
[18:06] <janimo> or hadn editing of some files
[18:06] <janimo> yes, but this with weired argas thatn usual
[18:06] <janimo> of course it may have just been the regular Ncommander fearmongering at work and all is easy-peasy
[18:08]  * janimo just remembers that ad-ridden wiki where the process was confusingly written down
[18:08] <janimo> also ramconsole is great, that prompted me to think of having it available easily on the ac100
[18:09] <janimo> infinity, also I'd probably need the exact model I have for the factory images
[18:10] <janimo> infinity, which is the easiest out of the archive solution for creating arm rootfs from c86? Anything better than deprecated rootstock?
[18:10] <janimo> but higher level than debootstrap
[18:12] <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
[18:12] <infinity> janimo: live-build, though we have no nice wrappers to make it brain-dead.
[18:13] <janimo> infinity, oh does it do cross-builds too?
[18:13] <infinity> It can.  I've not tested it much, but I know Linaro uses it.
[18:13] <janimo> hmm, I should probably ask them what they use to create the l-m-c tarballs
[18:14] <infinity> Then again, you can just untar ubuntu-core, toss in /usr/bin/qemu-arm-static, and tailor it yourself quickly too. :P
[18:14] <janimo> yes, the qemu + taylor it yourself bits what I hate
[18:14] <janimo> :)
[18:15] <janimo> I wonder if I am such a niche person with uncommon needs when I keep complaining about our build tools in general :)
[18:18] <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.
[18:18] <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.
[18:18] <infinity> s/it only/is only/
[18:18] <janimo> infinity, well not very non-standard mind you, getting a xubuntu-desktop is quite a common use case I'd say
[18:19] <infinity> Well, then you also said "optionally including other packages". ;)
[18:19] <infinity> But, anything that isn't a base image set is "custom" in my mind.
[18:19] <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
[18:20] <janimo> the whole debootstrap --foreign and 2 stages stuff is not something I want to learn about right now
[18:20] <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.
[18:20] <infinity> Otherwise, yeah, that works.
[18:20] <infinity> (But you could have started with core, which would save you from the --foreign business)
[18:20] <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
[18:21] <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.
[18:21] <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
[18:22] <janimo> infinity, the cross-build part is where I am lost as I never did that
[18:22] <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
[18:23] <infinity> There's no cross involved in the above.
[18:23] <infinity> Just emulation.
[18:23] <infinity> Which is also how live-build and higher level tools work.
[18:23] <janimo> infinity, where does qemu-arm-static get involved?
[18:23] <infinity> And mk-sbuild, for that matter.
[18:23] <infinity> janimo: You just copy it into the chroot to /usr/bin
[18:23] <janimo> yes, I saw ps whosing qemu while running mk-sbuild
[18:24] <janimo> hmm, and then everything just gets ran by it?
[18:24]  * janimo must try
[18:24] <infinity> So, "untar core chroot/ && cp /usr/bin/qemu-arm-static chroot/usr/bin/ && chroot chroot su -"
[18:25] <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.
[18:25] <infinity> janimo: So, as long as your current root has the emulator, you win.
[18:25] <janimo> yes, it has it, let's see
[18:25] <infinity> (since interpreters are found by path, whether it's an emulator, ld.so, /bin/sh, etc)
[18:28] <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
[18:29] <infinity> janimo: Well, yes.  The above assumed you were root.