| 01:34.36 | *** join/#oe kgilmer (~kgilmer@2604:2000:84c7:2d01:1d4b:9242:6b79:254e) |
| 02:33.03 | *** join/#oe s3v3n62mm2 (~s3v3n62mm@p5DDC3668.dip0.t-ipconnect.de) |
| 03:19.07 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 03:21.42 | *** join/#oe pompomJuice (~pompomJui@41.0.38.138) |
| 03:33.49 | *** join/#oe NvrBst (~NvrBst@gateway/tor-sasl/nvrbst) |
| 03:55.44 | *** join/#oe KNERD (~KNERD@24.175.253.226) |
| 04:24.17 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 05:04.49 | *** join/#oe crxz0193 (~crxz0193@123.201.50.65) |
| 05:38.44 | *** join/#oe Jefro (~jefro@50-0-152-82.dedicated.static.sonic.net) |
| 06:09.15 | *** join/#oe rob_w (~bob@unaffiliated/rob-w/x-1112029) |
| 06:23.09 | *** join/#oe matt120 (~matt10@65-15.80-90.static-ip.oleane.fr) |
| 06:31.05 | *** join/#oe tasslehoff (~Tasslehof@77.40.182.98) |
| 06:40.26 | *** join/#oe ka6sox-home (~ka6sox@nasadmin/ka6sox) |
| 06:42.45 | *** join/#oe ant_work (~ant__@host54-128-static.10-188-b.business.telecomitalia.it) |
| 06:52.46 | *** join/#oe msm` (~msm@cpe-72-182-100-192.austin.res.rr.com) |
| 06:57.45 | *** join/#oe dv_ (~quassel@chello080108088242.14.11.vie.surfer.at) |
| 06:57.54 | *** join/#oe diego_r (~diego@host65-246-static.10-188-b.business.telecomitalia.it) |
| 07:03.05 | *** join/#oe kroon (~kroon@fw.mikrodidakt.se) |
| 07:03.13 | *** join/#oe woglinde (~henning@fb-n15-11.unbelievable-machine.net) |
| 07:11.23 | *** join/#oe eballetbo (~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net) |
| 07:19.44 | rob_w | woglinde, omap_wdt works, forgot about the NOWAYOUT kernel config option |
| 07:44.11 | *** join/#oe ao2 (~ao2@2001:1418:117::1) |
| 08:01.10 | *** join/#oe paulbarker (~pbarker@ygg.betafive.co.uk) |
| 08:03.27 | mckoan | good morning |
| 08:03.42 | kroon | mckoan, morning |
| 08:06.48 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 08:16.46 | *** join/#oe joob (~joob@185.31.152.97) |
| 08:17.53 | *** part/#oe joob (~joob@185.31.152.97) |
| 08:20.36 | *** join/#oe dany (~Thunderbi@sestofw01.enea.se) |
| 08:34.19 | *** join/#oe bluelightning (~paul@83.217.123.106) |
| 08:34.20 | *** join/#oe bluelightning (~paul@pdpc/supporter/professional/bluelightning) |
| 08:34.51 | koen | hrm |
| 08:35.05 | koen | looks like meta-qt5 doesn't generate an env file for the target |
| 08:35.29 | koen | gets a dejavu |
| 08:41.06 | bluelightning | morning all |
| 08:45.21 | mckoan | hi bluelightning, all |
| 08:45.34 | bluelightning | hi mckoan, koen |
| 08:45.42 | koen | hey mckoan & bluelightning |
| 08:53.39 | woglinde | rob_w good to know |
| 08:53.44 | woglinde | hi koen |
| 08:53.59 | woglinde | hi mckoan and bluelightning |
| 08:56.55 | bluelightning | hi woglinde |
| 09:05.53 | koen | hey woglinde |
| 09:20.04 | *** join/#oe focus (~Doug@host81-149-149-147.in-addr.btopenworld.com) |
| 09:26.29 | *** join/#oe mra_ (mrannanj@melkki.cs.helsinki.fi) |
| 10:06.20 | pompomJuice | seriously this bitbake process splitting my images into multiple packages... it only causes ball-ache... |
| 10:07.21 | pompomJuice | I just wanna quickly compile and run linaro flashbench, but the git repo is set to build debug binaries. Bitbake notices these debug binaries and puts them in flashbench-dev that you cannot install since you can't install flashbenhch because it is empty... this entire insane system is well, insane! |
| 10:07.41 | pompomJuice | stop thinking and to what I say |
| 10:07.47 | pompomJuice | so frustrating |
| 10:09.25 | bluelightning | pompomJuice: it depends on what files you are building and how they get laid out... some software fits less well to our defaults |
| 10:10.47 | bluelightning | what files the software you are building produces* that is |
| 10:17.25 | pompomJuice | ... |
| 10:18.13 | pompomJuice | git://git.linaro.org/people/arnd.bergmann/flashbench.git |
| 10:18.19 | pompomJuice | its a simple little makefile project |
| 10:18.22 | pompomJuice | nothing fancy |
| 10:18.36 | pompomJuice | I make a recipy, it takes me 2 minutes |
| 10:18.57 | pompomJuice | then I start wresling with the insane system... that takes me 5 days to get the thing to release my binaries into the god damn ipk |
| 10:19.23 | pompomJuice | because it deems them to be debug |
| 10:19.28 | pompomJuice | even though the human knows better |
| 10:21.26 | pompomJuice | does someone know what I must put in here to stop insane from removing debug binaries? -> INSANE_SKIP_${PN}="??" |
| 10:23.14 | bluelightning | insane doesn't actually do any packaging, at all |
| 10:23.20 | bluelightning | it's what reports potential issues |
| 10:23.39 | bluelightning | if you do not want the default packaging layout, change PACKAGES and FILES as desired |
| 10:24.13 | pompomJuice | FILES_${PN}= ... |
| 10:24.15 | pompomJuice | I do have that |
| 10:24.30 | pompomJuice | but something takes them out of my main ipk since they are debug |
| 10:24.40 | pompomJuice | AFAIK it is the insane system |
| 10:24.45 | bluelightning | no, it isn't |
| 10:24.53 | bluelightning | files will go into the package whose FILES matches first in the order the packages are mentioned in PACKAGES |
| 10:24.58 | pompomJuice | what part of bitbake is doing this? |
| 10:25.15 | bluelightning | ${PN}-dbg and ${PN}-dev are *before* ${PN} in the default value of PACKAGES, it couldn't work otherwise |
| 10:25.34 | pompomJuice | aah |
| 10:26.35 | bluelightning | this is all in package.bbclass, but you don't have to look there; just change FILES_${PN}-dev = "" or something like that |
| 10:26.48 | pompomJuice | jsut did |
| 10:26.50 | pompomJuice | compiling... |
| 10:27.02 | Crofton|work | any python gurus around |
| 10:27.09 | bluelightning | Crofton|work: sort of... |
| 10:27.32 | Crofton|work | let me pastebin the diff between pyconfig.h for native and target builds |
| 10:28.46 | Crofton|work | http://pastebin.com/XixrJufE |
| 10:29.03 | Crofton|work | the problem line is at 15 or so |
| 10:29.10 | Crofton|work | I can't see why it is different |
| 10:29.20 | pompomJuice | ok that just made the files dissapear |
| 10:29.26 | pompomJuice | now the two binaries are nowhere |
| 10:29.35 | pompomJuice | not inserted in any IPK |
| 10:29.44 | Crofton|work | and it gets defiend for the native pyconfig.h, which leads to a build failure for ice |
| 10:29.55 | bluelightning | pompomJuice: did you get installed but not shipped warnings? |
| 10:30.54 | pompomJuice | yes |
| 10:30.55 | bluelightning | Crofton|work: I don't know much about this file, but if I had to guess it would be that it simply could not do the test when cross-compiling; if that's the case it would probably be a bug in how we build python for the target |
| 10:31.11 | Crofton|work | well, it look s lik eundef is correct |
| 10:31.20 | bluelightning | pompomJuice: ok, don't ignore those - it's warning you about this exact problem |
| 10:31.22 | Crofton|work | that is what it is on the build machine |
| 10:31.30 | Crofton|work | but we get it wrong for the native case |
| 10:31.38 | Crofton|work | that is what is strange |
| 10:31.47 | bluelightning | Crofton|work: clues in config.log for python-native? |
| 10:31.49 | Crofton|work | I guess I need to read the code |
| 10:31.55 | Crofton|work | ok |
| 10:31.57 | Crofton|work | will do |
| 10:32.04 | Crofton|work | just hoping someone had a short answer |
| 10:32.05 | koen | flashbench builds 2 binaries: flashbench and erase |
| 10:32.19 | koen | which should go into ${bindir} |
| 10:32.27 | pompomJuice | yea |
| 10:32.34 | koen | if they end up in -dev, then you weren't installing them into ${bindir} |
| 10:32.38 | pompomJuice | do_install () { |
| 10:32.39 | pompomJuice | <PROTECTED> |
| 10:32.39 | pompomJuice | <PROTECTED> |
| 10:32.39 | pompomJuice | <PROTECTED> |
| 10:32.39 | pompomJuice | } |
| 10:32.45 | pompomJuice | FILES_${PN} = "\ |
| 10:32.46 | pompomJuice | <PROTECTED> |
| 10:32.46 | pompomJuice | <PROTECTED> |
| 10:32.46 | pompomJuice | " |
| 10:32.48 | pompomJuice | that does not work |
| 10:32.55 | bluelightning | pompomJuice: there's your problem |
| 10:33.03 | pompomJuice | what? |
| 10:33.04 | pompomJuice | tell me |
| 10:33.04 | bluelightning | pompomJuice: remove ${D}/ from the FILES value |
| 10:33.22 | pompomJuice | omg |
| 10:33.37 | pompomJuice | take it slow bob |
| 10:33.40 | koen | remove the FILES_{PN} value completely |
| 10:33.48 | bluelightning | yes, in fact what koen said |
| 10:33.49 | pompomJuice | ok |
| 10:33.50 | koen | ${bindir} is in there by default |
| 10:33.53 | bluelightning | the default value will do the right thing |
| 10:34.10 | bluelightning | in fact you can now remove the FILES_${PN}-dev = "" thing as well |
| 10:34.27 | koen | koen@beast:/build/v2013.12/sources/meta-qt5$ grep FILES_ ../openembedded-core/meta/conf/bitbake.conf |
| 10:34.29 | pompomJuice | building... |
| 10:34.32 | koen | FILES_${PN} = "${bindir}/* ${sbindir}/* ${libexecdir}/* ${libdir}/lib*${SOLIBS} \ |
| 10:34.43 | pompomJuice | aah |
| 10:35.20 | pompomJuice | now it is saying that files were not shipped |
| 10:35.31 | pompomJuice | in particular, those two binaries |
| 10:35.37 | pompomJuice | remember this does not have autotools |
| 10:35.42 | bluelightning | doesn't matter |
| 10:35.43 | pompomJuice | and no make install |
| 10:36.06 | pompomJuice | still does not work |
| 10:36.19 | bluelightning | you're definitely sure you removed your FILES_${PN} value? |
| 10:36.21 | pompomJuice | there is no flashbench-0.1 package |
| 10:36.23 | pompomJuice | yes |
| 10:36.42 | bluelightning | because it's behaving like you haven't... |
| 10:36.45 | pompomJuice | SRC_URI = " \ |
| 10:36.45 | pompomJuice | <PROTECTED> |
| 10:36.45 | pompomJuice | " |
| 10:36.45 | pompomJuice | S = "${WORKDIR}/git" |
| 10:36.45 | pompomJuice | do_compile () { |
| 10:36.46 | pompomJuice | <PROTECTED> |
| 10:36.46 | pompomJuice | } |
| 10:36.47 | pompomJuice | do_install () { |
| 10:36.47 | pompomJuice | <PROTECTED> |
| 10:36.48 | pompomJuice | <PROTECTED> |
| 10:36.48 | pompomJuice | <PROTECTED> |
| 10:36.49 | pompomJuice | } |
| 10:36.49 | pompomJuice | that is my entire recipy |
| 10:37.00 | pompomJuice | excluding licence stuff at the top |
| 10:37.03 | pompomJuice | that is on bitbake 1.20 |
| 10:37.13 | pompomJuice | yocto 1.5 |
| 10:37.13 | pompomJuice | all the latests stuff |
| 10:37.35 | pompomJuice | did a -c cleansstate |
| 10:37.46 | koen | 1.6 is out already |
| 10:37.55 | pompomJuice | yea il wait with that... |
| 10:38.03 | pompomJuice | that sneaky 1.4 -1.5 move cost me 3 months |
| 10:38.24 | pompomJuice | in the end I found that memcpy from memory given to me by the syslink shared memory API breaks |
| 10:38.26 | pompomJuice | fun |
| 10:38.30 | bluelightning | this will work just fine in 1.5 |
| 10:39.08 | pompomJuice | most likely since the new linaro uses neon to do memcpy or something... that is my guess |
| 10:39.30 | pompomJuice | bah I have to go |
| 10:39.32 | pompomJuice | damnit |
| 10:39.36 | pompomJuice | thanks for trying to help though |
| 10:39.41 | pompomJuice | be back in 30 mins |
| 10:39.44 | koen | ah syslink |
| 10:39.58 | koen | the joy of abandonded vendor kernel extensions |
| 10:50.26 | *** join/#oe anarsoul|2 (~anarsoul@178.124.194.242) |
| 11:11.50 | *** join/#oe kroon (~kroon@193.15.174.198) |
| 11:22.26 | *** join/#oe dany (~Thunderbi@sestofw01.enea.se) |
| 11:28.01 | *** join/#oe kgilmer (~kgilmer@2604:2000:84c7:2d01:1610:9fff:fed7:1ca9) |
| 11:28.05 | *** join/#oe _dv_ (~quassel@chello080108088242.14.11.vie.surfer.at) |
| 11:32.12 | *** join/#oe dany (~Thunderbi@sestofw01.enea.se) |
| 11:37.42 | pompomJuice | btw removing FILES_${PN} is not the issue, the issue is that something sees that the files are debug and then moves them to the -dev ipk whick cannot be install because of a built in dependency to the parent package that does not exist because there are no files for it, they were moved to the -dev ipk |
| 11:38.22 | pompomJuice | its shooting itself in the foot |
| 11:38.44 | koen | what do you mean with 'files are debug'? |
| 11:38.54 | koen | debug files get moved to -dbg, not -dev |
| 11:38.57 | pompomJuice | gcc -g |
| 11:39.06 | pompomJuice | oh yea soz |
| 11:39.08 | pompomJuice | dbg |
| 11:39.11 | pompomJuice | I got those mixed |
| 11:39.16 | koen | patebin the recipe as well as the output from bitbake |
| 11:39.34 | pompomJuice | I am so used to the same happening to .so files.. they are usually moved to -dev |
| 11:40.24 | pompomJuice | http://pastebin.com/BDEpQbMB |
| 11:40.36 | koen | remove PR=r0 |
| 11:40.46 | pompomJuice | kk |
| 11:42.05 | pompomJuice | building for output |
| 11:42.14 | koen | http://hastebin.com/mixonoxajo.vbs |
| 11:42.16 | koen | that's what I get |
| 11:43.05 | koen | http://hastebin.com/uyavaqohir.rb |
| 11:43.27 | pompomJuice | do you have ipks? |
| 11:43.52 | pompomJuice | with files in them? |
| 11:45.33 | pompomJuice | I get the same prolems with some other sources that only produce .so files ( as supposed to .so.1 )... such as mono |
| 11:45.40 | koen | http://hastebin.com/wojuvuboxi.avrasm |
| 11:46.02 | pompomJuice | yea |
| 11:46.06 | pompomJuice | but that wont install |
| 11:46.20 | koen | why not? |
| 11:46.22 | koen | flashbench_git-r0.0_armv7ahf-vfp-neon.ipk has the files |
| 11:46.32 | pompomJuice | oh wait |
| 11:47.09 | pompomJuice | ok so that is on 1.6? |
| 11:47.20 | pompomJuice | I see the package names look different |
| 11:47.27 | pompomJuice | mine is |
| 11:47.31 | koen | no, 1.5 |
| 11:47.38 | koen | but that won't make a difference |
| 11:48.55 | pompomJuice | ok now I am confused |
| 11:49.03 | *** join/#oe kristoffer (~kristoffe@c-e882e253.171-2-64736c10.cust.bredbandsbolaget.se) |
| 11:49.04 | pompomJuice | yours is working |
| 11:49.06 | pompomJuice | mine is not |
| 11:49.15 | pompomJuice | that depends on bitbake right? |
| 11:49.20 | pompomJuice | that behaviour? |
| 11:49.23 | pompomJuice | mine is on 1.20 |
| 11:49.25 | koen | no |
| 11:49.29 | *** join/#oe exosyst (~exosyst@95.151.107.24) |
| 11:49.37 | pompomJuice | where does that behaviour come from? |
| 11:49.46 | koen | the packaging behaviour that would influence that hasn't changed in years |
| 11:49.54 | koen | it's in package*bbclass and bitbake.conf |
| 11:50.09 | pompomJuice | meta-angstrom,git://github.com/Angstrom-distribution/meta-angstrom,angstrom-v2013.12-yocto1.5,HEAD |
| 11:50.15 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 11:50.20 | pompomJuice | meta-openembedded,git://github.com/Angstrom-distribution/meta-oe.git,angstrom-staging-yocto1.5,HEAD |
| 11:50.29 | koen | if you do 'bitbake flashbench -c package_write' what end up in packages-split? |
| 11:50.31 | pompomJuice | openembedded-core,git://github.com/Angstrom-distribution/oe-core.git,angstrom-staging-yocto1.5,HEAD |
| 11:50.37 | pompomJuice | checking |
| 11:51.40 | *** join/#oe kgilmer (~kgilmer@184.152.73.182) |
| 11:51.43 | pompomJuice | interesting |
| 11:52.32 | pompomJuice | http://hastebin.com/tagodatire.sm |
| 11:52.57 | pompomJuice | the files are in flashbench/usr/bin |
| 11:53.07 | koen | as they should |
| 11:53.22 | koen | and bitbake flashbench -c package_write -f ? |
| 11:53.26 | koen | that should give you ipks |
| 11:53.45 | pompomJuice | kk |
| 11:54.24 | pompomJuice | there it is |
| 11:54.28 | pompomJuice | weird |
| 11:55.00 | pompomJuice | that worked |
| 11:55.12 | pompomJuice | the packace is located in deploy-ipks |
| 11:55.16 | pompomJuice | and that is a neat trick |
| 11:55.21 | pompomJuice | package* |
| 11:55.48 | koen | I suspect you had some caching issues where bitbake didn't pickup changes in your recipe |
| 11:56.03 | pompomJuice | aah |
| 11:56.07 | koen | I've seem some weird heisenbugs with that |
| 11:56.10 | koen | it shouldn't happen |
| 11:56.15 | pompomJuice | aah |
| 11:56.20 | pompomJuice | nuke cache? |
| 11:56.32 | pompomJuice | let me see |
| 11:56.44 | koen | a bitbake flashbench -c cleansstate would fix that |
| 11:56.55 | pompomJuice | yea I do cleansstate all the time |
| 11:57.01 | pompomJuice | you have to |
| 11:57.20 | pompomJuice | or the thing just stucks in it's current state as you know |
| 11:57.21 | koen | I wish I could reproduce those cache issue |
| 11:57.29 | koen | filing a bug without a reproducer is useless |
| 11:57.38 | koen | and gets me more comic sans spam from intel people |
| 11:58.06 | koen | <PROTECTED> |
| 11:58.12 | koen | that fixes a lot of things |
| 11:58.32 | pompomJuice | yea doing that now |
| 11:58.36 | koen | if you don't bitbake will start using a few gigabyte more ram after a few builds |
| 11:58.50 | koen | keep the sqlite stuff in cache/ |
| 11:59.00 | koen | bad things happen when those go away |
| 11:59.06 | pompomJuice | oh ok |
| 11:59.11 | pompomJuice | normally I just trash the folder |
| 11:59.17 | pompomJuice | those sqlite things come through the repo |
| 11:59.23 | koen | yes |
| 11:59.25 | pompomJuice | why do cache things come down from the repo? |
| 11:59.33 | koen | to keep versions in sync |
| 11:59.34 | pompomJuice | I am sure I deleted them since |
| 11:59.40 | pompomJuice | must I restore themmm |
| 11:59.44 | pompomJuice | as bad things are happening |
| 11:59.59 | koen | if you delete them the build will produce foo_1.0-r0.0.ipk |
| 12:00.08 | koen | the online feeds will have foo_1.0-r0.5.ipk |
| 12:00.10 | pompomJuice | aah |
| 12:00.19 | pompomJuice | that is what I have |
| 12:00.42 | pompomJuice | I thought that was part of a new system that enables "upgrades" since versions that stay the same get pertubated with .5? |
| 12:00.46 | koen | to avoid 'opkg update' doing spurious updates the sqlite files are in git |
| 12:00.55 | koen | which of course is a binary merge nightmare :( |
| 12:01.02 | pompomJuice | yea disaster |
| 12:01.10 | koen | but importing the info with bitbake-prserv-tool takes ~3 minutes |
| 12:01.12 | pompomJuice | does that even work |
| 12:01.38 | koen | no, binary merges don't work |
| 12:01.39 | pompomJuice | do you think I broke something by deleteing those files"? |
| 12:01.44 | koen | better, they don't even exist |
| 12:02.06 | koen | 'opkg update ; opkg upgrade' will try to upgrade nearly everything |
| 12:02.14 | bluelightning | koen: do not discourage people from filing bugs, please |
| 12:02.15 | pompomJuice | ok but it worked |
| 12:02.35 | pompomJuice | somehow |
| 12:02.37 | pompomJuice | it worked |
| 12:02.45 | pompomJuice | your package_write -f |
| 12:02.53 | pompomJuice | somehow got the thing to make new ipks |
| 12:03.01 | pompomJuice | they are now located in the deploy folder |
| 12:03.12 | pompomJuice | happy |
| 12:04.02 | pompomJuice | aand poof it worked |
| 12:04.14 | pompomJuice | seems we unlocked it somehow |
| 12:04.57 | pompomJuice | why did you say I must remove PR? |
| 12:05.07 | pompomJuice | I use PR to indeicate recipy changes...? |
| 12:05.19 | pompomJuice | but lately bitbake has been incredible in detecting changes... |
| 12:05.28 | pompomJuice | it even knows that I change "patch" files |
| 12:05.49 | koen | right |
| 12:05.58 | koen | that's why I called it 'heisenbugs' |
| 12:06.04 | koen | it works about 98% of the time |
| 12:06.12 | pompomJuice | lol |
| 12:06.15 | pompomJuice | bizarre |
| 12:06.58 | bluelightning | this is unlikely to be a cache bug |
| 12:07.00 | koen | stabs meta-qt5 again for not being able to used to on-target builds |
| 12:10.38 | *** join/#oe CMoH (~cipi@unaffiliated/c-moh) |
| 12:27.13 | Crofton|work | bluelightning, looks like the patch that fixes the issue is applied to pyhton but not python-native |
| 12:27.15 | Crofton|work | testing now |
| 12:28.36 | bluelightning | that reminds me, we really ought to upgrade to a new version of Python 2.7 |
| 12:28.42 | Crofton|work | yeah |
| 12:28.53 | bluelightning | if someone feels like taking that task on, I did make a start on it last cycle |
| 12:28.56 | Crofton|work | I just need to fix the host contaminatoin |
| 12:29.22 | Crofton|work | looks like the guy that did the work weaseled around the root cause, and used host python :) |
| 12:29.29 | *** join/#oe dany (~Thunderbi@sestofw01.enea.se) |
| 12:30.13 | Crofton|work | yep |
| 12:30.19 | Crofton|work | let me make a patch for python-native |
| 12:30.32 | Crofton|work | frak more backports for diane |
| 12:30.40 | *** join/#oe adelcast (~adelcast@130.164.62.249) |
| 12:31.35 | Crofton|work | adelcast, gm |
| 12:33.51 | *** join/#oe tasslehoff (~Tasslehof@77.40.182.98) |
| 12:35.15 | *** join/#oe crxz0193 (~crxz0193@123.201.50.65) |
| 12:41.54 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 12:47.28 | Crofton|work | annoying, the oe-core READm lacks the git send-email line to copy/paste |
| 12:48.07 | stefan__ | is anyone around who has experience with meta-mingw ? I'm trying to use it but run into build errors. |
| 12:51.56 | bencoh | meta-mingw ? is it supposed to work ? |
| 12:53.07 | bluelightning | Crofton|work: much easier to set the options in the .git/config file for the repository |
| 12:53.24 | bluelightning | then you never have to remember the appropriate options again |
| 12:53.36 | Crofton|work | well, nothing in the README about that either :) |
| 12:53.45 | Crofton|work | yes, i am cranky this morning |
| 12:53.47 | bluelightning | Crofton|work: no, there isn't |
| 12:54.06 | Crofton|work | yet another reference to the Yocto Project as a build system on the tubes |
| 12:54.08 | bluelightning | basically add this http://pastebin.com/hpTvT74s |
| 12:54.39 | stefan__ | bencoh: I don't know. I assume that's the point of it. :-) (http://layers.openembedded.org/layerindex/branch/dylan/layer/meta-mingw/) |
| 12:56.07 | bencoh | hm btw, not sure the default separate builddir in autotools.bbclass was a good idea |
| 12:57.17 | bluelightning | bencoh: why not? |
| 12:57.40 | bluelightning | stefan__: could you pastebin the error you are getting? |
| 12:59.09 | stefan__ | bluelightning: sure, one sec. |
| 13:00.41 | bencoh | bluelightning: it's been getting on my nerves the whole morning to the point I ended up changing .bbclass to B = $S :] |
| 13:00.52 | bencoh | too many broken packages |
| 13:09.45 | JaMa | bencoh: there is patch on ML to set it only in broken recipes |
| 13:10.10 | JaMa | bencoh: well for the layers which are included in my world builds |
| 13:11.32 | JaMa | koen: I'm not very keen on that meta-qt5 backport, the usage of path variable is documented on wiki and I don't want to change behavior in release branch (even that in this case it's not dangerous) |
| 13:12.04 | koen | JaMa: I needed it to build stuff against qt5 |
| 13:12.51 | JaMa | koen: https://github.com/meta-qt5/meta-qt5/wiki/Building-with-OE#bad-include-paths-and-build-failing-to-find-qt5-headers |
| 13:14.21 | *** join/#oe jkridner (~jkridner@c-98-250-189-79.hsd1.mi.comcast.net) |
| 13:14.22 | *** join/#oe jkridner (~jkridner@pdpc/supporter/active/jkridner) |
| 13:14.42 | bencoh | JaMa: oh ? |
| 13:14.50 | bluelightning | Crofton|work: http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Streamlining_git-send-email_with_configuration |
| 13:15.00 | bencoh | JaMa: autotools-brokensep, or something else ? |
| 13:15.14 | bluelightning | bencoh: it's a change for the better in the long run |
| 13:15.20 | bencoh | bluelightning: yeah :) |
| 13:15.28 | bencoh | we're just not there yet though |
| 13:15.44 | JaMa | bencoh: yes B=S or brokensep |
| 13:16.39 | koen | JaMa: the backport makes more things work "out of the box", which I why I proposed it |
| 13:19.40 | koen | gets back to trying to generate a qt.conf use on the target |
| 13:20.30 | koen | JaMa: btw, getting the target qmake to build and work wasn't hard, just a matter of S=B and a few small tweaks (adding -p to mkdir) |
| 13:20.49 | koen | JaMa: is S!=B a hard requirement for qtbase or can we disable it to get qmake? |
| 13:22.40 | *** join/#oe Leatherface- (~leatherfa@2001:470:dd7d:0:1994:c013:4006:f01d) |
| 13:25.18 | *** join/#oe dany (~Thunderbi@sestofw01.enea.se) |
| 13:34.13 | stefan__ | bluelightning: sorry for the latency, got caught in a conference call... |
| 13:34.25 | stefan__ | bluelightning: so my problem with producing the mingw SDK is this: |
| 13:35.35 | stefan__ | nativesdk-mingw-w64-runtime_2.0.8.bb runs do_configure, which fails, because configure can't find the compiler. (The specific error from config.log is: |
| 13:36.07 | bluelightning | stefan__: which version of the build system are you building with? |
| 13:36.13 | stefan__ | <PROTECTED> |
| 13:36.44 | stefan__ | I'm working with the 'daisy' branch. |
| 13:37.02 | stefan__ | should I retry with master ? |
| 13:38.09 | bluelightning | stefan__: no, I wouldn't expect much difference, and you're better off with daisy unless you need to be on the bleeding edge (and daisy is fairly new already) |
| 13:38.29 | stefan__ | but I'm also not sure why there would be a configure task involving a target compiler (where 'target' is not the OE target, but the host) |
| 13:38.39 | stefan__ | right, thought so. |
| 13:39.58 | RP | stefan__: Which SDKMACHINE is that with? |
| 13:40.28 | stefan__ | RP: x86_64-mingw32 |
| 13:40.45 | stefan__ | (I'm trying your meta-mingw layer...) |
| 13:40.52 | RP | stefan__: high BB_NUMBER_THREADS? |
| 13:41.13 | stefan__ | yeah, the default (which I always find too high) |
| 13:41.26 | stefan__ | is there a race condition involved ? |
| 13:41.56 | RP | stefan__: I'm wondering if there is a missing dependency. You could try "bitbake gcc-crosssdk-initial", "bitbake gcc-crosssdk" and then retry your original command |
| 13:42.02 | stefan__ | ("the default" == "BB_NUMBER_THREADS ?= "${@oe.utils.cpu_count()}"") |
| 13:43.31 | stefan__ | Actually, this is the second invocation. The first time I got lots of errors on the terminal which I failed to redirect into a file (errors during the sysroot setup due to header files not being found...) |
| 13:43.56 | stefan__ | Then I just restarted (with "&> log" appended), and got this new error I'm reporting here. |
| 13:45.22 | RP | stefan__: logs should be in tmp/logs/cooker FWIW |
| 13:46.59 | stefan__ | RP: so I tried running the steps individually as you suggested. The first (gcc-crosssdk-initial) was already completed. gcc-crosssdk then fails, with the same log as above. |
| 13:47.26 | RP | stefan__: DISTRO=poky? |
| 13:47.44 | stefan__ | yes |
| 13:48.08 | RP | stefan__: I'm just seeing if this will reproduce here |
| 13:48.24 | stefan__ | great, thanks. |
| 13:48.39 | RP | stefan__: it doesn't :( |
| 13:48.47 | stefan__ | darn |
| 13:49.24 | stefan__ | Well, "find . -name x86_64-pokysdk-mingw32-gcc" does find something. It just isn't in the PATH it seems. |
| 13:49.46 | *** join/#oe dany (~Thunderbi@sestofw01.enea.se) |
| 13:49.55 | RP | stefan__: does ls tmp/sysroots/x86_64-linux/usr/bin/x86_64-pokysdk-mingw32.gcc-crosssdk-initial/ show the gcc ? |
| 13:50.29 | stefan__ | yes, with prefix (x86_64-pokysdk-mingw32-gcc) |
| 13:51.24 | RP | stefan__: can you confirm that binary executes ok? |
| 13:51.32 | stefan__ | so that path should be in the env when configure is invoked ? |
| 13:51.38 | JaMa | koen: I would prefer to keep B!=S in qmake5, because when I was initially working on meta-qt5 I was hit by incorectly "pre-configured" B many times |
| 13:51.40 | RP | stefan__: I think so |
| 13:51.55 | stefan__ | it does execute fine (with the usual error message "...no input files" |
| 13:52.35 | RP | stefan__: You are using the daisy branch of meta-mingw? |
| 13:52.48 | stefan__ | I don't think so. |
| 13:53.00 | stefan__ | just the default (master ?) |
| 13:53.07 | RP | stefan__: aha, use daisy |
| 13:53.25 | stefan__ | switches and retries |
| 13:55.04 | stefan__ | do I need to make clean ? Just rebuilding yields the same errors. |
| 13:56.20 | RP | stefan__: just to be clear, you now have daisy main metadata and meta-mingw daisy ? |
| 13:56.25 | stefan__ | oups, pilot error. ('daisy' != 'origin/daisy') |
| 13:56.35 | RP | stefan__: I'd have thought it would rebuilt things... |
| 13:57.21 | stefan__ | still no joy. |
| 14:02.51 | RP | stefan__: well, the mingw-w64-runtime recipe does: |
| 14:02.51 | RP | STAGINGCC_class-nativesdk = "gcc-crosssdk-initial" |
| 14:02.51 | RP | PATH_prepend = "${STAGING_BINDIR_TOOLCHAIN}.${STAGINGCC}:" |
| 14:03.08 | RP | stefan__: so somehow its not seeing that or not having the right effect :/ |
| 14:04.08 | stefan__ | tries to debug that |
| 14:12.13 | RP | stefan__: bitbake nativesdk-mingw-w64-runtime -e | grep PATH= and similar might help |
| 14:12.58 | *** join/#oe kgilmer (~kgilmer@2604:2000:84c7:2d01:1173:4483:1d86:3184) |
| 14:13.26 | stefan__ | yeah, I'm looking at something similar. What does "${STAGINGCC}" expand to ? |
| 14:13.58 | stefan__ | oups, just a few lines up. :-) |
| 14:15.09 | stefan__ | hmm, I can't see any "gcc-cross-initial" in PATH, so that PATH_prepend doesn't seem to have happened. |
| 14:15.50 | stefan__ | is there a way to inject print commands right into .bb files ? |
| 14:17.46 | RP | stefan__: you're looking for gcc-crosssdk-initial |
| 14:18.04 | RP | which should be the value STAGINGCC will have taken |
| 14:19.46 | stefan__ | that isn't in PATH either. |
| 14:25.34 | stefan__ | is there a way to debug (i.e., trace) all this variable assignment and expansion business ? |
| 14:29.28 | nerdboy | moin |
| 14:29.55 | nerdboy | waves at RP |
| 14:30.03 | RP | hi nerdboy |
| 14:30.32 | RP | stefan__: if you look at the full output of -e, that is pretty much the method available |
| 14:30.56 | RP | stefan__: there should be a variable history in there |
| 14:33.49 | nerdboy | still not sure why gentoo amd64 multilib and libpseudo don't get along... |
| 14:34.29 | *** part/#oe msm` (~msm@cpe-72-182-100-192.austin.res.rr.com) |
| 14:40.47 | koen | JaMa: I'll see if I can make target qmake work with B!=S, if that fails I guess I can make a qmake_5.x.bb recipe |
| 14:40.48 | *** join/#oe adelcast (~adelcast@130.164.62.249) |
| 14:43.29 | stefan__ | RP: what is the best target to use if I only want to build the SDK, i.e. if I'm not interested in the target image ? |
| 14:43.40 | stefan__ | sorry for the 'target' overload. :-) |
| 14:44.12 | RP | stefan__: gcc-cross-canadian |
| 14:44.35 | RP | suspects you'll not get around the error that way |
| 14:44.45 | stefan__ | right, that was a separate question |
| 14:45.02 | RP | stefan__: if you pastebin the complete failure including the header I can take a look and see if I can spot anything obvious |
| 14:45.20 | stefan__ | what do you mean by "header" ? |
| 14:46.21 | RP | stefan__: the bit which says "Build Configuration:" |
| 14:47.06 | stefan__ | ok, so the full output of "bitbake gcc-crosssdk " ? |
| 14:49.34 | stefan__ | RP: http://pastebin.com/ecnjrriY |
| 14:51.19 | *** part/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 14:51.20 | *** join/#oe nerdboy (~sarnold@gentoo/developer/nerdboy) |
| 14:51.33 | RP | stefan__: that is quite a different error to the one you pasted earlier :( |
| 14:51.36 | nerdboy | stefan__: can you also post the config.log stuff? |
| 14:51.46 | ant_work | RP: hi, I didn't pay attention..are we building with gcc 4.9 already? |
| 14:51.49 | RP | stefan__: we need to see the contents of config.log |
| 14:51.57 | RP | ant_work: not by default quite yet |
| 14:52.03 | RP | ant_work: but its there |
| 14:54.14 | stefan__ | RP, nerdboy: http://pastebin.com/6qzD9J0y |
| 14:54.20 | *** join/#oe anarsoul (~anarsoul@178.124.194.242) |
| 14:54.35 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 14:54.39 | RP | stefan__: stdio.h: No such file or directory - header issues |
| 14:54.50 | RP | stefan__: can you clean tmp and start again now you have the right branches |
| 14:54.55 | RP | stefan__: we need to rule that out |
| 14:55.06 | ant_work | RP: just this knob? |
| 14:55.07 | ant_work | GCCVERSION ?= "4.8%" |
| 14:55.32 | nerdboy | error: no include path in which to search for limits.h |
| 14:55.49 | stefan__ | RP: do I need to blow away the entire tmp/ dir ? |
| 14:55.59 | *** join/#oe s3v3n62mm (~s3v3n62mm@p5DDC3668.dip0.t-ipconnect.de) |
| 14:56.34 | nerdboy | you can try the previous command with -c cleansstate |
| 14:56.56 | nerdboy | but might need to nuke the whole thing and rebuild... |
| 14:57.51 | RP | ant_work: yes |
| 14:57.55 | stefan__ | ok. This is going to take a while... |
| 14:58.14 | RP | stefan__: At this point I think you need to build something known good |
| 14:58.15 | ant_work | RP: ok, I'll have fun tonite |
| 14:58.59 | stefan__ | RP: yeah, right. Switching branches in the middle of a build isn't helpful. :-) |
| 15:00.34 | nerdboy | why do you have mixed paths? => /opt/poky/1.6/sysroots/x86_64-pokysdk-mingw32/usr/include |
| 15:00.38 | *** join/#oe Jafura (~Jean-Fran@ptr-178-50-75-192.dyn.mobistar.be) |
| 15:00.41 | nerdboy | that doesn't look right... |
| 15:01.26 | nerdboy | everything should be under /usr/local/OpenEmbedded/yocto/poky/build/tmp/... |
| 15:01.58 | nerdboy | stefan__: can you check your *.conf paths? |
| 15:03.15 | stefan__ | nerdboy: I definitely haven't added any "/opt/poky/..." paths anywhere. Where should I look ? |
| 15:03.33 | nerdboy | local.conf first i guess |
| 15:03.50 | stefan__ | that's clean. |
| 15:04.20 | nerdboy | then i don't get the /opt/poky part |
| 15:05.04 | *** join/#oe kgilmer_ (~kgilmer@65.209.23.146) |
| 15:05.34 | stefan__ | perhaps that's a prefix injected by meta-mingw ? |
| 15:05.43 | nerdboy | it's still early, but i'm pretty sure that should be /usr/local/OpenEmbedded/yocto/poky/build/tmp/sysroots/x86_64-nativesdk-mingw32-pokysdk-mingw32/usr/include |
| 15:05.58 | *** join/#oe Crofton|work (~balister@pool-108-44-91-50.ronkva.east.verizon.net) |
| 15:06.51 | nerdboy | goes to fire up the coffee |
| 15:15.59 | Crofton|work | vim fails |
| 15:16.08 | *** join/#oe kscherer_ (~kscherer@128.224.252.2) |
| 15:16.10 | Crofton|work | | touch: cannot touch 'auto/config.mk': No such file or directory |
| 15:16.27 | *** join/#oe fray (U2FsdGVkX1@gate.crashing.org) |
| 15:18.57 | Crofton|work | look sliek S != B issues |
| 15:19.29 | bencoh | meh |
| 15:19.30 | bencoh | :) |
| 15:19.48 | Crofton|work | fix it the wrong way or figure out the right way? |
| 15:19.51 | Crofton|work | that is the question |
| 15:28.19 | ant_work | anarsoul: should I take that version of the DMA patch or the revised one on LAKML ? |
| 15:28.49 | anarsoul | ant_work: well, take the version which I sent to you, it works |
| 15:28.57 | ant_work | ok, thx |
| 15:28.59 | Crofton|work | any advice on fixing this: http://pastebin.com/W71Srg7w |
| 15:29.04 | Crofton|work | fro S != B |
| 15:34.05 | *** join/#oe jonmasters (~jcm@edison.jonmasters.org) |
| 15:45.25 | nerdboy | Crofton|work: i tend to separate the autoconf stuff from the actual configure |
| 15:46.05 | Crofton|work | can you be more specific |
| 15:46.08 | nerdboy | had an issue not long ago where it only worked as a separate task, but in do_configure it failed |
| 15:46.13 | Crofton|work | I jsut hacked in the S's and B's :) |
| 15:46.25 | bencoh | :) |
| 15:47.05 | nerdboy | there seems to be some funkiness in how the autotools stuff works in do_configure |
| 15:47.24 | nerdboy | not the auto-expert |
| 15:47.58 | nerdboy | i just beat on it until i get tired or it does what i want... |
| 15:48.45 | stefan__ | RP, nerdboy: this time the build finished successfully. Yay ! :-) |
| 15:48.54 | RP | stefan__: great :) |
| 15:49.00 | nerdboy | good deal |
| 15:51.36 | kergoth | Crofton|work: aclocal and autoconf must run in ${S} sinc they write configure from configure.ac and aclocal.m4 from the other macros. oe_runconf should run in ${B}. |
| 15:52.06 | kergoth | Crofton|work: also, the way that hardcodes those things rathe rthan using autotools.bbclass is pretty gross :) |
| 15:52.17 | kergoth | (i realize you probably weren't the one that wrote that, but on general principle) |
| 15:52.17 | *** join/#oe kgilmer (~kgilmer@65.209.23.146) |
| 15:52.17 | Crofton|work | yeah |
| 15:52.50 | kergoth | so you'd probably want to cd ${S}, do your autoconf stuff, then cd back to ${B} to do the configure |
| 15:53.02 | kergoth | afaik thats a pretty common pattern in do_configures like this one |
| 15:53.03 | Crofton|work | what is the default for do_configure? |
| 15:53.11 | kergoth | read autotools.bbclass :) |
| 15:53.14 | Crofton|work | trying with the mess commented out |
| 15:53.35 | kergoth | ah, the whole do_configure task commented? worth a shot, certainly |
| 15:53.36 | stefan__ | RP: I do have a few followup questions. Since I have just built a mingw compiler (with sysroot), what would be the most appropriate package to use for this so I can install it on Windows ? Right now I only have rpms. |
| 15:53.38 | Crofton|work | | NOTE: make DESTDIR=/home/balister/src/oe-core/build/tmp-eglibc/work/armv7at2hf-vfp-neon-oe-linux-gnueabi/vim/7.4.258-r0/image install |
| 15:53.39 | Crofton|work | | make: *** No rule to make target `install'. Stop. |
| 15:54.06 | stefan__ | s/package/package format/ |
| 15:54.21 | nerdboy | Crofton|work: here's the example i was thinking of: https://github.com/openembedded/meta-oe/commit/b306212c8919a8638d5e97acfd6262bcbd3401ed |
| 15:54.45 | RP | stefan__: didn't it build a zip? |
| 15:55.04 | nerdboy | Crofton|work: also what kergoth said... |
| 15:55.06 | RP | stefan__: tmp/deploy/sdk/ ? |
| 15:55.25 | stefan__ | RP: there is no sdk/ in tmp/deploy/, only rpm/ and licenses/ |
| 15:55.34 | RP | stefan__: what did you build? |
| 15:55.44 | RP | stefan__: bitbake meta-toolchain is probably what you want |
| 15:55.58 | kergoth | nerdboy: fyi, i see a problem in that commit. it relies on bitbake's hardcoded built in 'dirs' flag. when you create a new task and assume it runs from somewhere in particular, sit should really have do_src_prepare[dirs] = "${S}" :) |
| 15:56.04 | kergoth | s/sit/it/ |
| 15:56.33 | kergoth | basically in general no one should assume that they know where a new task will run from, just to keep people aware |
| 15:56.45 | kergoth | we want to kill bitbake's dirs flag default at some point, so it's something to be aware of |
| 15:56.57 | nerdboy | good to know... |
| 15:57.24 | nerdboy | heh, gentoo went the other way a while back |
| 15:57.43 | kergoth | our problem is we want to retain the bitbake vs oe separation, and right now bitbake has knowledge of ${B} |
| 15:57.44 | stefan__ | RP: OK, running that now. The second question is how I can add packages to be included in the SDK. |
| 15:57.45 | kergoth | Bad Thing(tm) |
| 15:58.01 | stefan__ | (In fact, I would assume that question to be answered in some online document, I just didn't find it.) |
| 15:58.18 | nerdboy | kergoth: curse you for caring about coupling and information hiding |
| 15:58.36 | *** join/#oe NightMonkey (~NightrMon@pdpc/supporter/professional/nightmonkey) |
| 15:58.41 | kergoth | nerdboy: you wouldn't know I care about such things if were to read the old bitbake code... but that was written a long time ago :) |
| 15:58.54 | RP | stefan__: the same way you would with the linux version of the sdk. bitbake <image> -c populate_sdk will build an SDK that corresponds to the image's contents |
| 15:59.21 | nerdboy | damn, i really don't sound much like a geophysics guy anymore... |
| 15:59.55 | stefan__ | RP: right. But how do I add packages, i.e. how do I indicate in the recipe of a package that it is going to be part of the SDK, not just the target ? |
| 16:00.12 | stefan__ | (I'm talking about a tool, not a library) |
| 16:01.42 | nerdboy | the "normal" way would be the image recipe |
| 16:02.20 | nerdboy | ie, bitbake image_name -c do_populate_sdk |
| 16:02.52 | *** join/#oe lumag (~lumag@nat-min.mentorg.com) |
| 16:03.24 | kergoth | stefan__: target recipes can be freely included in the sdk's target sysroot. if it's a build tool, you need a nativesdk variant (add nativesdk to BBCLASSEXTEND), then you could add nativesdk-yourrecipe to the host syroot of the sdk |
| 16:04.41 | stefan__ | isn't sure he can semantically analyze that yet, but will store that info for later use. :-) |
| 16:04.42 | kergoth | nerdboy: that commit reminds me, I think it'd be cool to provide, in our classes, a pre-configure "prepare the source tree" task, which is only run if it's defined. then recipes could just define the function and it'd be used, no messing with adding tasks |
| 16:04.57 | nerdboy | in the classic setup i "inherited" the previous guy had made his own meta-toolchain tasks and added package names |
| 16:05.22 | nerdboy | kergoth: i like that |
| 16:05.52 | kergoth | it seems to be a common pattern, and it'd make our recipes at least slightly more declarative |
| 16:05.54 | nerdboy | seem like src prep and configure need some real separation |
| 16:07.37 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 16:08.25 | *** join/#oe JaMa (~martin@ip-89-176-104-3.net.upcbroadband.cz) |
| 16:28.08 | *** join/#oe kroon (~kroon@89-253-118-72.customers.ownit.se) |
| 17:14.51 | *** join/#oe anarsoul (~anarsoul@80.249.95.37) |
| 17:22.15 | *** join/#oe dos1 (~dos@unaffiliated/dos1) |
| 17:28.52 | stefan__ | RP: OK, I got much further, but still an error: "ERROR: nativesdk-packagegroup-sdk-host not found in the base feeds (x86_64-nativesdk-mingw32 noarch any all)." |
| 17:29.20 | *** join/#oe JBD1986 (~JBD1986@8.20.30.249) |
| 17:29.25 | stefan__ | (in the meta-toolchain do_populate_sdk task) |
| 17:29.53 | JBD1986 | all, I'm having an issue connecting to WPA-enterprise networks when switching from dylan to dora branches of yocto build system. My issue is similar to: http://shr-project.org/trac/ticket/2107 . I was wondering if anyone has seen this issue before, and if there was an actual solution that allows CONFIG_WPS to be enabled? |
| 17:34.26 | JBD1986 | morphis, I believe the commit that introduced this came from you https://github.com/openembedded/oe-core/commit/2e4d939b6a0061eec22b859a827dedda51b299ba |
| 17:35.07 | JBD1986 | morphis, do you have any idea on some dependencies that may be required with this change? |
| 17:35.14 | pompomJuice | how do I make a user on angstrom have root access? |
| 17:37.28 | Crofton|work | you mean install sudo? |
| 17:38.33 | Crofton|work | why is -natine appended and nativesdk- prepended? to confuse me? |
| 17:41.13 | morphis | JBD1986: what are you using on top of wpa-supplicant to connect to the network? |
| 17:42.02 | morphis | JBD1986: if only wpa-supplicant maybe ask on the wpa-supplicant mailinglist |
| 17:42.07 | morphis | didn't saw a problem with it yet |
| 17:46.17 | JBD1986 | morphis, we're using connman 1.21 |
| 17:46.33 | morphis | JBD1986: maybe also ask in #connman |
| 17:46.52 | JBD1986 | I already tried connman, they referred me to wpa_supplicant lol |
| 17:47.27 | stefan__ | kergoth: any idea about the above error ? |
| 17:47.35 | JBD1986 | the issue is definitely resolved by removing CONFIG_WPS from wpa_supplicant |
| 17:50.19 | kergoth | no idea |
| 17:53.33 | morphis | JBD1986: but removing CONFIG_WPS isn't a real solution |
| 17:53.44 | morphis | so there is a problem somewhere inside the stack |
| 17:54.04 | morphis | ask in #connman I am sure they will help you |
| 17:55.13 | *** join/#oe rob_w (~rob@unaffiliated/rob-w/x-1112029) |
| 18:00.27 | *** join/#oe woglinde (~henning@g225125074.adsl.alicedsl.de) |
| 18:28.09 | *** join/#oe nitink (nitink@nat/intel/x-bqzyrkqbyiutitoa) |
| 18:28.55 | *** join/#oe eFfeM (~frans@c73189.upc-c.chello.nl) |
| 18:40.14 | *** join/#oe woglinde (~henning@g226163244.adsl.alicedsl.de) |
| 18:46.46 | *** join/#oe flo_lap (~fuchs@sign-4db60829.pool.mediaWays.net) |
| 18:46.47 | *** join/#oe flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 18:49.22 | kergoth | experiments with automatic set/unset of noexec flags based on conditions |
| 18:49.28 | *** join/#oe ldnunes (~ldnunes_@177.194.208.225) |
| 18:54.16 | nerdboy | scrounges a power brick for the udoo thing |
| 19:28.02 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |
| 19:36.50 | *** join/#oe _chase_ (~a0271661@nat/ti/x-ocdloltklbiczxsm) |
| 20:02.42 | *** join/#oe Jefro (~jefro@64.39.121.255) |
| 20:25.04 | *** join/#oe Vutral (~ss@mirbsd/special/Vutral) |
| 20:28.35 | *** join/#oe ant_home (~andrea@host253-196-dynamic.45-79-r.retail.telecomitalia.it) |
| 20:31.00 | *** join/#oe aloril (~aloril@dsl-tkubrasgw2-54f80b-12.dhcp.inet.fi) |
| 20:57.42 | *** join/#oe s3v3n62mm (~s3v3n62mm@p5DDC3668.dip0.t-ipconnect.de) |
| 21:01.59 | *** join/#oe Jefro (~jefro@64.39.121.255) |
| 21:06.09 | *** join/#oe Shawn286 (~Shawn@unaffiliated/shawn156) |
| 21:08.58 | *** join/#oe nitink1 (nitink@nat/intel/x-lnkvqjwrcdxzvigo) |
| 21:45.48 | *** join/#oe nitink (~nitink@134.134.139.74) |
| 21:50.42 | *** join/#oe kroon (~kroon@89-253-118-72.customers.ownit.se) |
| 21:54.10 | *** join/#oe Shawn287 (~Shawn@unaffiliated/shawn156) |
| 21:55.52 | *** join/#oe hillct (~hillct@cpe-071-070-219-043.nc.res.rr.com) |
| 22:18.20 | *** join/#oe sr105|away (~sr105@65349hfc19.tampabay.res.rr.com) |