| 00:32.55 | *** join/#uclibc xiangfu (~xiangfu@124.205.34.122) |
| 01:03.19 | *** join/#uclibc animeloe[net] (~animeloen@unaffiliated/animeloe) |
| 01:18.05 | *** join/#uclibc julm (~julm@commune-des.alpes.fr.eu.org) |
| 02:00.22 | *** join/#uclibc hgb (~hgb@tussi.moria.no) |
| 02:21.59 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 02:27.43 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 02:34.13 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 02:53.53 | *** join/#uclibc bitterman (~yury@84.51.198.114) |
| 03:16.51 | *** join/#uclibc ashes (~ashes@modemcable247.172-202-24.mc.videotron.ca) |
| 03:37.12 | *** join/#uclibc Whoopie_ (Whoopie@unaffiliated/whoopie) |
| 03:40.57 | *** join/#uclibc curious (curious@bwv190.internetdsl.tpnet.pl) |
| 03:46.01 | *** join/#uclibc julm (~julm@commune-des.alpes.fr.eu.org) |
| 04:26.28 | *** join/#uclibc hgb (~hgb@tussi.moria.no) |
| 04:28.49 | *** join/#uclibc julm (~julm@commune-des.alpes.fr.eu.org) |
| 04:30.04 | *** join/#uclibc wash (~wash@76-231-175-122.lightspeed.wlfrct.sbcglobal.net) |
| 04:34.57 | *** join/#uclibc julm (~julm@commune-des.alpes.fr.eu.org) |
| 04:44.21 | *** join/#uclibc antgreen (~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com) |
| 05:44.30 | *** join/#uclibc saftsack__ (~oliver@p5DDCDFF2.dip.t-dialin.net) |
| 06:08.20 | *** join/#uclibc doc2 (~Dieter@139.12.1.251) |
| 06:09.35 | *** join/#uclibc CapnKernel (~mjd@ppp59-167-188-93.static.internode.on.net) |
| 06:13.23 | *** join/#uclibc hgb (~hgb@tussi.moria.no) |
| 06:55.29 | *** join/#uclibc ncopa (~ncopa@3.203.202.84.customer.cdi.no) |
| 07:06.25 | *** join/#uclibc Artemys (~quassel@stp25-1-82-225-18-227.fbx.proxad.net) |
| 07:07.50 | *** join/#uclibc julm (~julm@commune-des.alpes.fr.eu.org) |
| 07:58.07 | kos_tom | hello |
| 08:17.41 | *** join/#uclibc tiny (~ivob@unaffiliated/tiny) |
| 08:31.23 | *** join/#uclibc likewise (~likewise@205-89-ftth.onsneteindhoven.nl) |
| 08:41.29 | *** join/#uclibc xiangfu (~xiangfu@124.205.34.122) |
| 09:09.32 | *** join/#uclibc kos_tom (~thomas@humanoidz.org) |
| 09:13.07 | Jacmet | kos_tom: I am now |
| 09:13.21 | kos_tom | Jacmet: hey, hello :) |
| 09:13.54 | kos_tom | Jacmet: this was to discuss the patch proposed by vapier to use a custom tree for the kernel source tree (to make it possible to use an already available source tree) |
| 09:14.09 | kos_tom | Jacmet: in general, I like this, but I wanted to see if we wanted to make this more generic. |
| 09:14.30 | vapier | how can it possibly be more generic than "enter a fs path" |
| 09:15.00 | kos_tom | Jacmet: because at the package level, we have the same issue, when you're working on your app/library, you would want Buildroot to use the source tree you are editing instead of downloading a tarball or a git repo |
| 09:15.51 | Jacmet | kos_tom: sorry, I haven't had time to look at the patch yet |
| 09:16.31 | Jacmet | kos_tom: but yes, if we could do something like that easily that would be cool |
| 09:30.20 | *** join/#uclibc Artemys (~quassel@stp25-1-82-225-18-227.fbx.proxad.net) |
| 09:40.54 | dj-death | kos_tom: interesting idea ;) |
| 09:56.11 | kos_tom | Jacmet: the problem is how to implement this and how it should be presented to users. |
| 09:59.22 | Jacmet | kos_tom: yes, I don't really have any ideas about it atm |
| 09:59.35 | Jacmet | is coming down with a flu .. - Can't think :/ |
| 10:00.24 | kos_tom | argh :-( |
| 10:00.54 | Jacmet | kos_tom: yes, indeed :/ |
| 10:01.28 | Jacmet | I should go home, but I have invited a bunch of people for a meeting this afternoon |
| 10:11.57 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 10:13.29 | dj-death | kos_tom: why not introduce a package named 'external-pkg' and let the user specify the path to it with something like this : make external-pkg EXTERNAL_PKG_PATH=/tmp/somewhere |
| 10:14.36 | dj-death | kos_tom: in the pre hook we would touch .stamp_downloaded/.stamp_patched/etc... to avoid useless steps |
| 10:15.46 | dj-death | kos_tom: but it make sense only for autotooled packages... |
| 10:16.16 | dj-death | kos_tom: otherwise the user would have to write a makefile |
| 10:17.02 | kos_tom | dj-death: well, initially I wanted to allow the user to do this for any existing package. |
| 10:18.23 | dj-death | kos_tom: unless the user sets a variable to an external makefile that will be included by buildroot |
| 10:18.55 | kos_tom | dj-death: yeah, to somehow "override" the default BR behaviour. |
| 10:19.08 | dj-death | make external-pkg EXTERNAL_PKG_PATH=/tmp/somewhere EXTERNAL_PKG_MK=/tmp/pkg.mk |
| 10:19.34 | kos_tom | yeah, but this is really for external packages |
| 10:19.46 | kos_tom | I wanted this to also work for Linux, Cairo, Gtk2, even if they are packaged inside Buildroot. |
| 10:19.58 | dj-death | in case the variable is not defined we fill it with a home made .mk which display an error |
| 10:20.19 | dj-death | kos_tom: hmmm ok |
| 10:29.54 | kos_tom | dj-death: btw, do you think you'll have time to make some progress on the package management ? |
| 10:30.08 | kos_tom | dj-death: it'd be really awesome if we could have it working for 2011.02. |
| 10:30.32 | kos_tom | dj-death: I'll be around Paris around Christmas, maybe we can set up a one-day hacking session on this topic ? |
| 10:37.28 | *** join/#uclibc likewise_ (~likewise@205-89-ftth.onsneteindhoven.nl) |
| 11:07.07 | *** join/#uclibc likewise (~likewise@205-89-ftth.onsneteindhoven.nl) |
| 11:08.27 | dj-death | kos_tom: the end of the year is going to be a little crazy for me |
| 11:09.33 | kos_tom | dj-death: hm, ok. So it is possible for somebody else to build on top of your package management work ? |
| 11:09.46 | dj-death | kos_tom: I'm planning a relocation to london early in january |
| 11:09.50 | dj-death | kos_tom: yes of course |
| 11:10.00 | kos_tom | dj-death: oh, relocating to london, nice! |
| 11:10.26 | dj-death | heh |
| 11:10.28 | dj-death | I hope |
| 11:44.04 | *** join/#uclibc dantje (~dvg@HSI-KBW-091-089-103-221.hsi2.kabelbw.de) |
| 11:58.32 | *** join/#uclibc gustavoz (~gustavoz@host155.201-252-51.telecom.net.ar) |
| 12:02.43 | *** join/#uclibc julm (~julm@commune-des.alpes.fr.eu.org) |
| 12:08.47 | *** join/#uclibc julm (~julm@commune-des.alpes.fr.eu.org) |
| 12:17.35 | *** join/#uclibc julm (~julm@195.88.84.51) |
| 12:44.20 | *** join/#uclibc risca (~risca@tappan-125-84.eduroam.liu.se) |
| 13:08.56 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 13:23.59 | *** join/#uclibc doc2 (~Dieter@139.12.1.251) |
| 13:25.19 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 13:30.52 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 13:52.55 | *** join/#uclibc CapnKernel (~mjd@ppp59-167-188-93.static.internode.on.net) |
| 13:52.55 | *** join/#uclibc dougmencken (~quassel@93.123.156.139) |
| 13:54.36 | dj-death | kos_tom: about the external package thing, it might be possible to overwrite the <PKG_NAME>_DIR |
| 13:55.19 | speakman | dj-death: this is weird; I was just about to press enter to say exactly the same thing, when your line appeared... |
| 13:55.23 | speakman | creepy it is |
| 13:55.49 | dj-death | ;) |
| 13:55.55 | kos_tom | dj-death: yeah, maybe. I'm not sure what the exact consequences would be. |
| 13:56.34 | dj-death | but we would have to move $(BUILD_DIR)/%/.stamp_* rules into GENTARGETS_INNER |
| 13:56.37 | kos_tom | there are also other issues involved: with the default build procedure, once the .stamp_* files exist, next time you run "make" in Buildroot, it doesn't restart the build of the package |
| 13:56.51 | kos_tom | while here, for external packages, you want to run the build + install step everytime you run "make" in Buildroot. |
| 13:57.06 | dj-death | kos_tom: yep |
| 13:57.30 | gustavoz | feel free to checkout toolchain-rework now that binutils is a package ;) |
| 13:57.35 | dj-death | you'll need to set to buildroot you're about to build something externaly |
| 13:57.55 | dj-death | s/set/tell/ |
| 13:57.58 | gustavoz | TODO: fix xtensa patches support in binutils, fix elf2flt in the toolchain |
| 13:58.26 | kos_tom | dj-death: yeah. Doesn't sound very easy to do. |
| 13:58.38 | dj-death | this would deactivate download/patch |
| 13:59.07 | dj-death | then one more variable to override pkg build directory |
| 13:59.17 | dj-death | and the rule to trigger |
| 13:59.51 | kos_tom | ideally, I'd like to have a "local.mk" so that the user can override what he wants to do with the packages. But as we discussed in Cambridge, the issue is that it's not possible to include this file between the variable definitions in the package .mk and the call to GEN/AUTOTARGETS |
| 14:00.03 | *** join/#uclibc WildPikachu (~nkukard@about/linux/staff/wildpikachu) |
| 14:00.03 | speakman | PKG_OVERRIDE_BUILDDIR=... and if set, always build and install (ignore .stamps?) |
| 14:00.44 | kos_tom | speakman: yeah, but in which file do you put this PKG_OVERRIDE_BUILDDIR ? |
| 14:01.01 | dj-death | BR_BUILD_EXTERNAL=1 => no download/patch |
| 14:01.15 | kos_tom | aah, or maybe the local.mk file can be included *before* all package .mk files |
| 14:02.09 | dj-death | and for example set LIBGTK2_DIR=/tmp/gtk+ => you change the libgtk2 package build directory, without touching anything else |
| 14:02.11 | speakman | kos_tom: cd ~/path/to/buildroot && make MYPKG_OVERRIDE_BUILDDIR=~/path/to/myproject |
| 14:02.29 | speakman | you could also set your env; export MYPKG_OVERRIDE_BUILDDIR=~/... |
| 14:02.41 | kos_tom | speakman: I'd prefer to have the MYPKG_OVERRIDE_BUILDDIR in a file, but it doesn't make a lot of difference. |
| 14:02.52 | speakman | In this way, you can build several packages externally |
| 14:03.02 | dj-death | I would rather avoid to change the whole build directory |
| 14:03.32 | speakman | dj-death: what would you prefer? copying source files? VPATH build? |
| 14:05.45 | dj-death | speakman: hmm i though you wanted to change the variable containing "ouput/build/" by something else |
| 14:05.48 | dj-death | speakman: my mistake |
| 14:06.40 | kos_tom | speakman's idea sounds pretty good to me on the principle. |
| 14:06.42 | speakman | thought we were talking about executing e.g. PKG_BUILD_CMDS in a custom path? |
| 14:07.06 | kos_tom | gustavoz: yeah, I git-fetched your tree yesterday evening. I'll do it again now, because I'll spend 2H in the train tonight, so I'll be able to have a look at it. |
| 14:07.49 | gustavoz | kos_tom: ideas i'm shuffling around... make gcc target a package (and keep the host/cross one as it is for now), elf2flt->package (like 95% sure) |
| 14:08.14 | gustavoz | kos_tom: i'll prolly be doing the sysroot move later today |
| 14:08.44 | gustavoz | and do the cleanup later on too, there are many unnecessary leftovers around :) |
| 14:08.50 | kos_tom | gustavoz: target gcc as a package: full ack for me. |
| 14:09.07 | kos_tom | gustavoz: I'm just curious to see how you'll solve the version selection problem. |
| 14:09.23 | gustavoz | kos_tom: as it is right now you can build a target binutils without gcc and works. reasons for that, probably a few, but it works. |
| 14:09.42 | gustavoz | (without a target gcc) |
| 14:10.26 | gustavoz | for the sake of sanity i'll probably inherit the main gcc version |
| 14:11.11 | kos_tom | -BINUTILS_DEPENDENCIES = gmp mpc mpfr |
| 14:11.11 | kos_tom | +BINUTILS_DEPENDENCIES = gmp mpfr |
| 14:11.20 | kos_tom | mpc should still be a dependency if GCC 4.5 is selected, no ? |
| 14:11.30 | *** join/#uclibc risca (~risca@tappan-125-28.eduroam.liu.se) |
| 14:11.45 | kos_tom | gustavoz: the problem is that the "main gcc version" is something that does not exist when you use an external toolchain :-) |
| 14:12.00 | gustavoz | kos_tom: oh right, same applies to binutils now that i think of it :) |
| 14:12.24 | gustavoz | kos_tom: old binutils package? the 4.5.x thing is fixed for the last one. |
| 14:13.15 | gustavoz | kos_tom: i'm also considering reorganizing the toolchain menu somewhat but that requires some deep thought |
| 14:14.06 | gustavoz | kos_tom: the basic idea would be to move all the target dev stuff out of the way, so "target gcc" would be like i handle "target binutils" now in the packages/development menu, we could select versions there |
| 14:14.43 | gustavoz | and the option dev stuff like elf2flt/gdb* be in the package menu too under dev stuff |
| 14:14.48 | gustavoz | *optional |
| 14:16.28 | kos_tom | gustavoz: on overall, those seems to be good ideas. |
| 14:16.52 | kos_tom | but I'd keep the cross-gdb within the toolchain menu, and move all target packages to the Package menu (target gdb, target gdbserver, target toolchain) |
| 14:17.16 | gustavoz | kos_tom: yeah on second thought gdb should be kept around toolchain |
| 14:17.25 | gustavoz | elf2flt probably too |
| 14:17.38 | speakman | sorry, but what's the common length of a "short" git commit revision id? |
| 14:20.17 | gustavoz | kos_tom: from what i've seen i can use mpc in binutils regardless of gcc version, it just doesn't seem appropiate though |
| 14:20.29 | speakman | using the auto target package model; how do I specify which branch to export from remote repo? |
| 14:20.52 | kos_tom | gustavoz: ok. The thing is that : |
| 14:20.54 | kos_tom | @@ -1,6 +1,6 @@ |
| 14:20.54 | kos_tom | <PROTECTED> |
| 14:20.54 | kos_tom | <PROTECTED> |
| 14:20.54 | kos_tom | - select BR2_PACKAGE_MPC |
| 14:20.54 | kos_tom | + select BR2_PACKAGE_MPC if BR2_GCC_VERSION_4_5_X |
| 14:20.54 | speakman | (it seems to not care in Makefile.package.in) |
| 14:20.57 | kos_tom | doesn't seem to match: |
| 14:21.07 | kos_tom | -BINUTILS_DEPENDENCIES = gmp mpc mpfr |
| 14:21.07 | kos_tom | +BINUTILS_DEPENDENCIES = gmp mpfr |
| 14:21.21 | gustavoz | kos_tom: check at the end of binutils.mk |
| 14:21.32 | kos_tom | because when GCC 4.5 is selected, if you enable binutils, then mpc will be selected, but you won't have the guarantee that it is built before binutils |
| 14:21.47 | kos_tom | gustavoz: ah, damn, my bad. |
| 14:22.04 | speakman | sorry, the refspec would superseed the branch name. |
| 14:22.05 | kos_tom | I was looking at the patches, not the files directly, so I got confused. My mistake. |
| 14:22.15 | gustavoz | kos_tom: i added it later on :) |
| 14:23.07 | kos_tom | I don't really like the BINUTILS_CONF_OPT that pass --build/--host/--target since those are already passed by the Makefile.autotools.in infrastructure |
| 14:23.08 | gustavoz | i'm almost certain someone will ask if we'll do the cloog/ppl dance too with this, my likely answer "no, use ct-ng" :) |
| 14:23.29 | gustavoz | kos_tom: it'll break arm eabi if i don't do the --target dance |
| 14:23.49 | gustavoz | host/build can probably be left alone though |
| 14:24.44 | gustavoz | one word sums the breakage up "ldscripts" |
| 14:26.59 | kos_tom | gustavoz: I think gcc should move to package/gcc as well, even for the cross version, and even if the cross version does not use the package infrastructure |
| 14:27.34 | gustavoz | kos_tom: my thinking was along those lines too and just keep the toolchain directory for the glue |
| 14:28.16 | kos_tom | gustavoz: agreed. |
| 14:28.17 | gustavoz | kos_tom: or make a new package/toolchain dir and glue everything up there, that's another option as well |
| 14:29.03 | gustavoz | kos_tom: i'll try to split gcc target first and see how i can use as much as possible of the package infra to keep it "sane" for the cross |
| 14:29.27 | gustavoz | there's really no need to keep the fetch/patch stages by hand for instance |
| 14:33.08 | kos_tom | gustavoz: yes, sure. |
| 14:35.03 | gustavoz | suddenly there's a zoo-like smell coming from outside, wonder who did the bad deed |
| 14:37.05 | gustavoz | zoo isn't far away but i kinda doubt the wind is so precise |
| 14:42.02 | *** join/#uclibc dalias (dalias@216-12-86-13.cv.mvl.ntelos.net) |
| 14:58.50 | ncopa | interesting. seems like uclibc's make install fails with latest gnu tar |
| 14:59.00 | ncopa | but works with bb tar |
| 15:30.08 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 15:38.06 | dalias | haha |
| 15:38.13 | dalias | what does make install use tar for? :) |
| 15:38.43 | ncopa | not sure |
| 15:39.23 | ncopa | i could image something like tar -c lib/* | tar -x -C "$DESTDIR" |
| 15:39.42 | ncopa | so you replace all libs in one go |
| 15:40.03 | ncopa | actually, i dont think make install works when DESTDIR=/ |
| 15:40.42 | ncopa | btw |
| 15:40.56 | ncopa | i have created a bootable alpine linux iso with x86_64 |
| 15:45.00 | dalias | seems like cp -a would work just as well |
| 15:45.33 | ncopa | yeah |
| 15:45.37 | ncopa | i dunno why they tar |
| 16:00.08 | *** join/#uclibc mnt_real (~mnt_real@bas1-montreal43-2925385338.dsl.bell.ca) |
| 16:08.52 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 16:14.39 | *** join/#uclibc BlindMan (~othmar@h081217021188.dyn.cm.kabsi.at) |
| 16:21.01 | *** join/#uclibc tsukasa (~tsukasa@unaffiliated/tsukasa) |
| 16:32.47 | *** join/#uclibc 30BAAH2II (~dvg@HSI-KBW-091-089-103-221.hsi2.kabelbw.de) |
| 17:20.49 | *** join/#uclibc WildPikahcu_ (~nkukard@41-133-248-248.dsl.mweb.co.za) |
| 17:57.43 | *** join/#uclibc elko_ (~not@krlh-5f7227e0.pool.mediaWays.net) |
| 17:58.15 | *** join/#uclibc likewhoa (~likewhoa@ool-18bc83b1.dyn.optonline.net) |
| 18:05.26 | *** join/#uclibc y_morin (~ymorin@ARennes-256-1-75-87.w90-32.abo.wanadoo.fr) |
| 18:27.11 | *** join/#uclibc likewise (~likewise@82-170-243-215.ip.telfort.nl) |
| 19:47.50 | *** join/#uclibc tsukasa (~tsukasa@unaffiliated/tsukasa) |
| 19:52.13 | *** join/#uclibc Whoopie_ (Whoopie@unaffiliated/whoopie) |
| 20:10.33 | *** join/#uclibc trem (~trem@mol92-1-81-57-136-23.fbx.proxad.net) |
| 20:33.40 | *** join/#uclibc antgreen` (~user@CPE00222d6c4710-CM00222d6c470d.cpe.net.cable.rogers.com) |
| 20:56.57 | *** join/#uclibc WildPikachu (~nkukard@about/linux/staff/wildpikachu) |
| 21:15.29 | *** join/#uclibc PortaLu (~LucretiaL@5ac2a2b2.bb.sky.com) |
| 22:15.46 | *** join/#uclibc likewise (~likewise@82-170-243-215.ip.telfort.nl) |
| 22:57.49 | y_morin | Jacmet: Hello! Around? |
| 23:02.57 | *** join/#uclibc luneff (~yury@84.51.198.114) |
| 23:47.40 | *** join/#uclibc mikecompile (~mikecompi@c-71-206-170-188.hsd1.va.comcast.net) |
| 23:49.59 | mikecompile | I'm trying to load firmware to a usb device in busybox, but I can't create the loading and data files because I don't have permission |
| 23:50.39 | mikecompile | is there something I'm missing? |