| 00:41.35 | *** join/#oe dijenerate (~dijenerat@199.47.52.87) |
| 00:45.34 | *** join/#oe andyross (~andy@c-67-171-188-207.hsd1.or.comcast.net) |
| 01:17.13 | *** join/#oe KNERD (~KNERD@24.175.249.177) |
| 01:35.44 | *** join/#oe msm (~msm@cpe-70-112-201-132.austin.res.rr.com) |
| 01:45.51 | *** join/#oe _Lucretia__ (~munkee@94.12.255.152) |
| 02:24.07 | *** join/#oe silviof1 (~silviof@ppp-188-174-120-32.dynamic.mnet-online.de) |
| 02:39.11 | *** join/#oe jkridner (~jason@pdpc/supporter/active/jkridner) |
| 02:52.26 | *** join/#oe liuyq (~liuyq0307@221.123.128.227) |
| 04:35.14 | *** join/#oe abesis (~abesis@82.222.89.188) |
| 05:34.56 | *** join/#oe tasslehoff (~tasslehof@147.84-49-231.nextgentel.com) |
| 05:37.38 | *** join/#oe abesis (~abesis@78.187.167.191) |
| 05:41.44 | *** join/#oe zecke (~ich@91-65-247-145-dynip.superkabel.de) |
| 05:47.14 | *** join/#oe KNERD (~KNERD@24.175.249.177) |
| 05:48.02 | *** join/#oe Noor1 (~noor@110.93.212.98) |
| 06:24.54 | *** join/#oe Vutral (ss@mirbsd/special/Vutral) |
| 06:30.18 | *** join/#oe Zagor (~bjst@sestofw01.enea.se) |
| 06:30.18 | *** join/#oe Zagor (~bjst@rockbox/developer/Zagor) |
| 06:37.43 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:38.43 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 06:47.36 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 07:06.13 | mckoan | good morning |
| 07:07.52 | *** join/#oe pvanhoof (~philip@codeminded.be) |
| 07:09.22 | *** join/#oe ascor (~ascorL@191.202.6.109.rev.sfr.net) |
| 07:11.06 | silvio__ | morning all |
| 07:12.13 | mckoan | silvio__: hi |
| 07:13.12 | likewise | morning |
| 07:17.44 | silvio__ | mckoan, hi |
| 07:20.16 | *** join/#oe like2wise (~likewise@203-158-ftth.on.nl) |
| 07:27.40 | *** join/#oe TheBootroo (~TheBootro@191.202.6.109.rev.sfr.net) |
| 07:29.42 | *** join/#oe stefan_schmidt_w (~stefan_sc@62.6.189.26) |
| 07:31.01 | *** join/#oe shoragan (~jlu@debian/developer/shoragan) |
| 07:34.43 | *** join/#oe pigeon (~pigeon@eth5284.nsw.adsl.internode.on.net) |
| 07:37.59 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 07:45.12 | apelete | good morning |
| 07:53.30 | mckoan | gm apelete, likewise, all |
| 07:54.33 | *** join/#oe dlan^ (~dennis@116.228.88.131) |
| 08:01.29 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 08:01.29 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:11.24 | silvio__ | hi apelete |
| 08:12.15 | bluelightning | morning apelete, silvio__, all |
| 08:14.21 | apelete | hi mckoan, silvio__, bluelightning |
| 08:15.10 | *** join/#oe jackmitchell (~Thunderbi@195.171.99.130) |
| 08:17.21 | silvio__ | hi bluelightning , hi all :P |
| 08:17.27 | silvio__ | hi bluelightning , hi all :) |
| 08:20.43 | *** join/#oe florian_kc (~fuchs@port-217-146-132-69.static.qsc.de) |
| 08:20.44 | *** join/#oe florian_kc (~fuchs@Maemo/community/contributor/florian) |
| 08:21.00 | silvio__ | I broken something in my building machine, when I build a SDK, not only my, the gcc executable for i686 are not deployed inside, some suggest? |
| 08:25.15 | *** join/#oe jackmitchell (~Thunderbi@195.171.99.130) |
| 08:30.03 | mckoan | silvio__: in that case I delete the whole tmp :-( |
| 08:30.39 | bluelightning | I doubt that will help |
| 08:33.42 | silvio__ | mckoan, do you mean tmp-eglibc? |
| 08:35.19 | silvio__ | mckoan, or also out-eglibc and tmp-eglibc |
| 08:41.28 | mckoan | silvio__: I have had random build problems in the past and was caused by file corruption in tmp-eglibc, a total rebuild solved (to me) |
| 08:42.02 | mckoan | of course that wasn't an OE problem |
| 08:47.47 | apelete | speaking of tmp-eglibc, how is the name of that directory chosen ? |
| 08:47.51 | apelete | my tmp directory is named "tmp-eglibc-eglibc" and I wonder if that's normal |
| 08:48.01 | apelete | http://paste.debian.net/248197/ |
| 08:49.23 | *** join/#oe panda84kde (~diego@static-217-133-170-65.clienti.tiscali.it) |
| 08:49.38 | bluelightning | apelete: what is your DISTRO value? |
| 08:49.48 | bluelightning | apelete: usually this indicates defaultsetup.conf is being parsed twice |
| 08:50.07 | silvio__ | my is quite different, I had following folders: |
| 08:50.26 | silvio__ | downloads out-eglibc sstate-cache tmp-eglibc |
| 08:51.22 | *** join/#oe KNERD (~KNERD@24.175.249.177) |
| 08:51.54 | apelete | bluelightning: according to bitbake output my DISTRO is "jlime-2010.1" (the same value as in local.conf) |
| 08:52.43 | bluelightning | apelete: ok... what does bitbake -e | less indicate for TMPDIR? it should show how it is getting set |
| 08:56.05 | silvio__ | bluelightning, for my TMPDIR="/home/oe-core/build/out-eglibc" |
| 08:56.52 | silvio__ | so I immagine that I have to delete not only tmp-eglibc, but also out-eglibc, I m right? |
| 08:57.20 | silvio__ | or is useless? Because I prefer don t remove all builded :( |
| 08:58.20 | *** join/#oe CMoH|notebook (~cipi@unaffiliated/c-moh) |
| 09:00.01 | *** join/#oe VtS_ (~quassel@188-22-213-2.adsl.highway.telekom.at) |
| 09:00.05 | apelete | bluelightning: ha, defaultsetup.conf is being parsed twice indeed, you're right: http://paste.debian.net/248200/ |
| 09:00.46 | *** join/#oe lamikr (lamikr@nat/nokia/x-nhnhutnubpbnzble) |
| 09:01.34 | apelete | I copied the file in my conf/distro dir AND included in my distro file too |
| 09:02.10 | apelete | it's only monday and I'm feeling ashamed already... |
| 09:24.55 | *** join/#oe JaMa (~martin@ip-62-24-80-7.net.upcbroadband.cz) |
| 09:42.10 | apelete | bluelightning: seems it wasn't me after all, defaultsetup.conf is included from bitbake.conf from oe-core |
| 09:43.27 | apelete | I guess I'll remove "require conf/distro/defaultsetup.conf" from my distro conf file then |
| 09:45.01 | bluelightning | apelete: so it is... I did not realise that :/ |
| 09:45.08 | bluelightning | sorry if I led you astray |
| 09:46.03 | apelete | no problem, you pointed me on the right track nonetheless |
| 09:49.34 | bluelightning | I've just fixed the migration guide |
| 09:51.27 | *** join/#oe ant_work (~ant@host6-80-static.42-85-b.business.telecomitalia.it) |
| 09:57.58 | *** join/#oe CMoH (~cipi@78.96.83.205) |
| 09:57.59 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 10:00.53 | *** join/#oe cbrake (~cbrake@oh-69-34-21-229.sta.embarqhsd.net) |
| 10:01.56 | *** join/#oe diego_kynetics (~diego@static-217-133-170-65.clienti.tiscali.it) |
| 10:05.42 | apelete | great |
| 10:06.31 | *** join/#oe tasslehoff (~tasslehof@147.84-49-231.nextgentel.com) |
| 10:07.36 | apelete | bluelightning: if I set 'DEFAULTTUNE_ben-nanonote = "mips32el-nf"' instead of 'DEFAULTTUNE = "mips32el-nf"', the setting is not taken into account |
| 10:07.48 | apelete | what am I missing ? |
| 10:08.11 | bluelightning | apelete: what does bitbake -e | less report for DEFAULTTUNE? |
| 10:08.14 | *** join/#oe TheBootroo (~TheBootro@191.202.6.109.rev.sfr.net) |
| 10:08.38 | bluelightning | (in the first instance) |
| 10:11.04 | *** join/#oe Crofton|work (~balister@pool-96-240-175-73.ronkva.east.verizon.net) |
| 10:17.16 | dv_ | apelete: dont trust the regular bitbake output when you run it. I had the same problem. bitbake -e should show that you are using mips32el-nf |
| 10:18.02 | dv_ | I hope this is fixed in daryl... |
| 10:18.08 | bluelightning | dv_: you mean the "build configuration" output at the start of the build? |
| 10:18.14 | dv_ | yeah |
| 10:18.35 | bluelightning | I'm not sure if anyone filed a bug for that one or whether it got fixed |
| 10:18.41 | apelete | bluelightning: here it is |
| 10:18.43 | apelete | $ bitbake -e | grep DEFAULTTUNE |
| 10:18.43 | apelete | # $DEFAULTTUNE [5 operations] |
| 10:18.43 | apelete | DEFAULTTUNE="mips32el-nf" |
| 10:18.52 | dv_ | there you go, it is being used |
| 10:19.38 | apelete | yeah, but build ocnfiguration output is showing wrong info like you said dv_ : |
| 10:19.38 | apelete | TUNE_FEATURES = "o32 bigendian fpu-hard mips32" |
| 10:19.38 | apelete | TARGET_FPU = "" |
| 10:19.52 | dv_ | I had the same problem, as said. I set DEFAULTTUNE_<machine> to a hardfp setting in local.conf , and it didnt show "callconvention-hard" in the build config |
| 10:20.18 | bluelightning | right; and as apelete is using master (correct?) we still have the bug :/ |
| 10:20.25 | dv_ | but checking with bitbake -e , and looking at the arguments used for gcc by running ps ax showed me that hardfp was indeed being used |
| 10:20.43 | apelete | bluelightning: yes, using bitbake's master branch |
| 10:20.57 | bluelightning | apelete: what about oe-core? |
| 10:21.01 | dv_ | bluelightning: I was pointed to a patch in the mailing list, but it didnt help |
| 10:21.12 | apelete | bluelightning: master branch of oe-core too |
| 10:21.16 | bluelightning | ok |
| 10:21.32 | bluelightning | dv_: could you please file a bug at bugzilla.yoctoproject.org? |
| 10:21.38 | dv_ | http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/30164 <- this one |
| 10:22.17 | dv_ | gotta go now, but will do as soon as I am able to |
| 10:22.24 | apelete | thanks for helping dv_ |
| 10:23.38 | bluelightning | thanks |
| 10:38.38 | *** join/#oe sr105` (~sr105@65349hfc19.tampabay.res.rr.com) |
| 10:40.12 | *** join/#oe _chase_ (~a0271661@192.94.92.11) |
| 10:40.53 | *** join/#oe likewise (~likewise@203-158-ftth.on.nl) |
| 10:50.59 | ensc|w | hates anonymous python functions in global .bbclass'es; especially these which do d.getVar(..., True)... devshell bbclass creates now an huge unreadable stacktrace when a SRC_REV=${AUTOREV} can not be determined |
| 10:52.45 | bluelightning | we could of course fix the error handling so a backtrace doesn't occur |
| 10:54.37 | ensc|w | it is still conceptually broken; why does devshell need to expand ${SRC_REV} in the recipe parsing phase? |
| 10:57.28 | *** join/#oe blitz00 (~stefans@192.198.151.44) |
| 10:57.29 | *** join/#oe blitz00 (~stefans@unaffiliated/blitz00) |
| 11:05.50 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 11:10.39 | bluelightning | ensc|w: probably because it needs to determine PV ? |
| 11:10.52 | bluelightning | without PV you can't have WORKDIR |
| 11:17.53 | ensc|w | bluelightning: I know this; that's why I hate anonymous python functions in global .bbclass'es; especially these which do d.getVar(..., True). For PV this might be not a direct problem because this variable it expanded at other places too. But such functions introduce silent problems |
| 11:18.39 | bluelightning | ensc|w: what alternative would you suggest? |
| 11:25.09 | ensc|w | avoid such anonymous functions or use d.getVar(..., False). For the devshell.bbclass case, I am not sure what to do because all the related code is very dirty and it is not obvious to me when/whether global variables (e.g. os.environ in terminal.bbclass) are set/reset |
| 11:29.35 | *** join/#oe nslu2-log_ (~nslu2-log@140.211.169.184) |
| 11:31.00 | *** join/#oe eren (~eren@unaffiliated/eren) |
| 11:32.04 | *** join/#oe jackmitchell (~Thunderbi@195.171.99.130) |
| 11:43.53 | hrw | hello |
| 11:44.13 | hrw | JaMa: can you take a look at my libvpx and tbb patches? |
| 11:44.33 | *** join/#oe phdeswer (~phdeswer@194.157.27.2) |
| 11:55.28 | hrw | hm. external-toolchain-linaro, GCCVERSION = "linaro-4.7" and it tries to build random gcc with 'bitbake gcc' |
| 11:59.25 | *** join/#oe Tartarus (~trini@pixelshelf.com) |
| 11:59.26 | JaMa | hrw: yes, when I find some time |
| 11:59.33 | hrw | thanks |
| 11:59.37 | *** join/#oe nslu2-log_ (~nslu2-log@140.211.169.184) |
| 12:00.34 | JaMa | hrw: btw libunwind_1.1.bb is still failing to build on qemuarm as reported before, not sure why it slipped through my prepush check and I've applied it |
| 12:01.02 | hrw | JaMa: was working here ;( |
| 12:04.01 | hrw | ok sorted out gcc - layers priorities matter |
| 12:04.55 | *** join/#oe jackmitchell (~Thunderbi@195.171.99.130) |
| 12:04.55 | *** join/#oe eren (~eren@unaffiliated/eren) |
| 12:09.37 | *** join/#oe joeythesaint (~jjm@128.224.252.2) |
| 12:11.23 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 12:14.37 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 12:20.30 | silvio__ | hello hrw |
| 12:25.03 | hrw | hi silvio__ |
| 12:35.38 | *** join/#oe mhnoyes (~mhnoyes@sourceforge/sitedocs/mhnoyes) |
| 12:42.59 | *** join/#oe joeythesaint (~jjm@128.224.252.2) |
| 12:47.07 | *** join/#oe lamikr (lamikr@nat/nokia/x-ugejhsbkudmlqcit) |
| 12:49.11 | *** join/#oe denisATeukrea (~GNUtoo@host56-161-dynamic.1-79-r.retail.telecomitalia.it) |
| 12:51.36 | *** join/#oe _Lucretia_ (~munkee@176.253.92.37) |
| 12:51.36 | *** join/#oe _Lucretia_ (~munkee@pdpc/supporter/active/lucretia) |
| 12:54.59 | *** join/#oe dos11 (~dos@unaffiliated/dos1) |
| 13:13.06 | *** join/#oe rsalveti (~rsalveti@201.82.227.188) |
| 13:13.06 | *** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti) |
| 13:18.20 | silvio__ | I broken something in my building machine, when I build a SDK, not only my, the gcc executable for i686 are not deployed inside, some suggest? |
| 13:18.38 | silvio__ | could related to this?: |
| 13:18.46 | silvio__ | ERROR: Nothing PROVIDES 'virtual/i686-angstromsdk-linux-gcc' (but /home/oe-core/build/../stuff/meta-btw/recipes-devtools/tasks/task-test-toolchain-host.bb DEPENDS on or otherwise requires it) |
| 13:30.32 | *** join/#oe jackmitchell (~Thunderbi@195.171.99.130) |
| 13:32.02 | *** join/#oe rsalveti (~rsalveti@201.82.227.188) |
| 13:32.03 | *** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti) |
| 13:49.42 | apelete | bluelightning: removing defaultsetup.conf from the distro conf file introduced an eglibc build error |
| 13:49.47 | apelete | http://paste.debian.net/248236/ |
| 13:50.28 | bluelightning | apelete: looks a lot like your DISTRO_FEATURES is empty or at least has no libc-* features in it |
| 13:50.35 | *** join/#oe sr105 (~sr105@65349hfc19.tampabay.res.rr.com) |
| 13:55.46 | apelete | bluelightning: that's strange, how can it be empty since there is a "include conf/distro/defaultsetup.conf" in bitbake.conf ? |
| 13:56.08 | bluelightning | apelete: use bitbake -e | less to find out what has happened to DISTRO_FEATURES |
| 13:56.56 | apelete | bluelightning: okay, thanks. (gotta be used to bitbake -e) |
| 13:57.23 | bluelightning | apelete: the tracing of operations is brand new (and very useful in these kinds of situations) |
| 13:57.47 | bluelightning | hence why I suggest piping through less rather than grep since grep will filter out that info |
| 13:57.55 | *** join/#oe likewise_ (~likewise@203-158-ftth.on.nl) |
| 14:04.33 | *** join/#oe gcoville (~gcoville@jupiter.domainmasters.com) |
| 14:04.55 | *** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 14:09.52 | *** join/#oe jkridner|work (~jkridner@pdpc/supporter/active/jkridner) |
| 14:15.28 | apelete | bluelightning: adding DISTRO_FEATURES += "${DISTRO_FEATURES_LIBC_DEFAULT}" in distro conf seems to fix it (still building, but got past eglibc already) |
| 14:17.02 | bluelightning | apelete: presumably you're setting DISTRO_FEATURES with = ? |
| 14:17.13 | hrw | | checking for arm-oe-linux-gnueabi-gcc... arm-linux-gnueabihf-gcc -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon --sysroot=/home/hrw/HDD/devel/canonical/aarch64/openembedded/build/tmp-eglibc/sysroots/genericarmv7a -march=armv7-a -marm -mthumb-interwork -mfloat-abi=hard -mfpu=neon -isystem/home/hrw/HDD/devel/canonical/aarch64/openembedded/build/tmp-eglibc/sysroots/genericarmv7a/usr/include --sysroot=/home/hrw/HDD/devel/canonical/aarch64/openembedded/bu |
| 14:17.16 | bluelightning | (which is fine) |
| 14:17.20 | hrw | fun |
| 14:19.07 | apelete | bluelightning: using += since I let defautsetup.conf manage the DISTRO_FEATURES setting |
| 14:19.29 | apelete | but I'll read the bitbake -e output more closely to undesrtand why the setting was squashed |
| 14:20.19 | bluelightning | hmm |
| 14:23.11 | *** join/#oe pepermint (~pepermint@host20-4-dynamic.13-87-r.retail.telecomitalia.it) |
| 14:24.59 | dv_ | bluelightning: the aforementioned bug with the build config belongs to OE core or to bitbake |
| 14:25.00 | dv_ | ? |
| 14:27.35 | apelete | bluelightning: built the kernel successfully by adding DISTRO_FEATURES += "${DISTRO_FEATURES_LIBC_DEFAULT}" (instead of require'ing defaultsetup.conf). time to go back to the bitbake -e output and see what differs |
| 14:27.41 | bluelightning | dv_: I think OE-Core since that's where that info is gathered |
| 14:43.13 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 14:50.01 | *** join/#oe rsalveti (~rsalveti@201.82.227.188) |
| 14:50.02 | *** join/#oe rsalveti (~rsalveti@unaffiliated/rsalveti) |
| 14:51.16 | hrw | <PROTECTED> |
| 14:53.25 | dv_ | a little bit, yes :) |
| 14:56.21 | apelete | bluelightning: got it, the culprit is bitbake.conf. it is setting DISTRO_FEATURES ?= "" at line 723 |
| 14:56.24 | apelete | http://paste.debian.net/248255/ |
| 14:56.40 | apelete | (I love bitbake -e already, powerful feature) |
| 14:57.04 | dv_ | yeah |
| 14:57.26 | dv_ | but when you start digging into OE, or writing complex recipes, you start wishing for a cluster as the build machine :) |
| 14:57.34 | bluelightning | apelete: ok... I guess it expects the distro config to set an appropriate value in that case |
| 14:57.48 | bluelightning | brb |
| 15:00.06 | *** join/#oe bluelightning_ (~paul@83.217.123.106) |
| 15:00.07 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 15:00.22 | afournier | i am baking a library that is hosted on github, but using the tarball from the website. once unpacked the name of the directory is something like "username-Project-dXXXX" how can i specify S so it does not care of the XXXX ? |
| 15:00.50 | apelete | dv_: I built an 8-core cpu machine with 16GB of ram because I was digging into OE |
| 15:01.02 | bluelightning | afournier: hmm... you could mv it at the end of do_unpack perhaps... |
| 15:01.22 | afournier | bluelightning: you always have good ideas ! |
| 15:01.28 | apelete | dv_: a cluster may be my next build machine ;) |
| 15:02.36 | dv_ | apelete: look at what this guy uses: http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg21702.html |
| 15:05.14 | apelete | dv_: wow. well, I am not digging into OE that hard yet :) |
| 15:05.56 | bluelightning | you don't need a huge machine to get reasonable build times: http://www.burtonini.com/wordpress/2012/11/15/yocto-build-times/ |
| 15:06.40 | *** join/#oe hollisb (~hollisb@nat-wv.mentorg.com) |
| 15:09.58 | apelete | that's the kind of build times I get on my 8-core AMD cpu with 16GB of ram (using a 256GB ssd instead of hdd though) |
| 15:11.11 | apelete | seems reasonable to me since the machine was not that expensive (bought the parts last january and assembled it myself) |
| 15:12.48 | apelete | wish I had an intel cpu though, but they were too expensive compared to amd counterparts |
| 15:14.22 | *** join/#oe KNERD (~KNERD@24.175.249.177) |
| 15:17.14 | *** join/#oe vpopov (~happylife@dyn-32-176.fttbee.kis.ru) |
| 15:17.42 | *** join/#oe zenlinux_ (~sgarman@c-50-137-42-92.hsd1.or.comcast.net) |
| 15:17.43 | dv_ | stick lots of ram in your machine, and you are pretty well off already I guess |
| 15:18.18 | dv_ | (because then you have a huge disk cache) |
| 15:20.12 | apelete | yeah, and I'm also using a webcache proxy to cache downloaded archives locally (on a 2TB hdd. ssd is for devel purpose only) |
| 15:23.20 | apelete | caching doesn't work for content downloaded from git/svn/scm, but it's better than nothing (I hate it when a download server is offline when I need it) |
| 15:24.19 | bluelightning | we do produce tarballs from scm fetches... won't help if you don't specify a full fixed revision for SRCREV though |
| 15:25.36 | dv_ | I have a "yocto-downloads" directory. it is holy and those who delete stuff from it get hunted down by a squad of men in black. :) |
| 15:25.58 | apelete | bluelightning: you mean there are tarballs of scm fetches available on oe mirrors ? |
| 15:26.40 | bluelightning | apelete: I think we do provide those for releases yes |
| 15:26.56 | bluelightning | apelete: but not necessarily for latest master at a given time |
| 15:27.20 | bluelightning | on the yoctoproject.org mirrors that is |
| 15:28.59 | apelete | bluelightning: that means bitbake will fetch from the tarballs instead of the scm if I give it the exact SRCREV in a recipe ? |
| 15:32.55 | apelete | while working on oe-classic I found out that having a dl server going offline is a huge pain in the back, that's why I setup a webcache proxy locally (and I configured it to keep files on the disk for months) |
| 15:35.29 | bluelightning | apelete: ah now I see what you mean by webcache |
| 15:36.04 | bluelightning | apelete: you can set up a local mirror with PREMIRRORS (even easier setup via own-mirrors.bbclass) |
| 15:37.32 | apelete | bluelightning: good to know, wasn't aware of that so I chose to set up squid on my build machine |
| 15:38.08 | apelete | every single download goes through squid, and if the file has been download before, it is served from the hdd |
| 15:38.59 | apelete | except for files hosted on a scm of course |
| 15:39.27 | apelete | s/download/downloaded/ |
| 15:40.28 | *** join/#oe zecke (~ich@91-65-247-145-dynip.superkabel.de) |
| 15:41.46 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 15:44.53 | ensc|w | is it expected that do_package_setscene() is executed for every package everytime when an image is built? do_fetch + do_write_srcrev + do_build + do_rm_work is called for every package in RunQueue then |
| 15:46.53 | bluelightning | ensc|w: it's a known interaction problem between buildhistory and rm_work in latest master |
| 15:47.13 | ensc|w | ok, thx |
| 15:47.57 | bluelightning | ensc|w: FYI: http://lists.linuxtogo.org/pipermail/openembedded-core/2013-April/037881.html |
| 15:48.17 | bluelightning | I should have a go at doing the postfunc change tonight actually |
| 15:49.23 | dv_ | btw how do you call something like VAR[index] ? |
| 15:49.29 | dv_ | what is this? a dictionary? |
| 15:49.34 | bluelightning | dv_: that's a varflag |
| 15:49.41 | dv_ | ah |
| 15:50.10 | dv_ | do the pre/postfunc varflags exist on OE-classic? |
| 15:50.21 | dv_ | I have this one recipe that still uses populate_package_prepend |
| 15:50.25 | bluelightning | I'm not sure, but I suspect not |
| 15:50.36 | bluelightning | dv_: that should still be valid... |
| 15:50.47 | dv_ | I'd like to replace that with a prefunc. but this recipe is supposed to run with OE-classic as well (specifically OE-classic with arago) |
| 15:51.10 | bluelightning | dv_: that won't be possible because of the tabs/spaces change if nothing else |
| 15:51.17 | dv_ | it would solve the issue with the indentations, yocto uses 4 spaces, arago uses tabs |
| 15:51.18 | bluelightning | you'll need to have two different versions |
| 15:51.32 | dv_ | but prefuncs are their own functions, they are not simply appended |
| 15:51.43 | bluelightning | indeed |
| 15:51.54 | dv_ | which is why I would like to use them. then I need only one version. |
| 15:52.10 | dv_ | there would be no mixup of spaces and tabs |
| 15:52.16 | bluelightning | well, I can only say good luck with that - there are other differences |
| 15:52.24 | dv_ | :/ oh well. |
| 15:52.31 | bluelightning | it may well work but I'm not sure that it will |
| 15:52.33 | kergoth | it's awy more trouble than its worth. branch and be happy |
| 15:52.37 | dv_ | currently I do have two different populate_package_prepend versions |
| 15:52.54 | dv_ | I'll stick to that then, as ugly as it may be |
| 16:05.09 | ensc|w | mmh... busybox mount does not work with systemd :( the 'mount -o remount /' does not make it rw as expected |
| 16:06.51 | kergoth | try an explicit rw, perhaps? mount -o remount,rw /? |
| 16:06.52 | kergoth | shrug |
| 16:08.05 | *** join/#oe mr_science (~sarnold@net-cf9a4e91.cst.impulse.net) |
| 16:08.06 | *** join/#oe mr_science (~sarnold@gentoo/developer/nerdboy) |
| 16:08.07 | ensc|w | kergoth: systemd's systemd-remount-fs.service calls only 'mount -o remount' |
| 16:08.15 | *** join/#oe bluelightning_ (~paul@83.217.123.106) |
| 16:08.15 | *** join/#oe bluelightning_ (~paul@pdpc/supporter/professional/bluelightning) |
| 16:08.28 | mr_science | moin |
| 16:08.47 | ensc|w | kergoth: accordingly man-pages, this is the correct thing and mount -o remount should takes options from /etc/fstab |
| 16:12.15 | bluelightning | ensc|w: is it a case that we're currently disabling a busybox option that we need to enable? |
| 16:14.10 | *** join/#oe JaMa (~martin@ip-62-24-80-7.net.upcbroadband.cz) |
| 16:16.07 | ensc|w | bluelightning: I do not think so; I enabled all mount related options except mtab and see this behavior |
| 16:17.33 | bluelightning | hmm, kind of sounds like a busybox bug then |
| 16:24.11 | *** join/#oe g1zer0 (~g1zer0@host32-76-dynamic.244-95-r.retail.telecomitalia.it) |
| 16:25.38 | *** join/#oe gizero (~g1zer0@host32-76-dynamic.244-95-r.retail.telecomitalia.it) |
| 16:31.40 | *** join/#oe ftonello (~felipe@wsip-70-183-20-162.oc.oc.cox.net) |
| 16:33.10 | *** join/#oe pvanhoof (~philip@codeminded.be) |
| 16:38.24 | hrw | does openembedded-core/scripts/sstate-cache-management.sh works for someone? |
| 16:40.31 | hrw | I have 61404 files in sstate-cache (62GB) |
| 16:41.15 | hrw | ok know why |
| 16:41.36 | *** join/#oe _Lucretia_ (~munkee@pdpc/supporter/active/lucretia) |
| 16:41.42 | hrw | wrong cache dir... |
| 16:42.20 | *** join/#oe woglinde (~henning@g225144034.adsl.alicedsl.de) |
| 17:03.48 | *** join/#oe abesis (~abesis@82.222.89.188) |
| 17:05.30 | *** join/#oe ohama (ohama@cicolina.org) |
| 17:06.26 | *** join/#oe Tartarus (trini@pixelshelf.com) |
| 17:17.21 | *** join/#oe _Lucretia_ (~munkee@pdpc/supporter/active/lucretia) |
| 17:17.54 | apelete | bluelightning: built the kernel successfully with the right distro_features setting, at last. (thanks for your help btw) |
| 17:18.07 | bluelightning | apelete: np |
| 17:18.40 | apelete | but I'm still getting a weird error messages at the end of the build: |
| 17:18.40 | apelete | ERROR: Creation of tar /fast/devel/oe-core.git/meta-jlime/build/tmp-eglibc/deploy/tar/kernel-vmlinux-2.6.36-r0.tar.gz failed. |
| 17:18.40 | apelete | ERROR: Creation of tar /fast/devel/oe-core.git/meta-jlime/build/tmp-eglibc/deploy/tar/kernel-dev-2.6.36-r0.tar.gz failed. |
| 17:19.35 | bluelightning | apelete: are you inheriting package_tar somewhere? |
| 17:19.52 | apelete | bluelightning: yes, in my distro conf |
| 17:20.04 | bluelightning | ah right, I suspect that may be broken |
| 17:20.07 | apelete | I have PACKAGE_CLASSES += "package_tar" |
| 17:20.15 | bluelightning | do you use that? |
| 17:20.39 | apelete | the tar file ? ye. |
| 17:20.50 | apelete | s/ye./yes./ |
| 17:21.03 | bluelightning | ah ok, what for just out of curiosity? |
| 17:21.41 | apelete | it easier to upload the images to the jlime community that way |
| 17:21.48 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 17:22.04 | apelete | I could tar it by hand I guess... |
| 17:22.13 | bluelightning | apelete: hang on, tarballs of the image and packages are separate things... |
| 17:22.36 | bluelightning | package_tar is about creating a tarball for individual packages |
| 17:22.55 | apelete | ah, that's not what I want then |
| 17:23.03 | apelete | I want tarballs for my images |
| 17:23.21 | bluelightning | ah right, in that case just ensure tar.gz (or tar.bz2, or just tar, etc.) is in IMAGE_FSTYPES |
| 17:23.49 | apelete | okay, I already got that: IMAGE_FSTYPES = "tar.gz tar.bz2 jffs2" |
| 17:24.09 | bluelightning | ok, so you should be set, and you can remove the package_tar line that's causing errors |
| 17:24.18 | apelete | so I guess I won't be needing the PACKAGE_CLASSES += "package_tar" setting |
| 17:24.22 | bluelightning | right |
| 17:24.27 | apelete | thanks. |
| 17:24.33 | bluelightning | (although to be fair it shouldn't error out like that) |
| 17:27.21 | apelete | it errors but the packages are created nonetheless: http://paste.debian.net/248301/ |
| 17:27.49 | bluelightning | hmm, odd |
| 17:29.04 | apelete | anyway, I won't be needing them. I only want tarball of my final image and I still have work to do before getting there |
| 17:29.15 | apelete | thanks for helping :) |
| 17:30.05 | bluelightning | apelete: you're welcome :) |
| 17:31.15 | bluelightning | apelete: just looking at your patch... would you mind adding a header to the included kernel patch mentioning what it does, Upstream-Status and adding your signed-off-by? |
| 17:35.48 | apelete | bluelightning: hmm, the changes I did in that patch are already in the mainline kernel. I just looked at the kernel changesets and applied the same fixes. |
| 17:36.12 | bluelightning | apelete: ah ok, it would be Upstream-Status: Backport in that case |
| 17:36.22 | bluelightning | which is really useful to know when you're updating the kernel recipe :) |
| 17:36.37 | apelete | bluelightning: ok, I'll add it then |
| 17:36.41 | bluelightning | thanks |
| 17:37.19 | apelete | bluelightning: is there an exemple of such an header in OE I can look at to get it right ? |
| 17:37.29 | bluelightning | one sec |
| 17:37.32 | apelete | s/exemple/example/ |
| 17:39.05 | bluelightning | apelete: http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-core/dropbear/dropbear/nopw-option.patch |
| 17:39.32 | bluelightning | so not too much info needed really |
| 17:40.19 | apelete | bluelightning: great, thanks. I'll do a patch v3 as soon as I can (maybe tonight) |
| 17:40.41 | apelete | gotta go, see you later. |
| 17:40.46 | bluelightning | apelete: thanks, cya |
| 17:42.20 | *** join/#oe abesis (~abesis@82.222.89.188) |
| 17:44.10 | *** join/#oe zenlinux (~sgarman@c-76-105-137-48.hsd1.or.comcast.net) |
| 17:45.41 | *** join/#oe abesis2 (~abesis@82.222.89.188) |
| 17:50.16 | *** join/#oe phdeswer (~phdeswer@194.157.27.2) |
| 17:55.48 | *** join/#oe ChrisD1_Away (~ChrisD@merak.alcor.co.uk) |
| 17:58.04 | *** join/#oe ensc_ (~irc-ensc@p4FFCFE25.dip.t-dialin.net) |
| 18:01.50 | *** join/#oe kristoffer (~kristoffe@c-f9dfe555.010-30-6c6b7012.cust.bredbandsbolaget.se) |
| 18:18.12 | *** join/#oe eren (~eren@unaffiliated/eren) |
| 18:27.06 | *** join/#oe flo_lap (~fuchs@sign-4d094126.pool.mediaWays.net) |
| 18:27.07 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 18:35.37 | *** join/#oe abesis (~abesis@188.57.238.41) |
| 18:50.10 | *** join/#oe KNERD (~KNERD@24.175.249.177) |
| 19:01.05 | *** join/#oe pvanhoof (~philip@codeminded.be) |
| 19:09.50 | *** join/#oe abesis (~abesis@176.42.251.157) |
| 19:20.32 | *** join/#oe pepermint (~pepermint@host20-4-dynamic.13-87-r.retail.telecomitalia.it) |
| 19:42.31 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:53.36 | *** join/#oe phdeswer (~phdeswer@a88-113-104-180.elisa-laajakaista.fi) |
| 19:53.56 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 19:59.05 | *** join/#oe _Lucretia_ (~munkee@pdpc/supporter/active/lucretia) |
| 20:14.58 | *** join/#oe jkroon_ (~jkroon@89-253-118-72.customers.ownit.se) |
| 20:20.42 | JaMa | woglinde: I think I know why you're seeing so many do_package_setscene executions with rm_work, http://lists.linuxtogo.org/pipermail/openembedded-core/2013-February/035382.html |
| 20:20.50 | JaMa | No enf |
| 20:20.51 | JaMa | of chain tasks depend directly on do_package anymore.". |
| 20:21.10 | JaMa | probably we have too many task still depending on them |
| 20:22.05 | *** join/#oe hollisb (~hollisb@nat-wv.mentorg.com) |
| 20:23.14 | woglinde | hm |
| 20:30.01 | *** join/#oe vpopov (~happylife@dyn-32-176.fttbee.kis.ru) |
| 20:57.04 | *** join/#oe rcf (~rcf@d51A58861.access.telenet.be) |
| 20:58.57 | *** join/#oe balister_ (~balister@pool-96-240-163-56.ronkva.east.verizon.net) |
| 20:59.02 | *** join/#oe Crofton|work (~balister@pool-96-240-163-56.ronkva.east.verizon.net) |
| 21:11.05 | *** join/#oe bluelightning (~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com) |
| 21:11.06 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 21:18.33 | *** join/#oe pepermint (~pepermint@host20-4-dynamic.13-87-r.retail.telecomitalia.it) |
| 21:27.18 | *** join/#oe ant_home (~andrea@host14-255-dynamic.14-87-r.retail.telecomitalia.it) |
| 21:34.43 | *** join/#oe zenlinux (~sgarman@c-76-105-137-48.hsd1.or.comcast.net) |
| 21:37.43 | *** join/#oe pib1956 (~pib1956@your.friendly.media.team.coder.ark-cr.info) |
| 22:24.06 | *** join/#oe KNERD (~KNERD@24.175.249.177) |
| 22:27.13 | *** join/#oe spacecolonyone (~spacecolo@dhcp239.obs.carnegiescience.edu) |
| 22:31.03 | spacecolonyone | So I've got my own bbappend for a kernel, and in it I do MACHINE_KERNEL_PR_append="foo". I build and deploy my angstrom image all works, but opkg list-upgradable reports my kernel as being upgradable. I don't want this |
| 22:31.57 | spacecolonyone | What have I failed to configure to prevent this. In essence, I'd like to break chain so it NEVER reports it can be upgraded |
| 22:33.50 | *** join/#oe Tartarus (trini@pixelshelf.com) |
| 22:39.04 | ant_home | apelete: no way to boot vanilla kernels on ben-nanonote? |
| 23:01.57 | *** join/#oe devzero_ (~devzero@ip-88-153-59-6.unitymediagroup.de) |
| 23:22.40 | *** join/#oe challinan (~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |