[01:33] <josheee12[1]> i have a device with a Cortex A8.  how difficult would it be to build Maverick's kernel for it?
[01:44] <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
[08:16] <hrw> morning
[10:55] <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:57] <lool> hrw: ^
[10:58] <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:59] <lool> Doesn't really relate to what we do though
[10:59] <hrw> sveinse: did you used 10.04 or only 10.10?
[11:00] <sveinse> 10.10
[11:01] <sveinse> after sysroot was enabled, we have found a realiable way to build non-deb apps for ubuntu target
[11:04] <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:05] <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:06] <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:07] <sveinse> The beauty of the ubuntu cross compiler is the fact that it is harmonized with the native compiler/libs on target
[11:08] <sveinse> So I raise my question again then: How can we cross build non xdeb apps for ubuntu target?
[11:10] <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:12] <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:13] <hrw> sveinse: so instead of installing into your sysroot you install into system
[11:13] <sveinse> thanks, I'll look into it!
[11:14] <sveinse> hrw: Do you happen to have a description of how somewhere? As a kickstart, I mean.
[11:15] <hrw> "xapt -aarmel install ncurses" or sth like that
[11:15] <hrw> I used it once and it was easy
[11:16] <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:17] <sveinse> Yes, I'm using rootstock to make the rootfs I use sysroot against, so that part is known
[11:18] <sveinse> Have to leave. Back in 45 mins..
[14:07] <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:09] <lool> rsalveti: I'd like to add an IGEP build as well
[14:10] <lool> rsalveti: Not sure that's supported though
[14:10] <lool> rsalveti: Overo would also be helpful
[14:13] <lool> rsalveti: Seems IGEP was submitted and fixed; anything preventing its merge?
[14:22] <lool> rsalveti: How do I contribute to your x-loader packaging to add an overo flavor?  Could we keep it in Launchpad instead?
[14:25] <rsalveti> lool: hey
[14:25] <rsalveti> lool: are final, and it'd be ok to add igep as well
[14:26] <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:27] <rsalveti> lool: I'd prefer to wait the patches to be in the main tree first
[14:28] <rsalveti> but if it takes too long we can for sure push it at the package itself
[14:32] <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:33] <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:34] <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:35] <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:36] <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:37] <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:38] <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:39] <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:40] <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:41] <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:42] <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:53] <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:55] <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:56] <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:57] <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
[15:00]  * rsalveti brb
[15:04] <jcrigby> lool: ping?
[15:04] <lool> jcrigby: In a call, give me 30mn?
[15:05] <jcrigby> sure, just saw my name mentioned
[15:48] <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:53] <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:54] <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:55] <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:56] <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:58] <jcrigby> how does the kernel deal with this same issue?
[15:59] <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
[16:00] <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:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <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:09] <jcrigby> lool, for the latest release I thought we had arrived at a pure git solution
[16:10] <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:14] <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:15] <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:16] <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:17] <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:18] <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:19] <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:20] <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:21] <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> :)
[17:40] <ogra> hmm, looks like ubuntu-netbook is installable
[17:40]  * ogra fires off an image build
[18:08] <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:09] <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:10] <rsalveti> maybe janimo knows better
[18:10] <ogra> if it works we could just drop RB
[18:24] <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:25] <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:30] <rsalveti> lool: which group should I add, ubuntu-core-dev or ubuntu-dev?
[18:31] <ogra> janimo, yeah, i was only worried about our builds and was thinking of ripping out RB
[18:32] <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:33] <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:35] <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:36] <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:37] <rsalveti> I'm not in ubuntu-dev nor ubuntu-core-dev yet
[18:37] <rsalveti> but working on it
[19:31] <rsalveti> lool: at lp:x-loader you can find the latest branch for the debian package stuff
[19:32] <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:42] <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:44] <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?
[20:23] <armin76> kaim: good luck
[20:24] <kaim> =)
[20:25] <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:26] <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:27] <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:28] <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:31] <kaim> there isn't and thats why its an interesting one
[20:33] <jhobbs> well sir, let me know when grub for arm is ready!
[20:35] <kaim> jhobbs: I did hope there is one already =)
[20:35] <kaim> i.e. GRUB
[20:38] <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:39] <slangasek> lool: right, though it does reintroduce the classical Debian NMU problem
[20:39] <lool> slangasek: Exactly
[23:03] <EmbeddedLinuxGuy> Hi ubuntu-arm. I'm having a bit of trouble booting an Ubuntu image I created with rootstock
[23:04] <EmbeddedLinuxGuy> on my Gumstix Overo OMAP3530. It may be the "sh -> dash" issue.
[23:06] <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:07] <EmbeddedLinuxGuy> I boot up and it gets as far as Freeing init memory: 160K, then no more output.
[23:08] <elesueur> i doubt this is a dash/bash problem
[23:09] <EmbeddedLinuxGuy> OK. I'll try a different kernel.
[23:12] <lool> EmbeddedLinuxGuy: Did you setup a serial console?
[23:13] <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:14] <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:15] <lool> You need some initrd to go with it
[23:15] <lool> as to honor stuff like serialtty= and fixrtc on the cmdline
[23:17] <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:18] <EmbeddedLinuxGuy> I assumed if there were an initrd it would be embedded in the kernel image.
[23:29] <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:34] <EmbeddedLinuxGuy> lool: Thanks, I have a feeling the kernel cmdline is being set by my u-boot.bin file.
[23:36] <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:37] <lool> EmbeddedLinuxGuy: When we have Linaro hwpacks (hopefully RSN now :-) I should have another one for you  :-)
[23:51] <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:52] <lool> rsalveti: Ah I can't join yet
[23:52] <lool> s/jon/push
[23:54] <lool> rsalveti:
[23:54] <lool> https://code.launchpad.net/~lool/x-loader/packaging-fixes/+merge/46717