[07:00] <janimo> ogra_, I uploaded a new ac100 kernel last night, it is waiting for approval
[12:27] <hrw> which version of kernel you guys use on ac100?
[12:27] <ogra_> 3.1.something
[12:28] <ogra_> i think .10
[12:28] <janimo> hrw, 3.1.10 from nvidia
[12:28] <janimo> hrw, they have various 3.1 based branches with heavy churn among them inside arch/arm/mach-tegra and related drivers/
[13:44] <janimo> infinity, around? Can you let the newest ac100 kernel upload through? thanks
[13:45]  * ogra_ guesses we'll have to wait until the freeze is lifted
[13:45] <ogra_> or did you push to -proposed ?
[13:52] <janimo> ogra_, no, plain archives. Forgot about -proposed
[13:53] <janimo> or rather I never really knew what the current approval/freeze process had become
[13:53] <janimo> if it is more automated due to -proposed being a queue which is flushed after freeze I'll remember it for next time :)
[13:54] <janimo> so universe is frozen not because it could affect images but because it can tie up builders?
[13:56] <ogra_> well, the pieces that are on the images that you dont want in the archive during a freeze (i.e. that you dont want to distrub the image testing with) should go to proposed
[14:29] <janimo> ogra_, oh forgot that universe bits go to images. Anyway I usually do not upload the kernel meta so it can be tested without being automatically upgraded to immediately
[14:29] <ogra_> yeah
[14:30] <ogra_> and the freeze should eb gone real soon now
[15:01] <ogra_> hmm ..
[15:01] <ogra_> bazaar.launchpad.net/~ubuntu-branches/ubuntu/breezy/xscreensaver/breezy/view/head:/debian/patches/01lockscreen.dpatch
[15:02] <ogra_> i wonder if i should spend some hours on the weekend with that
[15:07] <xnox> ogra_: is this page http://www.ubuntu.com/download/arm correct?
[15:08] <ogra_> looks ok, yes
[15:09] <ogra_> we should probably make the desktop link less arch specific at some point
[15:14] <xnox> ogra_: any updates to "supported" platforms list?
[15:14] <ogra_> omap4 ...
[15:14] <ogra_> thats is
[15:14] <ogra_> it
[15:15] <ogra_> for the server side, ask the server guys :)
[15:15] <xnox> what about AC100 ?
[15:15] <xnox> os is that community?
[15:16] <phh> http://cdimage.ubuntu.com/releases/12.04/release/ it's there
[15:16] <phh> just not documented
[15:16] <ogra_> and not canonical supported
[15:16] <ogra_> yeah, its community
[15:17] <xnox> ok.
[15:17] <ogra_> everything on desktop is community but the panda
[15:17] <ogra_> same for server plus highbank and armadaxp
[15:17] <ogra_> i think
[15:18] <hrw> even when it was done by canonical people
[15:19] <ogra_> hrw, "spare time work" :)
[15:19] <hrw> ;))
[15:44] <bizulk> Hello world ! I've just install ubuntu precise on beagleboard xM, followed the step to install and test DSP acceleration. But /etc/init.d/dsp start result  in FATAL : module tidspbrdidge not found. Shall I compile kernel and the module by myself of is there a way to directly download it ?
[15:45] <ogra_> "followed the step to install and test DSP acceleration" > did you find that on an ubuntu wiki ?
[15:46] <bizulk> http://elinux.org/BeagleBoardUbuntu#DSP
[15:46] <ogra_> well, talk to the people maintaining that wiki
[15:47]  * ogra_ doesnt think the ubuntu kernel has any DSP support, our omap3 kernel is plain mainline
[15:48] <bizulk> ogra_: 3.2.0 kernel has  if compiled for it.  but I can't even check it as the /proc/config.gz is missing.
[15:48] <ogra_> it is in /boot
[15:48] <ogra_> (as for all ubuntu kernels, no matter what arch)
[15:50] <bizulk> oh yes your're right and... well the tidspbridge is not set
[15:51] <bizulk> maybe in the repo there a compiled kernel supported for it. I don't want to mix ubunt stuff with things I get from the net you known
[15:51] <RoyK> bizulk: you can turn on /proc/config.gz in the kernel config before you build it, but afaik ubuntu doesn't do that by default
[15:52] <ogra_> right, since we ship it as a textfile in /boot already
[15:53] <ogra_> bizulk, if its in mainline already and just needs enabling, file a bug and point ppisati to it
[15:53] <ogra_> flipping an existing config option is surely possible
[15:54] <bizulk> RobertCNelson is the one that write the wiki. Whi is ppisati ?
[15:56] <ogra_> ppisati, is the ubuntu kernel maintainer for arm kernels
[15:56] <ogra_> he is the master of the configs :)
[15:57] <bizulk> ok. Maybe I shall before upgrade since I see in the package list some kernel stuffs...
[15:58] <ogra_> sure, but dont expect that the option was switched one or so :)
[16:42] <sveinse> What can I do to speed up apt-get dist-upgrade? I'm running on omap3 with sdcard system, and dist-upgrading from natty to precise takes 40minutes!
[16:42] <ogra_> only 40 mins 1
[16:42] <ogra_> !
[16:43] <hrw> sveinse: only 40 minutes?
[16:44] <sveinse> ok, I think I'm in the wrong school :P   Management wont accept this, and 10 minutes would be more like it
[16:44] <ogra_> you must have a really fast card or a really small system
[16:46] <ogra_> dist upgrading an SD based  system with a desktop installed i would rather measure in hours than in minutes
[16:46] <sveinse> small system, I guess. Card's about 3-4Mb/s in write speed. The sum of all debs are about 170megs
[16:47] <ogra_> how much of these 40min is download time ?
[16:48] <sveinse> none, or out of scope of this. We deploy the debs in a container which the user puts on a USB device and puts in the device
[16:48] <ogra_> ah
[16:48] <ogra_> well, for a 3-4M/s device thats definitely pretty fast
[16:49] <sveinse> Hmm, I'll say that to my project manager :P Speak with the guys in #ubuntu-arm. LOL
[16:50] <ogra_> i'm surprised the system is usable wrt app startup times on such a blockdev
[16:50] <sveinse> Well thats another issue. We have 40 secs from power to functional GUI. Also too long
[16:51] <ogra_> pretty good for such a device
[16:51] <sveinse> I did a bootchart, and its either cpu-bound or IO-bound. Plain busy all of the time
[16:51] <ogra_> yeah
[16:51] <ogra_> unlikely that you can suqeeze more out of that
[16:53] <sveinse> yup. And I'm starting to feel that perhaps Ubuntu and a deb based distro wasn't the right thing for this little embedded thing
[16:54] <ogra_> well, ubuntu and debian are general purpose distros ...
[16:54] <ogra_> doing embedded with that is hard
[16:54] <ogra_> (ask the emdebian guys :) )
[16:55] <sveinse> Because, coming back to my original question, there is nothing you can do with dpkg to speed it up? Some area to use tmpfs in, allow it to cache, anything?
[16:57] <sveinse> Oh yeah, I know about this. Given my now soon to be two years of adopting cross compilation with debian packages
[16:59] <ogra_> well, i'm working on an actual embedded filesystem builder over here (spare time project) ...
[16:59] <ogra_> with luck it might m,ake 13.04
[17:00] <sveinse> Two main reasons for picking Ubuntu btw: 1) Large base of pre-compiled apps, 2) armv7 support out of box, now armhf as well
[17:00] <sveinse> And 3) selecting a deb based distro, as deb is a great tool for distributing updates
[17:01] <ogra_> well, packaging systems are quite some overhead on embedded ...
[17:03] <GrueMaster> sveinse: If you are using this for development, I recommend using a USB device for root.  Much faster than an SD (as much as 10x).  For final deployment, SD is ok, as minimal updates are required.
[17:06] <sveinse> GrueMaster: Point is that we have a couple of thousand units on the market with natty. We want to upgrade these to precise and the HW cannot boot from USB
[17:09] <GrueMaster> Ah, field upgrade.  Actually, the way I did it was to use the SD for /boot and a usb drive for rootfs.  But in this case, not sure what to tell you.  Maybe script it to reboot to a console only (no X) runonce script that performs the update.  Less overhead that way.
[17:09] <sveinse> (Not intending to troll, but) Would you guys accept that your mobile phone or pad take 40 minutes to do an OTA upgrade?
[17:10] <ogra_> nope
[17:10] <ogra_> oh, wait update
[17:10] <ogra_> yeah
[17:10] <GrueMaster> Actaully, my Droid 2 Global did when it went from 2.2 to 2.3.
[17:10] <GrueMaster> And it is essentially the same HW as the BeagleXM.
[17:10] <ogra_> 40min for an OTA update is fine imho
[17:10] <GrueMaster> Same with my Nook Color.
[17:11] <ogra_> as long as the device tells me in advance
[17:11] <ogra_> and lets me postpone until i have time to do the update
[17:11] <GrueMaster> Yes.  User controlled upgrade.
[17:12] <ogra_> if it doesnt tell me "it takes a few munites" but then goes on for 40
[17:12] <ogra_> *minutes
[17:13] <sveinse> Oh, I'm struggling with an interesting "feature" here. We've implemented a udev hook to look for upgrade files when an USB device is inserted.
[17:13] <ogra_> and whats your prob with it ?
[17:13] <sveinse> That has worked fine very long, but now it fails miserable. What do you think happens to the processes started by udev when udev is upgraded ;)
[17:14] <ogra_> ah, yeah
[17:15] <sveinse> It simply cuts the upgrade in the middle of everything. I mean, there are like four nested script and they are cut off like they never existed
[17:17] <GrueMaster> Sounds like you should be doing a two-stage upgrade.  Stage one is triggered by udev ( copies run-once scripts over, deletes or moves triggering mechanism), stage two does the actual upgrade.
[17:18] <sveinse> Yes, I was experimenting with using disown in bash to fork off the upgrade, but apparently its killed then. It probably still belongs to the same process group
[17:18] <sveinse> I'm going to try to use setsid. If that fails, then I'm going for a solution similar to GrueMaster's proposal