| === Jack87_Away is now known as Jack87 | ||
| === Jack87 is now known as Jack87_Nap | ||
| josheee12[1] | i have a device with a Cortex A8. how difficult would it be to build Maverick's kernel for it? | 01:33 |
|---|---|---|
| rsalveti | josheee12[1]: depends a lot on what kind of device you're using | 01:44 |
| rsalveti | saying it's cortex a8 only doesn't help much | 01:44 |
| === Jack87_Nap is now known as Jack87 | ||
| hrw | morning | 08:16 |
| sveinse | I was a little surprised to find that --sysroot was removed from binutils-arm-linux-gnueabi. I understand it conflicts with xdeb, but isn't it a drastic measure. It breaks the way we crossbuild ubuntu apps (that are not debian packages). How can I do so without sysroot? | 10:55 |
| lool | hrw: ^ | 10:57 |
| lool | sveinse: I | 10:58 |
| lool | sveinse: I'm not sure which exact sysroot you mean; you mean with the support for --sysroot, or with a specific sysroot setting? | 10:58 |
| hrw | sveinse: sysroot was not enabled in lucid time too | 10:58 |
| lool | I think we just fixed the linker path to look in the right dirs, and didn't need the sysroot hack; but if --sysroot is useful, it should be enabled in both ld and cross-ld builds | 10:58 |
| lool | Doesn't really relate to what we do though | 10:59 |
| hrw | sveinse: did you used 10.04 or only 10.10? | 10:59 |
| sveinse | 10.10 | 11:00 |
| sveinse | after sysroot was enabled, we have found a realiable way to build non-deb apps for ubuntu target | 11:01 |
| sveinse | basically we have a armel rootfs which we sysroot ld with "--sysroot=/home/user/rootfs-dev -L=/lib -L=/usr/lib" | 11:04 |
| hrw | sveinse: if you do not use xdeb then use binutils from maverick not from maverick-updates | 11:04 |
| sveinse | As mentioned in #692987 we pin against 2.20.51.20100908-0ubuntu2cross1.50 to keep our buildsystem up and running | 11:05 |
| hrw | sveinse: sysroot support was enabled by mistake in 10.10 | 11:05 |
| hrw | I got it sneaked in during doing lot of changes in whole toolchain | 11:05 |
| sveinse | So basically, this (sysroot) is something we will never have then? | 11:05 |
| hrw | not in official packages | 11:06 |
| sveinse | Thats too bad because the other cross compiler alternative, CSL, has a different libc configuration which makes problems during starting of apps on target | 11:06 |
| sveinse | The beauty of the ubuntu cross compiler is the fact that it is harmonized with the native compiler/libs on target | 11:07 |
| === njpatel_ is now known as njpatel | ||
| sveinse | So I raise my question again then: How can we cross build non xdeb apps for ubuntu target? | 11:08 |
| sveinse | I'd be happy to blog about how we managed to build apps for ubuntu target, but I don't know how relevant this is now if sysroot is a mistake... | 11:10 |
| sveinse | Nor how we shall continue to build our apps | 11:10 |
| hrw | sveinse: use xapt to install cross libs and do compilation | 11:12 |
| hrw | xapt will fetch armel libs, mangle them and install to /usr/arm-linux-gnueabi/ dir | 11:12 |
| hrw | compiler will look there | 11:12 |
| hrw | linker too | 11:12 |
| hrw | and then you can copy results into your device | 11:12 |
| hrw | sveinse: so instead of installing into your sysroot you install into system | 11:13 |
| sveinse | thanks, I'll look into it! | 11:13 |
| sveinse | hrw: Do you happen to have a description of how somewhere? As a kickstart, I mean. | 11:14 |
| hrw | "xapt -aarmel install ncurses" or sth like that | 11:15 |
| hrw | I used it once and it was easy | 11:15 |
| sveinse | does this setup a fakeroot environment somewhere? ok.... I'll read myself up on it before asking 10000 questions. | 11:16 |
| hrw | no, it will not give you copy of rootfs | 11:16 |
| hrw | this one you need to generate. rootstock does it | 11:16 |
| hrw | or multistrap | 11:16 |
| sveinse | Yes, I'm using rootstock to make the rootfs I use sysroot against, so that part is known | 11:17 |
| sveinse | Have to leave. Back in 45 mins.. | 11:18 |
| === zyga_ is now known as zyga-vaio | ||
| === Jack87 is now known as Jack87_Bed | ||
| === _dmart_ is now known as dmart | ||
| === ian_brasil__ is now known as ian_brasil | ||
| lool | rsalveti: Around? | 14:07 |
| lool | rsalveti: I'd like to confirm the x-loader package names with you | 14:07 |
| lool | rsalveti: We moved everything to a x-loader source package and the names x-loader-omap3-beagle and x-loader-omap4-panda are final, right? | 14:07 |
| lool | rsalveti: I'd like to add an IGEP build as well | 14:09 |
| lool | rsalveti: Not sure that's supported though | 14:10 |
| lool | rsalveti: Overo would also be helpful | 14:10 |
| lool | rsalveti: Seems IGEP was submitted and fixed; anything preventing its merge? | 14:13 |
| lool | rsalveti: How do I contribute to your x-loader packaging to add an overo flavor? Could we keep it in Launchpad instead? | 14:22 |
| rsalveti | lool: hey | 14:25 |
| rsalveti | lool: are final, and it'd be ok to add igep as well | 14:25 |
| lool | rsalveti: Can you commit to the main x-loader tree to add IGEP? Or would you be ok to pull them in the Ubuntu tree? | 14:26 |
| rsalveti | lool: igep patches are still not merged | 14:26 |
| rsalveti | lool: I'd prefer to wait the patches to be in the main tree first | 14:27 |
| rsalveti | but if it takes too long we can for sure push it at the package itself | 14:28 |
| lool | Anand works in Linaro and announced the new x-loader stuff; I've emailed him to ask him for a review | 14:32 |
| lool | rsalveti: So, I'd like to contribute to the packaging, how do I do this? | 14:32 |
| rsalveti | lool: and the only 2 flavors that were actually tested were beagle and panda | 14:33 |
| rsalveti | even on the main tree | 14:33 |
| rsalveti | that's why I just activated these 2 first | 14:33 |
| lool | rsalveti: the announcement said overo support should work | 14:33 |
| ian_brasil | thx to whoever fixed the kubuntu mobile natty builds | 14:33 |
| lool | Currently, thanks mainly to Steve's efforts, the tree builds for and | 14:33 |
| lool | works on the following platforms: the OMAP3 EVM, the Overo and Beagle | 14:33 |
| lool | (both 35xx and 37xx), and the Pandaboard. | 14:33 |
| lool | rsalveti: ^ | 14:33 |
| rsalveti | well, it *should* work but as I don't have the hardware and nobody said that was using it, I didn't add it by default | 14:34 |
| rsalveti | but ok, can easily activate it | 14:34 |
| rsalveti | lool: I can move it to bzr if you want | 14:34 |
| rsalveti | not something I actually like, but ok | 14:34 |
| lool | rsalveti: I don't mind either way, but I need some kind of way to update it | 14:35 |
| lool | rsalveti: Another option would be a gitorious team with a lot of Ubuntu Developers in it | 14:35 |
| lool | rsalveti: But we should leverage launchpad for packaging really | 14:35 |
| lool | rsalveti: Up to you, just tell me where to commit | 14:35 |
| lool | I can work with either git or bzr, just can't commit to ~rsalveti obviously ;-) | 14:36 |
| ogra | its more upstream stuff whats in gitorious, no ? | 14:36 |
| rsalveti | ogra: not in my tree | 14:36 |
| lool | ogra: It's just a git hosting place; you can think of it like Launchpad -- merge requests etc. | 14:36 |
| ogra | ah | 14:36 |
| rsalveti | I have 2 trees, one for upstream work and another for packaging | 14:36 |
| lool | Just like github | 14:36 |
| ogra | lool, i know what gitorious is | 14:36 |
| ogra | i was referring to rsalveti's branch | 14:36 |
| rsalveti | :-) | 14:36 |
| rsalveti | lool: will move to LP, will make it easier | 14:36 |
| rsalveti | lool: ping you back when I'm done | 14:37 |
| lool | rsalveti: thanks | 14:37 |
| rsalveti | lool: can you test overo? | 14:37 |
| lool | rsalveti: No, I gave them all away, but we have 6 tobi + overo in linaro | 14:37 |
| rsalveti | or we'll be just creating the package without testing it? | 14:37 |
| rsalveti | lool: can you ask someone to test current master tree? | 14:38 |
| lool | rsalveti: I'd rather have them test of the package | 14:38 |
| lool | That way we're testing binaries built with our in-archive toolchain etc. | 14:38 |
| rsalveti | well, it's the same toolchain they are probably using at the desktop | 14:38 |
| rsalveti | or at least should | 14:38 |
| lool | rsalveti: There's one u-boot build rule that is not in the x-loader rules which I suspect might be important | 14:38 |
| rsalveti | lool: which one? | 14:39 |
| lool | rsalveti: jcrigby stripped -Bsymbolic from the LDFLAGS explicitly, noting that it broke relocation; I don't think your x-loader relocates, but it could have other side effects | 14:39 |
| lool | Maybe not though | 14:39 |
| lool | Just wanted to mention it | 14:39 |
| lool | rsalveti: Why do you assume it's borken? :-) | 14:39 |
| lool | rsalveti: Steve Sakoman was testing his tree regularly, and I think this tree started of his tree; | 14:40 |
| rsalveti | lool: because the tree is new and nobody said to me it works :-) | 14:40 |
| lool | rsalveti: One thing I'd like to discuss in the future is merging the MLOs in a single package | 14:40 |
| lool | I think one package per board doesn't scale | 14:41 |
| rsalveti | x-loader should die | 14:41 |
| lool | that too | 14:41 |
| rsalveti | it's not going to get a lot more boards | 14:41 |
| lool | we have the same problem with u-boot-linaro though | 14:41 |
| lool | which is getting a lot of boards | 14:41 |
| rsalveti | u-boot sure, not x-loader | 14:41 |
| lool | rsalveti: LP #702046 | 14:41 |
| ubot2 | Launchpad bug 702046 in x-loader (Ubuntu) (and 2 other projects) "Overo support (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/702046 | 14:42 |
| lool | rsalveti: Well I'd rather have the same layout for x-loader and for u-boot | 14:42 |
| lool | it's essentually the same problem and we're shipping both in linaro hwpacks | 14:42 |
| lool | anyway, we have time to discuss this | 14:42 |
| lool | maybe we can move to IPL instead | 14:42 |
| rsalveti | lool: one question, how is it done with the linaro packages at the archive? | 14:53 |
| rsalveti | the ones that are mainly done at git.linaro.org? | 14:53 |
| rsalveti | like u-boot? | 14:53 |
| rsalveti | if you want to change it, for example | 14:53 |
| rsalveti | or any other ubuntu developer | 14:53 |
| lool | rsalveti: Until now, I grabbed the u-boot-linaro source package and uploaded to the archive; last week, I saw that u-boot-linaro has a Vcs-Git; I checked that the branch had all my uploads and asked slangasek about it; I don't remember the outcome, but I want to chat with jcrigby to find out | 14:55 |
| lool | rsalveti: I don't want to commit to git://git.linaro.org/boot/u-boot-linaro-stable.git for package updates either | 14:56 |
| rsalveti | well, at least with gitorious you can created a merge request | 14:56 |
| rsalveti | so if any ubuntu dev want to change the package, it will probably need to send the patch to the owner, right? | 14:57 |
| rsalveti | I | 14:57 |
| rsalveti | I'm just trying to understand the packaging policy | 14:57 |
| * rsalveti brb | 15:00 | |
| jcrigby | lool: ping? | 15:04 |
| lool | jcrigby: In a call, give me 30mn? | 15:04 |
| jcrigby | sure, just saw my name mentioned | 15:05 |
| === ian_brasil__ is now known as ian_brasil | ||
| lool | jcrigby: pong | 15:48 |
| lool | jcrigby: Yeah, I wanted to ask about the u-boot-linaro packaging | 15:48 |
| lool | jcrigby: it's in git.linaro.org, which means other ubuntu developers can't commit it when updating | 15:48 |
| lool | jcrigby: Maybe we should just release u-boot-linaro tarballs monthly, or when we see fit, and maintain the packaging in a bzr branch on launchpad | 15:48 |
| jcrigby | lool: for me git is easier and I'm willing to accept patches via email. How main ubuntu u-boot developers are there? | 15:53 |
| lool | jcrigby: Problem is the Vcs field | 15:54 |
| jcrigby | jcrigby, I don't understand | 15:54 |
| lool | jcrigby: The usual workflow to work on a package with a Vcs field is something like debcheckout, hack, commit, upload; but they can't commit | 15:54 |
| lool | So they wont commit and the next person doing debcheckout will be looking at an old version of the package | 15:55 |
| lool | also, you risk uploading a new u-boot-linaro overwriting packaging changes which are only in the archive and not in git | 15:55 |
| jcrigby | so lets just take it out of bzr completely | 15:55 |
| lool | bzr? | 15:55 |
| lool | I'm speaking of the git packaging branch | 15:56 |
| lool | is it in bzr?? | 15:56 |
| jcrigby | no | 15:56 |
| lool | jcrigby: If instead we would put the packaging under a bzr branch owned by ~ubuntu-dev, anybody able to update the package in the archive woudl also be able to commit | 15:56 |
| rsalveti | it could be in git, but then you need to add permission to every ubuntu developer | 15:56 |
| rsalveti | or change to bzr and add ~ubuntu-dev | 15:56 |
| jcrigby | how does the kernel deal with this same issue? | 15:58 |
| ogra | the kernel doesnt use bzr at all | 15:59 |
| ogra | they refuse to | 15:59 |
| jcrigby | I think that was my point | 15:59 |
| rsalveti | jcrigby: kernel is different | 15:59 |
| jcrigby | why | 15:59 |
| rsalveti | probably because they want :-) | 15:59 |
| jcrigby | upstream u-boot is git | 15:59 |
| rsalveti | I know, same as x-loader | 15:59 |
| lool | jcrigby: I personally don't like the fact that the kernel is different, it's an unfortunate exception | 15:59 |
| lool | jcrigby: A lot of upstream are in git, and while it's ok to have different Vcses for differnet packages, it's not ok to prevent the upload of more and more packages | 16:00 |
| lool | jcrigby: kernel team is also much larger :-) you are guaranteed to find a kernel developer every hour of the day, while you might personally go on leave :-) | 16:01 |
| jcrigby | ok,so what needs to happen? | 16:02 |
| ogra | lots of upstreams are git btw | 16:02 |
| lool | jcrigby: Well it could be a number of things | 16:02 |
| jcrigby | ogra, I know, I just don't like bzr much | 16:02 |
| lool | jcrigby: Perhaps the simplest conceptually is to stop worrying about the packaging branch in git, kill it entirely, and use the Ubuntu archive and its corresponding bzr branches for history | 16:03 |
| ogra | well, at some point bzr might become required to build a deb | 16:03 |
| jcrigby | ogra, fine I'm willing to learn | 16:04 |
| lool | jcrigby: that way, you can either use bzr if you need to dig up history, or just apt-get source + hack + prepare a debdiff for sponsoring to get something uploaded | 16:04 |
| lool | Basically, you keep both the apt-get source option and the bzr option open | 16:04 |
| jcrigby | but no git option | 16:04 |
| lool | Another way would be to start some gitorious/github team | 16:04 |
| jcrigby | no | 16:04 |
| lool | and we'd add as many people who'd like to join to it | 16:04 |
| lool | but that wont ever match the set of people who can upload to Ubuntu | 16:05 |
| jcrigby | so what prevents non packaging patches from being uploaded | 16:05 |
| lool | jcrigby: I expect the packaging updates of u-boot-linaro to be relatively straightforward from now on, so maybe it's not a big deal? | 16:05 |
| lool | jcrigby: Nothing prevents it | 16:05 |
| lool | jcrigby: And that's fine; gcc-linaro releases are patched before they go into Ubuntu | 16:06 |
| jcrigby | and how do those non packaging patches go upstream | 16:06 |
| lool | jcrigby: Depends | 16:06 |
| lool | jcrigby: Sometimes they come straight from upstream, but didn't propagate into a tarball release yet | 16:06 |
| lool | jcrigby: Sometimes they are sent upstream by the person uploading to Ubuntu | 16:06 |
| lool | jcrigby: Sometimes they are quick workarounds which need another solution upstream, and only a bug is filed | 16:07 |
| ogra | sometimes (if its a bad ubuntu maintainer) they arent forwarded at all too | 16:07 |
| lool | jcrigby: I think you had a lot of chats about this type of stuff with slangasek; I don't mind if you prefer getting his own explanation on this stuff; he is native and has usually better arguments than I do | 16:08 |
| jcrigby | lool, for the latest release I thought we had arrived at a pure git solution | 16:09 |
| lool | jcrigby: Well, it's valid as long as you keep it to Linaro PPAs for instance | 16:10 |
| lool | jcrigby: Because people who can commit to git can also upload an updated package to the PPA and vice-versa | 16:10 |
| jcrigby | lool: ok lets assume that all we get from git.linaro.org is a tarball which is upstream + linaro patches (if any) | 16:14 |
| jcrigby | lool, and all packaging is in bzr | 16:14 |
| lool | jcrigby: Yup | 16:15 |
| jcrigby | and someone commits and uploads a non packaging change | 16:15 |
| lool | Yes | 16:15 |
| jcrigby | I notice the change and decide it needs to go upstream so I send it up and while waiting for upstream to accept it I also apply it to git.linaro.org | 16:15 |
| lool | Ok | 16:16 |
| lool | (You're being nice :-) | 16:16 |
| jcrigby | as always:) | 16:16 |
| jcrigby | so I do a new tarball release (maybe on demand or every two weeks) | 16:16 |
| jcrigby | how do I do the bzr merge with the new tarball? Is that easy? | 16:17 |
| lool | jcrigby: it's easy | 16:17 |
| jcrigby | lool, ok then I see no problem | 16:17 |
| lool | jcrigby: It will sound complex if I describe it to you on IRC, but it's really easy | 16:18 |
| lool | jcrigby: The main reason for complexity is the way in which the packaging changes are added | 16:18 |
| lool | jcrigby: For instance, the packager could either add a debian/patches/foo.patch | 16:18 |
| lool | or (s)he could just change the package tree and upload, that would end up in the diff | 16:18 |
| jcrigby | right, in the foo.patch case then with new tarball they would just remove it? | 16:19 |
| lool | in the latter case, bzr might be able to see that the changes were merged upstream (not 100% sure); in the former case, the package would fail to build because the build would apply a patch which is already applied | 16:19 |
| jcrigby | right | 16:19 |
| lool | so the packager would have to remove the patch when updating to the new tarball (which is what we usually do) | 16:19 |
| jcrigby | ok | 16:20 |
| jcrigby | lool, I see my bzr skills will need improving but that is fine | 16:20 |
| lool | jcrigby: Frankly, if you can git I don't see why you wouldn't bzr | 16:20 |
| lool | You can't even rebase, and there is no working-copy versus staged changes stuff, so there is less to learn ;-) | 16:21 |
| jcrigby | :) | 16:21 |
| ogra | hmm, looks like ubuntu-netbook is installable | 17:40 |
| * ogra fires off an image build | 17:40 | |
| rsalveti | ogra: hm, no logs :-) | 18:08 |
| rsalveti | even worse | 18:08 |
| ogra | rsalveti, yeah, seems to always happen if a manually triggered build fails | 18:08 |
| ogra | but i found our issue | 18:08 |
| ogra | seb128 will solve it tomorrow | 18:09 |
| rsalveti | ogra: what was it? | 18:09 |
| ogra | rhythmbox is ftbfs | 18:09 |
| ogra | and the old RB depends on the old webkit | 18:09 |
| ogra | what was the status of banshee ? | 18:09 |
| rsalveti | hm, ok | 18:09 |
| rsalveti | maybe janimo knows better | 18:10 |
| ogra | if it works we could just drop RB | 18:10 |
| janimo | rsalveti, ogra, I am waiting for banshee 1.9.2 to be uploaded by mono team | 18:24 |
| janimo | and see if the crash on startup appears | 18:24 |
| ogra | k | 18:24 |
| ogra | then we'll just wait another day for the rhythmbox fix | 18:24 |
| janimo | I guess that neds to come anyway so I am not wokring on it , they had a maemo crash bugfix there, may be the same | 18:25 |
| rsalveti | lool: which group should I add, ubuntu-core-dev or ubuntu-dev? | 18:30 |
| ogra | janimo, yeah, i was only worried about our builds and was thinking of ripping out RB | 18:31 |
| janimo | ogra, I thought I'd leave alone RB and other desktop apps while webkit and indicator transitions are being done | 18:32 |
| janimo | after that settles it will probably nolonger be FTBFS on new uploads | 18:32 |
| ogra | webkit is done, i was about to look at RB but seb128 seems to have a new upstream ready for tomorrow | 18:32 |
| lool | rsalveti: main > ubuntu-core-dev, universe > ubuntu-dev | 18:32 |
| janimo | too bad LP cannot figure out to only start builds until build deps are satisfied (or maybe they are not stated strictly enough?) | 18:33 |
| lool | rsalveti: You don't necessarily need a team BTW | 18:33 |
| ogra | so i was looking into the opportunity to drop RB and pull in banshee for today so we get images | 18:33 |
| lool | rsalveti: You could just rely on the UDD branches | 18:33 |
| ogra | but it can wait another day i suppose | 18:33 |
| janimo | ogra, I see. | 18:33 |
| ogra | for the RB fix | 18:33 |
| rsalveti | lool: well, I created a project for it, so a team sounds fine | 18:35 |
| rsalveti | just to put the debian stuff into a proper bzr branch | 18:35 |
| lool | rsalveti: A project just for a packaging branch? | 18:35 |
| lool | rsalveti: a team is enough to hold it | 18:35 |
| lool | rsalveti: lp:~team-name/x-loader/ubuntu-packaging | 18:35 |
| lool | Usually ~ubutnu-core-dev or ~ubuntu-dev/x-loader/ubuntu | 18:36 |
| lool | Unless you created the x-loader project, which would be a good idea indeed | 18:36 |
| rsalveti | lool: x-loader project | 18:36 |
| rsalveti | I'm not in ubuntu-dev nor ubuntu-core-dev yet | 18:37 |
| rsalveti | but working on it | 18:37 |
| rsalveti | lool: at lp:x-loader you can find the latest branch for the debian package stuff | 19:31 |
| rsalveti | lool: also released a new version, can you sponsor the update? | 19:32 |
| rsalveti | otherwise I can just ask janimo or ogra :-) | 19:32 |
| rsalveti | if you prefer I can also generate the debdiff | 19:32 |
| slangasek | lool, jcrigby: for those packages where we have the same person maintaining both the upstream linaro branch and the Ubuntu packaging, I've been favoring a git-buildpackage solution for now on the grounds that using bzr for packaging branches isn't going to make anything /easier/ than where we are now. But if you think there's a concern that other Ubuntu folks will be changing these packages, I'm equally happy to get jcrigby going with bzr | 19:42 |
| kaim | Hello all! I'm a bit new to "embedded linux" so need some help. Going to migrate my GPS from WinCe to Linux 4 ARM CPU and is searching for some guide. or HowTo to figure out what I'll need and what the troubles may be. Can one send me a web link on the subj? | 19:44 |
| armin76 | kaim: good luck | 20:23 |
| kaim | =) | 20:24 |
| armin76 | kaim: what you mainly need is a kernel for your device | 20:25 |
| armin76 | and a way to load it, of course(bootloader) | 20:25 |
| kaim | As i do find for now ARM Linux has a support of my cpu | 20:26 |
| kaim | but for the rest I have to examine the hardware first | 20:26 |
| armin76 | well, support for the cpu is easy to find | 20:27 |
| armin76 | but the device is what matters | 20:27 |
| kaim | It seems like there is now distribution for handlets yet. | 20:27 |
| armin76 | and again, you need a bootloader first | 20:27 |
| kaim | grub is not an option? | 20:27 |
| kaim | it must be some port some wher | 20:27 |
| kaim | were | 20:27 |
| jhobbs | =( | 20:27 |
| jhobbs | you could start playing with arm on linux on a device that's well supported already to get the ropes | 20:28 |
| jhobbs | like a beagleboard | 20:28 |
| jhobbs | otherwise you have to learn a lot at once, it may be rough times if there is no guide for your device! | 20:28 |
| kaim | there isn't and thats why its an interesting one | 20:31 |
| jhobbs | well sir, let me know when grub for arm is ready! | 20:33 |
| kaim | jhobbs: I did hope there is one already =) | 20:35 |
| kaim | i.e. GRUB | 20:35 |
| lool | slangasek: I understand; I personally pushed to be able to upload stuff when people were on leave and I had to get some stuff done; it could be that we can live with the owner of the Vcs then merging back later in these cases | 20:38 |
| slangasek | lool: right, though it does reintroduce the classical Debian NMU problem | 20:39 |
| lool | slangasek: Exactly | 20:39 |
| === ian_brasil____ is now known as ian_brasil | ||
| EmbeddedLinuxGuy | Hi ubuntu-arm. I'm having a bit of trouble booting an Ubuntu image I created with rootstock | 23:03 |
| EmbeddedLinuxGuy | on my Gumstix Overo OMAP3530. It may be the "sh -> dash" issue. | 23:04 |
| EmbeddedLinuxGuy | Where does "dash" mess things up? Is it (1) on my host PC, (2) on the target FS created by rootfs, or (3) in the qemu image where rootfs runs? | 23:06 |
| elesueur | what actually happens? | 23:06 |
| EmbeddedLinuxGuy | I boot up and it gets as far as Freeing init memory: 160K, then no more output. | 23:07 |
| elesueur | i doubt this is a dash/bash problem | 23:08 |
| EmbeddedLinuxGuy | OK. I'll try a different kernel. | 23:09 |
| lool | EmbeddedLinuxGuy: Did you setup a serial console? | 23:12 |
| EmbeddedLinuxGuy | Yeah I did --serial ttyS2 as per the Gumstix wiki | 23:13 |
| lool | EmbeddedLinuxGuy: dash shouldn't matter anyway, host PC or not | 23:13 |
| lool | EmbeddedLinuxGuy: Which kernel is this with? newer OMAP serials are ttyO2 and not ttyS2 IIUC | 23:13 |
| EmbeddedLinuxGuy | OK some web page said this would cause it to halt and cause corruption. | 23:13 |
| lool | Hmm Andy just submitted a patch to linaro-image-tools to use ttyS2, maybe it's just ttyS2 for overo | 23:14 |
| EmbeddedLinuxGuy | I was using the Angstrom 2.6.35 from November 15, but I am switching to a 2.6.34 | 23:14 |
| lool | Oh that would certainly use ttyS2 | 23:14 |
| lool | You need some initrd to go with it | 23:15 |
| lool | as to honor stuff like serialtty= and fixrtc on the cmdline | 23:15 |
| EmbeddedLinuxGuy | OK. I was following a Wiki page that said: just put the kernel image, an MLO file, and a u-boot file on your first MicroSD partition | 23:17 |
| EmbeddedLinuxGuy | and the root filesystem on the second partition. | 23:17 |
| EmbeddedLinuxGuy | I assumed if there were an initrd it would be embedded in the kernel image. | 23:18 |
| lool | EmbeddedLinuxGuy: You need to have the proper cmdline arguments to match your kernel | 23:29 |
| lool | EmbeddedLinuxGuy: also, the rootfs might try to setup a tty of some sort as to allow you to login over serial; that's the goal of serialtty=, but that only work with an Ubuntu-ish initrd | 23:29 |
| EmbeddedLinuxGuy | lool: Thanks, I have a feeling the kernel cmdline is being set by my u-boot.bin file. | 23:34 |
| EmbeddedLinuxGuy | I have been trying to work from http://www.gumstix.net/wiki/index.php?title=Installing_Ubuntu_10.04_on_Gumstix_Overo but I am willing to try a different recipe | 23:36 |
| lool | EmbeddedLinuxGuy: When we have Linaro hwpacks (hopefully RSN now :-) I should have another one for you :-) | 23:37 |
| lool | rsalveti: i sponsored your x-loader and did some packaging cleanups | 23:51 |
| lool | rsalveti: You have a fair number of patches, are this reviewed by upstream? | 23:51 |
| lool | rsalveti: Also, I was wondering whether we need -fno-stack-protector both in a patch and in rules | 23:51 |
| lool | rsalveti: Ah I can't join yet | 23:52 |
| lool | s/jon/push | 23:52 |
| lool | rsalveti: | 23:54 |
| lool | https://code.launchpad.net/~lool/x-loader/packaging-fixes/+merge/46717 | 23:54 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!