[08:41] <XorA> morning
[10:02] <flag_> guys, anyone know how to preserve a working serial console after framebuffer start?
[10:25] <flag_> ogra: do you know how i can preserve  a working serial console even after the framebuffer start?
[10:26] <ogra> preserve ?
[10:30] <flag_> flag_: yep, when the framebuffer starts, my console dies and i have to switch to my monitor to see what's going on
[10:31] <ogra> you should get all boot messages if you set the cmdline to point to serial and drop the "quiet" from the cmdline
[10:31] <ogra> just edit /boot/boot.script and run sudo flash-kernel
[10:36] <flag_> ogra: and what if one the variable in my uboot environment is longer than 80 chars? on do i print it in its entirety?
[10:37] <ogra> you editor should display it fine
[10:38] <flag_> no no
[10:38] <flag_> i mean, i'm in uboot and i try to "printenv $var"
[10:38] <flag_> but the content of var is longer than 80chars
[10:38] <flag_> thus it's truncated
[10:41] <ogra> there is only the hardcoded env (which just loads the boot.scr file) you will have to change a lot if you dont just edit boot.scr
[10:41] <ogra> so printenv wont get you very far
[10:41] <ogra> if it cuts off after 80 chars thats an issue with your terminal program
[10:41] <ogra> or with the TERM variable you use
[10:43] <flag_> ogra: i'm using minicom
[10:45] <ogra> well, i'd really recommend to rather change your boot.scr than to poke around in the uboot env
[11:26] <flag_> ogra: ok, deleted quiet from bootargs in boot.scr, but still my console dies after:
[11:26] <flag_> ogra: Starting kernel ...
[11:26] <flag_> Uncompressing Linux...........................................................................................................................................................................................
 you should get all boot messages if you set the cmdline to point to serial and drop the "quiet" from the cmdline
[11:26] <flag_> ogra: setenv bootargs root=UUID=e18764f5-7859-4509-gj48-bbcc01a1ff77 ro splash
[11:27] <ogra> did you set the cmdline to point to the serial terminal ?
[11:28] <flag_> ogra: bootargs=console=ttyS0,115200n8 root=UUID=54ec8187-d25e-413a-ac5b-99af9cc379fc (from u-boot)
[11:28] <ogra> is it like that in your boot.scr ?
[11:30] <flag_> ogra: bootargs in u-boot and boot.scr should match, right?
[11:30] <flag_> ogra: ah, got it
[11:34] <flag_> ogra: my bad, there was no console= in /boot/boot.scr but only in u-boot bootargs and i thought the kernel picked the console variable from u-boot
[11:35] <ogra> no, as i said above the u-boot stuff is totally irrelevant
[11:35] <ogra> its overriden as soon as boot.scr was loaded
[11:39] <flag_> ogra: k, thanks
[12:16] <hrw> heh.. I forgot how long can arm system need to upgrade..
[12:17] <ogra> heh
[12:17] <ogra> i did an ac100 update-manager upgrade over the weekend
[12:17] <ogra> took 36h
[12:17] <ogra> though on a very slow SD card
[12:17] <hrw> apt-get dist-upgrade from alpha3 to current - started >1h ago on sd
[12:18] <hrw> ogra: I reinstalled all packages on my dualcore atom in ~30 minutes. on 60MB/s sata
[12:28] <ogra> hmm
[12:28] <ogra> who fired off a netbook buid
[12:28] <ogra> *build
[12:29] <ogra> oh, not netbook, headless
[12:46] <hrw> http://www.computerworld.com.au/article/379549/calxeda_arm_chips_designed_480-core_servers/ - want one ;D
[12:51] <amitk> hrw: you can try convincing Rob or Martyn in Budapest
[12:51] <hrw> amitk: calxeda people?
[12:52] <amitk> hrw: yeah, you might know them as smoothstone people from previous UDSes
[12:53] <hrw> ah, right
[12:53] <hrw> the company which changes names
[13:13] <ogra_> k, finally unity-2d on ac100
[13:19] <hrw> you did not had it before?
[13:19] <ogra_> we didnt have neon runtime detection in QT
[13:19] <hrw> ah, right
[13:20] <ogra_> and after that i had to find out that the natty libc doesnt woork on tegra2
[13:20] <hrw> o.. hows that?
[13:20] <ogra_> http://gitorious.org/ac100/kernel/commit/227af643e6253e9a5c2a2f74468f855686c44117?diffmode=sidebyside
[13:20] <ogra_> see #linaro, was just discussed there
[13:21] <XorA> time to blag a ac100 now then :-D
[13:21] <ogra_> unity-2d is really snappy here
[13:23]  * hrw -> lunch
[14:25] <ogra_> janimo, poke
[14:26] <rsalveti> ogra_: cool, so new qt really worked well for you?
[14:26] <ogra_> yep
[14:26] <ogra_> currently using it afer i spent the whole weekend to get natty running
[14:26] <rsalveti> nice
[14:27] <janimo> ogra_, hello
[14:27] <rsalveti> ogra_: did you find what were the issues?
[14:27] <ogra_> libc is really badly broken on the ac100
[14:27] <rsalveti> you said you had many issues last week
[14:27] <ogra_> someone pointed me to http://gitorious.org/ac100/kernel/commit/227af643e6253e9a5c2a2f74468f855686c44117?diffmode=sidebyside
[14:27] <ogra_> i'm currently running with the maverick libc pinned
[14:27] <ogra_> janimo, so did you test headless ?
[14:27] <janimo> ogra_, not yet
[14:28] <ogra_> seems we have a bunch of issues with oem-config/ubiquity
[14:28] <rsalveti> ogra_: ouch, got it
[14:28] <janimo> was trying tosee why images fail
[14:28] <janimo> ogra_, I saw you made some changes around oem-config/upstrart last week
[14:28] <ogra_> janimo, the oem-config UI never comes up on serial
[14:28] <ogra_> unless no tty exists at all
[14:29] <ogra_> (i.e. it immediately works if i use a broken omapfb mode so ttys cant be started)
[14:29] <ogra_> i suspect ubiquity/oem-config simply has no code for that and uses the first console it finds
[14:30] <ogra_> the second big bug i see is that no user is created at all
[14:30] <janimo> what would a fix be? We need to keep ttys I think
[14:30] <ogra_> no idea yet
[14:30] <ogra_> i would suggest looking at d-i how it determines the used console
[14:30] <ogra_> if werial is set we should defautl to use it i think
[14:31] <janimo> ok
[14:31] <ogra_> effectively it doesnt seem like oem-config finishes its job
[14:31] <ogra_> the most funny part is that the debconf package removal that runs afterrrr oem-config defaults to serial
[14:31] <janimo> so right now one can log in but even if oem-config is started by hand it does not run
[14:31] <janimo> ?
[14:31] <ogra_> oem-config runs fine
[14:32] <ogra_> but on tty1
[14:32] <ogra_> while it takes input from serial (since the kernel defaults to it as first console)
[14:32] <ogra_> i can use my laptop kbd to fiddle with oem-config on the panda dvi screen
[14:32] <ogra_> :)
[14:33] <ogra_> it seems to just not use the right output
[14:33] <janimo> besides oem-config what else is broken?
[14:33] <ogra_> i havent found ut why we dont have build attempts since three days (ampty mails usually suggest that the connection to the image builder failed=
[14:34] <ogra_> well, oem-config doesnt create a user at all atm
[14:34] <janimo> ogra_, telepathy-glib FTBFS (regression) which holds up empathy
[14:34] <ogra_> janimo, shouldnt affect headless at all
[14:34] <janimo> ogra_, indeed
[14:34] <ogra_> we get empty build failure mails and i see no logs at all on the imagebuilder
[14:35] <janimo> who can debug that?
[14:35] <ogra_> someone has changed livecd-rootfs or debian-cd ... or the ssh connection from cdimage to the image builder is broken
[14:35]  * ogra_ will research that 
[14:40] <ogra_> so there was one change in livecd-rootf that only affects edubuntu
[14:42]  * ogra_ cant see any changes that could have made our builds fail
[14:42] <ogra_> lets try a manual build
[14:52] <ogra_> seems to run flawless
[15:32] <ogra_> http://cdimage.ubuntu.com/ubuntu-headless/daily-preinstalled/20110314/
[15:32] <ogra_> hmm, worked fine
[15:41] <ogra_> janimo, ^^^
[17:27] <GrueMaster> ogra_, janimo:  It still has issue with oem-config.  The program is displaying the user interactive screens on the attached monitor, but only taking input via serial console.
[17:27] <GrueMaster> ubuntu
[17:27] <GrueMaster> oops
[17:32] <GrueMaster> It also failed to create a user.  May be due to no network.  Not sure.
[17:35] <ogra_> GrueMaster, yes, as discussed above
[17:35] <GrueMaster> Bugs filed?
[17:35] <ogra_> GrueMaster, fi you give a broken frambuffer setting it works (i.e. if ttyS/O is the only console around)
[17:36] <ogra_> and the debconf bits after oem-config are on serial too
[17:36] <ogra_> oem-config was simply never used on serial i think
[17:36] <ogra_> so we are the first ones to face these issues
[17:37] <ogra_> no bugs filed yet, no
[17:37] <GrueMaster> I do see something interesting in the /var/log/oem-config.log.  It has an error open: /dev/tty not found.
[17:37] <ogra_> oh really ?
[17:37] <GrueMaster> I'll file a bug soon.  Flashing another SD to try on beagleXM.
[17:37] <ogra_> k
[17:38] <ogra_> it worked fine for me with the old kernel btw
[17:38] <GrueMaster> But it is near the end of the log (after other activity).
[17:38] <ogra_> because the omapfb setting completely broke the framebuffer
[17:38] <GrueMaster> Also, it failed to create a user, but that may be due to lack of network.
[17:38] <ogra_> unlikely
[17:39] <ogra_> wither we dont call all modules from the debconf frontend or what i suspect is my hack to rename the machine to localhost by default is bad
[17:39] <GrueMaster> Hey, I find unlikely bugs all the time.  I'm good at it, remember?  :P
[17:39] <ogra_> heh, yeah
[17:39] <ogra_> but i really doubt missing network has anything to do with it
[17:40] <GrueMaster> Same here, but I have seen weirder issues.
[18:31] <TheUni> rsalveti: ping
[18:32] <TheUni> rsalveti: i've begun cleaning xbmc's packaging and install scripts. it would be nice to have a mentor that i could speak with about best practices. know of anyone who might be willing/able to help?
[18:32] <rsalveti> TheUni: I can try to help on that
[18:33] <rsalveti> persia would be the best guy around for that
[18:33] <rsalveti> he knows a lot about packaging
[18:33] <rsalveti> TheUni: is it still the packaging tree?
[18:33] <TheUni> yes
[18:34] <TheUni> i have some work done locally to begin consolidating packages, but i'd like to know that i'm making things better and not worse
[18:34] <rsalveti> TheUni: and how is the daily builds, did you manage to get it to work?
[18:34] <TheUni> rsalveti: yes, daily builds are up. but they're not publicized yet because i'd like to rework the packages first
[18:34] <rsalveti> oh, ok
[18:34] <TheUni> incase we end up causing some conflicts while shifting things around
[18:35] <TheUni> https://launchpad.net/~team-xbmc/+archive/unstable
[18:35] <rsalveti> TheUni: at the moment it seems you're building for arm
[18:36] <rsalveti> at least Architecture: i386 amd64 powerpc ppc64
[18:36] <rsalveti> is that because of the daily builds?
[18:36] <rsalveti> cool
[18:36] <TheUni> rsalveti: simply because we haven't tackled packaging it yet
[18:38] <TheUni> but afaik current git is building/working on beagle
[18:38] <rsalveti> TheUni: cool, nice to know
[18:38] <TheUni> rsalveti: ok, i'll work up a list of questions and hand them off to you. you can pass me along if you'd like :)
[18:39] <rsalveti> some XBMC_CONFIG_OPTIONS would be arch specific, as for ARM we'd like to have gles support, and not gl and vdpau
[18:39] <rsalveti> TheUni: sure
[18:40] <TheUni> right
[18:40] <TheUni> gles is default for arm
[18:40] <rsalveti> but it does seems to be better
[19:47] <GrueMaster> Not sure what changed, but unity-2d-places is less than usable in the 20110311 image.  Can't even get to a terminal without crashing.
[19:47] <pmathews> s/hanf/hang/
[19:48] <GrueMaster> pmathews: ???
[19:50] <prpplague> GrueMaster: wrong wide post
[19:50] <prpplague> GrueMaster: that was for me
[19:50] <GrueMaster> ah
[19:58] <pmathews> oops
[19:59] <prpplague> kgilmer: you still working for bug?
[22:10] <kgilmer> hi prpplague, yep sure am.
[22:12] <prpplague> kgilmer: just ran across a post on linuxdevices, and just reminded me to ask
[22:13] <prpplague> kgilmer: http://www.linuxfordevices.com/c/a/News/Bug-Labs-BugSecure/
[22:14] <kgilmer> yep, that's our next bug version.
[22:15] <prpplague> kgilmer: don't suppose you guys are looking into omap4?
[22:15] <kgilmer> the pb chip is pretty cool
[22:15] <prpplague> kgilmer: i was curious about the pb chip
[22:16] <prpplague> kgilmer: i have heard that pb does a lot of cool designs that they keep pretty quiet about
[22:17] <kgilmer> sorry prpplague, in support crisis mode for a demo atm, got to get back to you later.
[22:18] <prpplague> kgilmer: np, later bud
[22:18] <prpplague> kgilmer: i understand all too well