[01:46] <jdsa> 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] <jdsa> can anyone explain why I calculate the value different than the TRM?
[02:21] <wookey> infinity: toolchain seems to basically work, but for some reason gpm fails to build.
[02:21] <wookey> hmm same failure for native build. Maybe it just doesn't like 2.17
[02:23] <wookey> Does it build for you?
[02:24] <wookey> 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] <wookey> aha. OE people have fixed it: http://patches.openembedded.org/patch/42449/
[02:32] <wookey> ok, that does the trick
[02:34] <infinity> I suspect that's the "wrong" fix, but it works for now.
[02:42] <wookey> is there a list of 2.17 changes that may break things like this?
[02:44] <infinity> This is the only one I've run into so far.  And yeah, actually, that may be the right fix for gpm.
[02:44] <infinity> Looks like they were relying on fcntl.h misatkenly including sys/types.h, which it shouldn't.
[02:44] <infinity> Of course, you can also get sys/types.h for free with enabling some system extensions.
[02:45] <infinity> Since stdlib.h has this:
[02:45] <infinity> #if defined __USE_SVID || defined __USE_XOPEN_EXTENDED || defined __USE_BSD
[02:45] <infinity> # include <sys/types.h> /* we need int32_t... */
[02:55] <infinity> wookey: Anyhow, uploading the fix to Ubuntu now, and submitting to Debian.
[02:57] <wookey> Ah OK. I'll not file this patch then
[02:57] <wookey> cheers
[02:57] <infinity> Guess it's about time for another rebuild test in Ubuntu.
[02:58] <infinity> 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] <wookey> do you recall which package?
[02:58] <infinity> alsa-lib
[02:59] <infinity> (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] <infinity> I should probably fix that right now too.
[03:00] <infinity> 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] <wookey> I guess so. It's just annoying for me when unrelated breakage comes and breaks everything
[03:03] <infinity> Ooo, even more evil, alsa-lib itself doesn't FTBFS, cause it doesn't use the broken header, it just exports it.
[03:03] <wookey> I have enough related breakage to be going on with
[03:03] <infinity> That's so much fail.
[03:03] <wookey> lovely
[03:04] <infinity> (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] <wookey> 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] <wookey> and staging fixes I forgot to upload source for
[03:06] <wookey> BTW you didn;t include my stage2 patch in eglibc. I'll file a bug to stop it getting dropped
[03:06] <wookey> 1-liner
[03:11] <infinity> I didn't include it because I'm looking at rewriting the whole stage mess.
[03:11] <infinity> You'd note that your stage2 patch introduces the *only* case of stage2 anywhere in the source.
[03:11] <infinity> Which seems a bit odd.
[03:12] <infinity> And, of course, the cross-base packages have a whole different set of staged build patches.
[03:12] <infinity> So, yeah.
[03:12] <infinity> 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] <infinity> 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] <infinity> Given that a stage1 (or a stage0, really) of glibc doesn't actually produce a library. :P
[03:14] <infinity> Just a useless stub.
[03:16] <infinity> I'm also considering pushing the interdependant stageN stuff to glibc and gcc upstream.
[03:17] <infinity> 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] <infinity> (Any attempts to do otherwise is a useless waste of time, since they need stubs from each other to build)
[03:21] <wookey> OK fair enough. I agree it needs a good sort out.
[03:21] <wookey> 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] <wookey> Or maybe it can hang around as a convenince wrapper
[03:23] <infinity> Well, some sort of wrapper will always be needed for people who want an automated way to bootstrap a toolchain from scratch.
[03:23] <infinity> 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] <infinity> 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] <wookey> It should work as in http://wiki.debian.org/MultiarchCrossToolchains
[03:24] <wookey> We need to fix the DEB_TARGET_ARCH=foo bit for consistency too. I've filed a few bugs about that
[03:24] <wookey> and done most of the work of adding it to dpkg-buildpackage
[03:25] <wookey> so you can do dpkg-buildpackage --target-arch foo
[03:25] <wookey> (sadly it has two other sorts of 'target' options already, but that's life).
[03:26] <infinity> I think I questioned before how much this really needs to be in dpkg, but I don't much care either.
[03:26] <wookey> This reduced the process cross-toolchain base does to 7 dpkg-buildpackage calls
[03:27] <infinity> I mean, once you have a toolchain, everything after that is just build/host crossing.
[03:27] <infinity> Special-casing just for the target toolchain build seems like a lot of engineering.
[03:27] <wookey> It's no erngineering. everything is already there in the sources
[03:27] <infinity> 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] <wookey> It just has different names in differnt packages and dpkg-builpackage ismissing an option for it
[03:31] <wookey> sbuild is multiarch enabled already, and buildds use sbuild, (don't they?) So it's already done in engineering terms
[03:31] <infinity> No, I mean, I'm not convinced buildds should be *allowed* to have/use cross-arch build-deps in the official archive.
[03:32] <infinity> 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] <wookey> You have to for cross compilers (unless we want to carry on with the libc-arch-cross bodgery
[03:32] <wookey> (and the libc transition showed why that's a bad plan)
[03:32] <infinity> That's not technically true.
[03:33] <infinity> We could do the n-stage bootstrap and then just throw away the results and depend on libc6-dev:otherarch.
[03:33] <wookey> 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] <wookey> OK, true
[03:34] <infinity> Which I might figure out how to do a bit later.
[03:34] <infinity> Since that's still an improvement on the road to what you want.
[03:34] <wookey> now we have multiarch, why not use it?
[03:34] <infinity> (In that the cross toolchain would now only look at M-A paths, and none of the cross madness)
[03:34] <wookey> Yes that would indeed be a step in the right direction
[03:35] <infinity> I guess I just see "bootstrapping a toolchain" as a rather different use-case than most other M-A stuff.
[03:35] <infinity> And not something people other than the toolchain maintainers should have to deal with, really.
[03:35] <infinity> It's not like "normal users" (or even normal developers) build native GCC all the time.
[03:35] <wookey> It is, but now we have the tech I don;t see why we shouldn't use it
[03:36] <wookey> No, but the native toolchain build is expected to work
[03:36] <wookey> seems to me the cross one should too
[03:36] <infinity> Because allowing foreign arch build-deps opens a lot of other cans of worms we need to think about very carefully.
[03:36] <wookey> Yes, that's fair enough.
[03:36] <infinity> I'd so far been very careful about explicitly turning OFF foreign arches on our buildds. :P
[03:36] <wookey> We can afford to be strict about what is accepted
[03:37] <infinity> (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] <wookey> but for cross-toolchians foreign-arch deps are definitely reasonable, I would say 'correct'.
[03:37] <wookey> skew is a problem...
[03:38] <infinity> Deps, yes.  But we can skip the build-deps part with my above deal.
[03:38] <wookey> butmostly for new arches
[03:38] <infinity> Anyhow, I need to run.  Movie date calls.
[03:38] <wookey> OK. cheers for help
[03:38] <infinity> No, skew is a problem on every single upload of.. Anything.
[03:38] <wookey> bedtime here
[03:39] <infinity> 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] <infinity> And that's all meant to "work" anyway, but it also means our arches aren't guaranteed self-contained anymore.
[03:39] <infinity> Or self-hosting.
[12:36] <ogra_> hrw, http://paste.ubuntu.com/1632851/ chromebook ambient light sensor control
[12:36] <ogra_> (eats a bit of battery due to polling though)
[14:40] <mosasaur> where is build-arm-chroot?
[14:40] <mosasaur> I mean the script
[15:26] <mosasaur> ah found it: http://packages.ubuntu.com/lucid/i386/qemu-kvm-extras-static/filelist
[17:07] <ogra_> oh, nice, flash is fully working on my chromebook as long as i dont use any compositor
[17:09] <tassadar_> like adobe flash?
[17:09] <tassadar_> or you mean the one built-in chrome?
[17:16] <ogra_> no, i mean the one that i copied from the chromeos partition to ubuntu
[17:16] <ogra_> running eith the ubuntu vhromium browser
[17:16] <ogra_> *chromum
[17:16] <tassadar_> hm, nice)
[17:16] <ogra_> bah
[18:46] <hrw> ogra_: run chromium browser with "--with-gl=egl" (or s/with/use/) ;)
[18:47] <ogra_> well, better add it to the chromium defaults proper :) but yeah
[18:47] <ogra_> see /etc/chromium-browser/default
[19:19] <Vic> 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] <Vic> Can someone help?
[21:16] <hrw> Vic: ignore warning
[22:09] <Vic> 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] <fly[ac100]> http://dpaste.org/g1Z5T/
[23:22] <fly[ac100]> how could it be?
[23:39] <infinity> Weren't those libraries supposed to get proper SO versioning at some point?
[23:48] <mdz> 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] <ubot2> Debian bug 659481 in llvm-3.0 "unable to execute command: No such file or directory" [Grave,Open]
[23:48] <mdz> anyone seen this?
[23:48] <mdz> (precise)
[23:50] <mdz> trying to compile a hello world has the same problem
[23:50] <mdz> aha, mounting /proc fixes it
[23:51] <mdz> in the chroot