| === xfaf is now known as zul | ||
| DanaG | Say, if I use an overlay and have an SD card write-protected, how long should it last? | 04:45 |
|---|---|---|
| persia | "how long" in what sense? | 04:47 |
| persia | Your overlay changes will last as long as your session lasts. | 04:47 |
| persia | Your SD media will last until entropy destroys the data (card- and environment- dependent) | 04:47 |
| DanaG | The latter is what I meant... media longevity. | 04:48 |
| persia | Then it depends on more factors than I can express. I can say "longer than if you write to it". | 04:50 |
| persia | longer if you stick your device in a lead-lined box (but not much, most of the radiation will be from components in the device, unless you put it somewhere particularly active) | 04:50 |
| persia | Putting it in a faraday cage will protect against some other interference. | 04:51 |
| persia | And so on... | 04:51 |
| persia | (using a shielded SD card, with an internal grounded faraday cage surrounding the flash might help, but that requires manufacturer connivance) | 04:52 |
| DanaG | What sort of time-span would the wearing-out likely be? 1 year? 2? 10? | 04:53 |
| persia | I can't answer that. Ask your SD manufacturer. | 04:56 |
| DanaG | ah. | 04:58 |
| persia | I used to work at a data manipulation firm. We sold the results of queries against our datasets. We bought the highest-reliability drives we could. Nonetheless, at my next job interview, when asked "Which commands do you use the most in the shell", I was told I must not use UNIX much because fdisk was in my answers. | 04:58 |
| persia | These were drives with multi-year MTBF ratings, but we had 5-10 failures a week. | 04:58 |
| DanaG | Is that due to luck, or just due to large sample size? | 04:59 |
| persia | Anyway, from a software perspective, if you only write to the flash once, you'll never end up with eraseblock issues, or wearing considerations, etc. | 04:59 |
| persia | large sample size. | 04:59 |
| persia | It was several TB of data stored over 9GB drives (the largest available at the time) | 04:59 |
| === Baybal_ is now known as Baybal | ||
| DanaG | Say, I figured out what was up with the hardlink troubles: http://lkml.org/lkml/2010/6/23/25 | 07:58 |
| === hrw|gone is now known as hrw | ||
| hrw | morning | 08:21 |
| hrw | persia: thousands of harddrives? | 08:22 |
| persia | Yep. All wired up through cabinets to a 6-way Turbolaser @ 600MHz. Bug iron for the day :) | 08:23 |
| persia | s/Bug/Big/ | 08:23 |
| hrw | impressive | 08:24 |
| DanaG | Say, that Airlife 100... what're the chances of getting Ubuntu on that? | 09:23 |
| DanaG | http://carrypad.com/productinfo/?id=606 | 09:23 |
| * persia looks | 09:24 | |
| DanaG | "Qualcomm SnapdragonTM QSD8250 (GSM/UMTS) 1GHz" | 09:26 |
| persia | http://www.qualcomm.com/products_services/chipsets/snapdragon.html completely fails to indicate ISA support. | 09:28 |
| persia | Anyway, if it's ISA-compatible, it's a kernel away. | 09:28 |
| persia | If not, too bad. | 09:28 |
| persia | Heavy though, at 1kg for a 10" notebook. | 09:28 |
| persia | Oh, and low-color screen (65,536 colors) | 09:29 |
| DanaG | Bleh. | 09:29 |
| persia | Indeed. | 09:29 |
| DanaG | I'm eyeing the Tegra2 stuff... I just wish they'd use Ubuntu instead of Android. | 09:29 |
| persia | Lots better 10" low-end laptops out there. | 09:29 |
| hrw | snapdragon is armv7 | 09:30 |
| persia | hrw, *all* snapdragon? Fully compliant? I know it's not coretex. | 09:30 |
| hrw | afaik 8250 is armv7 | 09:37 |
| hrw | but I may be wrong | 09:38 |
| persia | That likely makes it ISA-compatible then, making installing Ubuntu mostly a matter of finding a kernel, and knowing how to boot your desired kernel. | 09:44 |
| === amitk is now known as amitk-afk | ||
| === amitk-afk is now known as amitk | ||
| === asac_ is now known as asac | ||
| === xfaf is now known as zul | ||
| === kmargar is now known as markos_ | ||
| rsalveti | ogra: what happened with our builders? | 13:16 |
| rsalveti | the email I got has now messages :-) | 13:17 |
| rsalveti | *no | 13:17 |
| ogra | rsalveti, they were dead | 13:18 |
| ogra | all solved now | 13:18 |
| rsalveti | ogra: oh, cool | 13:18 |
| ogra | lag, if bug 625108 is solved with ES2 HW you dont need to work on it | 13:23 |
| ubot2 | Launchpad bug 625108 in linux-ti-omap4 (Ubuntu) "System hangs when you run ifconfig usb0 up and ifconfig usb0 down (affects: 1) (heat: 8)" [High,Confirmed] https://launchpad.net/bugs/625108 | 13:23 |
| ogra | we'll switch everything to ES2 after beta | 13:24 |
| lag | I'm not working on it per-say, rather taking responsibility for it | 13:25 |
| ogra | ah, k | 13:25 |
| lag | ogra: Don't worry, I'm not wasting my time, it's too precious | 13:26 |
| ogra | heh | 13:26 |
| lag | Who's tested the ES2.0? | 13:47 |
| rsalveti | lag: I did | 13:47 |
| rsalveti | GrueMaster also tested | 13:47 |
| lag | [ 521.163452] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX | 13:48 |
| lag | [ 521.221771] omapdss DISPC error: SYNC_LOST_DIGIT | 13:48 |
| lag | Did you get that? | 13:48 |
| lag | That happened during oem-config and the monitor turned itself off | 13:48 |
| rsalveti | lag: nops | 13:48 |
| lag | That was with my Phillips monitor | 13:48 |
| lag | I'll try it with my LG one | 13:49 |
| rsalveti | but was it working with correct resolution before turning itself off? | 13:49 |
| lag | rsalveti: Yeah, it looked fine | 13:49 |
| lag | When I initially started it up, it configured the rebooted and there was nothing | 13:50 |
| lag | Then I restarted it with my own boot.scr and it worked | 13:50 |
| lag | 5 mins into oem-config and [pow] | 13:50 |
| rsalveti | our 2.6.35 tree should have most of the hdmi fixes from robclark, so it should work better | 13:50 |
| rsalveti | at least it worked fine with my LG monitor | 13:50 |
| lag | rsalveti: Nope, this is your kernel ;) | 13:50 |
| rsalveti | lag: should be ok also | 13:51 |
| lag | Clearly it isn't :) | 13:51 |
| rsalveti | bugs :-) | 13:51 |
| lag | Arggggggggggggggggg BUGSSSSSSSSS | 13:51 |
| lag | mythripk: Afternoon | 13:52 |
| rsalveti | lag: test with your lg to see if you get a similar bug | 13:52 |
| lag | rsalveti: I'm doing so now | 13:52 |
| lag | rsalveti: That heartbeat LED is annoying | 13:54 |
| rsalveti | lag: haha :-) | 13:54 |
| lag | boom boom ... boom boom ... boom boom ... | 13:54 |
| rsalveti | at least you now know that the board is up and running :-) | 13:54 |
| lag | boom boom ... boom boom ... boom boom ... | 13:54 |
| rsalveti | lol | 13:55 |
| lag | rsalveti: Looks stable enough on the LG | 13:57 |
| ogra | as i said from the beginning, TI shoudl just ship proper monitors with the boards | 13:58 |
| rsalveti | haha | 13:58 |
| ogra | would have saved so much work for so many people :) | 13:58 |
| rsalveti | lag: so probably the issue is now related with phillips monitors | 13:58 |
| lag | rsalveti: Could be | 13:59 |
| * rsalveti imagining a huge box getting into his house with the monitor and the board | 13:59 | |
| ogra | who busy phillips anyway | 13:59 |
| lag | I only have those two lines to tell me anything though | 13:59 |
| ogra | *buys | 13:59 |
| rsalveti | lag: put the debug argument and try again | 13:59 |
| lag | Canonical do | 13:59 |
| ogra | silly canonical :P | 13:59 |
| lag | rsalveti: I will (still testing with LG) | 14:00 |
| rsalveti | lag: ok | 14:00 |
| lag | rsalveti: Same thing with LG | 14:01 |
| lag | [ 566.867828] omapdss DISPC error: GFX_FIFO_UNDERFLOW, disabling GFX | 14:01 |
| lag | [ 566.925109] omapdss DISPC error: SYNC_LOST_DIGIT | 14:01 |
| rsalveti | lag: that's weird | 14:03 |
| rsalveti | lag: could be you or your board again | 14:03 |
| rsalveti | :P | 14:03 |
| lag | rsalveti: No way! | 14:04 |
| lag | rsalveti: Two boards is unlucky enough, three would be ridiculous | 14:04 |
| rsalveti | haha | 14:08 |
| robclark | lag: do you have x-loader w/ DDR timings tweaks and 1gb support? | 14:16 |
| robclark | without that, I don't think DSS gets enough memory bandwidth to feed a 1920x1080 hdmi monitor.. | 14:17 |
| lag | robclark: Probably not? | 14:17 |
| * robclark finds link | 14:17 | |
| lag | I'm suing the ones rsalveti gave me | 14:17 |
| robclark | oh.. hmm.. es1 or es2? | 14:18 |
| rsalveti | lag: do you know exactly which one you got from me? | 14:18 |
| rsalveti | I built 2, one with 1gb and another with current gitorious tree | 14:18 |
| robclark | rsalveti / lag: looks like last two commits are not on official tree yet: http://gitorious.org/~robclark/pandaboard/robclarks-x-loader/commits/omap4_panda_es2.0-1gb | 14:19 |
| robclark | but I was seeing lots of GFX (and VID when doing video playback) underflows without those last two | 14:20 |
| robclark | (and last one lets you build w/ highmem and get a gig) | 14:20 |
| robclark | brb | 14:20 |
| * robclark gets coffee | 14:20 | |
| rsalveti | lag: http://people.canonical.com/~rsalveti/maverick/boot/es2/x-load.bin-1gb | 14:22 |
| rsalveti | did you test with this one? | 14:22 |
| rsalveti | this binary is from robclark's tree | 14:22 |
| lag | rsalveti: It doesn't look familiar | 14:23 |
| lag | rsalveti: I'm using the one you linked me to | 14:23 |
| lag | rsalveti: The one with u-boot-with-ubuntu-patches.bin | 14:23 |
| rsalveti | argh, disconnected, very unstable gsm connection | 14:25 |
| * rsalveti at linuxcon brazil | 14:25 | |
| rsalveti | lag: test with: | 14:31 |
| rsalveti | http://people.canonical.com/~rsalveti/maverick/boot/es2/MLO-1gb | 14:32 |
| rsalveti | and http://people.canonical.com/~rsalveti/maverick/boot/es2/u-boot.bin-with-ubuntu-patch | 14:32 |
| lag | rsalveti: Doing that now | 14:32 |
| rsalveti | cool | 14:32 |
| lag | ogra said that the vfat is trashed on first boot, do I need to change it somewhere else other than /boot? | 14:33 |
| rsalveti | lag: the vfat is trashed with this u-boot, and fixed with upstream one | 14:34 |
| rsalveti | lag: so grab the files, copy to a folder, format the partition and copy the new files | 14:35 |
| lag | rsalveti: No, I mean formatted | 14:35 |
| lag | ogra: ... | 14:35 |
| ogra | rsalveti, vfat is reformatted in jasper to make sure x-loader ends up in the first block after re-partitioning | 14:38 |
| rsalveti | ogra: oh, true, right | 14:38 |
| rsalveti | saw the code yesterday | 14:38 |
| lag | ogra: So I need to update the one in the boot partition and ? | 14:38 |
| ogra | we shouldnt need that for omap4 anymore, but omap3 definitely requires it | 14:39 |
| ogra | lag, kernel and initrd come from /boot in the rootfs | 14:39 |
| ogra | err, wait | 14:39 |
| lag | And x-loader? | 14:39 |
| ogra | no | 14:39 |
| ogra | you dont need to do anything | 14:39 |
| ogra | it gets copied from vfat to a tmpfs | 14:39 |
| ogra | and gets restored from there | 14:39 |
| lag | Well I'm replacing /boot/boot.script with my own one for a start | 14:40 |
| lag | Ah, that's good | 14:40 |
| lag | So it's just boot.script that I need to update | 14:40 |
| ogra | initrd gets re-rolled after oem-config is run | 14:40 |
| ogra | *then* it uses the stuff from /boot | 14:40 |
| lag | Okay | 14:40 |
| ogra | jasper just uses the tmpfs | 14:40 |
| lag | I notice that /boot/boot.script is headless | 14:41 |
| lag | Is the header attached during installation? | 14:41 |
| ogra | flash-kernel runs mkimage | 14:41 |
| lag | k | 14:41 |
| lag | Then I'm all set | 14:41 |
| ogra | /boot/boot.script is headless on purpose | 14:41 |
| ogra | *headerless | 14:41 |
| lag | ogra: I didn't think anything different | 14:42 |
| ogra | imagine menu.lst here ... its the file a user should be able to edit for canges | 14:42 |
| ogra | and then just run flash-kernel to update the actual boot.scr | 14:42 |
| GrueMaster | lag: I'll retest bug 615400 after I test beta. It requires a bit of work to test, as It involves a full upgrade from Lucid (which is really the only time you'd run into it). | 15:02 |
| ubot2 | Launchpad bug 615400 in flash-kernel (Ubuntu Maverick) (and 1 other project) "package initramfs-tools 0.97.2ubuntu1 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1 (affects: 1) (heat: 8)" [Undecided,Triaged] https://launchpad.net/bugs/615400 | 15:02 |
| lag | GrueMaster: No rush :) | 15:02 |
| GrueMaster | I'm just going through my emails & retest requests. :P | 15:03 |
| persia | GrueMaster, Were you ever able to replicate bug #613591 ? | 15:09 |
| ubot2 | Launchpad bug 613591 in jasper-initramfs (Ubuntu) "Jasper sometimes fails to resize root partition on omap4 (affects: 1) (heat: 167)" [Undecided,New] https://launchpad.net/bugs/613591 | 15:09 |
| GrueMaster | Not lately. | 15:09 |
| === amitk is now known as amitk-afk | ||
| * persia grumbles about unreproducible bugs | 15:27 | |
| lag | ogra: /boot/boot.script - it gets written over | 15:40 |
| lag | Where does it come from? | 15:40 |
| GrueMaster | lag: it is generated by jasper during first boot. | 15:44 |
| lag | How do I un-generate it? | 15:44 |
| lag | It's a pain in the ass | 15:44 |
| GrueMaster | If you are running our preinstalled images, it is created the first time it boots, and not touched again. | 15:45 |
| persia | Anyone have a jasper-based boot on a beagle with a resolution *other* than 1280x720 ? I'd appreciate any testing of the patch on bug #605831 | 15:45 |
| ubot2 | Launchpad bug 605831 in jasper-initramfs (Ubuntu Maverick) (and 1 other project) "Resolution should be taken from /proc/cmdline if provided (affects: 1) (heat: 8)" [Medium,Triaged] https://launchpad.net/bugs/605831 | 15:45 |
| GrueMaster | persia: isn't that the default in the boot image? | 15:45 |
| GrueMaster | I'm still pulling dailies. Will test when I can, if I can. | 15:47 |
| persia | GrueMaster, The patch is supposed to allow you to set an alternate default on the kernel command line. What I don't know is whether it works for someone with such hardware. | 15:54 |
| GrueMaster | Ideally, we shouldn't need any cmdline parameter for display resolution. | 15:55 |
| persia | Yeah, well. That requires better X autodetection than has been historically available | 15:59 |
| persia | But I'd rather allow folks to specify something other than default, as long as it needs to be hardcoded. | 15:59 |
| devilhorns | I've been having a lot of problems getting maverick installed/working on this laptop and was wondering if there are updated images (tried alpha-3), or perhaps another method I could use to get it installed ? | 16:02 |
| GrueMaster | devilhorns: What laptop? Arm based? | 16:02 |
| devilhorns | GrueMaster, no, this is x86. trying to get maverick installed on it so that I can do some development for arm devices | 16:03 |
| GrueMaster | Unfortunately, this channel is focused on Arm porting issues only. But I'm sure there is someone in #ubuntu-desktop that could help. | 16:04 |
| GrueMaster | We can help on the arm side. | 16:04 |
| GrueMaster | :P | 16:04 |
| devilhorns | yea ... alright, guess I am stuck w/ a broken box then, but thanks :/ | 16:05 |
| GrueMaster | Not necessarily. We're just not the right group to field x86 issues to. I also have a new x86 netbook that has issues with Maverick, but the people in #ubuntu-desktop are better equipped to help. | 16:06 |
| devilhorns | fair enough :) | 16:07 |
| persia | Or the folks in #ubuntu-testing might be inclined to help (although they'll want you to test pre-betas) | 16:09 |
| devilhorns | persia, hmmm, those may actually work, thanks :) | 16:09 |
| devilhorns | persia, seems I have better luck w/ alpha or pre-beta than I do w/ any releases :) | 16:09 |
| persia | devilhorns: The trick is to get really fussy about the regressions between beta and release :) | 16:10 |
| devilhorns | persia, lol, well not in my nature to get fussy :) | 16:10 |
| lag | ogra, GrueMaster: Why is x-loader.bin deleted? | 16:42 |
| lag | robclark: Have you tried to use our images? | 16:43 |
| GrueMaster | Huh? | 16:44 |
| GrueMaster | Where is it deleted? | 16:44 |
| lag | On first boot I guess | 16:44 |
| lag | boot.scr MLO u-boot.bin uImage uInitrd | 16:45 |
| lag | That's all that's left on the card | 16:45 |
| GrueMaster | MLO is x-loader | 16:45 |
| GrueMaster | Unless I am missing something. | 16:45 |
| lag | You are | 16:45 |
| lag | Apparently we need robclark's new fan-dangled x-loader.bin | 16:46 |
| lag | Which I loaded | 16:46 |
| lag | Then, something (usually bloomin' Jasper) deletes it | 16:46 |
| GrueMaster | No, jasper just doesn't know about it. | 16:47 |
| GrueMaster | for file in MLO boot.scr u-boot.bin uImage uInitrd; do | 16:47 |
| GrueMaster | That's from the section that reformats the vfat partition with proper CHS info. | 16:48 |
| GrueMaster | (why he doesn't just do "cp MLO boot.scr u-boot.bin uImage uInitrd * <target>" I don't know | 16:49 |
| persia | Try naming the new fan-dangled x-loader.bin "MLO" | 16:49 |
| GrueMaster | That was my next suggestion. | 16:49 |
| robclark | lag: kernel images.. or filesystem? | 16:49 |
| robclark | I pretty much only build my own kernels.. and filesystem I use I get from ndec and crew | 16:49 |
| persia | GrueMaster, Because of the sync() between each file write: it's a filesystem coherency concern (FAT isn't known to be as safe as some filesystems) | 16:50 |
| GrueMaster | ah. | 16:51 |
| lag | I can try to name x-loader.bin -> MLO and see if that works | 16:51 |
| robclark | fwiw persia, the MLO is signed.. so I'm not sure if you can just cp x-loader.bin MLO | 16:51 |
| lag | Ah | 16:51 |
| lag | Then we need a better solution | 16:52 |
| lag | I don't know how this worked for rsalveti ? | 16:52 |
| persia | Jasper needs to be generalised, but that's probably not safe within maverick timeframe. | 16:52 |
| robclark | lag: in x-loader tree there is a signGP script which can be used to make a MLO from an x-loader.bin.. | 16:52 |
| robclark | I've not looked much at how it works.. but might be interesting to you | 16:52 |
| robclark | but.. why do you have an x-loader.bin instead of x-loader.bin.ift (which is same as MLO)? | 16:53 |
| lag | I've never seen a x-loader.bin.ift | 16:54 |
| robclark | usually it is renamed immediately to MLO ;-) | 16:55 |
| robclark | I guess you only see the ift if you build x-loader yourself | 16:55 |
| lag | Which I haven't done | 16:55 |
| lag | Can you make me a fan-dangled MLO? | 16:55 |
| GrueMaster | lag: where did you get the x-loader.bin from? | 16:56 |
| lag | robclark | 16:56 |
| robclark | did I send you an x-loader.bin? | 16:56 |
| GrueMaster | ah | 16:56 |
| robclark | I probably meant to send an MLO.. opps | 16:56 |
| lag | Actually, I think you gave it to rsalveti, and he gave it to me | 16:57 |
| robclark | lag: I just mailed to you a MLO | 16:57 |
| lag | In fact | 16:57 |
| lag | Look: http://people.canonical.com/~rsalveti/maverick/boot/es2/ | 16:57 |
| lag | That's why it worked for rsalveti | 16:58 |
| lag | He's been trying to stitch me up! ;) | 16:58 |
| lag | Thanks robbiew | 16:58 |
| lag | Doh | 16:58 |
| robclark | heheh | 16:58 |
| lag | Thanks robclark | 16:58 |
| robclark | np | 16:58 |
| lag | Luckily robbiew isn't anyone important ;) | 16:58 |
| lag | Eeeeeeeeeeeeeeeeek! | 16:58 |
| GrueMaster | Now would any of us try to confuse our kernel dev's? | 16:59 |
| lag | I'm guessing rsalveti didn't know any better | 17:00 |
| robbiew | heh...I'm not important at all ;) | 17:01 |
| lag | I'll give him the benefit of the doubt | 17:01 |
| lag | robbiew: Sorry for the disturbance :D | 17:01 |
| lag | robbiew: Bloomin' tab complete | 17:01 |
| robbiew | no worries | 17:01 |
| GrueMaster | Tab complete works for people that know how to use it properly. ;p | 17:04 |
| * GrueMaster hides. | 17:05 | |
| === rbelem_ is now known as rbelem | ||
| === hrw is now known as hrw|gone | ||
| * rsalveti reading the backlog | 19:06 | |
| rsalveti | lag: you should use MLO-1gb | 19:11 |
| rsalveti | as I pointed later for you | 19:11 |
| GrueMaster | rsalveti: I think he figured that out. | 19:11 |
| rsalveti | that was compiled using robclark's tree and etc | 19:11 |
| rsalveti | the harder way | 19:12 |
| rsalveti | too bad I wasn't on-line | 19:12 |
| rsalveti | lag: did it work better with your monitor now? | 19:12 |
| rsalveti | GrueMaster: are you still facing the hang over the second boot at your images? | 19:13 |
| GrueMaster | Not sure. Haven't gotten that far yet. | 19:15 |
| GrueMaster | Was having desktop issues. Had to upgrade/reboot. | 19:15 |
| GrueMaster | One issue that seems to have resolved itsself is that the XM failed to load oem-config. Working now after zeroing out the microSD and reflashing. | 19:16 |
| rsalveti | hm, ok | 19:17 |
| GrueMaster | panda just finished oem-config. After it logs in, I'll reboot and see. | 19:17 |
| * GrueMaster wishes for more SD card readers to help parallelize reflashing. | 19:18 | |
| rsalveti | I discovered yesterday that using my built-in sd slot from my eeepc lets me write the sd image much faster than the usb one I have | 19:19 |
| GrueMaster | Hrm. the home button ENOWORKS. | 19:19 |
| GrueMaster | Yea, I would use the one on my netbook, but it is not supported by the kernel yet. | 19:19 |
| GrueMaster | And I'm out of both power plugs & desk space to attempt to resuscitate my old laptop. | 19:20 |
| dcordes | Hey guys. Just checked if I still get the wrong default gdm session. Used yesterday's image and it the error seems to persist | 19:31 |
| dcordes | -it | 19:32 |
| GrueMaster | Is that after running "/usr/lib/gdm/gdm-set-default-session une-efl"? | 19:39 |
| dcordes | GrueMaster: no. after that it always works | 19:39 |
| GrueMaster | Then it isn't an image issue. That cmd is run during our first-boot process. | 19:40 |
| dcordes | Ah ok then I can close the bug | 19:40 |
| dcordes | GrueMaster: It's not ran by oem-config right ? | 19:43 |
| GrueMaster | No, it is a part of jasper scripts that run in our initrd. | 19:44 |
| dcordes | GrueMaster: Ok. Have you considered including /etc/gdm/custom.conf with the according session line directly in the rootfs ? | 19:44 |
| GrueMaster | It would break other images that actually support 3D. | 19:45 |
| dcordes | Which use the exact same omap4 image ? | 19:48 |
| dcordes | Let me restate... Why do you want to keep machine specific configuration outside of the actual rootfs ? | 19:49 |
| GrueMaster | The basic image build process is the same across all arches that generate Ubuntu Netbook images. | 19:49 |
| GrueMaster | The preinstalled images for omap are identical to the live images for other armel platforms, and near identical to x86 images (we don't include openoffice as it is currently not building). | 19:50 |
| dcordes | Ah I have been wondering about the oo.org lack :) | 19:51 |
| dcordes | You said defaulting to une-efl in the rootfs (stock configuration) will break other images (machines?) that support 3d | 19:52 |
| dcordes | That raises two questions for me. Is it no the other way around i.e. efl session works on all machines ? Are the 3d machines not using an initramfs as well that could write the 3d session ? | 19:54 |
| GrueMaster | The problem is that the default launcher is Unity, which requires clutter (3D). Over 95% of the users of the base image will have support. And currently, the desktop team that is developing the core UNE don't have enough manpower to develop a clean way to determine which launcher to use by default. It will probably happen next cycle though. | 19:57 |
| dcordes | Ok so people are thinking about that already. | 19:59 |
| dcordes | That's good. I guess in the future you will stumble across more such machine specific questions | 20:00 |
| dcordes | What's the name of the 3d gdm session ? | 20:01 |
| GrueMaster | It worked last cycle, but the UNE developers are creating a new 3D launcher from scratch, plus there were gnome changes. At this point, we're too close to release to have a permanent solution added, so a little hacking is required. | 20:02 |
| dcordes | For me that's absolutely no problem. I have quite a list of items I need to apply for my machine to be usable anyway | 20:03 |
| dcordes | GrueMaster: What do you think? Keep the bug 'incomplete' until a global solution to write the correct gdm config for the target is present or close it because it is fixed for the 'supported' machines ? | 20:08 |
| dcordes | bug 625591 | 20:08 |
| ubot2 | Launchpad bug 625591 in jasper-initramfs (Ubuntu) "[ARM] ubuntu-netbook defaults to 3D session even after "fix" by jasper-initramfs (affects: 1) (heat: 10)" [Medium,Incomplete] https://launchpad.net/bugs/625591 | 20:08 |
| GrueMaster | Since you have your own kernel and boot method, you might take a look at our dove images instead. The next build should have a temporary fix. But it is a live image (similar to our cd images on x86). | 20:11 |
| dcordes | GrueMaster: Cool. Right now I am solving some kernel issues: WiFi driver is not detected by NetworkManager, Suspend is broken, framebuffer driver version is incompatbile with xf86-video-msm. Soon as I have these things solved and tested in the omap4 image I can try dove | 20:28 |
| dcordes | I am also going to look into utouch. I installed it already but it does not work out of the box. The test programs claim my touchscreen input device is not suported. I have yet to figure what utoutch expectes on the kernel driver level. | 20:29 |
| dcordes | I am wondering about a known working utouch touchscreen device driver so I can compare | 20:30 |
| GrueMaster | no idea. Not something I can readily test. | 20:39 |
| dcordes | GrueMaster: posted a bug on it :) | 20:48 |
| rsavoye | hum, arm-linux-gnueabi-objcopy doesn't appear to work on lucid-amd64... | 21:20 |
| dcordes | rsavoye: is that CS toolchain ? | 21:21 |
| rsavoye | it's from a ppa,. let me check | 21:22 |
| rsavoye | deb http://people.canonical.com/~hrw/ubuntu-maverick-armel-cross-compilers/ ./ | 21:22 |
| rsavoye | the object file was produced on an imx51 maverick based board | 21:22 |
| rsavoye | it works natively, it's just slow | 21:23 |
| dcordes | heh I remeber a blog entry from hrw|gone about starting to compile cross toolchains for canonical | 21:24 |
| rsavoye | so I tried to dissasemble it on the machine that was NFS exporting the build directory to the board | 21:24 |
| rsavoye | this is from his repo | 21:24 |
| dcordes | yeah | 21:24 |
| rsavoye | it doesn't like the magic number I think | 21:24 |
| rsavoye | it says it's an unsupported type | 21:24 |
| dcordes | hm so far I only compiled natively | 21:25 |
| dcordes | on my machine in maverick | 21:25 |
| rsavoye | me too, but the object files were on an NFS partition so I tried there for grins | 21:25 |
| rsavoye | I' | 21:26 |
| rsavoye | ll try on a 32bit machine for another test | 21:26 |
| dcordes | hrw|gone: sure has tested the cross toolchains on amd64 host machine. People would have come across the problem already | 21:26 |
| rsavoye | at least the object file is produced from a GPL'd program :-) | 21:26 |
| rsavoye | it might work if you built it al cross. here it was built on maverick-arm, and objdump'd on lucid-amd64 | 21:27 |
| rsavoye | which should work fine | 21:27 |
| rsavoye | objdump: Can't disassemble for architecture UNKNOWN! | 21:32 |
| rsavoye | yep, it dissasemnles fine on a 32bit host, but fails on amd64 | 21:32 |
| rsavoye | guess I get to file a bug report | 21:32 |
| dcordes | hrw|gone: might help you | 21:35 |
| mpoirier | davidm ? | 21:54 |
| lag | rsalveti: Yes, it now works | 22:02 |
| ogra_cmpc | GrueMaster, jasper isnt using cp because for omap3 we need to make sure MLO ends up in the very first block of the vfat (i used to just have a separate function for MLO but that didnt make sense so i wrote that loop) | 23:36 |
| GrueMaster | ok. Doesn't matter at this point. Issue was resolved. | 23:37 |
| ogra_cmpc | yep just wanted to explain why it is as it is | 23:38 |
| ogra_cmpc | panda shouldnt need that anymore but jasper is used on both, omap3 and 4 | 23:38 |
| dcordes | Is there a list of supported hardware ? | 23:42 |
| dcordes | ARM hardware | 23:42 |
| dcordes | I keep getting confused about all the boards you guys are talking about | 23:42 |
| GrueMaster | I'm not sure that we have one readily available. We have two main focuses: build & support Ubuntu on armv7 based hardware, and build & support images on specific systems. | 23:51 |
| GrueMaster | First part is carried across releases. Second one can change every cycle due to contracts. | 23:52 |
| GrueMaster | And sometimes it changes mid-cycle. | 23:53 |
| GrueMaster | But for the most part, we are driving towards armv7 support in the entire Ubuntu pool of applications. | 23:54 |
| GrueMaster | Does that make sense? | 23:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!