| 00:18.48 | *** join/#uclibc WildPikachu (~nkukard@about/linux/staff/wildpikachu) |
| 00:28.21 | *** join/#uclibc WildPikahcu_ (~nkukard@dsl-247-39-77.telkomadsl.co.za) |
| 00:40.54 | *** join/#uclibc xiangfu (~xiangfu@124.205.34.122) |
| 01:10.00 | *** join/#uclibc WildPikahcu_ (~nkukard@41-133-248-248.dsl.mweb.co.za) |
| 01:11.00 | *** join/#uclibc WildPikachu (~nkukard@about/linux/staff/wildpikachu) |
| 01:23.35 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 03:25.59 | *** join/#uclibc tchan (~tchan@lunar-linux/developer/tchan) |
| 03:40.35 | *** join/#uclibc Whoopie_ (Whoopie@unaffiliated/whoopie) |
| 04:15.59 | *** join/#uclibc angstrom1 (~mobilgeni@117.192.66.105) |
| 04:46.27 | angstrom1 | Thanks folks :). I figured out and enabled those options in the build. Now when I try to run the build, it fails to execute sed. The permissions are correct. /bin/bash: /home/linuxsri/Projects/SBC/buildroot-2010.08/output/toolchain/bin/sed: cannot execute binary file |
| 04:46.28 | angstrom1 | make: *** [/home/linuxsri/Projects/SBC/buildroot-2010.08/output/build/busybox-1.17.1/.stamp_configured] Error 126 |
| 04:53.32 | *** join/#uclibc antgreen (~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com) |
| 05:03.48 | angstrom1 | Anyone?? |
| 05:43.59 | *** join/#uclibc saftsack__ (~oliver@p5DDCE5FB.dip.t-dialin.net) |
| 05:57.13 | *** join/#uclibc fabled (~fabled@mail.fi.jw.org) |
| 06:05.32 | *** join/#uclibc doc2 (~Dieter@139.12.1.251) |
| 07:01.18 | speakman | try: file /home/linuxsri/Projects/SBC/buildroot-2010.08/output/toolchain/bin/sed |
| 07:02.39 | *** join/#uclibc angstrom2 (~mobilgeni@117.192.71.114) |
| 07:35.17 | *** join/#uclibc kos_tom (~thomas@humanoidz.org) |
| 08:13.27 | *** join/#uclibc angstrom1 (~mobilgeni@117.192.77.60) |
| 08:22.08 | CIA-62 | 03vda.linux 07master * r5ab20641d687 10busybox/Makefile: Bump version to 1.18.0 |
| 08:22.36 | CIA-62 | 03vda.linux 07refs/tags/1_18_0 * r5ab20641d687 10busybox/Makefile: Bump version to 1.18.0 |
| 08:29.50 | CIA-62 | 03vda.linux 07master * r6deeded94283 10busybox-website/news.html: Announce 1.18.0 |
| 08:44.59 | CIA-62 | 03vda.linux 071_18_stable * r5ab20641d687 10busybox/Makefile: Bump version to 1.18.0 |
| 08:53.09 | *** join/#uclibc |aks| (~kvirc@mx.3alitydigital.de) |
| 08:56.08 | *** join/#uclibc doc2 (~Dieter@139.12.1.251) |
| 09:19.48 | *** join/#uclibc doc2 (~Dieter@139.12.1.251) |
| 09:30.47 | *** join/#uclibc calculus (~calculus@gentoo/user/calculus) |
| 09:37.10 | CIA-62 | 03dvlasenk 07master * rfc61b2addfe5 10busybox-website/news.html: mark 1.18.0 as *un*stable |
| 09:42.48 | CIA-62 | 03dvlasenk 07master * r7b8028ce1055 10busybox-website/news.html: cosmetic fixes in changelog |
| 12:28.35 | *** join/#uclibc ibot (~ibot@rikers.org) |
| 12:28.35 | *** topic/#uclibc is discussion of uClibc, Busybox and Buildroot | uClibc 0.9.31 was released 2nd Apr 2010 | busybox 1.17.3 was released 9 October 2010 (unstable busybox 1.18.0) | Buildroot 2010.08 was released 31 August 2010 (2010.11-rc1 on 9 November 2010) | For general setup issues try #elinux or #edev |
| 12:57.19 | *** join/#uclibc kos_tom (~thomas@humanoidz.org) |
| 13:15.33 | speakman | Shouldn't there be an additional "install" target in packages' Makefiles? |
| 13:16.39 | speakman | Currently, binaries are installed in the output/target on the "make" stage, which makes it timeconsuming to rebuild the output/target tree (when finetuning your skeleton for example) |
| 13:20.39 | gustavoz | there is |
| 13:21.15 | gustavoz | $package-install does the trick, of course if you're tweaking and said package was installed it does nothing, but you can $package-uninstall first to force it |
| 13:28.29 | speakman | Is there a target in top level Makefile to rebuild output/target/ dir? |
| 13:29.27 | speakman | I just did rm -rf output/target/ and then "make" on top level. The result was a new output/target/ dir with just a minor of all stuff supposed to be there. The skeleton wasn't even copied. |
| 13:30.14 | kos_tom | speakman: the stamps files related to the installation of packages are not in output/target, so removing output/target just cannot work. |
| 13:32.17 | gustavoz | find output/build -name .stamp_target_installed -exec rm {} \; may work, never tested though |
| 13:32.50 | dj-death | you'll miss the libc etc... |
| 13:32.59 | gustavoz | oh yes, that's the reason "may work" :) |
| 13:33.20 | speakman | really? according to http://buildroot.uclibc.org/buildroot.html#add_packages there should be a $(TARGET_DIR)/$(LIBFOO_TARGET_BINARY): $(LIBFOO_DIR)/$(LIBFOO_BINARY) target? |
| 13:33.27 | dj-death | I think removing output/build/.root may help |
| 13:33.46 | dj-death | but it's going to reinstall staging as well (for the libc part) |
| 13:34.11 | speakman | nope, removing .root didn't do the trick |
| 13:34.15 | gustavoz | what's the problem with your skeleton? if it's clean enough you may usually just overwrite everything in the target with it |
| 13:35.07 | speakman | gustavoz: that's maybe true, but it's much "cleaner" to have a "install" target in top level Makefile |
| 13:36.54 | gustavoz | speakman: it might be interesting, however i'm interested in doing the toolchain migration ATM :) |
| 13:36.59 | speakman | if all packages were like the tutorial, removing output/target/ should work. At least for the non toolchain-packages. http://buildroot.uclibc.org/buildroot.html#manual-tutorial |
| 13:37.16 | speakman | toolchain migration? |
| 13:38.12 | gustavoz | speakman: the manual makefile is the old way of doing packages, we're going away from that |
| 13:38.15 | speakman | (note that there's no libfoo-install target) |
| 13:38.43 | speakman | gustavoz: so what's the plan? |
| 13:39.01 | gustavoz | speakman: autotargets for auto* packages or gentargets for regular makefile |
| 13:39.03 | speakman | sort of liked it... :) |
| 13:39.32 | speakman | http://buildroot.uclibc.org/buildroot.html#generic-tutorial ? |
| 13:39.50 | gustavoz | yes |
| 13:41.02 | gustavoz | with the old method you had to do almost everything by hand and duplicated things that are pretty much generic |
| 13:41.17 | speakman | may I ask where the "magic" of autopackages happens? like where's the parsing of the Makefile? |
| 13:41.40 | speakman | gustavoz: that's true, at least for packages using autotools. |
| 13:42.14 | gustavoz | speakman: it's the same for generic (non-auto) packages, you don't need to handle the fetching, patching and so on |
| 13:42.55 | speakman | oh.. it's line 27 i guess; $(eval $(call GENTARGETS,package,libfoo)) |
| 13:43.31 | kos_tom | speakman: "manual packages" no longer exist. |
| 13:43.56 | kos_tom | speakman: as stated at the beginning of this section, "NOTE: new manual makefiles should not be created, and existing manual makefiles should be converted either to the generic infrastructure or the autotools infrastructure. This section is only kept to document the existing manual makefiles and to help understand how they work." |
| 13:44.02 | gustavoz | part of the toolchain thing i'm doing is getting them away from being manual packages for example |
| 13:45.01 | kos_tom | speakman: generic and autotargets packages use infrastructure in package/Makefile.{package,autotools}.in |
| 13:45.19 | speakman | kos_tom: you want me to read ALL the documentation? *blush* :) |
| 13:45.22 | kos_tom | gustavoz: is it possible to track your progress on this on some git tree ? |
| 13:45.49 | kos_tom | speakman: basically, what you want to do is today not possible with the current infrastructure. We need to make further improvements to make this possible. |
| 13:45.54 | gustavoz | kos_tom: i'll be uploading the stuff once i finish my regression tests :) |
| 13:46.34 | speakman | kos_tom: you mean remaking the output/target/ ? |
| 13:46.50 | kos_tom | speakman: yes. |
| 13:47.03 | kos_tom | gustavoz: great. Is the job finished already ? |
| 13:47.40 | gustavoz | kos_tom: not yet, done with the support stuff (mpc, mpfr, gmp) and making the toolchain use the new way |
| 13:48.05 | gustavoz | kos_tom: next step is moving binutils/gcc to host instead of staging, and then probably converting binutils to a package. gcc might be tricky in that regard. |
| 13:48.49 | gustavoz | at the moment everything works even target toolchain |
| 13:49.32 | *** join/#uclibc mnt_real (~mnt_real@bas9-montrealak-1177755340.dsl.bell.ca) |
| 13:50.25 | kos_tom | gustavoz: so mpc, mpfr and gmp are now installed in $(HOST_DIR), and the toolchain is linked dynamically against it ? |
| 13:50.31 | kos_tom | s/it/them/ |
| 13:51.36 | speakman | priceless bot? :) |
| 13:51.49 | gustavoz | kos_tom: yes sir |
| 13:52.04 | kos_tom | gustavoz: awesome! |
| 13:52.16 | kos_tom | gustavoz: so you're using the --rpath trick ? |
| 13:52.52 | speakman | kos_tom and gustavoz: How far is the migration of this "new way" to mainline? |
| 13:52.58 | gustavoz | kos_tom: not needed, gcc is hardcoded to find libmpfr/gmp/mpc in the correct path |
| 13:53.13 | speakman | http://wiki.debian.org/RpathIssue |
| 13:53.15 | kos_tom | gustavoz: ah. How ? |
| 13:53.33 | kos_tom | speakman: yes, rpath on target is incorrect, but rpath on host is ok for what we are doing. |
| 13:53.40 | speakman | oh i see |
| 13:55.15 | *** join/#uclibc bkuhn (~bkuhn@fsf/director/conservancy.president.bkuhn) |
| 13:57.06 | speakman | Looking at the "new way" of doing packages Makefile, there is a LIBFOO_INSTALL_TARGET_CMDS; shouldn't that be enought for a "make install" (or even better; "make image") feature in Buildroot? |
| 13:58.12 | speakman | (another feature I'd like is to see is to split the target filesystem into two filesystem images, but that's another story I guess) |
| 13:58.15 | kos_tom | speakman: probably. Not sure what's the use case is for such a "make install" target. |
| 13:58.57 | speakman | to remake the filesystem? |
| 13:59.11 | speakman | if there has been a change in skeleton e.g. |
| 13:59.57 | speakman | I remember Axis supported "make images" in their SDK (which worked pretty much as Buildroot does), and I used pretty often. |
| 14:00.56 | gustavoz | kos_tom: i'm passing the hostdir for the components and it gets hardcoded in the binaries (--with-mpc=$(MPC_HOST_DIR) and so on) |
| 14:01.11 | kos_tom | gustavoz: ah, ok. |
| 14:01.29 | gustavoz | kos_tom: i'm waiting for jacmet to pull the remaining patches for 2010.11 to upload this, or i could just make a new repo |
| 14:01.33 | speakman | No more host binaries in staging dir..? |
| 14:01.43 | kos_tom | gustavoz: you can make a separate branch in the same repo. |
| 14:02.01 | gustavoz | kos_tom: yes, but i gotta merge first :) |
| 14:02.01 | kos_tom | speakman: no, we're moving away from that since it's incorrect. |
| 14:02.19 | kos_tom | merge what ? |
| 14:02.21 | speakman | kos_tom: I agree it is |
| 14:02.25 | gustavoz | kos_tom: jacmet's changes :) |
| 14:02.54 | kos_tom | gustavoz: not sure to understand. Just base your toolchain changes on the current buildroot master, and put them in a separate branch from you 2011.11-specific fixes. |
| 14:04.03 | speakman | May I ask if there's a official roadmap for Buildroot? I'm interrested in the development, but I havn't heard of this new "toolchain migration" :) |
| 14:04.41 | speakman | Is there any lists of available Buildroot git repositories? |
| 14:05.13 | speakman | CIA seems to know a few, but won't hand over the list :) |
| 14:07.04 | gustavoz | kos_tom: i'll give it a shot, my git-fu isn't top notch :) |
| 14:07.17 | gustavoz | should have branched before |
| 14:07.20 | kos_tom | speakman: no, we don't have a written roadmap. I've started a wiki, but haven't had the time to migrate contents over it. This would be the good place for this kind of stuff. |
| 14:07.33 | kos_tom | gustavoz: you can create a branch as an afterthought as well. |
| 14:07.51 | gustavoz | kos_tom: hmm yeah but i gotta roll back conflicting commits |
| 14:08.03 | gustavoz | s/roll/resolve/ |
| 14:08.18 | speakman | kos_tom: sounds great! Is there an official project manager for Buildroot currently? |
| 14:08.19 | kos_tom | not sure what your repo organization is, so a bit hard to help you here :) |
| 14:08.32 | kos_tom | speakman: yes, Peter Korsgaard (Jacmet on IRC) |
| 14:08.39 | gustavoz | kos_tom: i did a pull from master buildroot -> my master, so it's messy :) |
| 14:08.44 | speakman | Thanks! :) |
| 14:08.47 | gustavoz | and i've commited to my master |
| 14:08.57 | kos_tom | gustavoz: aah, this is bad. |
| 14:09.13 | gustavoz | kos_tom: i'll export the remaining patches, refetch everything and branch there |
| 14:09.30 | gustavoz | that way i can keep my master -> real master |
| 14:10.32 | speakman | or rename your master, and pull a new master? |
| 14:11.50 | gustavoz | it'll be easier to redo so i can branch small fixes for-2010.11 and so on |
| 14:11.58 | gustavoz | i'll need multiple branches |
| 14:13.23 | kos_tom | gustavoz: I always have ~10 local branches to do BR development. |
| 14:13.46 | gustavoz | kos_tom: i've seen, didn't expect to be doing that much so i didn't branch initially but things changed |
| 14:13.54 | kos_tom | gustavoz: I had a gmp-conversion branch, of which a few commits might be interesting to you (minor cleanups). |
| 14:13.54 | speakman | (maybe you could checkout your current master into a new branch, and then revert your master into origin/master) |
| 14:14.27 | gustavoz | i'm just saving the relevant patches, it's easy, i'll git am everything once i'm upstream |
| 14:14.30 | speakman | branching is sort of science... |
| 14:14.32 | kos_tom | gustavoz: you can always create a branch for the current commit, and then move back master to the latest commit of the upstream master branch. |
| 14:14.40 | kos_tom | gustavoz: a branch is nothing but a pointer to a particular commit |
| 14:15.00 | speakman | kos_tom: like I just said... :D |
| 14:15.02 | gustavoz | kos_tom: gotta do the cleanup to see what's pending for 2010.11 anyway, i'm not that far |
| 14:15.40 | speakman | Is there at least a roadmap for 2010.11? |
| 14:16.42 | kos_tom | speakman: 2010.11 is mostly done. rc1 has been released, so nothing spectacular will happen before the release. And the final release should show up in ~one week. |
| 14:17.17 | gustavoz | my pending fixes are mostly build fixes, like the squid one |
| 14:18.08 | speakman | sounds great. It just that it's seems a bit difficult to new people (like me) to know what's going on. Hence my questions :) |
| 14:18.42 | kos_tom | gustavoz: http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=gmp-conversion&id=d4558237e2f1277a21fcf5e4837f5d34d6c8cdcd |
| 14:18.51 | kos_tom | gustavoz: http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=gmp-conversion&id=f239ca52a5999443316c5fbf07903f713edb2fad |
| 14:18.58 | kos_tom | gustavoz: http://git.buildroot.net/~tpetazzoni/git/buildroot/commit/?h=gmp-conversion&id=092311d1f725f114d72c1106e8ded2971480f424 |
| 14:19.26 | gustavoz | kos_tom: cool, thanks, i'll be merging your mips patches as well |
| 14:19.29 | kos_tom | gustavoz: if you could pick up such clean-ups as part of your work, that'd be great. |
| 14:19.45 | gustavoz | kos_tom: sure, that's the idea :) |
| 14:19.45 | kos_tom | gustavoz: ah, I would have preferred to keep working on the MIPS patches as they are definitely not finalized. |
| 14:20.06 | kos_tom | gustavoz: for the gmp-conversion patches, just go ahead. I don't mind if you don't keep the attribution, those are trivial cleanups. |
| 14:20.23 | gustavoz | kos_tom: as you wish, o64 is probably the broken puppy you mentioned |
| 14:20.42 | gustavoz | kos_tom: wrt to binutils my plan is to just make it a package, shouldn't be an issue. |
| 14:21.08 | kos_tom | gustavoz: yes, good idea. Have you move gmp/mpfr/mpc to package/ as well ? |
| 14:21.24 | gustavoz | kos_tom: they were packages before, though manual ones, they're auto now :) |
| 14:21.37 | kos_tom | gustavoz: the issue with binutils/gcc is the version selection. When you are in external toolchain mode and you want binutils and gcc for the target, you don't have the version selection available. |
| 14:21.44 | kos_tom | gustavoz: ah, yes, right they were packages. |
| 14:42.37 | *** join/#uclibc Skyscraper (5c4d6a90@gateway/web/freenode/ip.92.77.106.144) |
| 14:42.48 | Skyscraper | hello |
| 14:43.27 | *** join/#uclibc risca (~risca@tappan-125-84.eduroam.liu.se) |
| 15:19.12 | *** join/#uclibc dj-death_ (~djdeath@ims92-1-88-163-235-97.fbx.proxad.net) |
| 15:19.46 | *** join/#uclibc gmk_ (~gmk@69.72.137.146) |
| 15:21.11 | *** join/#uclibc tteras_ (~fabled@mail.fi.jw.org) |
| 15:23.53 | *** join/#uclibc blindvt_ (~bf@85-127-155-31.dynamic.xdsl-line.inode.at) |
| 15:48.42 | *** join/#uclibc wash (~wash@149.106.192.131) |
| 16:05.09 | gustavoz | kos_tom: http://repo.or.cz/w/buildroot-gz.git/shortlog/refs/heads/toolchain-rework (now with host_dir instead of staging_dir, still testing but works so far) |
| 16:30.13 | *** join/#uclibc tsukasa (~tsukasa@unaffiliated/tsukasa) |
| 16:33.20 | kos_tom | - #rm -f $(STAGING_DIR)/usr/bin/{ar,as,ld,nm,objdump,ranlib,strip} |
| 16:33.20 | kos_tom | + #rm -f $(HOST_DIR)/usr/bin/{ar,as,ld,nm,objdump,ranlib,strip} |
| 16:33.33 | kos_tom | this is commented out, but I really hope the toolchain installation will never install those files. |
| 16:34.05 | kos_tom | gustavoz: looks good! |
| 16:34.22 | kos_tom | gustavoz: but now that you install the toolchain in HOST_DIR, where do you copy the sysroot from HOST_DIR to STAGING_DIR ? |
| 16:34.26 | gustavoz | kos_tom: yeah, i'll do the cleanup later on, there are many of those :) |
| 16:35.09 | gustavoz | kos_tom: sysroot is installed in staging from the beginning |
| 16:35.26 | kos_tom | gustavoz: ok, I think we'll want to change this. |
| 16:36.00 | gustavoz | kos_tom: probably, it's a work in progress(tm). we'll also want to handle libmudflap since it's installed in host_dir and should be in staging_dir (maybe target_dir too) |
| 16:36.16 | kos_tom | gustavoz: ok. |
| 16:36.58 | gustavoz | kos_tom: and the docs, we may finally say "hey put HOST_DIR/usr/bin in your path and build away!" |
| 16:39.32 | kos_tom | gustavoz: that's the goal! |
| 16:39.47 | kos_tom | gustavoz: and also to build a sdk. I will write down the report from the Buildroot Developer Day tonight. |
| 16:39.47 | gustavoz | ok, gdb needs a fix, testing, fixing... |
| 16:39.57 | gustavoz | kos_tom: cool that way i'll know where to head to |
| 16:40.10 | kos_tom | gustavoz: I asked " the issue with binutils/gcc is the version selection. When you are in external toolchain mode and you want binutils and gcc for the target, you don't have the version selection available." 2 hours ago. Do you have an idea on this ? |
| 16:40.59 | gustavoz | kos_tom: didn't look into that, but have an idea how to solve it in the future: make gcc/binutils target packages |
| 16:41.32 | gustavoz | kos_tom: at the moment binutils/gcc .mk files make both which i don't like that much |
| 16:41.33 | kos_tom | gustavoz: maybe even cross gcc and cross binutils need to be moved into package/ as well. |
| 16:41.41 | *** join/#uclibc tchan (~tchan@lunar-linux/developer/tchan) |
| 16:42.17 | gustavoz | kos_tom: binutils will be a package, i don't see that being a problem and it's next on my list for the rework. gcc might be somewhat spooky to achieve but i'll give it a shot. |
| 16:42.35 | gustavoz | kos_tom: mostly because gcc is built a couple of times with uclibc |
| 16:42.47 | kos_tom | gustavoz: yeah, gcc is a complicated beast. |
| 16:43.17 | *** join/#uclibc roadies (~chrislrob@stun.cmf.nrl.navy.mil) |
| 16:44.02 | gustavoz | kos_tom: gdb is another candidate to be a proper package |
| 16:44.12 | kos_tom | gustavoz: yes, definitely. |
| 16:44.33 | gustavoz | kos_tom: the main aim should be to just keep toolchain/ for the glue |
| 16:44.39 | kos_tom | gustavoz: and I'd really like to take advantage of this rework effort to clean up the way it interacts with external toolchains as well. |
| 16:45.06 | roadies | After upgrading to Fedora 14 buildroot will not build generating the following error: Makefile:178: *** mixed implicit and normal rules. It seems make has changed. Anyone run into this and a fix? |
| 16:48.26 | gustavoz | yay, nothing in staging/usr/lib or bin! |
| 16:49.42 | Skyscraper | does anyone know, how to crosscompile perl for MIPS? |
| 16:53.21 | kos_tom | gustavoz: you moved the sysroot to host_dir ? |
| 16:53.28 | kos_tom | Skyscraper: well, just use Buildroot, no ? :-) |
| 16:53.45 | kos_tom | roadies: what is your config ? which package does not build exactly ? |
| 16:54.38 | gustavoz | kos_tom: not yet |
| 16:54.59 | kos_tom | gustavoz: oh, ok. |
| 16:55.11 | gustavoz | kos_tom: it's still living at staging_dir |
| 16:55.18 | roadies | kos_tom: was trying to build release 2010_08 but now trying the release candidate |
| 16:56.00 | roadies | kos_tom: it appears to be running without failure so far.... |
| 16:56.06 | gustavoz | kos_tom: oh, yeah, wrong wording on my part "empty staging/lib and staging/usr/bin" (not usr/lib) hehe |
| 16:56.50 | gustavoz | kos_tom: no host crap actually :) |
| 16:58.42 | kos_tom | roadies: well, "buildroot fails too build" is far too unprecise to be able to help. There are hundreds of packages and hundreds of configurations in Buildroot. |
| 16:59.14 | kos_tom | roadies: but your problem is related to the fact that Fedora 14 uses make 3.82, and yes 2010.11-rcX have fixes for this. |
| 16:59.40 | roadies | kos_tom: yeah sorry so note, the real problem I think is with the kernel itself, aka one fix for this was the main Makefile in the linux sub-directory. The downside to this is one can't build a prior linux release...say....2.6.19.1 |
| 17:01.13 | roadies | kos_tom: thanks its what I though, aka change with make which is a bummer cause even though buildroot allows building prior linux it wont work cause of make update |
| 17:01.15 | kos_tom | roadies: yes. That's a known problem with make 3.82. Everybody is wondering why they broke the compatibility so quickly. |
| 17:01.57 | roadies | kos_tom: they did that to drive struggling fools like me up the wall... *sigh* |
| 17:02.10 | roadies | :-D |
| 17:03.26 | gustavoz | kos_tom: the intention of having a sysroot copy in host_dir is to be able to "pack a toolchain" so to speak right? |
| 17:05.08 | kos_tom | gustavoz: yes. But the intention is to compile/install the sysroot in host_dir, and *then* copy it to staging_dir, similarly to what we do with external toolchain and crosstool-ng toolchains. |
| 17:06.03 | gustavoz | kos_tom: so basically build a $(HOST_DIR)/usr/mips-xxxx/sysroot directory in it to avoid overwriting host files? |
| 17:06.14 | gustavoz | (or some other dir that's already been thought of) |
| 17:10.15 | kos_tom | gustavoz: exactly. |
| 17:44.35 | *** join/#uclibc y_morin (~ymorin@ARennes-256-1-75-87.w90-32.abo.wanadoo.fr) |
| 18:08.51 | *** join/#uclibc trem (~trem@mol92-1-81-57-136-23.fbx.proxad.net) |
| 18:34.18 | *** join/#uclibc Artemys (~quassel@stp25-1-82-225-18-227.fbx.proxad.net) |
| 19:22.09 | *** join/#uclibc Orphis_ (~quassel@belgarath.moomoocamp.net) |
| 19:40.48 | kos_tom | trem: hello |
| 19:41.08 | trem | kos_tom: hello |
| 19:45.47 | *** join/#uclibc rellig (~rellig@vs1191017.vserver.de) |
| 19:57.10 | *** join/#uclibc gustavoz (~gustavoz@host145.190-31-135.telecom.net.ar) |
| 20:05.35 | *** join/#uclibc rellig (~rellig@vs1191017.vserver.de) |
| 20:06.02 | y_morin | kos_tom, trem: hello! |
| 20:06.03 | y_morin | wants to play also! |
| 20:06.23 | trem | that's a new game |
| 20:06.43 | kos_tom | trem: I've push a fix to the for-2011.02/boards-cleanup branch that so that with minimal kernel configs, it doesn't hang asking hundreds of questions. |
| 20:07.15 | trem | kos_tom: I haven't forget the sh4 config, but my box don't want to boot |
| 20:34.19 | *** join/#uclibc risca (~risca@h241n2-n-a31.ias.bredband.telia.com) |
| 20:46.32 | *** join/#uclibc wash (~wash@149.106.192.131) |
| 20:48.23 | *** join/#uclibc Orphis (~quassel@belgarath.moomoocamp.net) |
| 21:08.13 | kos_tom | Jacmet: around ? |
| 21:08.19 | kos_tom | trem: ah, hardware problem ? |
| 21:08.49 | kos_tom | I am very stupid, I removed the few slides I prepared for the Buildroot Developer Day. |
| 21:09.09 | trem | kos_tom: I don't understand, grub tell me "error 18" |
| 21:09.22 | trem | kos_tom: I've just removed some old kernel .... |
| 21:22.13 | *** join/#uclibc Orphis (~quassel@belgarath.moomoocamp.net) |
| 21:28.42 | y_morin | kos_tom: nice report! :-) |
| 21:29.09 | kos_tom | y_morin: I hope I didn't miss anything important. |
| 21:30.39 | y_morin | kos_tom: not that I could notice. |
| 21:30.50 | y_morin | s/not/none/ |
| 21:43.20 | *** join/#uclibc trem_ (~trem@mol92-1-81-57-136-23.fbx.proxad.net) |
| 21:47.56 | *** join/#uclibc dantje (~dvg@HSI-KBW-091-089-103-221.hsi2.kabelbw.de) |
| 22:31.01 | trem | nite all, sweet dreams |
| 22:36.01 | *** join/#uclibc khem (~khem@99-57-141-118.lightspeed.sntcca.sbcglobal.net) |
| 22:54.25 | *** join/#uclibc hgb (~hgb@tussi.moria.no) |
| 23:40.57 | *** join/#uclibc hgb (~hgb@tussi.moria.no) |
| 23:53.02 | *** join/#uclibc WildPikachu (~nkukard@about/linux/staff/wildpikachu) |