[07:00] ogra_, I uploaded a new ac100 kernel last night, it is waiting for approval [12:27] which version of kernel you guys use on ac100? [12:27] 3.1.something [12:28] i think .10 [12:28] hrw, 3.1.10 from nvidia [12:28] hrw, they have various 3.1 based branches with heavy churn among them inside arch/arm/mach-tegra and related drivers/ === doko_ is now known as doko [13:44] 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] or did you push to -proposed ? [13:52] ogra_, no, plain archives. Forgot about -proposed [13:53] or rather I never really knew what the current approval/freeze process had become [13:53] 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] so universe is frozen not because it could affect images but because it can tie up builders? [13:56] 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] 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] yeah [14:30] and the freeze should eb gone real soon now [15:01] hmm .. [15:01] bazaar.launchpad.net/~ubuntu-branches/ubuntu/breezy/xscreensaver/breezy/view/head:/debian/patches/01lockscreen.dpatch [15:02] i wonder if i should spend some hours on the weekend with that [15:07] ogra_: is this page http://www.ubuntu.com/download/arm correct? [15:08] looks ok, yes [15:09] we should probably make the desktop link less arch specific at some point [15:14] ogra_: any updates to "supported" platforms list? [15:14] omap4 ... [15:14] thats is [15:14] it [15:15] for the server side, ask the server guys :) [15:15] what about AC100 ? [15:15] os is that community? [15:16] http://cdimage.ubuntu.com/releases/12.04/release/ it's there [15:16] just not documented [15:16] and not canonical supported [15:16] yeah, its community [15:17] ok. [15:17] everything on desktop is community but the panda [15:17] same for server plus highbank and armadaxp [15:17] i think [15:18] even when it was done by canonical people [15:19] hrw, "spare time work" :) [15:19] ;)) [15:44] 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] "followed the step to install and test DSP acceleration" > did you find that on an ubuntu wiki ? [15:46] http://elinux.org/BeagleBoardUbuntu#DSP [15:46] 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] 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] it is in /boot [15:48] (as for all ubuntu kernels, no matter what arch) [15:50] oh yes your're right and... well the tidspbridge is not set [15:51] 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] 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] right, since we ship it as a textfile in /boot already [15:53] bizulk, if its in mainline already and just needs enabling, file a bug and point ppisati to it [15:53] flipping an existing config option is surely possible [15:54] RobertCNelson is the one that write the wiki. Whi is ppisati ? [15:56] ppisati, is the ubuntu kernel maintainer for arm kernels [15:56] he is the master of the configs :) [15:57] ok. Maybe I shall before upgrade since I see in the package list some kernel stuffs... [15:58] sure, but dont expect that the option was switched one or so :) [16:42] 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] only 40 mins 1 [16:42] ! [16:43] sveinse: only 40 minutes? [16:44] ok, I think I'm in the wrong school :P Management wont accept this, and 10 minutes would be more like it [16:44] you must have a really fast card or a really small system [16:46] dist upgrading an SD based system with a desktop installed i would rather measure in hours than in minutes [16:46] small system, I guess. Card's about 3-4Mb/s in write speed. The sum of all debs are about 170megs [16:47] how much of these 40min is download time ? [16:48] 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] ah [16:48] well, for a 3-4M/s device thats definitely pretty fast [16:49] Hmm, I'll say that to my project manager :P Speak with the guys in #ubuntu-arm. LOL [16:50] i'm surprised the system is usable wrt app startup times on such a blockdev [16:50] Well thats another issue. We have 40 secs from power to functional GUI. Also too long [16:51] pretty good for such a device [16:51] I did a bootchart, and its either cpu-bound or IO-bound. Plain busy all of the time [16:51] yeah [16:51] unlikely that you can suqeeze more out of that [16:53] 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] well, ubuntu and debian are general purpose distros ... [16:54] doing embedded with that is hard [16:54] (ask the emdebian guys :) ) [16:55] 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] Oh yeah, I know about this. Given my now soon to be two years of adopting cross compilation with debian packages [16:59] well, i'm working on an actual embedded filesystem builder over here (spare time project) ... [16:59] with luck it might m,ake 13.04 [17:00] 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] And 3) selecting a deb based distro, as deb is a great tool for distributing updates [17:01] well, packaging systems are quite some overhead on embedded ... [17:03] 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] 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] 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] (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] nope [17:10] oh, wait update [17:10] yeah [17:10] Actaully, my Droid 2 Global did when it went from 2.2 to 2.3. [17:10] And it is essentially the same HW as the BeagleXM. [17:10] 40min for an OTA update is fine imho [17:10] Same with my Nook Color. [17:11] as long as the device tells me in advance [17:11] and lets me postpone until i have time to do the update [17:11] Yes. User controlled upgrade. [17:12] if it doesnt tell me "it takes a few munites" but then goes on for 40 [17:12] *minutes [17:13] 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] and whats your prob with it ? [17:13] 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] ah, yeah [17:15] 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] 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] 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] I'm going to try to use setsid. If that fails, then I'm going for a solution similar to GrueMaster's proposal