=== JaMa|Zzzz is now known as JaMa === hrw|gone is now known as hrw [08:40] morning === XorA|gone is now known as XorA [10:48] persia: ping [10:51] saeed: ? [10:51] persia hey [10:51] does hibernate work for you on dove? [10:52] I don't have a dove board, so both "yes" and "no" seem like the wrong answer to that :) [10:53] anyway, I noticed that sound settings are not restored after hibernate [10:53] persia: saeed: going by what was said in the meeting yesterday, no would be the right answer [10:53] saeed: Which sound settings? [10:54] volume, mute, etc [10:54] I mean hw settings [10:54] Ah, hrm. [10:55] ericm_: Any ideas? [10:55] which part of the system should restore those settings after hibernate resume? [10:56] saeed: add "/etc/init.d/alsa start" to after-resume scripts? [10:57] hrw: where are those scripts located? [10:57] /etc/pm/sleep.d/ but I don't see any on my lucid installs, making me thing there is another solution somewhere [10:57] saeed: no idea - I do not have any machine running ubuntu [10:58] hrw: Let us limit discussions to Ubuntu approaches here though ;-) [10:58] monday will be funny day - working on ubuntu/arm without having usable machine for it [10:58] hrw: Eh, you don't have any laptop/desktop running Ubuntu? [10:59] lool: Debian on desktop, Debian on laptop [10:59] if does is an ASoC board then ASoC layer should restore sound exactly as is [10:59] dove [10:59] hrw: I personally dual boot Debian on my laptop [10:59] With a shared /home [10:59] lool: with 80GB hdd I have dual boot Debian/winxppro [11:00] considering buying asus ul30 as new platform so kubuntu will land there rather [11:00] XorA: so `/sbin/alsa --force-reload` shouldn't be required? [11:01] XorA: the dove has two sound cards (AC97 and i2s), both of them are asoc [11:01] lool: Do you use Ext2fsd? [11:01] persia: no, the machine/codec driver should restore [11:01] * XorA doesnt have a dove or even know what it is [11:01] kaouthia: No [11:01] That explains the lack of /etc/pm/sleep.d/50alsa in lucid. [11:01] but I did used to maintain ASoC [11:01] never heard of it [11:01] How do you access your /home from your windows partition? [11:02] kaouthia: I dont use windows [11:02] hrw: I do my ubuntu work on fedora here :-D [11:02] it's a dual boot of debian and ubuntu [11:02] lool: Ah okay [11:02] * lool needs to disappear for an hour [11:02] lool: both reside on same crypted lvm? [11:02] XorA: How does that work? I didn't know most of our development scripts were available for Fedora (or do you work in a chroot/VM)? [11:03] hrw: No reason they couldn't, given appropriate bootargs [11:06] persia: VM combined with native on zoom2 board [11:06] XorA: ah, yeah, VM is plenty sufficient. [11:07] Is the Zoom2 fast enough to use for development directly? I was under the impression it was a bit RAM-low. [11:07] XorA: can you explain how should machine/codec restore settings after hibernate? [11:08] persia: I recompiled xf86-video-omapfb with no real issues, havent tried kernel yet [11:08] saeed: look at the drivers in sound/soc/* [11:08] No need: that you are using it for that indicates it's sufficient :) [11:09] XorA: what I'm missing, is how can the driver get those parametes from? [11:09] saeed: because the driver wrote them to the codec [11:09] saeed: it remembers themk [11:10] XorA: but after hibernate, the driver will be loaded as from reboot [11:12] saeed: Im not very familiar with ubuntu on arm, I work on a different distro where we dont power down the chips [11:13] XorA: but hibernate usually powers down the system, right? [11:14] Indeed. That's the usual difference between "suspend" and "hibernate". [11:14] XorA; please note the resuming from standby (suspend to ram) works fine to me [11:15] * XorA has never hibernated an arm in that case [11:15] XorA: I think it's the same on x86 [11:15] hibernate as susped-to-disk-and-power-off? [11:15] yes [11:16] never did that on arm either [11:16] actually mainline kernel doesn't support that, we have added that functionality [11:16] On boot, we seem to use /sbin/alsa-utils to restore state with alsactl. [11:17] hrw: ever feel we have walked into a strange new world :-) [11:17] Might need support for that around hibernate in pm-utils [11:17] saeed: Do you know if it works on x86? with Ubuntu? You might be hitting a general bug. [11:18] (or powerpc) [11:18] persia: no [11:19] XorA: life without new challenges starts to be boring [11:20] https://help.ubuntu.com/community/SoundTroubleshooting definitely has notes on working around hibernation issues. [11:20] XorA: I returned from fosdem with devboard which I did not even connected serial yet [11:20] hrw: hehe [11:20] XorA: thinking about giving it for a friend as a gift [11:20] * XorA is just trying to fix the zoom2 kernel so serial is not needed [11:21] nice improvement over arm7tdmi which are high tech at his company ;D [11:21] XorA, have you seen bug 567260 ? [11:21] Launchpad bug 567260 in xf86-video-omapfb (Ubuntu) "xserver-xorg-video-omap* fail due to no /dev/fb (affects: 1) (heat: 10)" [High,Confirmed] https://launchpad.net/bugs/567260 [11:22] ogra: thats what I fixed [11:22] we have another two days for a fix [11:22] saeed: Do you also lose settings on reboot? [11:22] ogra: I can post patch to bug [11:22] so it if it goes into archive tomorrow or friday we can have it in final [11:22] persia: no [11:22] its a one liner [11:22] XorA, cool, please do so [11:22] * persia looks for another bug [11:22] gimme a few mins to replace kernel on zoom2 to extract bug [11:23] oneliners are usually the most amazing changes [11:23] I remember curses of one developer after his 4 hours of attempts to solve build error which I solved with oneliner for makefile [11:24] persia, you want a bug ? i have plenty [11:25] ogra: Do you have one about sound and hibernate? [11:25] * persia is looking for a *specific* bug [11:25] ogra: that bug is already detailing my one liner [11:25] saeed: Try adding /etc/pm/sleep.d/50alsa as indicated at https://help.ubuntu.com/community/SoundTroubleshooting#Getting%20ALSA%20to%20work%20after%20suspend%20/%20hibernate and see if that works. If not, it might give some hints on a path to resolve it. [11:26] persia, nope, but since i joined the installer team yesterday i can provide you with 100's of installer bugs if you are desperately in need for a bug :P [11:26] hrw: one particularry fun online fix that took one day to locate.. [11:26] -char foo; [11:27] +signed char foo; [11:27] ogra: I have code that generates lists of unfiled bugs on a regular basis already, if I'm just hunting bugs :) [11:28] haha [11:30] persia: I'll try [11:31] OTG working on boot awesome [11:31] saeed: If that doesn't work, please file a bug (`ubuntu-bug audio`) [11:31] XorA, which kernel ? [11:32] ogra: it works on all linux-omap kernels [11:32] ogra: specifically on my zoom2 [11:32] XorA, not ubuntu then [11:32] ogra: you guys could add it [11:33] XorA, out kernel team uses mainline only on omap [11:34] tahst why the omap kernel is actually .33 and not .32 like the rest of ubuntu [11:34] (except fsl-imx51) [11:34] yeah [11:34] ogra: your not allowed to patch at all? [11:34] ogra: so torvalds tree instead of linux-omap tree? [11:34] Oh, and -rt [11:34] persia, which is why i said omap :) [11:34] hrw, right [11:34] XorA, we are [11:34] ogra: "rest of ubuntu" was my picky point [11:35] amitk, backports/cross ports bits and pieces [11:35] XorA: Debian policy was: mainline kernel + backports from mainline. probably same/similar for ubuntu [11:35] persia: it didn't work, I'll fill a bug [11:35] XorA: pain for omap [11:35] saeed: Thanks. [11:35] hrw, well, whatever is maintainable, if amitk decides a certain patch from -omap is valuable that will also be pulled in [11:35] its up to our kernel maintainer ... [11:36] i'm only a consumer and tester ;) [11:36] ogra: http://git.openembedded.net/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/0042-musb-allow-host-io-without-gadget-module.patch [11:36] eggonlea: you aorund? [11:38] XorA: the idea is to further the mainlining of omap by using mainline kernels. I've talked to Tony about this and he agrees. linux-omap is more like a buffer to mainline. [11:39] amitk: I know this, linux-omap diffs have rapidly decreased over mainline [11:39] NCommander: yes. [11:40] and yes, i need to find time and pick out the right patches from 34-rc or linux-omap to unbreak OTG [11:40] amitk: see patch above :-) [11:44] XorA: thanks, I shall [11:44] amitk: Im unsure of the pushed to mainline status, but Ajay is the TI USB guy [11:44] amitk: http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/linux/linux-omap-psp-2.6.32/ is worht checking anyway [11:45] * XorA really hopes ubuntu speeds the mainlining of zoom2/3 patches [11:46] zoom and beagle hopefully [11:47] ogra: beagleboard needs first really stable working version [12:01] * amitk disappears for lunch [12:08] * ogra lols about XorA's patch for omapfb [12:08] XorA, i tought you had added any kind of autodetection [12:09] i know asac tries to add that before final [12:20] ogra: I may code that up one day, but for now I just need lucid running [12:59] hrw: ecryptfs actually [13:02] ogra: do you know why omapfb instead of fbdev is used as reported in 567260? [13:03] lool: it crypts files but not filesystem - right? [13:03] hrw: It's a filesystem on filesystem [13:03] so it crytps filesystem objects in filesystem objects [13:03] e.g. a dir to a dir and a file to a file [13:04] ok, I prefer crypted lvm - handle also swap so I do /boot + crypto-lvm(/ + swap) [13:10] shashi, its not used by default atm, only if you install the omapfb package [13:11] ogra: ok thanks....i was inputing some comments/ thoughts in 567260 [13:12] shashi, thanks :) [13:14] ok, tickets for uds bought/booked [13:15] clap clap clap [13:15] looking forward to meet you there :) [13:18] same [13:24] hrw, i was looking at the musb host/device patch, haven't tested it yet, but how's it working for you? [13:24] rcn-ee: I did not updated my beagle to this kernel yet === ogra_ is now known as ogra [14:32] saeed, could you update your resume from suspend status to bug 551491? [14:32] Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress] https://launchpad.net/bugs/551491 [14:51] WOHOO+ [14:52] * ogra_beagle wipes this install and starts over with the latest image hoping all is fine now [14:53] (II) XINPUT: Adding extended input device "bmi-lcd-ts" (type: TOUCHSCREEN) [14:53] ;D [14:53] congrats [14:54] other omap3 board [14:59] hrw: what board is this? [14:59] bug 2.0 [14:59] prototype [14:59] standard image? [14:59] or custom kernel? [14:59] no ubuntu [15:00] amitk: I am returning device on days so no ubuntu tests for it [15:04] ogra: you said something about the new image allowing me to install to sd itself? [15:05] amitk, the netinst one, yes [15:06] how do i put a custom kernel on those? [15:06] amitk, pos-install [15:06] *post [15:06] you cant do it in the image [15:07] right [15:07] d-i is closely built with the kernel [15:09] ericm_: done [15:19] amitk: http://wiki.debian.org/DebianInstaller/Modify/CustomKernel [15:19] zumbi: ? [15:20] zumbi, heh, thats ancient [15:20] amitk: are not you asking how to use d-i with custom kernel? [15:20] from a time where d-i was still on two floppies [15:20] zumbi: ohh right. :) thanks, i'll take a look [15:21] amitk, d-i changed completely ... thats even pre-ubuntu [15:21] amitk: ogra is right, looks old [15:21] its for 2.4 kernels :) [15:21] ogra: do you know a more up to date doc? [15:21] no [15:21] hehe lol [15:21] and its a hell lot of work even if i knew a doc [15:21] amitk: i would like to have efikamx (iMX51) in mainline kernel [15:21] 2.4... [15:22] ogra: using kernel-wedge? [15:22] zumbi: want to submit patches? pointers to git tree? pointer to someone that has hardware? [15:22] installing the existing image and just issuing dpkg -i linux-image .... *.deb is definately easier and a lot faster [15:23] amitk: i have hardware, the bad thing is they use freescale SDK [15:23] zumbi: that is fine if you don't mind wiping it over ;) [15:23] ogra: right, for efikamx, i wanted to add it to flash-kernel which hooks kernel-package [15:24] ogra: then use somethin similar to rootstock [15:24] flash-kernel hooks kernel-package ?? [15:24] flash-kernel is really only to set up the bootlaoder [15:25] you shouldnt abuse it for other stuff, rather create a new tool that flash-kernel can call [15:25] flash-kernel (debian version) calls mkimage on vmlinux and initrd [15:26] yes [15:26] I thought that was the best way to do for porting a new device [15:26] but it doesnt do anything with kernel-package [15:27] kernel-package provides me with a vmlinux and initrd, then flash-kernel could get me the right thing I need (uBoot format) [15:27] and i dont think we even support kernel-package in ubuntu [15:27] i might be wrong though, amitk might know better [15:27] kernel-package is a great tool [15:27] but i guess it doesnt properly hook into the ubuntu infrastructure [15:28] -ENOkernel-package [15:28] uhm.. that's sad [15:28] you don't even need a debian_dir, it creates it for you [15:28] yes, thats the scary part [15:29] zumbi: it might work for mainline kernels, but not for 'managed/supported' kernels. [15:29] but it is something the kernel team plans to look at in our sprint next week [15:29] amitk: it works for efikamx, kirkwood sheevaplug, and some others [15:29] (whether we should support it or not) [15:30] zumbi, FSVO works [15:30] what is FSVO? [15:30] zumbi: sure, but we don't support that HW, so why would we care? (to be blunt) [15:30] zumbi, as rootstock "works" to create an image [15:30] you will never get the same as you have with a real install with rootstock ... [15:30] and you will never get a proper ubuntu kernel package with kernel-package [15:31] so its "some system that looks like ubuntu" in the end [15:31] zumbi: though I would love for our kernel to support multiple boards with a single kernel tree. [15:31] zumbi, FSVO -> for some value of [15:31] well, I would like to find a way to have an embedded-installer which suits ubuntu and debian [15:31] which handles all this bootloader, kernel details [15:32] but it seems hard to find a consensus [15:32] you cant do it with the concept of a distro [15:33] you can only get close to it [15:33] i.e. like rootstock [15:33] but effectively you will always have a bunch of differences to the real thing [15:35] yes, it is hard to be generic.. :-/ [15:41] zumbi: At least in Ubuntu, we explicitly say we aren't building "embedded", so want d-i to just do the right thing. This approach happens to be viable for a huge volume of hardware that others may consider "embedded". [15:42] zumbi: Rather than building a new embedded installer, what might be helpful is improving the image modification tools in a way that one can easily swap the installed kernel. [15:42] And improving the kernel packaging scripts to make it easy to convert an arbitrary git tree into a packaging tree. [15:43] NCommander: ping [15:45] ogra: what is different compared to ubuntu if you go for a properly seeded rootstock fs and combine that with the kernel/bootloader packages? [15:45] asac: All the base config stuff. [15:45] persia: baseconfig like oem-config? [15:46] asac, debconf [15:46] rootstock surely doesnt seed all of debconf properly yet [15:46] ogra: what pieces are missing there? [15:46] asac: So, the base-config package went away, and the installer handles that. I ended up spending many months fixing a million little issues with moblin-image-creator and we determined it was easier to make ubiquity work for MID than to continue tracking down all the special cases. [15:46] ogra: so its a matter of tweaking seeds? [15:46] asac, no idea, i never made an effort to check that [15:46] asac: No, base-config like the *REALLY OLD* debian package. [15:47] its a matter of integrating rootstock better with debconf [15:47] persia: right. but thats now oem-config? [15:47] and using d-i modules instead of scripts [15:47] asac: Not at all. There is no relation between those packages. oem-config does *some* of the configuration post-install. [15:47] ogra: how do we know that d-i and ubiquity do all the same? [15:47] thats the reason why i switched to oem-config by default [15:47] persia: i agree on improving the kernel packaging scripts, but which ones? (debian, ubuntu, kernel-package, kernel-wedge,.. just reate yet another one) [15:47] But oem-config expects a d-i base install. [15:47] it does a good bunch of that using d-i modules [15:47] for me it feels like there is deviation anyway, though you would call both systems "ubuntu" [15:47] persia, it brings it [15:48] and removes it after it ran [15:48] zumbi: Ummm. I'm going to have to defer to the #ubuntu-kernel folks at this point :) [15:48] asac, right, but target has to be to minimize the deviation [15:48] ogra: No, it runs *some* d-i components. Some stuff never gets run in oem-config. [15:48] asac, which the step to oem-config did for example [15:48] ogra: right. just wanted to point out that quite a lot of details are probably not relevant for "ubuntu" [15:49] ogra: yeah. for me a rootfs + oem-config is ubuntu ;) [15:49] yeah, might be [15:49] thats how we ship stuff to production somewhere too, isnt it? [15:49] nobody researched yet if/what additional pieces are missing in a rootstock install [15:49] asac: In terms of use of the "ubuntu" term, no, but we expect there to be a large number of small bugs with a rootstock-based install (just as there are many known bugs with vm-builder installs, or any other tools that aren't d-i) [15:49] asac, not sure, thats something only OSG can answer [15:50] asac: Nothing called "Ubuntu" ships without a d-i installer to my knowledge. [15:50] right [15:50] I know of specialised remixes that use other installers (the one for the Netwalker is an example). [15:51] and the proper approach for rootstock might also be to run d-i with a preseed file for the second stage [15:51] guys: if I boot x86-64 from 10.04b2 cd can I make bootable pendrive? [15:51] instead of the script it uses atm [15:51] Doing that makes it just a normal install. [15:51] hrw: Sure. [15:52] persia: i would like to see those bugs ;) [15:52] at least one example [15:52] asac, as i said, nobody actually researched the differences [15:52] hrw: You might have to play some games to tell usb-creator to make the pendrive based on the cd in your drive though. [15:52] asac: I'll dig up a URL. [15:52] asac, you would have to diff the debconf DB between a real install and a rootstock one [15:53] i'm very sure there *are* differences ... just dont knwo which [15:54] asac: http://www.sharp.co.jp/support/ex-data/recovery.sh.tar.gz [15:55] asac: http://www.sharp.co.jp/support/mit/doc/install.html has instructions with screenshots (in case you don't read Japanese) [15:57] i wouldnt be able to follow that instruction ;) [15:57] asac: http://translate.google.com/translate?u=http%3A//www.sharp.co.jp/support/mit/doc/install.html&hl=pl&langpair=auto|en&tbb=1&ie=Shift_JIS [15:58] * hrw hails JS menu in bookmarks toolbar [15:58] heh, cool. Japanese->English translation with polish controls [15:58] P [15:58] bookmarklets saves lot of time [15:58] persia: s/hl=pl/hl=en/? [15:59] hrw: If I didn7t already know what the buttons did, yeah :) === XorA is now known as XorA|gone [16:00] persia: before google translate I used "Excite Japan" translator [16:00] it was like 'put url', select 'shelf->something', press button [16:00] Oh, if you skip the hl= bit entirely, it chooses your default once. [16:00] hrw: Excite Japan does a slightly better job with the text, but is less good for web pages. [16:01] time passed, less to do with japanese websites, so google is enough for me [16:01] ~curse sharp [16:02] GrueMaster: hmm, I may have spoken too soon on the dove suspend/resume. The first few times it worked for me but seem to be hitting a problem now [16:02] The Netwalker is actually a nice bit of kit. [16:02] And they seem to be supporting it some. [16:02] No idea if it sells well enough to keep that (likely needs more overseas orders to justify worldwide release) [16:03] netwalker is ugly... [16:04] Yeah, it's a bit large, and it doesn't convert, and the A key is in the wrong place, but other than that, it works. [16:04] and it is imx... [16:06] Well, I guess. I'm more interested in something I can actually put in my pocket and use than which is the best technology inside. [16:06] I have big aversion to xMB kernel patches [16:06] As long as all the other SoCs aren't available as 4-5" handhelds, how cool they are isn't so important. [16:06] I just use the stock kernel, and keep hoping someone will package a newer kernel. [16:06] persia: I have n900 for playing [16:07] hrw: You don't even want to get me started about the shortcomings of that device :) [16:07] Nice internals though. [16:07] persia: I just hope that netwalker team does not have anyone from zaurus teams [16:08] I've no idea. [16:08] 2.4.18-crappix (OE/OZ internal name for 2.4.18-embeddix) was total disaster from sharp [16:08] Dunno. It ships a kernel that works with Ubuntu, which is all I require in a kernel. [16:08] 2.4.18 + arm + pxa + others + bunch of others + wext updates + irda updates + bunch of fixes + bunch another ones [16:09] and only first 4 parts were from sharp [16:09] For this one, amitk said he managed to upstream most of the patches. [16:09] cool [16:11] * amitk looks up [16:11] amitk: where is imx51 mainline branch? [16:11] zumbi: in linus's tree? :) [16:11] *linus' [16:11] amitk: we have efikamx stuff http://gitorious.org/efikamx/linux-efikamx [16:12] amitk: i do not see any mach-mx5 in linus' tree [16:13] 2.6.34-rc? [16:13] 2.6.33 was looking via lxr [16:13] it went in in 2.6.34 [16:13] oh! ok, sorry [16:15] amitk, argh ! [16:15] amitk, read error on /dev/mtd2: cannot allocate memory [16:16] thast where ubiquity dies now :/ [16:17] That's flash-kernel-installer [16:18] ogra: i thought you got mtd write working... [16:19] amitk, it works with d-i [16:21] amitk, worst is that i dont actually read at all [16:22] ogra: is dd able to read/write? [16:22] amitk, seems its fw_setenv thats failing to write [16:22] yes, its dd able [16:22] but mtd2 holds the uboot config [16:23] ogra: Are you passing fw_setenv a mtd or a mtdblock device? [16:23] i only dd to ntd3 and 4 [16:23] echo "/dev/mtd2 0x0000 0x20000 0x20000" > /target/etc/fw_env.config [16:23] lool, ^^^^ [16:25] sounds good [16:25] ISTR the u-boot tools are using mtd calls for io [16:25] which would fail on mtdblock [16:25] i wonder if i need to wipe it like the other ntd devices before writing [16:25] i dont zero it out at install time [16:25] which i do with mtd3 and 4 [16:27] ogra: Have you looked for smarter tools in mtd-utils than dd? [16:27] dd isn't precisely eraseblock aware. [16:27] flash_eraseall + nandwrite -p? [16:28] first cleans mtd, second writes with padding [16:28] ogra: Oh you're dd-ing to mtdN? [16:29] ogra: To write kernels and initrd, you'd better write them directly to mtdblockN [16:30] hrw: Yes, that was what I was thinking, assuming it's NAND. [16:32] lool, i'm just doing what all other arches in flash-kernel do [16:32] persia: I do not remember when last time I used NOR [16:32] mostly NAND or OneNAND recently [16:32] hrw: My netwalker has redboot on NOR, but I don't have any interest in changing it, since the behaviour is sufficient for me. [16:33] lool, flash-kernel was minaly a copy/paste job with some adjustments [16:33] *mainly [16:33] i can reliably reproduce fw_setenv breakage though [16:34] andi suspect it is because uboot-envtools was never recompiled [16:34] ogra: copy&paste of dd against NAND isn't best, even if it's the same as something else. [16:35] persia, it is the same code for *all* platforms in flash-kernel [16:35] persia, rewrite flash-kernel if you feel it behaves wrong :) [16:35] Then I say it's all dangerous at best, and likely bad. [16:35] Maybe, after I deal with other things. [16:35] i'm just using the existing functions in there [16:35] and flash-kernel isnt my problem [16:35] But dd against NAND significantly reduces NAND life. [16:36] my problem is flash-kernel-installer [16:39] http://paste.ubuntu.com/419902/ [16:39] anyone having an idea ^^^^ ? [16:42] amm [16:42] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512589 [16:42] Debian bug 512589 in uboot-envtools "fw_setenv: Cannot malloc -131072 bytes: Cannot allocate memory" [Normal,Fixed] [16:48] * ogra is desparate [16:50] lool, any idea ? [16:50] * ogra doesnt get why it works in d-i [16:51] i have done about twenty netinst installs now and never hit it [16:51] and three -server [16:51] (alternate) === bjf is now known as bjf[afk] [16:54] persia, btw, looking at the code, flash-kernel translates /dev/mtd to /dev/mtdblock at some point [16:54] so the writing goes to mtdblock [16:55] hi. i'd like to be mount the daily .img file on my desktop, instead of using dd to write to SD card, e.g. I want to update the kernel in the .img file. i tried mount -t vfat -o loop xxx and it does not work. how can i do that? [16:55] * persia is slightly mollified [16:55] ndec: You need to use losetup and kpartx: there are multiple partitions on the image [16:55] * persia digs up a reference [16:55] there arent [16:55] there is just one [16:56] ogra: that's what I thought... [16:56] * persia is confused [16:56] but hwat persia said is still true ... either mount with offset or use kpartx [16:56] ndec: http://blog.dustinkirkland.com/2008/10/mounting-kvm-disk-image.html [16:56] ogra: what is the offset? what is the right command? [16:56] you need to use an offset that omits the MBR [16:56] ogra: Ah, so there's only one partition, but it is a partition. That makes sense. [16:56] i think something like -o offset,512 or some such [16:56] or offset=512 [16:58] ndec: use kpartx [16:58] Oooh, `kpartx -av foo.img` is supposed to just work. That saves effort. [16:58] ogra: thx. sudo mount -t vfat -o loop,offset=512 is working! [16:58] Yes [16:58] (remember to use `kpartx -dv foo.img` later) [16:58] mount -o loop,offset=512 imagefile.img /mountpoint shoudl work [16:58] You have to losetup it first [16:58] ogra, why don't I see omap images here? http://cdimage.ubuntu.com/netboot/lucid/ [16:58] lool: Not according to the comments on kirkland's blog [16:58] amitk, because they are ports and not officially supported in lucid [16:59] persia: actually it works, but you can't tell what name it will have [16:59] amitk: http://cdimage.ubuntu.com/ubuntu-netbook/ports/daily-live/current/ [16:59] persia: so it's inconvenient in scripts [16:59] amitk: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/omap/netboot/omap/ [16:59] persia, is right as usual :) [16:59] ogra: That's not a good reason. The issue is that someone in cdimage (hint) needs to add the links to the template script. [17:00] ogra: I'll dig you up a patch tomorrow if you're stuck (we can't land it until post-RC anyway) [17:00] ndec: looking for netboot images, not netbook ;) [17:00] persia, well, if i'm allowed to, i'm not sure what the status on supportability is here [17:00] amitk: these are in the archive directly [17:00] ogra: omap is *already* on cdimage. [17:00] amitk: we dont copy them to cdimage anymore [17:00] ogra: The issue is that they aren't likely to get to release [17:00] right, just found out lool [17:01] amitk: http://ports.ubuntu.com/ubuntu-ports/dists/lucid/main/installer-armel/current/images/ [17:01] persia, i'm currently more worried about the fs_setenv bug that i cant solve [17:01] oh right [17:01] i have no idea whats wrong [17:01] ogra: Go fix that. I'll give you a patch once the cdimage freeze lifts. [17:01] and that it works flawless in d-i doesnt help [17:01] persia, i'd love to, but i have no idea whats going on there [17:02] amitk: Could you file a bug against ubuntu-cdimage about the missing netboot links? [17:03] ogra: if I want to change the bootargs in boot.scr, do I just edit the file with emacs or do I need to regenerate something? [17:04] ndec: usually i remove the stuff from top, and then run mkimage ... again [17:04] after editing [17:04] that works quite well [17:05] GrueMaster, saeed: are either of you able to reproduce the suspend/resume problems I just updated the bug with on dove? [17:05] plars: bug #? [17:05] hey. had reconnect [17:05] GrueMaster: https://bugs.launchpad.net/ubuntu/+source/linux-mvl-dove/+bug/551491 [17:05] Launchpad bug 551491 in linux-mvl-dove (Ubuntu) "BSP update for Marvell Dove kernel LSP 5.1.0 (affects: 1) (heat: 8)" [High,In progress] [17:06] if something was written i didnt get it [17:06] * ogra had a OOM on his laptop [17:06] sigh [17:06] lucid sucks [17:06] ogra: hmm. i didnt hear that ;) [17:06] https://bugs.edge.launchpad.net/bugs/565981 [17:06] Launchpad bug 565981 in xorg-server (Ubuntu Lucid) (and 1 other project) "[KMS] gem objects not deallocated (affects: 15) (dups: 2) (heat: 96)" [Critical,Confirmed] [17:07] pitti just mailed -devel about it [17:07] plars: What do you mean by "enable audio" [17:07] ouch [17:07] yeah [17:07] i have to reboot once a day and see a lot of sad faces in chromium every day [17:08] ogra: chromium != lucid ;) [17:08] asac_, so with the fw_setenv bug i doubt we can have netbook for lucid [17:08] (intentionally) [17:08] asac_, chromium is just fallout [17:09] in the end my whole desktop dies [17:09] GrueMaster: unmuting the hp jack [17:09] GrueMaster: so that audio works [17:09] Ok, might want to clarify that in the bug report. [17:09] GrueMaster: not sure that it's related, but I think it's about the only thing I did between the time it worked, and stopped working [17:09] Otherwise it sounds like audio is disabled by default (it isn't). [17:10] GrueMaster: not truly disabled, no, you just can't hear anything til you do that [17:10] Yes, you can if you have the right hookup. [17:11] asac, another reconnect ? [17:11] I have a 2 RCA-to-mini female cable for just this purpose. [17:12] Just because the platform is designed with different audio jacks than normal desktops doesn't mean audio is disabled or not working by default. [17:13] Babbage has a special connector for laptop speakers and defaults to that (I'm still looking into the HP jack single channel issue on it though). [17:13] have a nice rest of day === hrw is now known as hrw|gone [17:14] * ogra has a screwed rest of day now :( after realizing the netbook image wont work [17:18] ogra: no i was connected through a second irc client until i was able to get my new ip ;) === bjf[afk] is now known as bjf [17:18] ah [17:18] GrueMaster: oh, ogra resolved that this morning [17:19] resolved what? [17:19] GrueMaster: use the hdphone jack instead, make sure it's set to audio output stereo [17:19] GrueMaster: on imx51, the single channel problem [17:19] ok, I'll try it here. [17:20] GrueMaster, HDSET -> mono phone headset, HDPHONE -> headphones (my guess) [17:20] you could probably take a look in the docs though to confirm that [17:21] GrueMaster: seems that there's no good way to get input though [17:39] plars: Why not plug a headset into the imx51 and try it that way? I have one here I can try. [17:39] oops, different plug. [17:41] GrueMaster: hmm? I'm not following. I did try it and it worked for me [17:43] I was referring to the input. [17:43] GrueMaster: I tried it briefly without success, but admittedly have not had much time to spend on it yet [17:43] If that is a headset jack, then it should be able to work with a standard phone headset (proficed the plug is the same size). [17:44] GrueMaster: ah, no I was just trying with a normal mic [17:44] normal mic might be wired wrong for this. [17:51] ogra: based on your previous comments, I assume the FlashKernel errors from Ubiquity on omap are still to be expected? [18:05] plars: I can get recording working on my babbage using the mic from my babbage 1 plugged into the internal connector. [18:06] * Martyn has audio working on the tegra2 .. but using a USB adapter [18:06] I'll need to keep hacking away at the linux driver for the SoC based hardware [18:06] Martyn: USB audio is a completely different driver set. [18:07] Still alsa, but not soc audio. [18:07] GrueMaster: Yep! [18:07] GrueMaster: But I needed it to work temporarily :) [18:08] so it was a good interim solution [18:08] I nearly have the tegra2 built in audio working.. there's an issue with the buffer I'm trying to solve [18:08] but I definitely have the mic input working now [18:34] plars, yes and i have no idea how to fix it :( http://paste.ubuntu.com/419902/ [18:34] it doesnt occur in d-i installs at all [18:35] ogra: something, probably in ubiquity, is trying to grab a huge chunk of ram it seems [18:35] ogra: any chance we could fiddle with the compcache percentages and make it happier? [18:35] plars, well, at that point there is even real swap available [18:36] ogra_cmpc: but order 5 is 128M right? [18:36] ogra_cmpc: that is clearly going to fail under our current setup [18:36] no matter how much swap we have [18:36] ubiquity calls swapon dirctly after partitioning [18:37] we use 128M compcache, right [18:37] i wonder if we need it at all now that we run in only-ubiquity mode [18:38] RAM should be sufficient to get through to the installer [18:38] err [18:38] partitioner [18:39] ogra: ram only? or back to 25% compcache? [18:39] plars, if you want to test that you could swapoff ramzswap after partitioning on tty [18:39] or even before [18:40] i wonder if we probably hit a general compcache issue here [18:40] ogra_cmpc: yeah, will give it a try. Is swapoff enough to make it let go of that memory? [18:40] rmmod probably too === hrw|gone is now known as hrw [19:50] ogra_cmpc: ok, I did the swapoff and rmmod early (right after booting) and still got a couple of page_alloc failures early on, but I was able to complete the install! [19:54] plars, dang ... not sure how to special case that in a nonintrusive way that slangasek accepts [19:54] i'll think about it we cant do anything before RC anyway [19:55] ogra_cmpc: I'd like to experiment a bit... I'm wondering if we could tone down the 50% to something like 35% and get away with it [19:55] plars, thanks a lot for the test ! [19:55] ogra_cmpc: at the very least, we have a cumbersome workaround [19:55] sure, play if you like [19:55] yeah [19:55] very good work ! [19:57] ogra_cmpc: I'll open a new bug against casper on this, rather than recycle the old one, unless you feel different? [19:57] yeah, do that [19:57] I think circumstances have changed enough that just tacking it on and reopening the old one would be confusing [19:58] indeed [19:58] though the question is if slangasek will allow it or not [19:58] and i also think it might really be specific to the omap kernel [19:59] i.e. .33 obviously has a new compcache implementation, there is very likely a reason for that [20:00] would be intresting to see what a babbage board does in the same case if you boot with mem=256M === hrw is now known as hrw|gone === XorA|gone is now known as XorA === jmcgee is now known as jmcgee|gone