[01:46] I have an arm cpu question: http://www.ti.com/lit/ug/spruf98x/spruf98x.pdf page 2614: OVF_Rate = (0xFFFF FFFF - GPTn.TLDR + 1) * (timer-functional clock period) * PS table16-11 the example for TLDR=0xFFFF FFF0 and PS=1 is equal to 524 μs. however, (0xFFFF FFFF - 0xFFFF FFF0 + 1) * (1/32768) * 1 = 488 μs [01:46] can anyone explain why I calculate the value different than the TRM? [02:21] infinity: toolchain seems to basically work, but for some reason gpm fails to build. [02:21] hmm same failure for native build. Maybe it just doesn't like 2.17 [02:23] Does it build for you? [02:24] I'm getting http://people.linaro.org/~wookey/buildd/raring-arm64/gpm_1.20.4-6-raring-arm64-20130210-0142.log with a lot of warnings, then missing major() [02:25] aha. OE people have fixed it: http://patches.openembedded.org/patch/42449/ [02:32] ok, that does the trick [02:34] I suspect that's the "wrong" fix, but it works for now. [02:42] is there a list of 2.17 changes that may break things like this? [02:44] This is the only one I've run into so far. And yeah, actually, that may be the right fix for gpm. [02:44] Looks like they were relying on fcntl.h misatkenly including sys/types.h, which it shouldn't. [02:44] Of course, you can also get sys/types.h for free with enabling some system extensions. [02:45] Since stdlib.h has this: [02:45] #if defined __USE_SVID || defined __USE_XOPEN_EXTENDED || defined __USE_BSD [02:45] # include /* we need int32_t... */ [02:55] wookey: Anyhow, uploading the fix to Ubuntu now, and submitting to Debian. [02:57] Ah OK. I'll not file this patch then [02:57] cheers [02:57] Guess it's about time for another rebuild test in Ubuntu. [02:58] I know of one other case of "I included fcntl.h, but I actually meant sys/types", but I don't know how rampant it is. [02:58] do you recall which package? [02:58] alsa-lib [02:59] (Which ends up manifesting in a cascaded fashion to many things that build-dep on libasound-dev, since the alsa headers have the broken assumption) [02:59] I should probably fix that right now too. [03:00] I might consider reverting the fcntl.h thing in glibc for a short while, but this is a case of "upstream is right, sucks to be lazy programmers who need to fix things", so maybe just a rebuild test and some whackamole is the better option. [03:02] I guess so. It's just annoying for me when unrelated breakage comes and breaks everything [03:03] Ooo, even more evil, alsa-lib itself doesn't FTBFS, cause it doesn't use the broken header, it just exports it. [03:03] I have enough related breakage to be going on with [03:03] That's so much fail. [03:03] lovely [03:04] (Well, or it uses it, but everything in the alsa sources that includes the broken header also includes sys/types, which is likely) [03:04] My vision of running through big long list just rebuilding everything has so far been thwarted thoroughly by new libc, new linux headers, new libgcc [03:05] and staging fixes I forgot to upload source for [03:06] BTW you didn;t include my stage2 patch in eglibc. I'll file a bug to stop it getting dropped [03:06] 1-liner [03:11] I didn't include it because I'm looking at rewriting the whole stage mess. [03:11] You'd note that your stage2 patch introduces the *only* case of stage2 anywhere in the source. [03:11] Which seems a bit odd. [03:12] And, of course, the cross-base packages have a whole different set of staged build patches. [03:12] So, yeah. [03:12] I want to reconcile it all, tear it all out, put it back in with something less confusing, and make sure it works for everyone's (apparently different) bootstrap methods. [03:14] The glibc/gcc interdependence makes them a bit weirder to really sort out how to codify this in a way that makes sense without a README anyway. [03:14] Given that a stage1 (or a stage0, really) of glibc doesn't actually produce a library. :P [03:14] Just a useless stub. [03:16] I'm also considering pushing the interdependant stageN stuff to glibc and gcc upstream. [03:17] So you can just (cd gcc && ./configure stage0 && make) && (cd glibc && ./configure stage0 && make) and then repeat for stage1, and have a functional pair. [03:17] (Any attempts to do otherwise is a useless waste of time, since they need stubs from each other to build) [03:21] OK fair enough. I agree it needs a good sort out. [03:21] The staging stuff in there isn;t actually broken. the tooclahin-cross-base packge and -source packages thing is a horrible hack that should die though [03:22] Or maybe it can hang around as a convenince wrapper [03:23] Well, some sort of wrapper will always be needed for people who want an automated way to bootstrap a toolchain from scratch. [03:23] But once you have a toolchain and you're crossing/rebuilding (like you're doing), yeah, that can be done entirely in the package, and I agree glibc's needs a tiny bit of fixing. [03:23] But, like I said, the fixing looks more like a rewrite, cause half the code is unused, and other half if only right by accident. :P [03:23] It should work as in http://wiki.debian.org/MultiarchCrossToolchains [03:24] We need to fix the DEB_TARGET_ARCH=foo bit for consistency too. I've filed a few bugs about that [03:24] and done most of the work of adding it to dpkg-buildpackage [03:25] so you can do dpkg-buildpackage --target-arch foo [03:25] (sadly it has two other sorts of 'target' options already, but that's life). [03:26] I think I questioned before how much this really needs to be in dpkg, but I don't much care either. [03:26] This reduced the process cross-toolchain base does to 7 dpkg-buildpackage calls [03:27] I mean, once you have a toolchain, everything after that is just build/host crossing. [03:27] Special-casing just for the target toolchain build seems like a lot of engineering. [03:27] It's no erngineering. everything is already there in the sources [03:27] Also, there's the part where this assumes buildds will/should be multiarch enabled in the distro, and I'm still unconvinced that's a good idea. [03:28] It just has different names in differnt packages and dpkg-builpackage ismissing an option for it [03:31] sbuild is multiarch enabled already, and buildds use sbuild, (don't they?) So it's already done in engineering terms [03:31] No, I mean, I'm not convinced buildds should be *allowed* to have/use cross-arch build-deps in the official archive. [03:32] I'm perfectly happy with sbuild doing this for out-of-archive bootstrap purposes, and it's quite handy (and I've even submitted patches to make it less crap). [03:32] You have to for cross compilers (unless we want to carry on with the libc-arch-cross bodgery [03:32] (and the libc transition showed why that's a bad plan) [03:32] That's not technically true. [03:33] We could do the n-stage bootstrap and then just throw away the results and depend on libc6-dev:otherarch. [03:33] I had stuff not building because the toolchain carefully used the 2.16 lib it had in libc-arm64-cross instead of the 2.17 installed as libc:arm64 [03:33] OK, true [03:34] Which I might figure out how to do a bit later. [03:34] Since that's still an improvement on the road to what you want. [03:34] now we have multiarch, why not use it? [03:34] (In that the cross toolchain would now only look at M-A paths, and none of the cross madness) [03:34] Yes that would indeed be a step in the right direction [03:35] I guess I just see "bootstrapping a toolchain" as a rather different use-case than most other M-A stuff. [03:35] And not something people other than the toolchain maintainers should have to deal with, really. [03:35] It's not like "normal users" (or even normal developers) build native GCC all the time. [03:35] It is, but now we have the tech I don;t see why we shouldn't use it [03:36] No, but the native toolchain build is expected to work [03:36] seems to me the cross one should too [03:36] Because allowing foreign arch build-deps opens a lot of other cans of worms we need to think about very carefully. [03:36] Yes, that's fair enough. [03:36] I'd so far been very careful about explicitly turning OFF foreign arches on our buildds. :P [03:36] We can afford to be strict about what is accepted [03:37] (briefly, the amd64 chroot had i386 enabled too, and this did actually cause curious issues when there was arch skew in the archive) [03:37] but for cross-toolchians foreign-arch deps are definitely reasonable, I would say 'correct'. [03:37] skew is a problem... [03:38] Deps, yes. But we can skip the build-deps part with my above deal. [03:38] butmostly for new arches [03:38] Anyhow, I need to run. Movie date calls. [03:38] OK. cheers for help [03:38] No, skew is a problem on every single upload of.. Anything. [03:38] bedtime here [03:39] If you have a foreign arch enabled and one of your build-deps builds on the foreign arch before the native one, and that satisfies (technically) the MA build-dep rules, you no longer build in a self-contained arch, you pull in the foreign one. [03:39] And that's all meant to "work" anyway, but it also means our arches aren't guaranteed self-contained anymore. [03:39] Or self-hosting. === zz_Jacky is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_Jacky === zz_Jacky is now known as zz_zz_Jacky === zz_zz_Jacky is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as zz_zz_Jacky === hatake is now known as blackjack === zz_zz_Jacky is now known as Jacky_ [12:36] hrw, http://paste.ubuntu.com/1632851/ chromebook ambient light sensor control [12:36] (eats a bit of battery due to polling though) === hatake is now known as blackjack === yofel_ is now known as yofel === Quintasan_ is now known as Quintasan === doko_ is now known as doko === Jacky_ is now known as zz_Jacky_ === zz_Jacky_ is now known as jackyalcine === jackyalcine is now known as Jacky_ === Jacky_ is now known as jackyalcine [14:40] where is build-arm-chroot? [14:40] I mean the script === zz_chihchun is now known as chihchun === chihchun is now known as zz_chihchun === rsalveti_ is now known as rsalveti [15:26] ah found it: http://packages.ubuntu.com/lucid/i386/qemu-kvm-extras-static/filelist === jackyalcine is now known as zz_jackyalcine === zz_jackyalcine is now known as jackyalcine === jackyalcine is now known as jackyalcine_ [17:07] oh, nice, flash is fully working on my chromebook as long as i dont use any compositor [17:09] like adobe flash? [17:09] or you mean the one built-in chrome? [17:16] no, i mean the one that i copied from the chromeos partition to ubuntu [17:16] running eith the ubuntu vhromium browser [17:16] *chromum [17:16] hm, nice) [17:16] bah === jackyalcine_ is now known as zz_jackyalcine_ === zz_jackyalcine_ is now known as jackyalcine === jackyalcine is now known as jackyalcine_ === jackyalcine_ is now known as zz_jackyalcine_ === zz_jackyalcine_ is now known as jackyalcine [18:46] ogra_: run chromium browser with "--with-gl=egl" (or s/with/use/) ;) [18:47] well, better add it to the chromium defaults proper :) but yeah [18:47] see /etc/chromium-browser/default === jackyalcine is now known as zz_jackyalcine [19:19] Trying to cross-compile an arm kernel on an x86_64 ubuntu 12.10, but get this error: dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf does not match gcc system type x86_64-linux-gnu [19:19] Can someone help? [21:16] Vic: ignore warning [22:09] Trying to cross-compile an arm kernel on an x86_64 ubuntu 12.10, but get this error: dpkg-architecture: warning: specified GNU system type arm-linux-gnueabihf does not match gcc system type x86_64-linux-gnu [23:22] http://dpaste.org/g1Z5T/ [23:22] how could it be? [23:39] Weren't those libraries supposed to get proper SO versioning at some point? [23:48] trying to build a package on armhf, and clang seems to be broken: it tries to execute a command "" (empty string) as in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659481 [23:48] Debian bug 659481 in llvm-3.0 "unable to execute command: No such file or directory" [Grave,Open] [23:48] anyone seen this? [23:48] (precise) [23:50] trying to compile a hello world has the same problem [23:50] aha, mounting /proc fixes it [23:51] in the chroot