**** BEGIN LOGGING AT Thu Sep 13 03:00:00 2012
Sep 13 09:15:40 <ppisati> ogra_: alive?
Sep 13 09:16:44 * ndec hopes!
Sep 13 09:46:26 <ppisati> ogra_: anyway, when you resurrect, can you tell me how to make my Q/omap4 boot from my sda1 instead of my mmcblk0p3? thanks
Sep 13 09:46:47 <ogra_> ppisati, yo, sorry, i was afk for a moment
Sep 13 09:49:11 <ogra_> ppisati, after you copied your rootfs edit preEvn.txt and add either the blockid or root=/dev/sda1 ... boot with this and run sudo flash-kernel on the running system (to make sure f-k picks up the change) ... for a test you could then also reboot again
Sep 13 09:49:32 <ogra_> (preEnv.txt lives on the first partiton of the SD)
Sep 13 09:55:27 <ppisati> ogra_: so i need to edit, reboot (why?) and then run flash-kernel?
Sep 13 09:56:12 <ogra_> flash-kernel uses the currently mounted rootfs to determine the blkid when generating preEnv.txt
Sep 13 09:56:28 <ogra_> so you need to manually change / first and boot with that
Sep 13 09:56:42 <ppisati> ogra_: uhm
Sep 13 09:56:46 <ogra_> ??
Sep 13 09:57:20 <ppisati> ogra_: i already tried to modify and reboot, but it didn't mount sda1 as /
Sep 13 09:57:27 <ppisati> ogra_: maybe i did something wrong, wait
Sep 13 09:57:48 <ogra_> what did you modify exactly ?
Sep 13 09:58:11 <ogra_> the cmdline lives in preEnv.txt on the first partition of the SD
Sep 13 09:58:15 <ppisati> yep
Sep 13 09:58:17 <ppisati> that stuff
Sep 13 09:58:34 <ppisati> i figured out by myself before asking
Sep 13 09:58:40 <ppisati> but since i couldn't change it
Sep 13 09:58:43 <ogra_> just changing it and rebooting should be enough, the rest above is just to make sure f-k does the right thing
Sep 13 09:58:45 <ppisati> i came on irc
Sep 13 09:58:52 <ppisati> let me retry
Sep 13 09:59:02 <ogra_> is there a boor.scr somewhere ?
Sep 13 09:59:28 <ogra_> (alongside with uEnv.txt and preEnv.txt)
Sep 13 09:59:38 <ppisati> ogra_: yep
Sep 13 09:59:44 <ogra_> remove it
Sep 13 09:59:46 <ppisati> ah
Sep 13 10:00:04 <ogra_> though it shouldnt be used ... but you never know
Sep 13 10:00:13 <ppisati> let's see
Sep 13 10:00:19 <ogra_> (u-boot is supposed to not use it if uEnv.txt exists)
Sep 13 10:01:27 <ppisati> /dev/mmcblk0p3 on / type ext4 (rw,errors=remount-ro)
Sep 13 10:01:46 <ppisati> sudo mount /dev/mmcblk0p1 /media
Sep 13 10:01:51 <ppisati> cat /media/preEnv.txt
Sep 13 10:01:56 <ppisati> bootargs=ro console=tty0 console=ttyO2,115200n8 debug earlyprintk=ttyO2,115200n8 root=UUID=2a29c98b-32b9-45e7-a484-e1aa17b754ef
Sep 13 10:02:12 <ppisati> /dev/sda1: UUID="2a29c98b-32b9-45e7-a484-e1aa17b754ef" SEC_TYPE="ext2" TYPE="ext3"
Sep 13 10:02:25 <ppisati> and i just rebooted, of course
Sep 13 10:02:38 <ppisati> the funny thing is that
Sep 13 10:02:43 <ppisati> /proc/cmdline is correct
Sep 13 10:02:52 <ogra_> oh, wait, you might still use an install with the broken root= setting behavior where it is hardcoded in the initrd
Sep 13 10:03:02 <ppisati> but u-boot still uses mmcblk0p3
Sep 13 10:03:06 <ogra_> try regenersating your initramfs
Sep 13 10:03:14 <ppisati> "why always me?" (Balotelli docet)
Sep 13 10:03:52 <ogra_> flash-kernel had a very silly behavior of hardcoding root in the initrd we sadly inherited that from debian and it was only recently fixed
Sep 13 10:04:09 <ogra_> make sure to have the latest flash-kernel indeed
Sep 13 10:06:29 <ppisati> ogra_: 3.0~rc.4ubuntu22?
Sep 13 10:06:33 <ogra_> yep
Sep 13 10:06:41 <ppisati> right or wrong?
Sep 13 10:06:46 <ogra_> right
Sep 13 10:06:48 <ppisati> ok
Sep 13 10:06:50 <ppisati> anyway
Sep 13 10:06:55 <ppisati> re-running flash-kernel
Sep 13 10:07:07 <ogra_> erm
Sep 13 10:07:13 <ogra_> update-initramfs should have already
Sep 13 10:07:23 <ppisati> it overwrites preEnv.txt with: "root=UUID=d0fec503-0269-4a8e-ba97-4d492eb093f4"
Sep 13 10:07:28 <ppisati> and that's mmc
Sep 13 10:07:35 <ogra_> yes, as i told you above
Sep 13 10:07:46 <ogra_> change it to your sda1 now
Sep 13 10:07:59 <ogra_> then reboot
Sep 13 10:08:24 * ogra_ hopes that hardcoding stuff doesnt leave cruft behind we have to dig for now so its gone 
Sep 13 10:09:21 <ppisati> :(
Sep 13 10:09:29 <ppisati> sudo update-initramfs -uv
Sep 13 10:09:31 <ppisati> ...
Sep 13 10:09:41 <ppisati> /media/preEnv.txt: root=UUID=d0fec503-0269-4a8e-ba97-4d492eb093f4
Sep 13 10:09:45 <ppisati> mmcblk0p3
Sep 13 10:09:57 <ogra_> yes, again, change it before you reboot
Sep 13 10:10:04 <ppisati> ah right
Sep 13 10:10:07 <ppisati> sorry
Sep 13 10:10:13 <ppisati> but wait
Sep 13 10:10:14 <ogra_> as i said above, f-k defaults to generate the uuid from the current /
Sep 13 10:10:26 <ppisati> ok
Sep 13 10:10:34 <ppisati> but i already tried to change it and reboot
Sep 13 10:10:44 <ppisati> it still boots from mmc
Sep 13 10:10:52 <ogra_> after regenerating the initrd ?
Sep 13 10:10:57 <ppisati> ah ok
Sep 13 10:11:03 * ppisati reboots
Sep 13 10:11:11 <ogra_> the debian flash-kernel hardcodes root= in the initrd
Sep 13 10:11:38 <ogra_> first regenerate it, then change preEnv.txt to the new uuid , then reboot
Sep 13 10:12:16 <ogra_> then check if / is right ... if so, re-run flash-kernel, if not we need to find where the hardcoded crap was left behind
Sep 13 10:12:36 * ogra_ goes to make some coffee ... brb
Sep 13 10:13:00 <ppisati> ok, rebooted after regenerating initramfs and changing preEnv.txt to root=UUID=$sda1
Sep 13 10:13:07 <ppisati> but / is still mmcblk0p3
Sep 13 10:16:11 <ogra_> $sda1 `
Sep 13 10:16:13 <ogra_> ?
Sep 13 10:16:23 <ppisati> $sda1 = sda1 UUID
Sep 13 10:16:28 <ogra_> oh, k
Sep 13 10:16:39 <ogra_> right, gimme a sec
Sep 13 10:16:56 * ogra_ has to dig wheer that hardcode stuff ends up
Sep 13 10:20:26 <ogra_> check if there is either a file "default_root" or param.conf in one for the initramfs config dirs
Sep 13 10:20:54 <ogra_>  /etc/initramfs-tools/conf.d/ /usr/share/initramfs-tools/conf.d/
Sep 13 10:22:55 <ppisati> both empty
Sep 13 10:23:45 <ogra_> can you check the "Bootloader-sets-root" var in teh db file in /usr/share/flash-kernel/db/
Sep 13 10:23:50 <ogra_> (for panda)
Sep 13 10:24:14 * ogra_ wonders why you always hit such curious corner cases
Sep 13 10:24:25 <ppisati> Bootloader-sets-root: yes
Sep 13 10:24:31 * ppisati too!
Sep 13 10:24:43 <ogra_> right, so the initrd shouldnt have any hardcoding
Sep 13 10:26:02 <ppisati> uhm
Sep 13 10:26:04 <ppisati> ok
Sep 13 10:26:14 <ppisati> there's something definitely wrong here
Sep 13 10:26:19 <ogra_> no idea why it does :/
Sep 13 10:26:26 <ppisati> let me debug it
Sep 13 10:26:28 <ppisati> thanks anyway
Sep 13 10:26:42 <ogra_> well, that case will likely not happen to anyone else
Sep 13 10:26:52 <ogra_> not sure its worth putting time in
Sep 13 10:27:57 <ogra_> its only an issue for people that have installed to SD with the broken f-k version and now want to move to USB disk
Sep 13 10:28:39 <ogra_> installing to SD is gotten pretty hard nowadays due to the live installer and having to prepare the partitions in an exact way
Sep 13 10:29:06 <ogra_> so i really dont expect many other people but you to hit that issue
Sep 13 10:33:06 <ogra_> ppisati, try if that helps: http://paste.ubuntu.com/1202351/
Sep 13 10:34:34 <ogra_> (and indeed you need ro re-roll the initrd, afterwards change preEnv.txt etc etc like before)
Sep 13 10:39:18 <ogra_> if that fixes it i know what to do...
Sep 13 12:07:53 <ogra_> rsalveti, i just uploaded a fix for bug 1034734 thats slightly different from yours, feel free to test ;)
Sep 13 12:07:53 <ubot2> Launchpad bug 1034734 in flash-kernel "flash-kernel shouldn't prompt the user when updating initramfs in case there's no valid /etc/fstab" [Medium,Confirmed] https://launchpad.net/bugs/1034734
Sep 13 12:08:12 <ogra_> (that should also fix ppisatis issues above)
Sep 13 13:25:17 <ogra_> ppisati, ubuntu23 should fix your issue
Sep 13 13:25:52 <ogra_> an upgrade should download it, i think it is published already
Sep 13 13:26:32 <ppisati> ubuntu23?
Sep 13 13:26:46 <ogra_> flash-kernel
Sep 13 13:26:50 <ppisati> ah ok
Sep 13 13:26:55 <ppisati> ack
Sep 13 13:26:56 <ppisati> tx
Sep 13 13:26:59 <ppisati> 10101!!!
Sep 13 13:27:15 <ogra_> the fix is for a slightly different issue but i belive it fixes yours too
Sep 13 13:27:48 <ppisati> later i'll give it a try
Sep 13 13:27:50 <ppisati> thanks
Sep 13 13:28:00 <ogra_> feedback apprecisted :)
Sep 13 13:28:02 <ppisati> trying to fix rtc and release a new kernel now
Sep 13 13:28:06 <ogra_> *appreciated too
Sep 13 13:28:09 <ppisati> will do
Sep 13 13:28:17 <ppisati> my internet connection is so bad these days...
Sep 13 13:28:24 <ogra_> ppisati, oh, wait, rsalveti has a fix for the broken graphics driver
Sep 13 13:28:29 <ogra_> would be good to get that in as well
Sep 13 13:28:51 <rsalveti> ogra_: yup
Sep 13 13:28:59 <rsalveti> ppisati: give me 5 mins and I'll have a link for you
Sep 13 13:31:06 <rsalveti> argh
Sep 13 13:31:29 <ogra_> argh ?
Sep 13 13:31:36 <rsalveti> xorg is getting most of my cpu randomly from time to time
Sep 13 13:31:43 <rsalveti> can't even type at my terminal
Sep 13 13:31:49 <ogra_> use waland
Sep 13 13:31:52 <ogra_> *way
Sep 13 13:31:53 <rsalveti> lol
Sep 13 13:31:56 <ogra_> :)
Sep 13 13:32:54 <rsalveti> 95% of my cpu at GetXIDRange
Sep 13 13:33:44 <ogra_> on your panda ?
Sep 13 13:33:53 <rsalveti> no, at my x86 host
Sep 13 13:33:58 <ogra_> phew ...
Sep 13 13:34:17 <ogra_> who cares about such wasteful arches anyway :)
Sep 13 13:34:41 <rsalveti> yeah :-)
Sep 13 13:37:03 <ogra_> i was actually wondering about their haswell stuff ... 9W isnt bad, but will the new ultrabooks have air scoops for the cooler or what ? http://www.heise.de/imgs/18/9/1/6/9/5/8/f5a34f507256bb9a.jpeg
Sep 13 13:38:40 <rsalveti> ppisati: http://paste.ubuntu.com/1202641/
Sep 13 13:38:44 <rsalveti> ppisati: mind giving it a try?
Sep 13 13:38:57 <rsalveti> would be good to check with whatever other patch you're planning to push as well
Sep 13 13:40:01 * ogra_ imagines the next ultrabook generation might look like this http://s3.racingjunk.com/ui/7/97/27518977-880-68-Chevelle-Hood-with-ram-air-scoop.jpg
Sep 13 13:55:34 <ppisati> rsalveti: drop me an email with the link/fix, my connection is really flaky
Sep 13 13:55:47 <rsalveti> ppisati: http://paste.ubuntu.com/1202641/
Sep 13 13:55:47 <rsalveti> ppisati: http://paste.ubuntu.com/1202641/
Sep 13 13:55:48 <rsalveti> ppisati: http://paste.ubuntu.com/1202641/
Sep 13 13:55:51 <rsalveti> :-)
Sep 13 13:55:53 <ppisati> lol :)
Sep 13 13:56:18 <rsalveti> but can send the email as well ;-)
Sep 13 13:56:21 <ppisati> ok, i'll pull all the stuff
Sep 13 13:58:51 <rsalveti> ppisati: sent as email as well
Sep 13 14:04:06 * ogra_ thinks you can also find it at http://paste.ubuntu.com/1202641/
Sep 13 14:04:20 <ogra_> :)
Sep 13 14:27:45 <Pici> gswain: you should be good now
Sep 13 14:48:48 <gswain> Pici: thanks :-)
Sep 13 14:49:03 <gswain> is there a certain chip that works best with 12.04 arm, we are thinking on using marvel armada 300
Sep 13 16:06:46 <Martyn> gswain : look at linaro for guidance as to what platforms are well supported
Sep 13 16:07:06 <Martyn> I've been concentrating on the TI:OMAP and ST:Spear platforms
Sep 13 16:07:09 <Martyn> as well as Calxeda
Sep 13 16:08:35 <gswain> Well I just noticed that the ubuntu arm paged happened to only mention marvell XP and calxeda
Sep 13 16:11:54 <gswain> I dont see where on the linaro site they cover specific chips
Sep 13 16:15:30 <Martyn> Ugh, I really am starting to hate how linaro is caring for that site.
Sep 13 16:15:32 <Martyn> One second
Sep 13 16:15:57 <Martyn> https://wiki.linaro.org/Boards
Sep 13 16:16:00 <Martyn> have at
Sep 13 16:16:31 <Martyn> and even that page isn't up to date
Sep 13 16:25:22 <asiekierka_> any TF101 OLiFE users?
Sep 13 16:33:37 <infinity> gswain: If you're looking for platforms supported by Canonical in 12.04, the list is short (Marvell ArmadaXP, Calxeda Highbank, and TI OMAP4)
Sep 13 16:34:21 <infinity> gswain: Martyn's right that Linaro builds kernels for a ton of platforms, but none of the that gets any level of "support" (ie: no security updates, etc)
Sep 13 16:34:45 <ogra_> well, there is the semi supported ac100 :)
Sep 13 16:35:06 <infinity> ogra_: Has the kernel had a single post-release update?
Sep 13 16:35:14 <ogra_> heh, no
Sep 13 16:35:24 <infinity> ogra_: If not (and I know the answer is no), I put it in the same category as the Linaro platforms.
Sep 13 16:35:26 <ogra_> it might get one if we find a sane way to fix the console
Sep 13 16:35:34 <Martyn> infinity : I'm also building kernels (nightly now) for ST Spear 1600
Sep 13 16:35:46 <Martyn> infinity : But it's not "official Canonical"
Sep 13 16:36:45 <infinity> Martyn: Yes, well, I'm not sure what he meant by "works with 12.04" either.  If he just wants to know if the userspace will work on his armv7 platform, the answer is always "yes", as long as he can find a kernel. :P
Sep 13 16:36:53 <Martyn> True
Sep 13 16:37:00 <Martyn> gswain : You still alive?
Sep 13 16:37:01 <infinity> Martyn: If he wants something that's supported and has security updates and we take bug reports for, the list shrinks.
Sep 13 16:37:08 <Martyn> No kidding :)
Sep 13 16:37:36 <Martyn> ogra_ : So, now I'm waiting for STMicro's Spear production run
Sep 13 16:37:47 <Martyn> Everything is at a halt, hardware wise.. so all the team can do is work on software
Sep 13 16:37:59 <ogra_> how sad
Sep 13 16:40:00 <Martyn> I'm unhappy
Sep 13 16:40:15 <Martyn> Every day that rolls on without chips, is another "wasted" day
Sep 13 16:40:24 <Martyn> I've got literally -thousands- of motherboards, with no CPUs
Sep 13 16:40:40 <Martyn> it's been like that for two months
Sep 13 17:06:01 <gswain> hey guys Martyn im here, i had to run out to a meeting
Sep 13 17:07:43 <gswain> infinity thanks: so the marvell Armada XP 300/301 would work then?
Sep 13 17:08:50 <gswain> and im a little fuzzy about driver support for everything that gets built onto the board, are there certain boards that are supported or not? im curious about things like nics and sata ports and wifi adapters
Sep 13 17:09:42 <gswain> and yea i was pretty much referring to what canonical supports for its 12.04 release, and was wondering if there was one of the three that worked better/ more reliable than the rest
Sep 13 17:09:50 <infinity> gswain: We support the XP, not the 300, though I'm not sure if the XP kernel might boot a 300 as well.
Sep 13 17:09:57 <infinity> (Having no 300 hardware, I can't really say)
Sep 13 17:10:04 <infinity> But they're two different SoCs.
Sep 13 17:10:11 <gswain> oh i didnt know that
Sep 13 17:10:13 <ogra_> infinity, you got other Xp hardware ?
Sep 13 17:10:50 <infinity> ogra_: I have no Marvell hardware at all, but "we" have a ton of XP kit.
Sep 13 17:11:06 <infinity> AFAIK, we have nothing with a 300/310 in it.
Sep 13 17:11:51 <ogra_> yeah
Sep 13 17:11:55 <ogra_> i was just wondering
Sep 13 17:23:02 <ogra_> hmm, so i switched to bip ...
Sep 13 17:23:23 <ogra_> i really like that i can connect multiple clients ...
Sep 13 17:23:33 <ogra_> but why does it have to be a system process
Sep 13 17:23:47 <ogra_> (dircproxy just runs as user)
Sep 13 17:28:29 <infinity> ogra_: irssi's proxy is quite nice (and a user process).
Sep 13 17:28:52 <ogra_> hmm, can it handle multiple connected clients ?
Sep 13 17:29:02 <ogra_> thats my main criteria
Sep 13 17:29:33 <ogra_> now that my ac100 has a decent speed and display i want it to be connected all the time as my desktop is
Sep 13 17:29:43 <infinity> I'm not entirely sure, since I don't use proxies at all, I just have a friend who swears by it.
Sep 13 17:30:15 <infinity> (I just use irssi in screen, which I can connect to as many times as I like cause, well, screen)
Sep 13 17:30:47 <ogra_> yeah, i'm a spoiled xchat user
Sep 13 17:32:00 <infinity> Irssi proxy is a bit different than most proxies, normally proxies create a new connection to IRC server when you connect to it, but irssi proxy shares your existing IRC connection(s) to multiple clients. And even more clearly: You can use only one IRC server connection to IRC with as many clients as you want. Can anyone figure out even more easier ways to say this, so I wouldn't need to try to explain this thing for minutes every time?
Sep 13 17:32:06 <infinity> ^-- From the irssi docs.
Sep 13 17:32:25 <ogra_> sounds exactly like bip
Sep 13 17:32:48 <ogra_> i'll take a look on the weekend
Sep 13 17:34:23 <GrueMaster> I can't remember what SOC the Dove boards had.  Thought it was the Armada 500 or something.
Sep 13 17:35:01 <ogra_> it was a dove :)
Sep 13 17:36:43 <infinity> 500/510 sounds right.
Sep 13 17:36:56 <ogra_> yep
Sep 13 17:37:03 <infinity> The 300/310 and XP are both vaguely related, but none are the same SoC.
Sep 13 17:37:05 <ogra_> became kirkwood, no ?
Sep 13 17:37:16 <infinity> No, Kirkwood's different again.
Sep 13 17:37:22 <infinity> Marvell has a lot of CPUs.
Sep 13 17:37:28 <ogra_> ah, k, then they were parallel developments
Sep 13 17:38:00 <GrueMaster> iirc, not all of the armada's are Armv7 compatible.
Sep 13 17:38:17 <infinity> It's a system integrator's dream, it's a software development nightmare.
Sep 13 17:38:25 <infinity> Until we get to the magical goal of a single zImage, anyway.
Sep 13 17:38:53 <ogra_> we could start with a singularized SoC
Sep 13 17:39:06 <ogra_> would make the zImage part so much easier
Sep 13 17:39:27 <GrueMaster> Isn't that what devicetree is for?
Sep 13 17:39:34 <infinity> Yep.
Sep 13 17:39:39 <ogra_> nah, thats software
Sep 13 17:39:58 <infinity> But DT doesn't buy us anything until the drivers and board-specific bits stop conflicting.
Sep 13 17:40:00 * ogra_ was more about merging the vendors ;)
Sep 13 17:40:05 <infinity> Which is being worked on, but it's a long road.
Sep 13 17:41:14 <infinity> ogra_: No thanks to the merging vendors idea.  Heck, any of us who built hobbyist machines during the early 2000s know that x86 CPUs wouldn't be half as awesome if it hadn't been for competition from AMD.
Sep 13 17:41:18 <GrueMaster> Only in arm are there 700 ways to implement the same SOC in a conflicting mannor.
Sep 13 17:41:38 <infinity> ogra_: Competition and diversity is the only thing that keeps ARM attractive to a lot of system builders.
Sep 13 17:41:43 <ogra_> infinity, so lets keep two then :)
Sep 13 17:42:16 <ogra_> (and none of them should be apple)
Sep 13 17:42:27 <infinity> We just need to clean up the kernel mess, that's all.  There's no reason all the SoCs can't be supported in a single kernel, except for splintered and conflicting development that made it so.
Sep 13 17:42:42 <ogra_> yeah, indeed
Sep 13 17:43:06 <ogra_> http://lkml.indiana.edu/hypermail/linux/kernel/1209.1/02654.html
Sep 13 17:43:18 * ogra_ likes the start of the first paragraph ...
Sep 13 17:44:55 <GrueMaster> Actually heading that way anyways.
Sep 13 17:45:39 <GrueMaster> Interestingly, by enabling the capabilities for cloud computing, Intel server sales are down.
Sep 13 17:45:43 <ogra_> well, the latest TI statement about OMAP sounded different
Sep 13 17:46:20 <prpplague> ogra_: link?
Sep 13 17:46:38 <ogra_> prpplague, i have only a german one, letr me see
Sep 13 17:48:30 <ogra_> hmm, cant find an english one
Sep 13 17:48:40 <ogra_> http://www.heise.de/newsticker/meldung/TI-Chef-sieht-die-OMAP-Chancen-bei-Smartphones-und-Tablets-schwinden-1707226.html
Sep 13 17:49:02 <ogra_> it points to http://www.media-server.com/m/p/fjs7m9d5 that should be the talk
Sep 13 17:50:12 <ogra_> essentially he says that TI wants to withdraw with OMAP from mobile and tablet and focus on industrial computing instead
Sep 13 17:50:36 <prpplague> interesting...
Sep 13 17:50:54 <ogra_> (and automotive)
Sep 13 17:51:35 <gswain> so is the arm version of ubuntu 12.04 still considered an LTS release?
Sep 13 17:51:40 <ogra_> he says he expects apple and samsung to own the whole market long term
Sep 13 17:51:51 <ogra_> gswain, no, it never was
Sep 13 17:52:28 <ogra_> well, arm server is iirc
Sep 13 17:52:30 <gswain> i thought 12.04 was supposed to be an LTS release for x86 stuff
Sep 13 17:52:38 <ogra_> yes
Sep 13 17:52:41 <ogra_> but not for arm
Sep 13 17:52:45 <gswain> oh bummer
Sep 13 17:53:30 <ogra_> we wont prevent bugfix uploads from building on arm after 18 months though :)
Sep 13 17:54:03 <gswain> what about security backports?
Sep 13 17:54:10 <gswain> how long do they last?
Sep 13 17:54:22 <ogra_> same thing ...
Sep 13 17:54:47 <ogra_> if there are security fixes uploaded even after 18 months they will be provided for arm too
Sep 13 17:54:49 <infinity> ogra_: Erm, that's not true at all.  precise/armhf is LTS.
Sep 13 17:54:55 <infinity> ogra_: Some/many of the IMAGES aren't, that's all.
Sep 13 17:54:56 <ogra_> infinity, desktop ?
Sep 13 17:55:07 <gswain> server
Sep 13 17:55:14 <ogra_> desktop is definitely not LTS
Sep 13 17:55:16 <gswain> im not using x or anything
Sep 13 17:55:30 <infinity> ogra_: Server, technically, but no one's actually going to try to sort out the package sets to decide what is and isn't. :P
Sep 13 17:55:38 <ogra_> right, as i said above, arm server is LTS
Sep 13 17:55:51 <ogra_> officially even
Sep 13 17:55:54 <ogra_> desktop isnt
Sep 13 17:55:57 <gswain> nice
Sep 13 17:55:59 <gswain> ok cool
Sep 13 17:57:18 <infinity> The "product" support is really more about the images (which we've already stopped building) than the packages.  But yeah, technically/officially, only "server" is LTS.
Sep 13 17:57:33 <ogra_> well, its also about the kernels
Sep 13 17:57:54 <ogra_> i dont think omap4 is LTS actually, only highbank and armadaXP are
Sep 13 17:58:16 <infinity> I got a different impression last time it came up.
Sep 13 17:58:25 <infinity> Plus, as long as we run omap4 in the DC, it's LTS. :P
Sep 13 17:58:29 <ogra_> k, then i might have misunderstood
Sep 13 17:58:35 <ogra_> hah
Sep 13 17:58:37 <ogra_> yeah
Sep 13 17:58:43 <infinity> And omap is "free" in the master branch, so it's LTS "by accident". ;)
Sep 13 17:58:51 <ogra_> right
Sep 13 17:59:38 <GrueMaster> Hmm.  Arm status seems to change like my underwear lately.
Sep 13 17:59:57 <ogra_> the various unity disasters in the past clearly show that arm isnt LTS on the desktop though :)
Sep 13 18:00:28 * ogra_ wonders if the unity upload that did hit precise-proposed today has the GLES patch or not :)
Sep 13 18:01:03 <ogra_> ... and if QA qill notice if its missing
Sep 13 18:01:08 <ogra_> *will
Sep 13 18:01:11 <infinity> ogra_: Well, it built, that's a good sign, right?
Sep 13 18:01:16 <GrueMaster> So, what has the dropping of Unity-2D done for Ubuntu TV & Ubuntu on Android?
Sep 13 18:01:29 <ogra_> infinity, it builds just fine defaulting to GL
Sep 13 18:01:36 <ogra_> thats the danger :)
Sep 13 18:01:44 <GrueMaster> Well, I would notice (if I were still QA).
Sep 13 18:01:50 <ogra_> you will only notice at runtime
Sep 13 18:02:06 * GrueMaster notices everything.
Sep 13 18:02:14 <infinity> ogra_: Not without libgl-dev installed, it wouldn't. ;)
Sep 13 18:02:35 <infinity> ogra_: And the build log only shows libgles2-mesa-dev
Sep 13 18:02:44 <ogra_> phwe, good
Sep 13 18:02:52 <ogra_> *phew even
Sep 13 18:14:14 <gswain> but the userland still gets updated as well?
Sep 13 18:14:18 <gswain> like apache and whatnot?
Sep 13 18:14:56 <ogra_> yes
Sep 13 23:20:17 <TypoNAM> perhaps one of you guys know, what do I need to do to get /dev/ttyS0 or whatever in Ubuntu 12.04 to make use of Pandaboard ES's existing RS232 serial port. I'm trying to use the serial port from a program running on the pandaboard.
Sep 13 23:22:02 <infinity> TypoNAM: It's /dev/ttyO2
Sep 13 23:22:17 * ogra_ was about to say that :)
Sep 13 23:22:19 <infinity> TypoNAM: (Note that's an Oh, not a Zero)
Sep 13 23:25:25 <TypoNAM> I tried that and I'm not able to send nor receive any characters on any of the /devttOx devices
Sep 13 23:25:44 <TypoNAM> gah, /dev/ttyOx
Sep 13 23:26:43 <rcn-ee> well, did you try as root, or add yourself as 'dialout' group? it's ttyO2 for the serial on the panda..
Sep 13 23:27:10 <TypoNAM> I cheated, chmod a+rw /dev/ttyO*
Sep 13 23:54:06 <infinity> And if udev wasn't going to recreate those on reboot, that would work.
Sep 13 23:54:33 <infinity> Just "adduser your_name dialout" and log out.
Sep 13 23:54:39 <infinity> With a sudo on that.
Sep 14 02:12:02 <GrueMaster> Also note that by default the port is wired as a null-modem, not as a standard PC serial port.  You will need a null modem adapter to connect to anything other than a PC.
**** ENDING LOGGING AT Fri Sep 14 02:59:59 2012