| janimo | ogra_, I uploaded a new ac100 kernel last night, it is waiting for approval | 07:00 |
|---|---|---|
| hrw | which version of kernel you guys use on ac100? | 12:27 |
| ogra_ | 3.1.something | 12:27 |
| 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/ | 12:28 |
| === doko_ is now known as doko | ||
| janimo | infinity, around? Can you let the newest ac100 kernel upload through? thanks | 13:44 |
| * ogra_ guesses we'll have to wait until the freeze is lifted | 13:45 | |
| ogra_ | or did you push to -proposed ? | 13:45 |
| janimo | ogra_, no, plain archives. Forgot about -proposed | 13:52 |
| 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:53 |
| janimo | so universe is frozen not because it could affect images but because it can tie up builders? | 13:54 |
| 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 | 13:56 |
| 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:29 |
| ogra_ | and the freeze should eb gone real soon now | 14:30 |
| ogra_ | hmm .. | 15:01 |
| ogra_ | bazaar.launchpad.net/~ubuntu-branches/ubuntu/breezy/xscreensaver/breezy/view/head:/debian/patches/01lockscreen.dpatch | 15:01 |
| ogra_ | i wonder if i should spend some hours on the weekend with that | 15:02 |
| xnox | ogra_: is this page http://www.ubuntu.com/download/arm correct? | 15:07 |
| ogra_ | looks ok, yes | 15:08 |
| ogra_ | we should probably make the desktop link less arch specific at some point | 15:09 |
| xnox | ogra_: any updates to "supported" platforms list? | 15:14 |
| ogra_ | omap4 ... | 15:14 |
| ogra_ | thats is | 15:14 |
| ogra_ | it | 15:14 |
| ogra_ | for the server side, ask the server guys :) | 15:15 |
| xnox | what about AC100 ? | 15:15 |
| xnox | os is that community? | 15:15 |
| 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:16 |
| 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:17 |
| hrw | even when it was done by canonical people | 15:18 |
| ogra_ | hrw, "spare time work" :) | 15:19 |
| hrw | ;)) | 15:19 |
| 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:44 |
| ogra_ | "followed the step to install and test DSP acceleration" > did you find that on an ubuntu wiki ? | 15:45 |
| bizulk | http://elinux.org/BeagleBoardUbuntu#DSP | 15:46 |
| ogra_ | well, talk to the people maintaining that wiki | 15:46 |
| * ogra_ doesnt think the ubuntu kernel has any DSP support, our omap3 kernel is plain mainline | 15:47 | |
| 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:48 |
| bizulk | oh yes your're right and... well the tidspbridge is not set | 15:50 |
| 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:51 |
| ogra_ | right, since we ship it as a textfile in /boot already | 15:52 |
| 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:53 |
| bizulk | RobertCNelson is the one that write the wiki. Whi is ppisati ? | 15:54 |
| ogra_ | ppisati, is the ubuntu kernel maintainer for arm kernels | 15:56 |
| ogra_ | he is the master of the configs :) | 15:56 |
| bizulk | ok. Maybe I shall before upgrade since I see in the package list some kernel stuffs... | 15:57 |
| ogra_ | sure, but dont expect that the option was switched one or so :) | 15:58 |
| 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:42 |
| hrw | sveinse: only 40 minutes? | 16:43 |
| 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:44 |
| 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:46 |
| ogra_ | how much of these 40min is download time ? | 16:47 |
| 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:48 |
| sveinse | Hmm, I'll say that to my project manager :P Speak with the guys in #ubuntu-arm. LOL | 16:49 |
| 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:50 |
| 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:51 |
| 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:53 |
| 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:54 |
| 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:55 |
| sveinse | Oh yeah, I know about this. Given my now soon to be two years of adopting cross compilation with debian packages | 16:57 |
| 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 | 16:59 |
| 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:00 |
| ogra_ | well, packaging systems are quite some overhead on embedded ... | 17:01 |
| 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:03 |
| 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:06 |
| 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:09 |
| 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:10 |
| 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:11 |
| ogra_ | if it doesnt tell me "it takes a few munites" but then goes on for 40 | 17:12 |
| ogra_ | *minutes | 17:12 |
| 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:13 |
| ogra_ | ah, yeah | 17:14 |
| 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:15 |
| 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:17 |
| 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 | 17:18 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!