=== asac_ is now known as asac [02:34] janimo: poke === jkridner_ is now known as jkridner [12:42] jburkholder, yes? [13:07] janimo: hi, I was at the launchpad bugs about sysv-ucontext style functions not being implemented on arm [13:07] was looking at [13:08] do you know if there's a reason they can't be implemented? [13:10] lp #383975 [13:10] Launchpad bug 383975 in debian "[ARM] sysv-style ucontext functions appear not to be implemented on armel" [Unknown,Fix released] https://launchpad.net/bugs/383975 [15:22] lilstevie: So, firstly, there's a restriction that package names can only be lowercase letters, and a strong interest in having relatively short names. What do you think about "linux-transformer"? [15:23] lilstevie: You'll want to change the Maintainer: I'd suggest "Ubuntu Developers " unless you have prearranged agreement by the currently listed maintainer. [15:25] Something looks to have gone wonky with the header files: these are important to have auto-installed to work around some bugs in DKMS. [15:27] hi, if I want to port some packages for ARM, is it best to download the source from packages.ubuntu.com, or from the SVN or...? [15:28] emorris: Most of use use a deb-src entry pointing at onieiric, which ends up being downloeded from ports.ubuntu.com, archive.ubuntu.com, or some mirror. [15:28] I'd generally recommend a local mirror, although use rmadison to make sure that you have the current version. [15:29] Some folk use the auto-imported bzr trees, which are often correct, although sometimes there are import errors or unuploaded commits, which can lead to code skew. [15:31] persia, cool, I'll probably go for the deb-src way then. Also, what is rmadison? [15:32] emorris: It's one of the tools in devscripts: it queries a cgi interface on the archive master to determine which versions of the packages are newest in each release. [15:32] Well, each series, but kinda release. [15:33] persia, ah, got it. I tried to Google it, but Google auto-corrected it >:-( [15:33] thanks [15:33] Sometimes, for example, packages.ubuntu.com is out of date (by a day or two), because of transient issues, and one can get confused if a package is being rapidly developed and one relies upon that resource. [15:33] No problem. We're always happy to answer questions here. New folk wanting to help are the ones we like to help the most :) [15:35] Don't know how far I'll get, but it's worth a shot I guess! [15:35] What hardware are you using? [15:36] persia, pandaboard [15:37] And you're running oneiric? You probably also want to configure it to use a USB drive for your working area. [15:37] (maybe even for everything, depending on how much you like to fiddle) [15:39] Did you find the list of packages that aren't building today yet? [15:41] Still on Natty atm. Was only really planning to do a personal project atm, and get packages working as I need them [15:42] Aha. [15:43] Well, let us know if you find something that doesn't work, especially if you have a fix :) [15:43] If you find you have some time, and want to dig more, let us know. [15:44] In either case, we're very happy to help get your environment set up for development, and lead you through how we use the packages for development. [15:50] persia, cool, well I'm very happy to help where I can. I haven't really looked into it much yet, but I'll work my way through https://wiki.ubuntu.com/ARM before pestering the channel! [15:51] linux transformer is fine [15:51] and the maintainer stuff I hadnt changed [15:52] re persia [15:52] persia: the only reason it is longer is we were working on an -- convention [16:00] lilstevie: Right. So, there's some string limit on these that isn't actually that long. When one starts to generate all the udebs, this string gets kinda awkward. [16:00] As much as I'm a fam of getting as many kernels in the archive as possible, we obviously want to strive for concentration. [16:00] heh [16:01] It is my expectation that if we can use device-specific kernels to bootstrap specific devices, we'll be able to focus on getting integrated trees for things. [16:01] persia: well my only concern is there are 2 variants of the transformer [16:01] So, for oneiric, I'm expecting only two tegra kernels: ac100 and transformer. [16:01] wifi and 3G [16:01] Can a kernel be built that runs on both of them, or do the modules conflict somehow? [16:01] I guess a universal could be built [16:01] I'd much rather see loadable modules for the networking, and don't care that much about netbooting over 3G, for example. [16:02] but given the 3G isn't fully in the wild yet it is hard [16:03] emorris: Just let us know if you have questions: we surely haven't gotten all the docs up on the wiki, and we know some bits are confusing. [16:04] lilstevie: So, let's pretend we have a combined kernel, and do the wifi module load through udev. When the 3G becomes more available, we can fix the bugs in that kernel. [16:05] persia: well there is a ril driver in all recent versions [16:05] Oh, excellent. Let's pretend that works until we get a bug report. [16:06] sounds good [16:06] argh.. i've generated a rootfs with rootstock, cross-compiled the kernel, but how on earth do i generate the uImage? [16:07] lilstevie: I'll be on planes soon for a couple days, but I'll let you know when I am around enough, hoping to build and upload something. [16:07] ok :) [16:07] THe only other really obvious thing I see from looking over some of the files in debian/ is the changelog: that ought be a real email address, and a real name. [16:08] (since you've provided both to LP and in other places, this oughtn't be onerous) [16:08] yeah that I can understand :) [16:09] I was just getting it to you mainly [16:11] That's fine. I'm happy to have had a look, and glad to report that it looks like you've done it mostly right (from what I can tell from a quick review) [16:12] :) [16:17] fisuk, it isn't in arch/arm/boot? [16:29] emorris: ah, didn't know where to look! thanks! [16:37] recompiled it just with make... and make uImage did tell the location.. did before with dpkg-buildpackage and somehow missed it. [16:37] i guess i should write a wiki entry "kernel compilation for idiots" [18:50] jburkholder, hi, from what I read a while agi, ucontext are considered deprecated (not sure by what other API though) and not high priority. But I think just noone got around to implementing it. May require kernel changes too besides glibc, I do not know exactly