| 00:12.14 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 00:12.32 | *** join/#oe KNERD (~KNERD@24.175.253.226) |
| 02:00.04 | *** join/#oe GusBricker (~GusBricke@c220-237-20-42.eburwd9.vic.optusnet.com.au) |
| 02:13.01 | *** join/#oe s3v3n62mm (~s3v3n62mm@p5DDC03FC.dip0.t-ipconnect.de) |
| 02:48.24 | *** join/#oe Leatherface_ (~leatherfa@2001:470:dd7d:0:95ee:c3c2:e057:c570) |
| 03:23.17 | *** join/#oe pompomJuice (~pompomJui@41.0.38.138) |
| 03:52.43 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 04:01.14 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 05:39.22 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 05:46.10 | *** join/#oe dv__ (~quassel@chello080108088242.14.11.vie.surfer.at) |
| 05:56.12 | *** join/#oe crxz0193 (~crxz0193@203.247.149.152) |
| 06:07.33 | *** join/#oe crxz0193_ (~crxz0193@203.247.149.152) |
| 06:08.33 | *** join/#oe aloril (~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) |
| 06:43.59 | *** join/#oe ant_work (~ant__@host54-128-static.10-188-b.business.telecomitalia.it) |
| 06:58.09 | *** join/#oe jbrianceau_away (uid10952@gateway/web/irccloud.com/x-hndjgsmgkcsivlpv) |
| 07:07.08 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 07:10.41 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 07:12.29 | *** join/#oe lamikr (~lamikr@145.247.15.238) |
| 07:12.33 | *** join/#oe lamikr_ (~lamikr@145.247.15.238) |
| 07:14.08 | *** join/#oe lamikr (~lamikr@145.247.15.238) |
| 07:16.49 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 07:38.50 | *** join/#oe kroon (~kroon@89-253-118-72.customers.ownit.se) |
| 07:39.10 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 07:39.38 | *** join/#oe florian (~fuchs@port-217-146-132-69.static.qsc.de) |
| 07:39.38 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 07:47.33 | *** join/#oe CMoH (~cipi@89.123.40.81) |
| 07:47.33 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 08:03.23 | *** join/#oe phdeswer (~phdeswer@mobile-internet-bceea1-141.dhcp.inet.fi) |
| 08:10.38 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:13.27 | *** join/#oe matt10 (~m@APuteaux-651-1-56-123.w81-249.abo.wanadoo.fr) |
| 08:13.34 | afournier | morning all ! |
| 08:14.00 | *** join/#oe matt10 (~m@APuteaux-651-1-56-123.w81-249.abo.wanadoo.fr) |
| 08:14.39 | matt10 | hi |
| 08:15.00 | *** join/#oe stefan_schmidt (~stefan@p200300480915BE28F2DEF1FFFE6228F7.dip0.t-ipconnect.de) |
| 08:18.20 | *** join/#oe afournier1 (~admin@46.255.181.29) |
| 08:19.19 | *** join/#oe hillct_ (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 08:19.46 | *** join/#oe sr105|aw` (~sr105@65349hfc19.tampabay.res.rr.com) |
| 08:23.15 | *** join/#oe jkridner|work (~jkridner@c-98-250-189-79.hsd1.mi.comcast.net) |
| 08:27.49 | *** join/#oe roric (~roric@c-2d9c70d5.013-177-67626713.cust.bredbandsbolaget.se) |
| 08:29.26 | *** join/#oe SoylentYellow_ (~quassel@curie.ece.neu.edu) |
| 08:29.28 | *** join/#oe cbrake_ (~cbrake@cable-pool6-cs-200.doycomm.com) |
| 08:30.57 | *** join/#oe uwe_mobile__ (~uwe@static.88-198-8-117.clients.your-server.de) |
| 08:33.56 | *** join/#oe eballetbo_ (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 08:36.36 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 08:36.36 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:36.57 | *** join/#oe aloril (~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) |
| 08:46.06 | *** join/#oe blilly (~blilly1@c-50-170-54-92.hsd1.wa.comcast.net) |
| 08:47.03 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 08:47.05 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 08:49.02 | mago_ | in the OE core class for images (meta/classes/image.bbclass), there is an unnamed python function: python () { ... }. In fact, these unnamed python function seems to exist in many OE classes. When are they called? |
| 08:49.51 | *** join/#oe Frank_ichoo (~tom_say@cpe-70-118-168-41.stx.res.rr.com) |
| 08:51.44 | koen | anonymous functions |
| 08:52.26 | ant_work | koen: don't drink anonymous coffee ;) |
| 08:53.20 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 08:53.20 | *** join/#oe tgall_foo (~tgall@linaro/tgall-foo) |
| 08:53.20 | *** join/#oe mnemoc (~amery@geeks.cl) |
| 08:56.20 | bluelightning | mago_: http://www.yoctoproject.org/docs/current/bitbake-user-manual/bitbake-user-manual.html#anonymous-python-functions |
| 09:00.16 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 09:05.49 | mago_ | thank you! i always seem to lose that up-to-date bitbake manual. Why is the one at http://docs.openembedded.org/bitbake/html/ so old? it's the one I find when googling :) |
| 09:08.39 | bluelightning | hmm we should link that one to the new one |
| 09:08.58 | bluelightning | we only just updated and published the new one as part of the YP manual set in 1.6 |
| 09:09.38 | bluelightning | RP: do you have access to make that link? |
| 09:16.12 | mago_ | i've been trying to get profiling tools working for my image, so I enabled the "tools-profile" IMAGE_FEATURE so that it pulls in meta/recipes-core/packagegroup-core-tools-profile.bb into my image. My rootfs immediately grew by approx. 70 MB, and I was curious exactly what caused the increase. Turns out an uncompressed version of the kernel gets included in /boot/vmlinux. I suppose this image also contains symbol info etc needed for kernel profiling |
| 09:16.12 | mago_ | <PROTECTED> |
| 09:20.41 | *** join/#oe likewise (~chatzilla@ip-213-127-193-12.ip.prioritytelecom.net) |
| 09:20.53 | likewise | gm |
| 09:22.07 | likewise | I have the issue (dora release) that PACKAGE_GROUP_mystuff = "some packages" is not picked up, unless I place this in image.bbclass. |
| 09:22.38 | likewise | ERROR: 'mystuff' in IMAGE_FEATURES is not a valid image feature. |
| 09:23.16 | bluelightning | likewise: where else are you trying to put it? |
| 09:24.04 | bluelightning | mago_: I presume that's from the "kernel-image" package; the way to track down the link would be to use buildhistory's package dependency graphs |
| 09:24.30 | bluelightning | http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality |
| 09:24.34 | likewise | bluelightning: in my packagegroup-leon.bb |
| 09:24.56 | bluelightning | likewise: that can't work... it has to be somewhere the image recipe can see it |
| 09:25.14 | bluelightning | likewise: so a conf file, or a class that the image recipe inherits |
| 09:25.36 | koen | kernel-vmlinux more likely |
| 09:25.48 | koen | kernel-image should only have the compressed and stripped version |
| 09:26.08 | bluelightning | koen: that's more likely yes; though it may depend on the machine |
| 09:26.28 | bluelightning | I can't remember which way around it goes if the machine only supports uncompressed kernels |
| 09:26.28 | likewise | bluelightning: hmm, so a custom packagegroup with support for IMAGE_FEATURE / PACKAGE_GROUP (now FEATURE_PACKAGES) should always be matched with a conf or clasS? |
| 09:26.34 | bluelightning | that's probably not the case here though |
| 09:26.36 | koen | yes, our emulated machines at linaro do 'make Image' |
| 09:27.40 | bluelightning | likewise: you may be thinking of packagegroup recipes and PACKAGE_GROUP being directly related; they aren't really - they are two separate pieces of functionality that may sometimes be used in conjunction |
| 09:27.58 | bluelightning | (hence why I renamed that variable recently) |
| 09:28.15 | likewise | bluelightning: yes, I am aware of that (since yesterday) |
| 09:28.51 | bluelightning | likewise: it's a matter of how PACKAGE_GROUP works; it's a variable, therefore the feature definition must be within the scope of the image you want to use it in |
| 09:28.52 | likewise | bluelightning: I have packagegroup-mystuff. I then want to do FEATURES_PACKAGES_mystuff = "packagegroup-mystuff |
| 09:32.18 | bluelightning | likewise: I think the best place for that would either be your distro config or a custom class that your image recipes always inherit |
| 09:35.33 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 09:35.55 | *** join/#oe crxz0193 (~crxz0193@203.247.149.152) |
| 09:36.06 | likewise | bluelightning: I am trying the latter approach: mystuff-core-image.bbclass, which in turn inherits from core-image.bbclass |
| 09:37.01 | bluelightning | likewise: that's one way, or you could inherit both classes in your image recipes and not have mystuff-core-image.bbclass inherit core-image |
| 09:37.30 | RP | bluelightning: probably not :/ |
| 09:37.31 | bluelightning | up to you really, I guess your way is slightly less typing for each recipe :) |
| 09:37.59 | bluelightning | RP: ok, I'll see if I can find someone else who can |
| 09:39.41 | likewise | bluelightning: The need for a custom class is not clear from the manual at all: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-FEATURE_PACKAGES |
| 09:40.33 | bluelightning | likewise: a custom class isn't strictly required, but variable scope is important for all variables |
| 09:41.01 | bluelightning | likewise: I agree we don't document scoping for this and other variables as well as we should, I think there is even a bug open for that |
| 09:53.19 | likewise | bluelightning: I am porting an existing customer project (danny->dora), this customer had IMAGE_FEATURES set in the mymachine.conf. This worked before, but broke on dora. |
| 09:53.32 | koen | lovely |
| 09:53.40 | koen | IMAGE features in a MACHINE.conf |
| 09:53.46 | likewise | indeed... |
| 09:53.53 | bluelightning | yuck |
| 09:54.10 | likewise | So basically I am trying to clean up mess. |
| 09:54.13 | bluelightning | well, I guess if you don't stop people from doing that and you barely document that they shouldn't, this is what happens... |
| 09:55.10 | likewise | I think the strict QA checks are improving, it's just I haven't wrapped my head around how things should be done (TM) in all cases. I now have this really bad example in front of me. |
| 09:55.37 | likewise | I'm trying to unbreak things that the customer thinks aren't broken in the first place :) |
| 09:55.44 | bluelightning | right, understood |
| 09:56.31 | bluelightning | I guess what I was saying is it's somewhat understandable when people do things like this even though we might shake our heads at it |
| 09:57.14 | bluelightning | as you say over time we've added more checks to try to stop people from falling down holes |
| 09:57.43 | likewise | bluelightning: agreed, we are learning from this, me included :) |
| 09:57.47 | mago_ | oh man its annoying that the GitPython provided by Ubuntu LTS isn't up-to-date enough to play with buildhistory-diff .. |
| 09:58.04 | bluelightning | mago_: virtualenv is your friend ;) |
| 09:58.17 | likewise | koen: I guess the other approach is IMAGE_FEATURES_append_mymachine = " x y z" in an image recipe. |
| 09:58.54 | likewise | Basically it's all a way of saying "I want *thi* software on *that* machine", |
| 09:59.00 | likewise | thi->this |
| 09:59.04 | mago_ | btw, bluelightning, do you have one of those web interfaces to the buildhistory running somewhere? it'd be nice to take a peek, looks interesting |
| 09:59.28 | bluelightning | likewise: that's what MACHINE_(ESSENTIAL_)EXTRA_* are designed for really |
| 10:00.20 | bluelightning | although those do rely on you using a couple of the core packagegroups |
| 10:00.55 | bluelightning | mago_: unfortunately no... I've been asking for it to be set up since I wrote it but it hasn't happened yet |
| 10:04.18 | koen | likewise: or a custom image recipe |
| 10:32.45 | *** join/#oe ChrisD1_Away (~ChrisD@merak.alcor.co.uk) |
| 11:08.20 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 11:10.20 | *** join/#oe milan__ (~milan@111.93.218.67) |
| 11:23.56 | bluelightning | anyone know why our default config wouldn't set up an ipv6 LL address for eth0? |
| 11:24.03 | bluelightning | in theory that should happen automatically... |
| 11:26.12 | koen | the kernel is in charge of that, right? |
| 11:39.09 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 11:49.07 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 11:50.38 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 11:52.32 | *** join/#oe kristoffer (~kristoffe@c-e882e253.171-2-64736c10.cust.bredbandsbolaget.se) |
| 11:53.04 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 11:53.59 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 11:56.29 | *** join/#oe joeythesaint (~jjm@128.224.252.2) |
| 12:00.19 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 12:02.06 | *** join/#oe darkschneider (~gab@93-32-59-224.ip32.fastwebnet.it) |
| 12:02.08 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 12:11.06 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 12:14.19 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 12:17.27 | bluelightning | koen: I'm not entirely sure... but supposedly having an LL address is part of the ipv6 spec |
| 12:17.45 | bluelightning | ipv6 is definitely enabled, and lo gets an address... |
| 12:21.05 | likewise | bluelightning: thanks for the help |
| 12:21.30 | bluelightning | likewise: np |
| 12:26.03 | *** join/#oe adelcast (~adelcast@130.164.62.193) |
| 12:28.19 | *** join/#oe ajtag (~ajtag@cpc10-lee211-2-0-cust124.7-1.cable.virginm.net) |
| 12:32.09 | *** join/#oe kscherer (~kscherer@128.224.252.2) |
| 12:42.12 | *** join/#oe florian (~fuchs@sign-4db609e5.pool.mediaWays.net) |
| 12:42.13 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 12:47.05 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 12:52.12 | *** join/#oe kroon (~kroon@89-253-118-72.customers.ownit.se) |
| 12:52.25 | *** join/#oe muppe (~Marko@ip050-115.seclan.com) |
| 12:54.04 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 13:02.18 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 13:05.29 | muppe | Hi there. I wonder if anyone has some words of wisdom related to the boot issue that I am having with Texas Instruments board. I have built a yocto-based distro with the instructions given in http://processors.wiki.ti.com/index.php/MCSDK_UG_Chapter_Exploring#Yocto but the boot log prints out the following message:Starting udev, Missing devtmpfs, which is required for udev to run, Halting... |
| 13:07.30 | XorA | enable DEVTMPFS in your kernel |
| 13:09.18 | koen | JaMa: 312433fe5d8c45df7e78e60599cc7abce0874ab5 is wrong, those are generated files |
| 13:09.43 | koen | JaMa: gnome-control-center now classes with packages which also ship those generated files |
| 13:09.46 | muppe | XorA: I tried to enabled this CONFIG_DEVTMPFS (with and without CONFIG_DEVTMPFS_MOUNT) but it didn't make a difference. |
| 13:10.30 | koen | JaMa: do you want me to sent a patch that reverts it or a patch that reverts it and rms those files and do_install_append ? |
| 13:24.22 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 13:29.47 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 13:44.27 | *** join/#oe kroon (~kroon@89-253-118-72.customers.ownit.se) |
| 14:18.04 | *** join/#oe falstaff (~quassel@195-226-23-137.pool.cyberlink.ch) |
| 14:20.00 | falstaff | Hi, my application links to a library using LDFLAGS+=-lfoo, foo library exists as a package as well and builds fine. However, when building my application -lfoo is not applied to LDFLAGS and hence when calling the compilter |
| 14:20.24 | falstaff | I figured out that make -e overwrites the environment, hence LDFLAGS too |
| 14:21.04 | falstaff | How should I solve this issue? Should bitbake set the LDFLAGS environment correctly with -lfoo by itself? |
| 14:21.34 | falstaff | (I set DEPENDS="libfoo", hence the build system knows about this dependency...) |
| 14:31.24 | *** join/#oe kgilmer_ (~kgilmer@65.209.23.146) |
| 14:32.05 | *** join/#oe oneQubit (~oneQubit@c-69-138-31-87.hsd1.md.comcast.net) |
| 14:34.12 | *** join/#oe kgilmer__ (~kgilmer@65.209.23.146) |
| 14:36.21 | kroon | scratches head why he had to cleansstate a packagegroup recipe in order to get it to build |
| 14:38.14 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 14:39.48 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 14:41.26 | *** join/#oe pespin (~pespin@98.pool80-102-155.dynamic.orange.es) |
| 14:42.13 | JaMa | koen: ah sorry about that, revert+rms would be better |
| 14:42.17 | kergoth | falstaff: it depends on the buildsystem in question. you can set EXTRA_OEMAKE = "", if your buildsystem will obey the vars we need it to obey from the environment (CC, CFLAGS, LDFLAGS, etc). otherwise you could alter that LDFLAGS += line to use 'override LDFLAGS +='. Or better yet ,don't put -l in LDFLAGS. that doens't belong there. generally the convention is to use a separate variable for that, e.g. LIBS |
| 14:42.47 | JaMa | koen: I think that khem sent similar patch for one of gnome-* recipes |
| 14:45.19 | falstaff | kergoth, hm, just launched a devshell, LIBS is not set automatically |
| 14:45.36 | kergoth | that's not an oe/yocto variable |
| 14:45.39 | kergoth | you completely missed my point |
| 14:45.48 | falstaff | kergoth, so I guess the libraries to link has to be in the Makefile |
| 14:45.52 | kergoth | i said *in your buildsystem/makefile*, -l doesn't belong in LDFLAGS |
| 14:45.58 | kergoth | that's where it belongs, yes |
| 14:46.21 | kergoth | we don't want to duplicate knowledge that's in the buildsystem we're calling, unless absolutely necessary |
| 14:47.37 | falstaff | Ok, and usually GNU Makefiles know which libraries to link, but it souldn't be in the LDFLAGS since thats meant for the user of GNU Makefile, right? |
| 14:51.17 | kergoth | The convention is that ldflags holds flags like -O, -L, etc, not what you're linking against. Much as CFLAGS holds -I, -O, etc but not the files you're compiling |
| 14:52.06 | kergoth | http://www.gnu.org/software/make/manual/html_node/Implicit-Variables.html |
| 14:52.11 | kergoth | LDFLAGS |
| 14:52.12 | kergoth | Extra flags to give to compilers when they are supposed to invoke the linker, ‘ld’, such as -L. Libraries (-lfoo) should be added to the LDLIBS variable instead. |
| 14:52.17 | kergoth | from the gnu make manual |
| 14:52.39 | kergoth | it's just convention, of course, you don't have to do this. just one possible approach to resolving your problem |
| 14:55.51 | koen | JaMa: iirc the oe-classic class deleted all that stuff |
| 14:56.22 | falstaff | kergoth, thx! using conventions is always a good idea, especiallly when not knowing better :-) |
| 14:58.20 | JaMa | koen: I don't use it in any of my images, I just wanted to get rid of qa :/ |
| 14:59.11 | koen | JaMa: np, I was just trying something bigger than console-image in the angstrom release branch |
| 14:59.27 | koen | I know I fixed the mime thing properly in OE-classic :) |
| 14:59.58 | koen | I wish OE-core daisy had mesa 10.0 :/ |
| 15:04.00 | *** join/#oe nitink (nitink@nat/intel/x-qphzoiesondqviry) |
| 15:28.33 | *** join/#oe Leatherface- (~leatherfa@2001:470:dd7d:0:58ec:48d7:2fe9:cc93) |
| 15:32.54 | *** join/#oe khem` (~khem@99-57-140-30.lightspeed.sntcca.sbcglobal.net) |
| 15:33.15 | *** join/#oe afournier (~admin@46.255.181.29) |
| 15:52.16 | *** part/#oe falstaff (~quassel@195-226-23-137.pool.cyberlink.ch) |
| 16:07.21 | *** join/#oe Crofton (~balister@64-186-172-226.static-ip.telepacific.net) |
| 16:18.21 | *** join/#oe contempt (contempt@unaffiliated/contempt) |
| 16:30.04 | darknighte | khem: are you gonig to make it IP to OEDAM? |
| 16:32.43 | *** join/#oe esben (~esben@0x55532124.adsl.cybercity.dk) |
| 16:33.53 | otavio | It is hard for me to understand people talking in OEDAM |
| 16:33.57 | otavio | :-( |
| 16:34.05 | *** join/#oe ka6sox-here (40baace2@nasadmin/ka6sox) |
| 16:34.17 | fray | otavio we're mostly sitting on #yocto.. just an FYI.. |
| 16:34.19 | Crofton | sorry |
| 16:34.25 | *** join/#oe Jefro (40baace2@gateway/web/freenode/ip.64.186.172.226) |
| 16:34.31 | fray | but ya, we're chattering.. we'll try to be clearer as we go forward |
| 16:34.33 | Crofton | we grabbed a webcam they had sitting around |
| 16:34.37 | *** join/#oe HerbKuta (40baace2@gateway/web/freenode/ip.64.186.172.226) |
| 16:35.17 | *** join/#oe mr_science (40baace2@gateway/web/freenode/ip.64.186.172.226) |
| 16:35.19 | *** join/#oe dzu (~user@ppp-62-216-192-32.dynamic.mnet-online.de) |
| 16:35.25 | *** join/#oe tlwoerner___ (40baace2@gateway/web/freenode/ip.64.186.172.226) |
| 16:35.33 | *** part/#oe HerbKuta (40baace2@gateway/web/freenode/ip.64.186.172.226) |
| 16:37.30 | *** join/#oe mr_science (40baace2@gentoo/developer/nerdboy) |
| 16:43.57 | *** join/#oe roric (~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se) |
| 17:09.37 | *** join/#oe RagBal_ (~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 17:10.02 | *** join/#oe Rootert (~Rootert@54694E34.cm-12-2b.dynamic.ziggo.nl) |
| 17:19.12 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 17:57.21 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 18:10.45 | *** join/#oe jackmitch|home (~Thunderbi@cpc22-cmbg15-2-0-cust21.5-4.cable.virginm.net) |
| 18:12.53 | *** part/#oe dzu (~user@ppp-62-216-192-32.dynamic.mnet-online.de) |
| 18:23.06 | kergoth | ugh, bitbake's hardcoded fetch export vars make me sad |
| 18:23.28 | kergoth | as does the fact that oe-buildenv-internal doesn't respect existing BB_ENV_EXTRAWHITE |
| 18:26.39 | kergoth | hmm |
| 18:31.12 | kergoth | Okay, add nativesdk-ca-certificates to the buildtools tarball, add export of GIT_SSL_CAINFO to the buildtools-tarball env setup script, add GIT_SSL_CAINFO to BB_ENV_EXTRAWHITE, and hack it into being exported in do_fetch without changing signatures (e.g export GIT_SSL_CAINFO, or use of task_level_exports.bbclass), and git clones over https works regardless of where buildtools-tarball is installed or what the host distro is, afaict. |
| 18:31.28 | kergoth | without that, not so much :) |
| 18:31.35 | kergoth | does some sanity testing |
| 18:32.43 | kergoth | I should add a subcommand of bb to basically wrap bitbake -S for a task and then dumpsig that out, so you can inspect a signature of a specified task quickly |
| 18:32.47 | kergoth | that'd be handy, i'm thinking |
| 19:02.06 | *** join/#oe nitink (nitink@nat/intel/x-yyzrxtngiivcyjwd) |
| 19:08.41 | kroon | Testing out meta-mingw.. Shouldn't "SDKMACHINE=x86_64-mingw32 bitbake -c populate_sdk my-image" work in theory ? |
| 19:10.02 | mr_science | worked the last time tried it... |
| 19:10.19 | mr_science | *i even... |
| 19:11.13 | kergoth | kroon: only if you add it to BB_ENV_EXTRAWHITE. by default MAACHINE is htere, SDKMACHINE is not |
| 19:11.17 | kergoth | afaict anyway |
| 19:11.29 | kergoth | see poky/scripts/oe-buildenv-internal line 105 |
| 19:14.18 | *** join/#oe florian (~fuchs@Maemo/community/contributor/florian) |
| 19:14.27 | mr_science | sorry, "worked" meaning without changing SDKMACHINE on the fly... |
| 19:14.52 | mr_science | small screen, tired brain... |
| 19:14.59 | kroon | kergoth, I have SDKMACHINE there aswell on my system |
| 19:15.23 | kergoth | afaik it should work then, but no idea re: ming specifically :) |
| 19:15.51 | kroon | I see mingw recipes being processed, but also tasks failing |
| 19:30.37 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 19:31.03 | kroon | huh, did a wipe-sysroot, and now it seems to continue.. |
| 19:32.19 | kroon | I've generated sdk's for linux before, maybe I can't have both at the same time.. |
| 19:33.57 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 19:34.05 | *** join/#oe bluelightning (~paul@2001:8b0:258:7d7a:5e51:4fff:febb:401d) |
| 19:34.05 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 19:48.52 | *** join/#oe kgilmer_ (~kgilmer@65.209.23.146) |
| 19:57.56 | *** join/#oe Jeff_ (40baace2@gateway/web/freenode/ip.64.186.172.226) |
| 20:21.24 | *** join/#oe challinan (~chris@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net) |
| 20:25.15 | *** join/#oe roric (~roric@c-107ae455.213-3-64736c14.cust.bredbandsbolaget.se) |
| 21:07.06 | *** join/#oe Shawn286 (~Shawn@unaffiliated/shawn156) |
| 21:09.55 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 21:18.02 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 21:35.22 | akbennett | current core-image-sato-sdk-beaglebone booting & running tests on a BBB in LAVA - http://community.validation.linaro.org/scheduler/job/11600 |
| 21:38.06 | Crofton | akbennett, did you just do that? |
| 21:39.04 | Crofton | what is the error? multitasking sucks :) |
| 21:43.17 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 22:30.06 | *** join/#oe ant_home (~andrea@host154-42-dynamic.183-80-r.retail.telecomitalia.it) |
| 22:38.47 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 23:39.31 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 23:50.35 | *** join/#oe kuldeepdhaka (~kuldeepdh@unaffiliated/kuldeepdhaka) |
| 23:51.40 | *** join/#oe nitink (~nitink@134.134.137.71) |