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