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