| 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? | 01:46 |
| 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:21 |
| wookey | Does it build for you? | 02:23 |
| 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:24 |
| wookey | aha. OE people have fixed it: http://patches.openembedded.org/patch/42449/ | 02:25 |
| wookey | ok, that does the trick | 02:32 |
| infinity | I suspect that's the "wrong" fix, but it works for now. | 02:34 |
| wookey | is there a list of 2.17 changes that may break things like this? | 02:42 |
| 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:44 |
| 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:45 |
| infinity | wookey: Anyhow, uploading the fix to Ubuntu now, and submitting to Debian. | 02:55 |
| 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:57 |
| 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:58 |
| 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. | 02:59 |
| 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:00 |
| wookey | I guess so. It's just annoying for me when unrelated breakage comes and breaks everything | 03:02 |
| 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:03 |
| 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:04 |
| wookey | and staging fixes I forgot to upload source for | 03:05 |
| 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:06 |
| 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:11 |
| 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:12 |
| 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:14 |
| infinity | I'm also considering pushing the interdependant stageN stuff to glibc and gcc upstream. | 03:16 |
| 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:17 |
| 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:21 |
| wookey | Or maybe it can hang around as a convenince wrapper | 03:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| wookey | It just has different names in differnt packages and dpkg-builpackage ismissing an option for it | 03:28 |
| 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:31 |
| 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:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| 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:38 |
| 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. | 03:39 |
| === 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_ | ||
| ogra_ | hrw, http://paste.ubuntu.com/1632851/ chromebook ambient light sensor control | 12:36 |
| ogra_ | (eats a bit of battery due to polling though) | 12:36 |
| === 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 | ||
| mosasaur | where is build-arm-chroot? | 14:40 |
| mosasaur | I mean the script | 14:40 |
| === zz_chihchun is now known as chihchun | ||
| === chihchun is now known as zz_chihchun | ||
| === rsalveti_ is now known as rsalveti | ||
| mosasaur | ah found it: http://packages.ubuntu.com/lucid/i386/qemu-kvm-extras-static/filelist | 15:26 |
| === jackyalcine is now known as zz_jackyalcine | ||
| === zz_jackyalcine is now known as jackyalcine | ||
| === jackyalcine is now known as jackyalcine_ | ||
| ogra_ | oh, nice, flash is fully working on my chromebook as long as i dont use any compositor | 17:07 |
| tassadar_ | like adobe flash? | 17:09 |
| tassadar_ | or you mean the one built-in chrome? | 17:09 |
| 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 | 17:16 |
| === 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 | ||
| hrw | ogra_: run chromium browser with "--with-gl=egl" (or s/with/use/) ;) | 18:46 |
| ogra_ | well, better add it to the chromium defaults proper :) but yeah | 18:47 |
| ogra_ | see /etc/chromium-browser/default | 18:47 |
| === jackyalcine is now known as zz_jackyalcine | ||
| 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? | 19:19 |
| hrw | Vic: ignore warning | 21:16 |
| 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 | 22:09 |
| fly[ac100] | http://dpaste.org/g1Z5T/ | 23:22 |
| fly[ac100] | how could it be? | 23:22 |
| infinity | Weren't those libraries supposed to get proper SO versioning at some point? | 23:39 |
| 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:48 |
| mdz | trying to compile a hello world has the same problem | 23:50 |
| mdz | aha, mounting /proc fixes it | 23:50 |
| mdz | in the chroot | 23:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!