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