Wednesday, 2013-08-21

*** tlwoerner_ <tlwoerner_!~tlwoerner@linaro/tlwoerner> has quit IRC00:02
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC00:04
*** _julian <_julian!> has joined #yocto00:25
*** _julian_ <_julian_!> has quit IRC00:26
*** nitink <nitink!~nitink@> has joined #yocto00:43
*** davest <davest!Adium@nat/intel/x-kgltwapxlxccutav> has quit IRC00:45
*** scot__ <scot__!~scot@> has quit IRC00:49
*** nitink <nitink!~nitink@> has quit IRC00:56
*** nitink <nitink!nitink@nat/intel/x-umdtetjwfjcbnbxk> has joined #yocto01:07
*** munch <munch!> has quit IRC01:10
*** nitink <nitink!nitink@nat/intel/x-umdtetjwfjcbnbxk> has quit IRC01:13
*** Squix <Squix!> has joined #yocto01:20
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto01:27
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC01:30
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto01:31
-YoctoAutoBuilder- build #236 of nightly-oecore is complete: Failure [failed Building Toolchain Images] Build details are at
*** mulhern <mulhern!> has quit IRC01:47
*** seebs <seebs!> has quit IRC01:56
*** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto02:01
*** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC02:04
*** seebs <seebs!> has joined #yocto02:08
-YoctoAutoBuilder- build #256 of nightly-world is complete: Success [build successful] Build details are at
-YoctoAutoBuilder- build #261 of nightly-x86 is complete: Success [build successful] Build details are at
*** behanw <behanw!> has quit IRC02:34
*** Jefro <Jefro!> has quit IRC02:36
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC02:36
*** shoragan <shoragan!~jlu@2001:6f8:1178:2:219:99ff:fe56:8d7> has joined #yocto02:37
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto02:37
*** nitink <nitink!~nitink@> has joined #yocto02:47
*** darknighte is now known as darknighte_znc02:57
*** nitink <nitink!~nitink@> has quit IRC03:02
*** nitink <nitink!~nitink@> has joined #yocto03:13
*** tanamo <tanamo!cb7dac02@gateway/web/freenode/ip.> has joined #yocto03:22
*** andyross <andyross!> has joined #yocto03:24
*** smartin_ <smartin_!> has joined #yocto03:33
*** smartin <smartin!> has quit IRC03:34
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC04:11
*** smartin <smartin!> has joined #yocto04:23
*** smartin_ <smartin_!> has quit IRC04:24
*** andyross <andyross!> has quit IRC04:31
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto04:50
*** smartin_ <smartin_!> has joined #yocto05:39
*** smartin <smartin!> has quit IRC05:40
*** pidge <pidge!> has quit IRC05:47
*** zeeblex <zeeblex!apalalax@nat/intel/x-ldzbfwpwiutblirx> has joined #yocto05:48
*** tor <tor!> has joined #yocto05:48
*** amarsman <amarsman!> has joined #yocto05:55
*** nitink1 <nitink1!nitink@nat/intel/x-huzcqnzkmcxntctu> has joined #yocto05:59
*** nitink <nitink!~nitink@> has quit IRC05:59
*** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto06:03
*** zecke <zecke!> has joined #yocto06:04
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto06:04
*** nitink <nitink!nitink@nat/intel/x-ihyzgftjnreksfss> has joined #yocto06:04
*** nitink1 <nitink1!nitink@nat/intel/x-huzcqnzkmcxntctu> has quit IRC06:04
*** mihai <mihai!~mihai@> has joined #yocto06:17
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:34
*** silviof1 is now known as silviof06:43
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:47
-YoctoAutoBuilder- build #257 of nightly-world is complete: Failure [failed Building Images] Build details are at
-YoctoAutoBuilder- build #138 of nightly-qa-systemd is complete: Success [build successful] Build details are at
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC07:09
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto07:10
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto07:17
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto07:17
*** ka6sox <ka6sox!~ka6sox@nasadmin/ka6sox> has quit IRC07:19
*** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #yocto07:22
*** elmi82 <elmi82!> has joined #yocto07:29
*** mike <mike!c2881242@gateway/web/freenode/ip.> has joined #yocto07:39
*** mike is now known as Guest3701207:39
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto07:40
lpapp -> why am I getting this gtk doc fetching issue, especially when I have this in the downloads folder, already?
erbolpapp: do you also have
lpapperbo: yeah07:45
erboand no error about the checksum being wrong?07:45
ndecthis .tar.gz is the 'tree' archive, not the package archive required to build the recipe, i believe.07:46
ndecthe fetcher first clone the tree and create a local archive, then it creates the package tarball from that.07:46
lpapperbo: I do not see any checksum errors.07:46
ndecnext build, it fetches git updates (if any), recreate the tree tarball.07:46
ndecdo you have the tarball for that specific commit ID?07:47
lpappwhat is a tree archive07:47
erbondec: ok, so you need the git2/ and git2/git:// as well?07:47
erbominus the "git://"07:47
lpapppackage tarball + the .git stuff ?07:47
ndeclpapp: see my first comments above.07:47
lpappndec: I have not understood that.07:48
ndecbitbake keeps a local copy of the entire git tree.07:48
ndecit then create the recipe tarball from that copy.07:48
lpappis there an option for local.conf to override this behavior ?07:48
lpappotherwise there is not much point in checking stuff out, especially which comes from git ...07:49
lpappI would like it not to do any update at all.07:49
lpappotherwise we would need to rely on upstream stuff.07:49
lpappwhich can fail anytime blocking us.07:49
ndechmm. let me check. now i am a little confused.07:50
lpappso what downloads we check in, should be the "final" until further notification.07:50
lpappand and and ... poky releases should not use git anyway?07:50
lpappor a fixed tag ?07:50
*** Saur <Saur!pkj@nat/axis/x-wusqdwgeexlufqgj> has quit IRC07:50
*** RP <RP!> has quit IRC07:51
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:51
erbolpapp: I guess that if you leave the download folder untouched it should need to fetch the git on rebuilds, unless you use the git AUTOREV feature07:51
lpapperbo: I am just using upstream poky ...07:51
lpappit should be reliable.07:51
*** florian_kc is now known as florian07:51
lpappand users should be able to avoid the dependency on upstream repositories ...07:51
*** rikroled <rikroled!> has joined #yocto07:52
lpappand AFAIK poky does not like AUTOREV for stuff.07:52
erbolpapp: I agree, when it's fetched it shouldn't need access to the git until someone touches the build recipe to update SRCREV07:52
ndeclpapp: it should fetch only if the commit ID (srcrev) has changed.07:52
lpapp(still no answer on the mailing list though why gtk-doc stuff is needed at all, especially from git!)07:52
lpappwell, how can I solve this?07:52
lpappit has been blocking our CI for a while.07:53
erbocan you clone the gtk-doc-stub manually on that machine?07:54
erboI could clone it ok from here07:54
lpappit does not matter.07:54
lpappI mean: 1) I do not have access 2) We should not fetch it07:54
erbono you shouldn't, but now something has gone wrong..07:55
erbolpapp: is the error repeatable if you remove the gtk-doc-stub stuff from download?07:55
lpappyeah, so I need to find a way to disable the fetch.07:55
lpapperbo: no idea... that would require a commit07:56
lpappI rather avoid any commit unless if necessary.07:56
erbobitbake -c cleansstate gtk-doc-stub ?07:56
*** slaine <slaine!~slaine@> has joined #yocto07:56
lpapperbo: it is only failing on the CI07:56
lpapperbo: it had not failed locally before I committed.07:57
lpappand I have no access to the CI, etc.07:58
*** smartin <smartin!> has joined #yocto07:58
erbolpapp: for the future, maybe something like this might help you. (the Q: How do I create my own source download mirror  part)07:59
lpappand for now?07:59
*** smartin_ <smartin_!> has quit IRC07:59
erbolpapp: I don't know, just trying to help out with what I can08:00
*** belen <belen!~Adium@> has joined #yocto08:00
*** tonghuix <tonghuix!~tonghuix@> has joined #yocto08:00
lpappthanks.. I am just trying to find a workaround now not to block other people...08:01
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC08:02
erbolpapp: An ugly workaround to get going might be to create you own tarball + a bbappend that points to that instead of the upstream git08:02
erbobut it's not nice, so I guess it depends on how bad you need it working right now08:03
*** smartin_ <smartin_!> has joined #yocto08:06
lpapperbo: very bad. :D08:08
*** smartin <smartin!> has quit IRC08:09
lpapperbo: for the local source mirror, do we need more than a webserver point to a folder containing those, and mapped to a local url?08:10
*** RP <RP!> has joined #yocto08:10
*** tomz2 <tomz2!> has quit IRC08:11
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC08:11
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has quit IRC08:11
*** levi <levi!> has quit IRC08:11
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC08:11
*** tlwoerner <tlwoerner!> has joined #yocto08:12
*** JimBaxter <JimBaxter!> has joined #yocto08:12
*** tlwoerner <tlwoerner!> has quit IRC08:12
*** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has joined #yocto08:12
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto08:13
erbolpapp: I've never used it myself so I don't really know, but my understandning is that you either host them remote using a webserver or a local dir using a file:/// url in SOURCE_MIRROR_URL08:13
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto08:14
lpapperbo: uh, oh.08:14
*** tomz <tomz!> has joined #yocto08:14
lpapplocal will not make it work on the CI and the dev machines.08:15
lpappwebserver looks more reasonable to me.08:15
*** tomz is now known as Guest4918908:15
*** smartin_ is now known as smartin08:15
lpappoh, actually I am wrong.08:15
lpappyou can put it somewhere in the repository, too, and then everyone has that set.08:15
lpappbut not sure if it is a good practice to check so much stuff into a repository rather than just scp'ing to somewhere.08:16
erbono, probably better scp and serve over http08:16
lpappthe documentation could shed a bit more light. :)08:16
lpapperbo: yeah, but that means devs need to have access to the server.08:16
lpapppretty much all of them.08:16
lpapphmm, actually nope if only one is responsible for updating poky.08:17
*** tonghuix <tonghuix!~tonghuix@> has left #yocto08:17
*** Daemon404 <Daemon404!> has joined #yocto08:18
*** JimBaxter <JimBaxter!> has quit IRC08:19
*** JimBaxter <JimBaxter!> has joined #yocto08:24
ndeclpapp: well, sorry about the confusion... i checked, and indeed with the git fetcher there is no tarball create the 'unpack' is directly done from the local git clone using git checkout.08:25
ndecthat still doesn't explain your problem. but wanted to clarify08:26
*** smartin_ <smartin_!> has joined #yocto08:26
lpappok, thanks. So what is causing the issue then?08:26
ndecit's quite confusing, since git and svn fetcher don't behave the same way. with svn, it would create a tarball package_<revision>.tar.gz, in downloads, then it would just untar it in WORKDIR.08:27
ndeclpapp: not yet ;-)08:27
*** smartin <smartin!> has quit IRC08:27
lpappnot yet what08:27
*** mitz <mitz!> has joined #yocto08:28
*** sameo <sameo!~samuel@> has joined #yocto08:28
ndeclpapp: do you have access to downloads folder?08:28
ndecand can run cmd?08:28
ndeclooking at the code, my understanding is that the fetcher should 'fetch' only if the required commit is not yet in the local clone copy.08:29
lpappndec: server or local?08:29
ndecwhere you get the failure08:29
lpappwha cmd08:30
ndeclpapp: so when using git in SRC_URI, the fetcher will clone the git tree in downloads/git2/<git url>08:30
ndecthen to get the source in tmp/work/<package/... it would run a git checkout from downloads/git2/<xxx>08:31
*** honschu_ <honschu_!> has joined #yocto08:31
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto08:31
*** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC08:31
ndeccan you check in downloads/git2/ if you have the required commit (SRCREV)?08:32
ndeclpapp: to check if a commit exist, bitbake will do " git  log --pretty=oneline -n 1 <commit>"08:34
*** Squix <Squix!> has quit IRC08:40
lpappndec: I guess that is fine locally, too, then as the same is on the server due to the check in.08:42
ndeclpapp: i don't get that08:42
*** jeremiah <jeremiah!> has joined #yocto08:44
jeremiahI have some questions about cross-posting to the lists, typical procedural questions but I don't want to get flamed. :-)08:44
jeremiahI would like to cross-post to meta-ti and meta-ivi, is this considered an anti-pattern. TIA!08:45
lpappndec: downloads/git2/ is a folder.08:46
-YoctoAutoBuilder- build #256 of nightly-x86-64 is complete: Failure [failed Running Sanity Tests] Build details are at
lpappndec: so what did you mean by "if you have the required commit (SRCREV)"?08:47
ndeclpapp: to get the source to build the recipe, when using git, you need to have a git clone in download. so you have to be able to fetch that.08:48
ndecthe first time.08:48
lpappndec: I am not sure what you ask me to do.08:48
ndecthen when you clean/rebuild, bitbake won't fetch again, if the SRCREV (e.g. commit ID) hasn't changed.08:48
lpappas I said before, it is a folder, a git repository in fact.08:49
lpappit is not a bitbake recipe, whatsoever.08:49
lpappaccordingly, it has no SRCREV in.08:49
lpappwhich makes me confused why you are talking about SRCREV inside a git repository.08:49
ndecgtk-doc-stub fetches its sources from a git tree, according to SRC_URI in the .bb file.08:50
ndecthe .bb also specifies which version of the tree in the git it uses. that's SRCREV.08:50
*** smartin_ is now known as smartin08:51
ndecto get you the source, bitbake will clone (git clone) SRC_URI tree in downloads/git208:51
ndecthen it will checkout the SRVREV commit from that 'local' clone into $WORKDIR.08:51
lpappso what you are basically asking is to check the SRVREV in the gtk-doc-stub bitbake recipe08:51
lpappand see if that presents in the gtk stub doc build folder.08:51
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto08:52
ndecwell, based on your error, you must not even have a build folder yet for gtk-doc-stub.08:52
ndecsince it failed in the fetch.08:52
lpappno, I mean download08:53
ndeclpapp: do you have downloads/git2/
lpappyes, see above.08:53
ndecand do you have the commit mentioned in the .bb in that clone.08:53
erenmorning all08:55
lpappndec: SRCREV = "3dfd0a09de696ec8c544762747f8a0f77153622e"08:55
lpappgit show 3dfd0a09de696ec8c544762747f8a0f77153622e08:55
lpappfatal: bad object 3dfd0a09de696ec8c544762747f8a0f77153622e08:55
*** sgw_ <sgw_!> has quit IRC08:55
ndecok that explains why it tries to fetch from network at least.08:56
lpappwhy does it ?08:56
ndecbecause the 'requested' commit id does not exist in the local clone, the local clone needs to be updated.08:56
lpappwhy does it contain a non-existing SRCREV anyway?08:56
*** another_andy <another_andy!> has quit IRC08:56
lpappwhen it is cloning an existing that should be present locally, yeah?08:56
*** ScriptRipper1 <ScriptRipper1!> has quit IRC08:57
ndecit might be an old clone.08:57
ndecthat was clone before the object was pushed.08:57
*** rikroled <rikroled!> has quit IRC08:57
rburtongtk-doc-stub hasn't been touched for ages, so i'd be curious to see what head is in that clone08:57
*** another_andy <another_andy!> has joined #yocto08:57
erbothe gtk-doc-stub recipe hasn't been touched since 2012-07-28 :/08:57
ndeclpapp: in my case, it exists: $ git log --oneline -1 3dfd0a09de696ec8c544762747f8a0f7715362208:57
ndec3dfd0a0 Import introspection stub machinery too08:57
*** ericben <ericben!> has quit IRC08:58
lpappthat folder is actually in our git tree08:58
lpappso git show will get the wrong stuff08:58
rburtonlpapp: aah08:58
lpapphow can I get the local git stuff?08:58
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC08:58
lpappi.e. nested git repository.08:58
ndeci don't think you can have download managed as a git tree, since bitbake relies on being able to run git commands too.08:58
*** ericben <ericben!> has joined #yocto08:58
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto08:58
JaMasomeone seeing gcc-cross-initial failures since last oe-core upgrade? | /OE/oe-core/tmp-eglibc/work-shared/gcc-4.8.1-r0/gcc-4.8.1/gcc/builtins.c:843:65: error: 'STACK_SAVEAREA_MODE' was not declared in this scope08:58
rburtonlpapp: its a bare clone, so maybe it can't auto-detect it08:59
*** rikroled <rikroled!~tbn@> has joined #yocto08:59
lpappndec: it is not the download managed as a git tree, but the whole poky.08:59
lpappndec: with our custom layer, etc.08:59
ndecis download inside that tree?09:00
lpappit is a perfectly valid use case to manage addition under git just like poky is managed under git.09:00
lpappyes, of course.09:00
lpappbuild/downloads is inside the poky root after all.09:00
rburtonlpapp: you can try "git --git-dir=. show" inside downloads/git2/
*** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto09:01
lpappgit --git-dir=. show 3dfd0a09de696ec8c544762747f8a0f77153622e09:01
rburtonthat should force it to consider the current directory as the git directory as the autodetect isn't working09:01
lpappfatal: Not a git repository: '.'09:01
lpappnot even with full path.09:02
rburtonthis is what i get09:02
rburtonross@melchett ~/Yocto/downloads/git209:02
rburton$ git show09:02
rburtoncommit 3dfd0a09de696ec8c544762747f8a0f77153622e09:02
lpappok, that is not working for me.09:02
rburtonso what you have there isn't actually a clone09:03
lpappit --version09:03
lpappgit version
ndecrburton: i don't think you can clone a git, inside another git that easily.09:03
*** ant_work <ant_work!> has joined #yocto09:03
lpapprburton: yes, true.09:03
rburtonndec: i suspect git will auto-ignore some files that are important09:03
lpapprburton: there is no .git/ whatsoever.09:04 $ ls09:04
lpappHEAD  config  description  hooks  info  objects  packed-refs09:04
ndecyes, it would auto ignore the entire .git ;-)09:04
rburtonndec: bare clones don't have .git/09:04
rburtonlpapp: $ la09:04
rburtonbranches  config  description  FETCH_HEAD  HEAD  hooks  info  objects  packed-refs  refs09:04
lpappyou mean ls -a?09:04
rburtonno branches, no refs09:04
lpappnothing more, I checked.09:04
lpapponly . and ..09:04
lpappbut how does --git-dir work for you then anyway?09:05
lpappyou have made a manual checkout or what?09:05
rburtonlpapp: you're missing the branches and refs directories09:05
rburtonso its only half a git clone you've got09:06
lpapprburton: half a git clone ?09:06
lpappbut why would that work locally, and not remotely ?09:06
ndecrburton: just did a quick try, it should work in fact. i could add a bare tree in another top level tree.09:06
rburtonlpapp: no idea. what i can tell you is that i've got more files in my working fetch of gtk-doc-stub than you have in your broken one09:07
*** smartin <smartin!> has quit IRC09:07
ndecrburton: argh. but when cloning that test tree, it removed the branches and heads dirs...09:07
ndecrefs and branches i meant.09:08
*** smartin <smartin!> has joined #yocto09:08
ndeclpapp: i think the short answer, is that git can't have 'bare tree' embedded inside a top level tree.09:09
ndecby making a top level tree with all the poky stuff, that breaks the internal behavior of the bitbake git fetcher which is expected to create git clone in downloads.09:09
lpappndec: looks like you guys would need to find a solution for this use case at some point ...09:10
lpappndec: also, are you sure git really does not support that?09:10
lpappndec: oh, and just for reference, the same way, denzil has just worked fine.09:11
*** sgw_ <sgw_!> has joined #yocto09:11
ndeci just tried, and was able to reproduce your issue.09:11
lpappndec: so what made poky break this09:11
ndecwith git i mean09:11
lpappdenzil has not used git fetcher?09:11
ndeci think the fetcher has changed indeed. to allow the WORKDIR to be a 'git' tree.09:12
lpappmeh, bah, doh, gosh, uh, oh, huh, what, ok. :)09:12
lpappso it is yet another regression.09:12
lpappany quick workaround?09:12
lpappor the people can only be unblocked by series investment for dylan?09:13
lpappit is very painful to update two releases ahead apparently.09:14
lpappI think the migration path should be done smoother.09:14
lpappI had a bunch of issues already, and then this again.09:14
rburtonlpapp: i'll repeat my advice from a few weeks ago - putting downloads/ into git will really hurt you, even if it worked09:14
rburtonin six months time you'll have a *giant* git repository09:14
lpapprburton: 621 MB09:15
lpappon a few TB server.09:15
lpapp>>> 621/1000000009:15
lpappjust with 1 TB09:15
rburtonlpapp: for every client who wants to clone that repo09:15
rburtonand fwiw, my downloads/ is 22G09:16
-YoctoAutoBuilder- build #258 of nightly-arm is complete: Success [build successful] Build details are at
rburtoni really wouldn't want that directory to be in the same git repo as my layer09:16
lpappright, so >>> 621/50000009:16
lpapp500 GB locally.09:16
lpapp(on one disk, does not count the other)09:16
ndeclooking at diffs between dylan and denzil, i have some doubts it used to work with denzil... that code hasn't chnaged.09:17
lpapprburton: even the whole build dir, not the downloads, is much less here than 22 GB.09:17
lpappndec: we have never had any issues with this on denzil.09:17
lpappthen, maybe the previous suggestion is not valid about this not supposed to work.09:18
lpappand the root cause may be something else.09:18
lpappbut it has definitely worked on denzil off-hand.09:18
ndeclpapp: it might depends on how you manage your download 'git tree' too.09:18
ndechow do you add/commit stuff in your tree.09:19
lpappdenzil: du -sh downloads/09:19
lpapp261M    downloads/09:19
lpappndec: not sure what you mean.09:19
lpapprburton: I am sure your download is not containing only image-core-minimal ...09:19
lpappperhaps some very hefty stuff even perhaps the result of more builds.09:19
ndecwhen a build is done, there are new files in downloads. so i guess you have to commit these files for the next build09:20
lpappndec: ?09:20
lpappndec: downloads were checked as is after the successful local build.09:20
lpappwithout any tinkering.09:21
*** Stygia <Stygia!> has joined #yocto09:21
*** jackmitchell <jackmitchell!> has quit IRC09:21
ndecyou should compare the checkout of your tree on the server. it is missing files, even before you run bitbake. i don't see how this can be a denzil vs dylan issue09:21
lpappI am not sure what you mean.09:22
ndecyour tree on your CI server is different from your local tree where you did your commit.09:22
lpappit is not missing any files.09:22
lpappit is the same as locally.09:22
lpappand local works just fine.09:22
ndeclocally you must have these 'refs' an branches folder which are missing on the server.09:22
ndecin downloads/git2/..09:22
lpappit is the local stuff not having it, and working fine.09:23
ndecbecause you don't start with a clean env, and the sources are from sstate?09:23
ndecor already unpacked09:23
lpappI always start with clean state.09:23
lpappespecially before checking in.09:23
lpappoh, btw, and the server seems to have branches and refs.09:24
lpappSRCREV is present in that bare clone.09:25
*** Daemon404 <Daemon404!> has quit IRC09:26
lpappperhaps I did some half-baked check in, I will double check again.09:26
lpappit is a mess when you need to use another machine with ssh to log in to be able to build Poky, and then you end up having few machines around, and you need to make sure everything is always sync'ed up09:27
lpappit would be a lot easier if stuff just worked out of the box on arch. ;)09:27
lpappoh, hmm, I actually have an idea what went haywire!09:30
lpappI got a push feedback from git about a few thousand files09:30
lpappit was a warning... maybe git cannot handle 4-5.000 files?09:30
lpappand several files were left out accordingly?09:30
lpappndec: git add that-gtk-doc-stuff-dir does not seem to add branches and refs.09:33
lpappis that a correct behavior? We do not have anything like that in .gitignore, whatsoever.09:34
ndeclpapp: i am sorry. need to get back to (my) work. i recommend you carefully check how 'sub' git are handled in your CI. if you need to understand what bitbake does with git, check out bitbake/lib/bb/fetcher/
ndecmy feeling is that your issue is related to download being in a git tree already.09:37
lpappactually the issue is this:09:37
lpappscp -r A.B.C.D:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/downloads/git2/ ./downloads/git2/
lpappwhich gives no result.09:38
lpappwhy is that?09:38
lpapp-> /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/downloads/git2/ presents on the server. Is it because it is an empty folder?09:38
lpappthen who cares about branches and refs if they are empty?09:38
lpappat least, branches is empty.09:39
lpappyeah, scp does not copy empty folders, which is really empty for gtk doc stub.09:40
lpappoh, git needs those for operate even if they are empty.09:41
lpappbut git add actually does not add empty folders to the repository.09:42
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto09:48
*** Net147 <Net147!> has joined #yocto09:49
-YoctoAutoBuilder- build #237 of nightly-oecore is complete: Success [build successful] Build details are at
*** mitz <mitz!> has quit IRC10:03
*** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto10:08
*** Saur <Saur!pkj@nat/axis/x-tgxbnipafcplcnzs> has joined #yocto10:09
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:09
lpapphmm, would the bare git clone be necessary also for local mirrors?10:10
lpappor there, we would only have the tarballs?10:10
StygiaHey, is anyone here monitoring the oe-develop mailing list/on the general development team? I made a patch commit, and I _think_ I did it right, but I would love for someone to say "Yup, that looks right" before I try and commit the rest of the recipes I wrote.10:13
lpappStygia: yes, a few people.10:14
Stygialpapp, Alright, I send a patch to the list today, 'libtaint-util-perl: added', would you care to check if it looks right? :) Once I"m sure I"m doing it right I have like 100 recipes I could push up.10:15
*** mitz <mitz!> has joined #yocto10:15
rburtonStygia: hm, what list was that sent to?10:17
rburtonStygia: is the list for most non-oe-core patches10:17
Stygiarburton, yes, I'm pretty sure this is where I send it.10:17
Stygiarburton, Ah wait, shit, I send it to core. Fuck me, just a sec10:18
Stygiarburton, Now I send it to openembedded-devel@10:18
* rburton looks at oe-core again10:18
Stygia.. sorry. I just execute things from my bash history too damn often. Usually it only bothers me and nobody else.10:19
Stygiarburton, I'm used to just being me and my boss, my mental routine isn't geared to think, my typo will affect other people.10:20
Stygiarburton, Anyway... If this looks right/is formatted properly/etc I'll be sending up a ton of patches soon.10:21
*** mitz <mitz!> has quit IRC10:22
rburtonStygia: feel free to pastebin the patch first if you want to get a quick review10:23
Stygiarburton, I did actually, bluelightening told me the patch itself looks right, but git send-email gave me some complaints about encoding so I put off actually pushing it to today (And today #git told me the server would decode the headers either way). So I am pretty sure it should be right.10:23
*** mitz <mitz!> has joined #yocto10:24
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto10:24
Stygiarburton, Just want to be sure I didn't screw it up somehow before I spam the mailing list with 50+ patches over a few days. :P10:24
Net147Stygia: are you subscribed to the mailing list?10:27
rburtonStygia: encoding warnings aren't generally a problem10:27
rburtonbut i suspect you're in the moderation queue10:27
*** jackmitchell <jackmitchell!> has joined #yocto10:28
Stygiarburton, I'm pretty sure I am.10:28
Stygiarburton, Quite possible. I have made a commit or two that was misformatted...10:28
Stygiarburton, But for reference this is the patch:
Net147Stygia: is your git author email you used when sending the patch the same as the email you subscribed with?10:29
rburtonStygia: looks good to me :)10:29
rburtonStygia: PATCHBOMB10:29
StygiaI'm pretty sure, yes, erp@movis.dk10:30
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC10:33
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto10:41
*** daBONDi_work <daBONDi_work!~david@> has joined #yocto10:59
daBONDi_workhi when i Define iamge_fstype as cpio.gz, will that be a rootfs? I want to make a system with only a kernel(vmlinuz) file an a gpio.gz file with rootfs and all stuff to boot the hole system in an tmpfs, so i can update the system with a new gpio.gz file while its running, is this possible? What Features i will need ?11:02
daBONDi_workcurrently i have a custom Image required from core-image-minimal with IMAGE_FSTYPES +=cpio.gz, but on bootprocess looks like in the cpio.gz gets not loaded, it tells me that failed to execute /init11:03
daBONDi_worki use follow lines in syslinux.cfg11:04
daBONDi_workKERNEL /vmlinuz11:04
daBONDi_workAPPEND initrd=/core-image-minimal-mrec-dev-iei-pv-d525-20130821103541.rootfs.cpio.gz rootfs=/dev/ram0 console=tty011:04
daBONDi_worksorry for asking prbly this dumb question, but iam quite a linux n00b =)11:05
StygiadaBONDi_work, I'm pretty sure cpio isn't a rootfs, I think you need the *.rootfs.tar.gz file11:06
*** mulhern <mulhern!> has joined #yocto11:06
daBONDi_workprbly i  need a initrd Image with rootfs Included, thats what iam reading, but don't know how to do that in an yocto bb11:07
*** abelloni <abelloni!> has quit IRC11:08
StygiadaBONDi_work, Initrd is an init ram fs, not a root fs as such.11:09
StygiadaBONDi_work, to boot just from the init ram fs, you need the cpio and initramfs files.11:10
*** abelloni <abelloni!> has joined #yocto11:10
StygiadaBONDi_work, Updating while running, though, I am not sure about. We use the initramfs ourselves, but only to decrypt our data partition and boot the actual OS...11:10
daBONDi_workso i need to make something like core-minimal-image-initramfs11:12
daBONDi_workand appanend in syslinux another initrd file11:12
daBONDi_workwith the rootfs.cpio11:12
StygiadaBONDi_work, Hmm. I'm not expert, so don't rely on just my saying so, but that does sound about right.11:13
ant_worksome bootloaders are supposed to be able to chain multiple initramfs11:13
daBONDi_workmy intention is to make a system booting into ram11:13
ant_workwhat will surely work is embedding a cpio in a first kernel and while booting the kernel add another initrd=11:14
ant_workI've tested it, 2 cpio stacked11:15
daBONDi_worklooks like grub can do it11:15
daBONDi_workbut prbly iam to dumb i need more learning on the linux boot process :-)11:15
StygiaI'm gonna add my vote as say ant_work is right here, that would work, it's exactly what we do to start up our temporary initrd.11:16
StygiaNot 100% if you can hotswap that, though, but still.11:16
daBONDi_workcurrently we using debirf for the system11:16
daBONDi_workit builds a debian system to run in ram11:16
daBONDi_workbut customization is a pain in the ass :-)11:17
daBONDi_workso i was hoping yocto can built that to, but with the superb bitbake engine11:17
ant_workif it can give any idea, see how we do for a linux-as-bootloader (kexec) specific initramfs inmplementation11:19
StygiadaBONDi_work, I'm not 100% _exactly_ how, but I'm pretty damn sure you can do that, yea.11:19
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC11:19
daBONDi_worki found the kexec thing also, prbly should look again and try to understand it completly :-)11:20
ant_workin that case kexecboot is the init process11:21
ant_workyou can customize as you want11:21
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC11:25
*** melonipoika <melonipoika!> has quit IRC11:27
Stygiarburton, How will I know if my patch gets accepted, I'll presumably see some emails on the list saying that such-and-such a patch was accepted?11:29
Stygiarburton, Probably a silly question, but I've never contributed anything to an open source project before, so.11:29
rburtonStygia: there's a changelog sent weekly, or just watch the repo11:29
rburtonwe don't do "thanks your patch has been merged" mails as that would be incredibly tiresome to send :(11:30
Stygiarburton, Hmm alright, fair enough. I suppose I"ll just go about spamming you with patches, then, and see at the end of the week.11:30
rburtonStygia: just checking but you're aware of the meta-perl layer that was discussed on oe-devel?11:30
* rburton can't recall who was in that thread11:31
*** belen <belen!~Adium@> has quit IRC11:31
*** belen <belen!Adium@nat/intel/x-krxslxacdtpmouom> has joined #yocto11:32
Stygiarburton, Yes.11:33
Stygiarburton, I am trying to commit these patches to meta-perl in oe-devel11:33
Stygiarburton, I made two commits there, for libcarp-perl and libtaint-util-perl11:34
Stygiarburton, in... meta-perl/recipes-perl/11:34
Stygiarburton, under meta-openembedded.11:34
rburtonmeta-perl lives! IT LIVES! MWHAHAHAHAHAHA.11:41
Stygiarburton, Hah.11:42
StygiaI'll make it live, whether it wants to or not.11:42
StygiaI have like 100+ recipes for CPAN modules... and I'm not gonna let them just sit and only be used by us. Too much damn effort went into this.11:42
StygiaPlus from the selfish perspective it looks great on a resume.11:43
* zibri plans to make heavy use of it for my personal projects :)11:43
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC11:43
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto11:44
StygiaOh fantastic. Do you need any of them urgently? I still need to clean up the naming and RDEPENDS properly, I'd prioritize anything someone was actually likely to use soonish.11:45
Stygiazibri, If it's on metacpan I probably have a recipe for it at this point... dependencies are intense there.11:45
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC11:45
zibrino, nothing right now. but thanks! i'll let you know :)11:45
*** _alex_kag_ <_alex_kag_!~alex_kag@> has joined #yocto11:45
zibriat least i'll double check so that i'm not duplicating your efforts!11:46
Stygiazibri, Oh yea, don't go making any cpan recipes anytime soon. :P I'm almost bound to have it at this point.11:46
Stygiazibri, Although I was lazy with DEPENDS so I'll have to clean up before I commit.11:46
*** _alex_kag_ <_alex_kag_!~alex_kag@> has quit IRC11:50
jeremiahperl -pe -i 's/.*/w00t!/' /etc/motd :D11:52
erbojeremiah: don't tell me you have a notification when someone mentions perl in a channel? :)11:53
*** Stygia <Stygia!> has left #yocto11:53
*** Stygia <Stygia!> has joined #yocto11:53
jeremiaherbo: hits erbo with the camel book11:53
Stygiajeremiah, Heh. I actually have that right here.11:54
StygiaFun story... the camel is actually scrapped off.11:54
jeremiahNow _that_ is heavy use11:54
StygiaBecause I bunked with muslims and its "Shirk" (polytheism) to pray in the same room as a picture of an animal.11:54
zibriembrace the camel11:54
erboI actually have a perl book with a camel on it.. I was reading it one day and it started making sense, then I realized I was holding it upside down :/11:54
jeremiahStygia: Ah, wow.11:54
StygiaSo... not the camel on my camel book has no face.11:54
StygiaLike an old painting of Muhammad, kinda hilarious.11:55
B4gderso, rather than moving the precious book you patched it? =)11:55
jeremiaherbo: I think you're thinking of the lama book11:55
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto11:56
lpapphi, do I need to define a do_compile function even though I would just do the regular make in a subfolder?11:56
StygiaB4gder, Yea it's just the cover, not like the picture of the camel matters at all.11:56
Stygialpapp, You should probably have the do_compile function doing that, it's what it's for11:56
lpappStygia: why? running "make" is pretty common.11:57
Stygialpapp, Well, the idea of using the recipes is to not have to do it manually.11:57
Stygialpapp, If you're gonna manually cd there and make, why use a recipe?11:57
zibribase.bbclass defines a simple oe_runmake11:57
lpappStygia: you are not following.11:57
Stygialpapp, Possible.11:57
lpappStygia: I do use a recipe, but why would everyone start adding the regular "make" for manual execution?11:58
zibridefines a simple do_compile calling oe_runmake*11:58
*** elmi82_ <elmi82_!> has joined #yocto11:58
*** elmi82 <elmi82!> has quit IRC11:58
lpappfor execution*11:58
*** elmi82 <elmi82!> has joined #yocto11:58
ant_worklpapp: simplest  do_compile () {12:00
ant_work        ${CC} ${CFLAGS} ${LDFLAGS} foo.c -o foo12:00
rburtonlpapp: have a look at the default do_compile in base.bbclass12:00
*** jeremiah <jeremiah!> has quit IRC12:01
*** smartin <smartin!> has quit IRC12:02
*** jeremiah <jeremiah!> has joined #yocto12:02
*** smartin <smartin!> has joined #yocto12:04
lpappant_work: as I said, it is about make, not ${CC}, i.e. we use Makefiles.12:05
lpapprburton: so basically I need to create a do_compile if you want something more advanced then make, like stepping into the src folder?12:06
rburtonlpapp: yeah, do_compile() { oe_runmake -C src}12:07
Stygialpapp, You should be able to set the WORKDIR variable for that. If I understand your question right, no, you can just require the proper class, instead of using do_compile and make, if all you want to do is 'make'.12:07
Stygiarburton, Couldn't he just set WORKDIR and import the maker class?12:07
Stygiaautotools/automake IIRC.12:08
rburtonStygia: presumably there's something in the top-level that's useful, even if its license files12:08
Stygiarburton, Ah, hmm, right. That would prelude that unless you love ../12:09
rburtoni'd find it clearer to use make -C12:10
Stygialpapp, Well you'd probably need to do make -C src, then, unless you simply want a flat 'fake'12:10
Stygiarburton, Yea exactly.12:10
StygiaHaving relative paths all over the place is confusing.12:10
rburtonbut this is a one-line do_compile function12:10
lpapprburton: thanks.12:11
*** smartin_ <smartin_!> has joined #yocto12:16
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has quit IRC12:20
*** smartin <smartin!> has quit IRC12:20
*** sameo <sameo!~samuel@> has quit IRC12:20
ndeclpapp: if you just need to pass extra parameters to make, you don't need to create do_compile, instead, you can do EXTRA_OEMAKE += "-C src". the base do_compile uses this variable.12:22
StygiaHmm. If I need to add a configuration line to php.ini (or any system config file), where is the right place to do that? In the image recipe?12:22
*** Net147 <Net147!> has quit IRC12:22
StygiaI have an image, and I need to add the browscap directive to php.ini... wondered what the right way to do that is.12:23
lpappndec: I prefer the inline version.12:25
StygiaI would lean towards writing my own php.ini, adding it to the PHP recipe, and then writing that out?12:25
*** scot__ <scot__!~scot@> has joined #yocto12:26
*** mulhern <mulhern!> has quit IRC12:29
zibrii have build failures on syslinux:, "gcc: error: unrecognized command line option '-malign-labels=0'" (MACHINE="nuc" (x86_64)). somebody recognizes this?12:30
zibri(on master of poky, meta-intel)12:31
lpappwhy am I getting unpack issues for such a line? SRC_URI = "file://foo.xz \12:44
lpappand foo.xz is in $packageroot/foo12:45
erbolpapp: shouldn't it be do_fecth that failed it it couldn't find the file?12:47
erbono more details in the error msg?12:47
lpappERROR: Function failed: Unpack failure for URL: 'file://foo.xz'.12:48
lpappxz -dc /path/to/foo.xz | tar x --no-same-owner -f - failed with return value 212:48
lpappxz: /path/to/foo.xz: File format not recognized12:49
lpapp| tar: This does not look like a tar archive12:49
lpapp| tar: Exiting with failure status due to previous errors12:49
lpappoopsie, corrupted file as it seems, bizarro.12:49
erbohmm, maybe it expects a tar.xz and not .xz12:50
lpapperbo: mayhaps ...12:51
erboit sure looked like it piped the output to tar atleast :)12:52
lpapprburton: -C src will not work12:54
lpappit apparently needs the version folder first something like 0.1-r012:54
lpappor WORKDIR or something12:55
rburtonlpapp: it starts in $S12:55
lpappmake: *** src: No such file or directory.  Stop.12:55
lpappI do have such a folder.12:56
lpappso why is make asserting?12:56
*** smartin_ <smartin_!> has quit IRC12:57
*** smartin <smartin!> has joined #yocto12:59
rburtonmaybe your default S is bad?12:59
rburtonhave a look in the work directory12:59
rburtonS defaults to $WORKDIR/$PN-$PV13:00
rburtonif that isn't where your sources appeared, set S to where they are13:00
lpappI am not sure what you mean.13:00
lpappoops, wrong content13:00
lpapp./tmp/work/bar/foo/0.1-r0 -> that is the source folder where "src" should be found.13:01
rburtonwork, so your S isn't right13:01
rburtonset S to where the sources ended up13:01
rburtonthe default assumes you've a tarball which expands to foo-0.113:01
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto13:04
lpappwhy don't I have that folder name?13:04
lpappI mean by default.13:04
rburtonbecause your sources didn't extract like that13:04
rburtonunpack simply extracts the tarballs it put into WORKDIR13:05
rburtonand the default is to assume that one of them used PN-PV as a directory13:05
rburtonif that isn't the case, then you need to set S13:05
lpappnot sure I follow.13:06
lpappI have got the 0.1-r0 stuff instead of foo foo-0.1, why?13:06
lpappthat has not much to do with the compression.13:06
*** smartin_ <smartin_!> has joined #yocto13:06
rburtonthat's workdir, where your SRC_URI contents got dropped13:06
lpappI mean... my uncompressed content should reside in that folder.13:06
rburtonunpack happens and extracts everything13:06
*** smartin <smartin!> has quit IRC13:07
rburtonif the tarball didn't unpack into a PN-PV directory, then you need to set S to point to where it did unpack13:07
rburtonie maybe the directory isn't versioned13:08
lpappso basically I need to use prefix when archiving with git.13:08
lpappIMO, Yocto could do this right by default.13:08
rburtondefine "right"13:09
rburtonthere is no "right"13:09
lpappcreate ${PN}-{PV}13:09
rburtonand then what?13:09
rburtonyou've an empty directory13:09
lpappand then get it working off-hand?13:09
rburtonas your sources when somewhere else13:09
*** jeremiah <jeremiah!> has quit IRC13:09
rburtonyes, if you're using git-archive, it makes sense to use --prefix and use name-version/13:09
lpappno, the sources should be uncompressed into that by Yocto.13:09
lpappif there is no prefix inside the archive.13:10
rburtondefine no prefix13:10
rburtonwhat if there are files and directories?13:10
rburtonthe default of S=PN-PV works for 99% of software in yocto13:10
lpappyeah, but apparently release guys have to do it manually.13:11
lpapprather than not using prefix, and yocto adding them by default.13:11
rburtontell the people making tarballs to use --prefix13:11
lpappthis is already coded into the recipe name after all, so it would not be hard.13:11
rburtonevery tarball since the mid-70s starts with a directory13:11
rburtonso yours should too13:11
lpapperm, it is not about what it should.13:12
lpappYocto could have a fallback.13:12
lpappwhen it is not, it is adding that.13:12
lpappor at least warning, whatever.13:13
lpappor both, actually.13:13
rburtonwe can add a warning that S doesn't exist13:13
rburtonyou probably had that in the logs already13:13
lpappno, that is an error13:13
lpappwhat I am saying there should be no error at all for simply missing prefices.13:14
rburtonit used to be auto-created which did confuse people, because you didn't get errors13:14
lpappnot error.13:14
lpappif you skip a warning, you are on your own ...13:14
lpappso what is confusion in there? :)13:14
*** cfo215 <cfo215!> has joined #yocto13:14
*** jeremiah <jeremiah!> has joined #yocto13:14
lpapprburton: does that make sense?13:17
*** jkridner <jkridner!~jkridner@nat/ti/x-csuqsmeypbmepruv> has joined #yocto13:25
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto13:25
*** scot__ <scot__!~scot@> has quit IRC13:25
*** scot <scot!~scot@> has joined #yocto13:25
lpapphmm, if a makefile for a software contains this line right at the beginning: CC = gcc13:35
lpappwill Yocto use the cross compiler supplied, i.e. can it override that somehow?13:36
lpappor that is a bad practice from the software author?13:36
rburtonthats bad practise13:36
rburton"However, an explicit assignment in the makefile, or with a command argument, overrides the environment."13:36
rburtonsays the make manual13:36
RPI think we use make -e don't we?13:37
RPso we force our environment to override the makefile13:37
rburtonoh, do we?13:37
*** munch <munch!> has joined #yocto13:37
rburtonso we do!13:37
zibrioe_runmake does that yes.13:37
ndecyes, we do.13:37
rburtonlearn something new every day ;)13:38
rburtonlpapp: it should get overridden by the cross compiler then13:38
RPbitbake.conf: EXTRA_OEMAKE = "-e MAKEFLAGS="13:38
rburtonanother good reason to use oe_runmake instead of make directly13:39
ndechowever -e is not recursively passed by make. so if you have a top level makefile that 'recurses' , -e is lost.13:39
rburtonthat pretty much ruins the point then doesn't it?13:40
ndeci was just debugging an issue about that last friday...13:41
ndecthat's when i noticed.13:41
lpapplimitation for doing the right thing in there is?13:42
rburtonlpapp: probably along the lines of "posix make says its isn't preserved"13:42
rburtonhand-rolling a build system using raw makefiles is so much effort13:43
lpappso what is the right practice? Not have CC line at all? Note, I have not written Makefiles by hand the last 5-6 years13:43
lpapphave been mostly using qmake, cmake, and a bit of autotools before.13:43
lpappwhere I do not need to care so much about all this.13:43
lpapprburton: yeah, that is where I agree.13:43
lpappIMHO, we should use cmake, but that is not a discussion for today.13:44
rburtonlpapp: shame, that's a perfectly reasonably solution13:44
lpappso what is the right GNU Makefile practice?13:44
*** melonipoika <melonipoika!> has joined #yocto13:46
ndecrburton: well, i think the '-e' is lost because we also set MAKEFLAGS=13:46
ndecotherwise the -e would be recursively used.13:46
rburtonlpapp: well, are you recursing? the defaults may just work.13:47
lpapprburton: yes13:47
lpappI am recursing.13:47
ndecyou could change EXTRA_OEMAKE not -e only, to see.13:48
ndeci haven't tried that yet.13:48
ndeci am not sure why we do MAKEFLAGS=13:49
lpapprburton: we can adjust the software easily though if needed... it was not written by me.13:49
rburtonlpapp: try changing that assignment to CC?=gcc13:50
rburtonthen the environment variable might take priority13:50
rburtonbeen a while since i've written a real makefile :(13:50
rburtonbut a quick test says that should work13:51
rburtonnote that CC already has a default in make, of "cc", which will also work so you don't even need to set CC13:51
rburtonits a default variable, there's loads of those13:51
*** behanw <behanw!> has joined #yocto13:53
*** cfo215 <cfo215!> has left #yocto13:56
*** bluelightning <bluelightning!> has joined #yocto13:57
*** bluelightning <bluelightning!> has quit IRC13:57
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto13:57
*** sameo <sameo!~samuel@> has joined #yocto13:59
lpapprburton: ok, so just remove.14:00
StygiaHey, we're having a weird (if relatively minor) issue with our boxes, and I wondered if anyone here'd seen anything similar.14:00
StygiaWhen we update our box's system image, we (right now) SCP an image over and reboot the box via SSH.14:00
StygiaHowever, we're frequently seeing that the box just "hangs" on the login screen instead of rebooting, until someone presses enter or something on the keyboard plugged into it.14:01
StygiaImmediately, I can't put my finger on what would cause behaviour like this, seeing as how it does reboot as soon as we "touch" it.14:01
StygiaAnyone here seen something like this before?14:01
*** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC14:02
rburtonStygia: stupid usb power management?14:02
rburtonx86 kernels until a few days ago enabled usb power management, which was Bad14:02
*** jeremiah <jeremiah!> has quit IRC14:02
Stygiarburton, I'm not sure? I'm not sure exactly how that would impact it. The reboot command is clearly "in there" somewhere since it triggers once we touch it.14:02
Stygiarburton, Hmm. I've honestly no idea.14:03
Stygiarburton, Sometimes it works, this time it did it right away. Sometimes it hangs.14:03
Stygiarburton, But, your suggestion would be trying a 3.10-ish kernel?14:03
*** jeremiah <jeremiah!> has joined #yocto14:04
Stygiarburton, Out of curiosity, why would you suspect USB power management of having to do with this? We plug in a USB thing that gives it power, but only when flashing, other than that we use a regular power input.14:04
rburtonStygia: is the keyboard usb?14:04
rburtoni've just seen keyboards acting odd when autosuspend was enabled14:05
rburtonbut unless you're running linux-yocto on x86, it should be disabled14:05
*** Stygia <Stygia!> has quit IRC14:07
*** smartin_ <smartin_!> has quit IRC14:07
*** cfo215 <cfo215!> has joined #yocto14:08
*** amarsman <amarsman!> has quit IRC14:08
*** Stygia <Stygia!> has joined #yocto14:09
*** smartin <smartin!> has joined #yocto14:09
*** amarsman <amarsman!> has joined #yocto14:09
*** kspr <kspr!> has quit IRC14:09
*** mulhern <mulhern!> has joined #yocto14:11
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC14:12
*** andyross <andyross!> has joined #yocto14:12
cfo215I'd like to add Qt4 from meta-oe to my distro each time I build it, and looking at the docs it looks as if IMAGE_INSTALL_append = " <packagename>" is how I'm supposed to do it.  I'm uncertain of the syntax though... do I just put "qt4" in <packagename> or do I use the bb package name "qt4-embedded_4.8.3" (bb file is
*** andyross <andyross!> has quit IRC14:17
lpappcfo215: qt4?14:18
lpappcfo215: any reason why not getting qt5 with meta-qt5?14:19
*** hollisb <hollisb!> has joined #yocto14:19
cfo215lpapp: I'm more familiar with qt4.14:19
lpappcfo215: yeah, but it is getting dead end.14:19
lpappmaybe there will be one more "last" bugfix release, but that is pretty much it.14:20
*** LiangC <LiangC!~Leon@> has joined #yocto14:20
lpappqt 5.2 feature freeze is less than a month ahead.14:20
*** LiangC <LiangC!~Leon@> has quit IRC14:20
*** LiangC <LiangC!~Leon@> has joined #yocto14:20
cfo215lpapp: does qt5 have better support of embedded linux with LCD and touchscreen.  I'm not using a "Desktop", just want to boot into my Qt app.14:20
lpappcfo215: yes, of course.14:21
cfo215lpapp: is meta-qt5 supported in "dev" builds; i.e. if I want to create a tool-chain build?14:22
lpappcfo215: ?14:23
cfo215when I build "Angstrom" for instance, one of my recipes allows me to build a tool chain.  e.g. it creates a file system with INCLUDE populated with the header files for all the installed software and add the cross-comipler for the target system.14:25
cfo215lpapp: I'll add meta-qt5 to my mix and see what happens ;)14:26
lpappcfo215: sorry, but I am not sure what you mean. Apparently, this explanation is not clear for me.14:26
lpapphow is a toolchain build related to qt5?14:27
lpapptoolchain build is happening way before a software like qt5 as that is the first in the queue.14:27
ndeci think cfo215 means a 'SDK' that includes the toolchain and all the libs/headers14:28
cfo215lpapp: no worries.  I'm just learning this whole process.  I'm more used to ./configure; make; make install...14:28
ndeci haven't tried for QT5, but several people have complained that SDK wasn't working, i believe.14:28
cfo215ndec:lpapp: that is exactly what I mean.14:28
lpappyeah, bluelightning claimed that SDK was not working.14:28
lpappcfo215: so you might be out of luck with that...14:29
lpappI have no idea what an SDK creation means though on the yocto level.14:29
cfo215ndec:lpapp: which is why I was looking to use qt4.. :)14:29
lpappcfo215: well, how about looking into the issue, and see if it is easy to fix?14:29
cfo215ndec:lpapp: I don't need to be on the "bleading-edge" for my app.14:29
lpappqt4 is really dead end, and no one should use it for new projects.14:29
*** arky <arky!~arky@> has joined #yocto14:30
lpappcfo215: it is more than just not bleeding edge.14:30
lpappeffectively, you are not getting any fixes anymore.14:30
lpappexcept a very few still sneaking in.14:30
cfo215lpapp:  I don't think I really have the skills for that.14:30
*** melonipoika <melonipoika!> has quit IRC14:31
*** Guest49189 <Guest49189!> has left #yocto14:31
lpappcfo215: well, if it is qt related, I can help. If it is yocto related, others can help in here.14:31
lpappI would help fixing it, but I do not even know why an SDK is needed.14:31
lpappor what it is supposed to provide.14:31
lpappyou can already build a library by adding a recipe.14:31
cfo215lpapp: ic, i'll try qt5 and see what happens.  May as well jump into the  pool.14:31
lpappwhat more does an sdk provide?14:32
cfo215lpap: the build paths; libraries; etc. conveniently bundled into a 'source'able environment file.  just makes development for a platform easier.14:33
cfo215lpapp: that way when your developing you just source the environment and your compiles know where everything is.14:34
cfo215lpapp:ndec: thanks for your input.  I value it.14:35
*** levi <levi!~user@> has joined #yocto14:38
*** panda84kde <panda84kde!> has joined #yocto14:39
lpappcfo215: I would say, let us fix the qt5 stuff unless it is a terrible pain. :)14:41
lpappqt4 is sooo much dead that it is only worth considering if there are headaches not doing so.14:41
lpappnot doing the qt5 stuff, that is.14:41
cfo215lpapp: I certainly couldn't fix it. ;)14:42
lpappcfo215: never know if you do not try.14:43
cfo215lpapp: I don't know what "qt 5.2 feature freeze is less than a month ahead." that means exactly.. but I think its related to git somehow.14:43
lpappcfo215: iirc the 20th of september is the feature freeze for 5.214:44
lpappcfo215: 5.1.1 is soon out.14:44
cfo215lpapp: true that!14:44
lpapp5.0 was out last December.14:44
*** mihai <mihai!~mihai@> has quit IRC14:44
*** amarsman <amarsman!> has quit IRC14:45
ndeclpapp: i don't think adding the QT5 sdk 'stuff' in meta-qt5 is trivial. that's my feeling. of course nothing is impossible, i just think one need to be quite used to OE to work on that.14:45
*** amarsman <amarsman!> has joined #yocto14:45
lpappndec: we will see.14:46
ndecnote that if you do it, i will use it ;-) since i need it too!14:46
cfo215ndec: that's certainly not me!  I'm still trying to add qt4 to my build.  I get ERROR: Required build target 'console-image' has no buildable providers.14:46
cfo215Missing or unbuildable dependency chain was: ['console-image', 'qt4-embedded_4.8.3']14:46
lpappndec: well, I do not care that much about something I do not even understand what it is for.14:46
lpappbut I am happy to help with qt5 in general.14:46
cfo215lpapp: I may just be calling on you for that...14:47
cfo215I tried IMAGE_INSTALL_append += "qt4" and IMAGE_INSTALL_append += "qt4-embedded_4.8.3" in my local.conf with similar results14:48
*** sameo <sameo!~samuel@> has quit IRC14:50
*** munch <munch!> has quit IRC14:52
cfo215lpap: another newb question: where do I clone meta-qt5?  in the top-level source dir or in meta-openembedded or someplace else?14:57
ndeccfo215: where you want ;-)14:58
lpappcfo215: up to you, I do it next to the other layers.14:58
ndecyou just need to put the right path in bblayer.conf14:58
lpappcfo215: but I know some people here do this right outside poky, so not next to the poky layers.14:58
cfo215ndec:lpapp: thanks, that may have answered my other problem... forgot to update bblayer.conf for qt4.14:59
ndecthat should help indeed.14:59
*** AlexG <AlexG!86bfdd48@gateway/web/freenode/ip.> has joined #yocto15:01
cfo215ndec: as I said that I noticed that my lastest try at adding qt4 was working.  I changed IMAGE_INSTALL_append += "qt4-embedded_4.8.3" to IMAGE_INSTALL_append += "qt4-embedded" in my local.conf15:01
cfo215ndec: no change to bblayers.conf.  Bitbake "just" found it... though I think it's supposed too... lol15:02
lpappI wonder if anyone can provide me a link to this SDK stuff15:03
lpappto read a more upon it.15:03
kergothcfo215: no, cloning a layer won't automagically add it to your builds. if you want to use the layer, it has to be added to bblayers. of course, qt4 doesn't reuqire meta-qt515:03
*** zenlinux_ <zenlinux_!> has quit IRC15:04
ndeclpapp: from high level
ndecthe 'SDK' is a 'standalone' installer that contains the cross compiler, qemu, and all 'dev' files for all packages.15:04
cfo215kergoth: thanks, I understood that bit.  I'm haven't bolted down a Qt version yet, but I'm still leaning on Qt4 because of the plethora of code out there for it.15:04
ndeclpapp: you generally create the SDK with bitbake -c populate_sdk <image>15:05
ndecand you get it in tmp/deploy/sdk15:05
cfo215ndec: thaks for that tip... writing it down...15:05
lpappndec: I have read that manual, but apparently it did not make it clear for me.15:05
ndecyou can then redistribute to others that can build applications against your image without needing to use OE.15:05
lpappndec: isn't the cross compiler built by core-image-minimal anyways?15:06
ndecyes. but the 'SDK' is relocatable. e.g. you can install it on a nother PC.15:06
lpappand why cannot a qt5 image just work without the need to use OE?15:06
lpapphow is the toolchain not relocatable?15:07
ndecin terms of hard coded path.15:07
*** andyross <andyross!> has joined #yocto15:07
*** sameo <sameo!samuel@nat/intel/x-dnkcbjaeqqzoocnr> has joined #yocto15:08
*** jkridner|work <jkridner|work!~jkridner@nat/ti/x-hzgsmswpdogrtrfn> has joined #yocto15:09
*** smartin_ <smartin_!> has joined #yocto15:09
ndecthe toolchain as it's built in tmp/sysroot cannot be 'exported' onto another PC.15:10
ndecthe 'SDK' with -c populate_sdk allows you to do that.15:10
ndecthe output of that command is a tarball that contains the toolchain, .h files, .so files, ...15:10
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC15:10
ndeci am not sure what you don't understand.15:10
*** smartin <smartin!> has quit IRC15:10
*** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto15:12
lpappndec: actually, all that should work out of the box.15:13
lpappwithout a dedicated sdk option imho.15:13
lpappthe toolchain should be relocatable, and also, the files should just be used in a description file with the relevant sections, like LIBRARIES = ... HEADERS = ...15:14
*** sameo <sameo!samuel@nat/intel/x-dnkcbjaeqqzoocnr> has quit IRC15:14
lpappit is not something that sounds complex for end user in an ideal world.15:14
*** sameo <sameo!samuel@nat/intel/x-steojqojsemntyam> has joined #yocto15:15
*** galak <galak!> has joined #yocto15:27
*** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has joined #yocto15:30
*** jeremiah <jeremiah!> has quit IRC15:31
*** zenlinux <zenlinux!> has joined #yocto15:34
*** rikroled <rikroled!~tbn@> has quit IRC15:53
*** smartin_ is now known as smartin15:53
*** belen <belen!Adium@nat/intel/x-krxslxacdtpmouom> has quit IRC15:55
*** nitink <nitink!nitink@nat/intel/x-ihyzgftjnreksfss> has quit IRC15:55
*** nitink <nitink!nitink@nat/intel/x-lfsguknexlurruys> has joined #yocto15:55
*** belen <belen!Adium@nat/intel/x-dfrjjotfzhuyzkqr> has joined #yocto15:57
*** arky <arky!~arky@> has quit IRC15:59
*** belen2 <belen2!Adium@nat/intel/x-bbylakuhyeypomcp> has joined #yocto15:59
*** belen <belen!Adium@nat/intel/x-dfrjjotfzhuyzkqr> has quit IRC16:01
*** mulhern <mulhern!> has quit IRC16:05
*** nitink <nitink!nitink@nat/intel/x-lfsguknexlurruys> has quit IRC16:06
*** nitink <nitink!nitink@nat/intel/x-ubdbuiibxxjhobqm> has joined #yocto16:07
*** davest <davest!Adium@nat/intel/x-avjfwtvgxlbpoavo> has joined #yocto16:09
*** smartin_ <smartin_!> has joined #yocto16:09
*** slaine <slaine!~slaine@> has quit IRC16:10
*** smartin <smartin!> has quit IRC16:11
*** nitink1 <nitink1!~nitink@> has joined #yocto16:14
*** nitink <nitink!nitink@nat/intel/x-ubdbuiibxxjhobqm> has quit IRC16:14
*** seebs <seebs!> has quit IRC16:20
*** seebs <seebs!> has joined #yocto16:22
*** ant_work <ant_work!> has quit IRC16:24
*** zeeblex <zeeblex!apalalax@nat/intel/x-ldzbfwpwiutblirx> has left #yocto16:25
*** Stygia <Stygia!> has quit IRC16:29
*** nitink1 <nitink1!~nitink@> has quit IRC16:29
*** nitink <nitink!nitink@nat/intel/x-giqjtdkrvcnytaxs> has joined #yocto16:29
RPlpapp: The difference is that the SDKMACHINE you set doesn't have to be the machine type you're building on and you get a nice easy to install file16:31
lpappthat should just work out of the box with the right architecture.16:33
lpappand all it would take, again with an ideal design, is to write a description.16:33
*** mulhern <mulhern!> has joined #yocto16:35
lpapprburton: ?16:40
rburtonwrong window!16:42
*** nitink <nitink!nitink@nat/intel/x-giqjtdkrvcnytaxs> has quit IRC16:42
*** nitink <nitink!nitink@nat/intel/x-leyxmsfiprqdemez> has joined #yocto16:42
*** galak <galak!> has quit IRC16:42
*** cfo215 <cfo215!> has left #yocto16:44
*** nitink <nitink!nitink@nat/intel/x-leyxmsfiprqdemez> has quit IRC16:47
*** nitink <nitink!~nitink@> has joined #yocto16:48
*** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC16:52
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC16:52
*** mulhern <mulhern!> has quit IRC16:55
kergothyow, weren't kidding about the parse slowdown with server mode :)16:59
kergothbrings back memories16:59
*** zecke <zecke!> has quit IRC16:59
rburtondoes it print "we recommend you install psyco"?17:03
*** eren <eren!~eren@unaffiliated/eren> has quit IRC17:03
*** elmi82 <elmi82!> has quit IRC17:05
*** panda84kde <panda84kde!> has quit IRC17:06
*** smartin <smartin!> has joined #yocto17:09
*** smartin_ <smartin_!> has quit IRC17:10
*** ftonello <ftonello!> has quit IRC17:14
*** ftonello <ftonello!> has joined #yocto17:14
*** mulhern <mulhern!> has joined #yocto17:16
*** mulhern <mulhern!> has left #yocto17:16
*** AlexG <AlexG!86bfdd48@gateway/web/freenode/ip.> has quit IRC17:21
*** sameo <sameo!samuel@nat/intel/x-steojqojsemntyam> has quit IRC17:24
*** belen2 <belen2!Adium@nat/intel/x-bbylakuhyeypomcp> has quit IRC17:30
*** belen <belen!~Adium@> has joined #yocto17:32
*** pidge <pidge!~pidge@> has joined #yocto17:34
*** belen <belen!~Adium@> has quit IRC17:35
*** mihai <mihai!~mihai@> has joined #yocto17:35
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC17:44
*** zecke <zecke!> has joined #yocto17:45
*** cfo215 <cfo215!> has joined #yocto17:48
cfo215does yocto support beaglebone out of the box or just beagleboard(-xm)?17:49
kergoththe bits provided by TI support both. see the meta-ti and meta-beagleboard layers17:51
*** tor <tor!> has quit IRC17:57
*** mbroadst <mbroadst!~mbroadst@kde/developer/mbroadst> has joined #yocto18:08
*** zenlinux <zenlinux!> has quit IRC18:09
*** smartin_ <smartin_!> has joined #yocto18:09
*** smartin <smartin!> has quit IRC18:10
seebsI will totally get meta-sourcery working with multilibs and everything. Any minute now. Surely, this will be the last bug I have to remove before my test builds complete on all the targets I care about.18:15
seebs... why is there a Dutch sailor waving to me as his ghostly ship passes? I feel concerned.18:17
cfo215kergoth: I added the meta-ti layer and updated my local.conf and bblayers.conf but get an error message when bitbaking.
denixcfo215: what branch are you using?18:18
kergothcfo215: make sure your branches are matched up between layers (e.g. don't try to use a master branch layer with a dylan branch poky/oe-core, or vice versa)18:18
cfo215denix:kergoth: dylan18:19
kergothdylan is a yocto release, version 1.4, afaik18:19
denixcfo215: dylan has mesa-9.0.218:20
*** reeve <reeve!81c0aafa@gateway/web/freenode/ip.> has joined #yocto18:20
reevehi everyone18:20
denixcfo215: so, error about mesa-9.1.6 means you are not using matching branches18:21
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto18:21
lpappndec: why is it difficult to fix the qt5 sdk stuff?18:21
reeveI'm trying to add google snappy into yocto, compilation/installation/rpm-creation were all successful. But when I include it into my core-image-lsb, it shows me error in do_rootfs like this:18:21
reeve|  |  528:Installing libsnappy1      ######################################## [ 44%] | Traceback (most recent call last): |   File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/", line 312, in __call__ |     self._process_rpmout() |   File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/pm.18:22
cfo215denix: thanks I'm really a newbie here.18:22
reevecan anyone help me out?18:22
cfo215and don't know how to match what to what.  Is that documented somewhere?18:22
denixcfo215: what is your base - is it poky or is it oe-core + some distro? in either case the branch of the base determines what other layers should use. if it's master, then other layers should use master. if it's dylan, then same for other layers18:24
cfo215denix: I followed the "Quick Start" from yocto-project.  So gussing it's poky.18:25
lpappcfo215: what is the issue?18:25
cfo215lpapp: I'm trying to switch to yocoto/poky instead of angstrom since it seems better supportd.  I added the meta-ti layer and updated my local.conf and bblayers.conf but get an error message when bitbaking.
denixcfo215: if it says 1.4 in the name, then it's dylan. you need to clone corresponding branches of additional layers18:27
denixcfo215: specifically, switch your meta-ti clone to dylan, instead of master18:28
cfo215denix: sorry a little vague on git:  I use "git clone -b <branch name> <repository>" when doing that?18:28
lpappcfo215: core-image-minimal should not have any relation to your meta-ti18:28
cfo215lpapp: i added it to my bblayers.conf18:28
lpappcfo215: cause of the toolchain or what do you use from there?18:29
denixcfo215: yes, or use git checkout later18:29
cfo215denix: thanks... I was just consulting the man page for git...18:30
*** eren <eren!~eren@unaffiliated/eren> has joined #yocto18:33
reevenobody knows my question? Where should I ask?18:34
seebsreeve: You might want to paste the output to something like pastebin, because the part you pasted doesn't seem to be the whole thing?18:37
reeveseebs: the other thing just look normal18:38
reeveseebs: let me try to paste more18:38
seebsI would recommend not pasting long output in IRC.18:38
seebsMostly people overlook it, or have trouble reading it.18:38
reevejust a little bit more, you can tell what I said18:38
seebsBut basically, that looked like a single line from an error message that would normally be 20+ lines.18:39
reeveor what's your suggestion? should I ask the question in mailing list?18:39
*** Stygia <Stygia!> has joined #yocto18:39
StygiaHey guys.18:39
reevein fact on my screen that's 34 liens, let me paste line by line18:39
seebsMy suggestion would be to grab the entire log from that line on, and post it to something like gist or pastebin, and post a URL in channel.18:39
seebs34 lines is too much for IRC.18:39
StygiaI just received the summary email of recent changes, but I don't see my patches (the two I submitted properly formatted and named in there).18:40
StygiaDoes that mean they got rejected?18:40
reevesorry, 4 lines18:40
reeve| Traceback (most recent call last):18:40
reeve|   File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/", line 312, in __call__18:40
reeve     self._process_rpmout()18:40
reeve|   File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/site-packages/smart/backends/rpm/", line 297, in _process_rpmout |     output =
reeve|   File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/", line 477, in read |     newchars, decodedbytes = self.decode(data, self.errors)18:40
reeve| UnicodeDecodeError: 'ascii' codec can't decode byte 0xa1 in position 740: ordinal not in range(128)18:41
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto18:41
kergothStygia: if there was no reply, and they weren't merged, more likely someone missed reviewing them at all, or hasn't had time to address them. this is fairly common in open source projects. you can always resend them with [resend] or similar in the subject line, but at times you just have to wait. how long as it been since yours were posted?18:41
* kergoth shrugs18:41
reeveseebs: it's a traceback from, complaining about ascii ...18:41
seebsHuh. That's a fascinating one. Some string, somewhere, which is expected to be all ASCII characters, has an 0xa1 in it.18:41
seebsWhich is indeed out of range.18:41
reevethis is google's snappy package ...18:42
Stygiakergoth, Alright, fair enough.18:42
Stygiakergoth, And hah... like a day or two.18:42
kergothah, yeah, might just have to wait a bit longer :)18:43
Stygiakergoth, And, further, I probably got on some list that means I require moderation approval because I submitted 2-3 patches incorrectly.18:43
StygiaAlright, fair enough. Thanks, I just wondered if I could/should keep submitting my recipes.18:43
cfo215kergoth: thanks for your help... cd meta-ti; git checkout dylan; cooking with gas now!18:45
kergothcfo215: glad to hear it18:46
seebsI think everything takes time to approve. I think my fairly simple and well-liked "set -e" patches took a couple-few months, due to a combination of various people's vacation schedules, higher priority tasks, and so on.18:49
Stygiaseebs, Hmm alright. Well fair enough.18:50
StygiaThese are new recipes, though, so I'm hoping it'll go in fairly soon.18:50
StygiaBecause I have like 100+ recipes to commit. :P Wouldn't want to clog the queue too much.18:50
* Crofton|work wonders what you are doing that stygia could find 100 recipes we do not have18:52
kergothStygia: where are you submitting them? which layer?18:52
kergothgetting a recipe into oe-core is non-trivial, only highly prevalent, key, core stuff is supposed to be going in there18:52
seebsDue to a humorous miscommunication, it turns out it's the first chapter of last year's revised Betty Crocker. Later we will realize that meta-delicious-cookies was the key to Yocto's long-term commercial success.18:53
Stygiathe new meta-perl layer.18:54
StygiaI have most of the stuff from metacpan as recipes here with me.18:54
kergothahh, cool18:56
bluelightningStygia: unless you sent some I'm not seeing, all of the ones you sent to the oe-devel list the other day had problems18:57
seebsmeta-combanitoric: This layer contains the set of all valid C programs which do not use line continuation, have no external dependencies, and are under ten lines long.18:57
bluelightningthere are still a huge (and growing) number of layers on github that aren't in the index :(18:58
seebsPATCH [0/aleph-0] ...18:59
seebsmeta-paradox: Contains recipes unsuitable for inclusion in any layer intended for use with oe-core.18:59
*** zenlinux <zenlinux!> has joined #yocto18:59
*** swex__ <swex__!~swex@> has quit IRC19:00
*** swex__ <swex__!~swex@> has joined #yocto19:01
Stygiabluelightning, Yea, I know. But I send two more that were formatted/named properly and with the correct (I think) metadata?19:01
bluelightningStygia: which ones were those? can you find them in ?19:03
Stygiabluelightning, libtaint-util-perl/
Stygiabluelightning, Hmm. Nope, I can't. Only the broken ones.19:04
bluelightningStygia: looks like they never made it to the list in that case19:04
Stygiabluelightning, Hmm alright. I didn't get banned or something for pushing broken patches, did I?19:05
bluelightningno, we wouldn't have done that... too many of us would have gotten banned by now :D19:05
seebsI don't think yocto would be well served by a community consisting only of people who never submit patches. :)19:05
StygiaWell alright, weird, I was sure I'd pushed them. But alright, I will push them again, then.19:06
seebsAt one point, we had a couple of months during which something somewhere in an IT department had decided that *some* outgoing mail to the oe-core list would be silently dropped without bounce messages, but mostly it was fine. Only affected us, I think, but there was a period during which maybe 5-10% of attempts to send patches to the list just sort of evaporated.19:07
StygiaHmm I think it's fine, all the shitty/broken patches I did submit were shown on the list just fine. :P19:08
*** smartin <smartin!> has joined #yocto19:09
*** smartin_ <smartin_!> has quit IRC19:10
cfo215is there a meta-qt4 or meta-qt5 layer in yocto?  I only found meta-qt319:11
cfo215maybe looking in the wrong spot...19:12
kergothclick on layers19:12
kergothclick in text box, type qt, hit enter19:12
cfo215kergoth: thanks19:12
kergothnot all yocto compatible layers are hosted at, so best to use the layer index there19:12
cfo215kergoth: I really do appreciate all the help.  Someday I won't be such a newb19:15
StygiaHmm. I don't think that worked.19:16
StygiaAt least my commit still doesn't appear on the list bluelightning linked.19:16
seebsSometimes there is a delay.19:17
StygiaI added each recipe, used git commit -s, added a commit message (with a summary on the top line), then used this command:  git send-email --confirm=always -M -119:17
seebsI've had messages that really did go through not show up for a couple-few hours.19:17
StygiaWeird. Email is usually pretty instant.19:18
StygiaBut fair enough, then.19:18
StygiaI was just wondering if something was broken in my approach or setup of git.19:18
*** daBONDi_work <daBONDi_work!~david@> has quit IRC19:19
*** darknighte_znc is now known as darknighte19:19
zibristygia: you set up postfix? you can have a look with "postqueue -p" (as root) to view any queued up mails.19:26
*** JimBaxter <JimBaxter!> has quit IRC19:26
zibrior /var/log/mail.log19:26
Stygiazibri, I'm pretty sure I did, I did push the other broken commits. But I'll have a look.19:27
StygiaAh, hmm. They say connection timed out.19:27
StygiaI'll have a look, thanks zibri19:28
zibriyou could try "telnet 25". in sweden a lot of isps filters port 2519:28
zibriif you can connect, you can continue investigate any local configuration issues. otherwise that's the probable culprit19:29
Stygiazibri, I'm not Swedish?19:29
zibrino, but i am.19:29
Stygiazibri, Jævlå svænsa19:29
zibrijust saying, it's like that here. probably elsewhere as well.19:30
StygiaHmm does give me 'no route to host'19:30
zibrii have issues building syslinux for meta-intel's nuc, both on master and dylan. (different error messages, at least some variation) :-(. on dylan, i get: "error: CPU you selected does not support x86-64 instruction set" (The compiler command includes -march=i386)19:35
*** Stygia <Stygia!> has quit IRC19:36
zibrion master, i got issues at roughly the same point, with errors about -malign-labels=0 not being a valid flag19:36
zibri <-- this one is from the master build19:37
zibriany ideas what i'm doing wrong?19:37
*** andyross <andyross!> has quit IRC19:41
*** andyross <andyross!> has joined #yocto19:43
*** Stygia <Stygia!~gmpsaifi@> has joined #yocto19:49
seebsOne thing that occasionally bites people in various ways is that x86 systems will occasionally want a given thing built specifically for x86 or x86_64, but by default we build a compiler that only supports one of those.20:00
seebsIf you're specifying -march=i386, and getting an error about x86-64 instruction set, that sort of implies that something generated x86-64 instructions or code, or asked for them. Not sure what, without more context. Assembler error?20:01
zibriunfortunately, i don't have any more context than those pastes. afaict, the only usage of -malign-traps=0 in syslinux seems to be falling back when the build system doesn't think the compiler has support for -falign-traps=0.20:06
*** mulhern <mulhern!> has joined #yocto20:06
*** cfo215 <cfo215!> has left #yocto20:07
*** sameo <sameo!~samuel@> has joined #yocto20:07
*** Stygia <Stygia!~gmpsaifi@> has quit IRC20:12
*** galak <galak!> has joined #yocto20:24
*** amarsman <amarsman!> has quit IRC20:28
*** mulhern <mulhern!> has quit IRC20:28
*** ant_home <ant_home!~andrea@> has joined #yocto20:31
*** zecke <zecke!> has quit IRC20:41
*** eren <eren!~eren@unaffiliated/eren> has quit IRC20:47
*** mulhern <mulhern!> has joined #yocto20:49
*** amarsman <amarsman!> has joined #yocto20:53
*** brm <brm!da653619@gateway/web/freenode/ip.> has joined #yocto21:05
brmHi guys! Anyone expert on yocto kernel configuration that can help me?21:06
brmadded a kernel config fragment to my layer, re-did the image, but the change has not gone through to the deploy directory21:07
*** cfo215 <cfo215!> has joined #yocto21:08
brmhey cfo215, know anything about kernel config development?21:10
cfo215brm: not really.  I'm just getting started with this stuff.  I have painfully learned how to setup my environment to build stuff though.  With a lot of help from people here.21:17
cfo215you could try for starters21:21
bluelightningbrm: did the change make it into the .config file in the build dir under the workdir for the kernel recipe?21:32
cfo215Got an error building core-image-minimal.   Error: qtbase-native not found in the base feeds (beaglebone armv7a-vfp-neon armv7a-vfp armv7a armv6-vfp armv6 armv5e-vfp armv5e armv5-vfp armv5 armv4 arm noarch any all).21:33
cfo215| ERROR: Function failed: do_rootfs (see /media/toshiba-usb3/work/poky/build/tmp/work/beaglebone-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_rootfs.3354 for further information)21:33
cfo215ERROR: Task 7 (/media/toshiba-usb3/work/poky/meta/recipes-core/images/, do_rootfs) failed with exit code '1'
bluelightningcfo215: that sounds like you added qtbase-native to IMAGE_INSTALL, which wouldn't be correct21:34
cfo215bluelightning: IMAGE_INSTALL_append += " qtbase qtbase-native" .. was added to local.conf.  What is the proper way?21:36
reeveseebs: stepped out for a while. Is there anything you could hint me to resolev the problem?21:37
seebsNothing obvious. Is this package in one of the normal layers, or is it local? It seems like the sort of thing that would get run into fairly often if it were in the core layers.21:38
*** Jefro <Jefro!> has joined #yocto21:39
bluelightningcfo215: qtbase-native isn't a package to be installed into the image; it's a recipe providing tools/libs to run on the build host21:41
bluelightningcfo215: I suspect you just want qtbase there21:41
cfo215blueligtning:  yes.  I just need to be able to run my home-built qt apps on the beaglebone.  I took out the IMA... line and the image built w/o errors.  Not sure if Qt got in there yet.  Haven't had time to look.21:43
bluelightningcfo215: if you took out qtbase as well, then I suspect it won't have21:43
cfo215bluelightning: i did take it out.  I'll put it back in... won't be long.21:44
reeveseebs: this is a package I'm trying to add into my own layer, but really nothing special21:45
reeveseebs: this is the link to the package, has anyone added it successfully?21:46
seebsI haven't heard of it before, so I don't know. I'm not sure where in the process this is failing, but I guess the first thing I'd probably do is look through any text associated with this for instances of 0xa1, or whatever that value was. If a description is including that character, maybe edit that.21:47
reeveenh? it seems the error was from extraction rpm script, meaning the created rpm has corrupted value?21:50
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC21:52
cfo215bluelightning: the new image is 20.8 MB compared to 2.9 MB w/o qtbase... so I'm guessing qt is in there somewhere.21:55
bluelightningcfo215: heh21:55
JaMazenlinux: Hi, can you extend to explicitly say that BSP layer shouldn't change metadata for other MACHINEs (i.e. describe that MACHINE overrides have to be used for each assignment/append and MACHINE subdirectories for files used from SRC_URI)? It's hard to explain this to some people and having link to some well written documentation would help a lot, thanks21:56
zenlinuxJaMa, you're looking for other "other" Scott, scottrif21:57
JaMazenlinux: ah sorry21:57
zenlinuxno prob :)21:57
zenlinuxman, I can't form a coherent sentence myself21:58
JaMascot: are you right scott for this task? ^^^ :)21:58
zenlinuxScott Rifenbark's nick is scottrif. He's in Europe IIRC so it may be late for him.21:59
JaMaOK, I'll check bugzilla anyway22:00
zenlinuxyour best bet is to make the request on the yocto ML or bugzill22:00
cfo215bluelightning: ./usr/lib/libQt* is in there.  I'm a happy camper today!.... now onto building the sdk... if I recall the command is bitbake -c populate_sdk console-image22:02
*** galak <galak!> has quit IRC22:03
bluelightningcfo215: :)22:03
bluelightningcfo215: not sure whether anyone's implemented the SDK for qt5 yet, last I checked nobody had22:03
cfo215bluelightning: I think I just verified that... :(  ERROR: Nothing PROVIDES 'core-image'22:05
*** andyross <andyross!> has quit IRC22:05
bluelightningcfo215: I think that's a mistake in your command line, at least out of the box there is nothing called "core-image"22:05
bluelightningno recipe, at least22:06
cfo215bluelightning: bitbake -c populate_sdk core-image-minimal is working... so far, so good...22:06
brmbluelightning: Sorry had to leave for a bit. I had a look in the work directory and can't even find a .cinfig!!22:23
brmoops .config22:23
*** darknighte is now known as darknighte_znc22:25
brmthe config fragment made it into the work directory, but don't know if it made the .config, as I can't find it22:26
kergoth.config is in the source tree, not workdir22:26
brmoh, where abouts? in the git folder?22:27
bluelightningkergoth: depends, at least linux-yocto uses a separate directory to build in22:28
brmthanks, will have a look22:28
kergothbitbake -e | grep '^B=' might be the best bet :)22:28
kergothbitbake -e virtual/kernel that is22:28
brmmy kernel is linux-mainline22:30
brmends up: "/home/bmentink/beagleboard_black/build/tmp/work/beaglebone-poky-linux-gnueabi/linux-mainline/3.8.13-r23a/git"22:31
kergothyep, thats .config will be after do_configure runs22:32
brmmy change did not get into the .config there22:33
bluelightninger, actually... if you're using linux-mainline, I'm not sure you'll have config fragment support22:34
brmI have no idea what i have done wrong with my fragment22:34
brmoh, so I have to make the change to what to get it to stick?22:35
bluelightningwithout config fragment support you will need to supply a full defconfig22:35
*** andyross <andyross!> has joined #yocto22:35
brmdo I put it into defconfig in that directory22:35
brmor can I put the defconfig file in my layer22:36
bluelightningit would go in the same place as any file your kernel recipe needed to reference (and you'll need to point to it in SRC_URI)22:36
bluelightningalternatively you can change your kernel recipe to be like meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb22:37
bluelightningthat provides config fragment support22:37
brmso just pich the portions that do the fragment support?22:38
bluelightningI think you'll have to pretty much take the whole thing22:40
bluelightningbut the difference with linux-yocto is you can point to your own standard source tree (or the mainline kernel source tree) rather than split source/meta branches that linux-yocto requires22:40
kergothI'd question that recipe naming. imo "linux-yocto" implies said source/meta branching22:41
bluelightningperhaps, but there was no config fragment functionality before linux-yocto either :)22:42
bluelightningat least not that I am aware of22:42
brmI am out of my depth here ..22:42
bluelightningbrm: have you had a look at this manual?
bluelightningbrm: that should cover the basics22:44
brmyep have, still struggling ..22:44
brmmost of the examples there assume linux-yocto kernel not mainline22:44
brmso a lot of the commands don't work22:45
bluelightningbrm: start with linux-yocto-custom; apart from the bits that talk about split meta branches, the rest is equally applicable to linux-yocto-custom22:45
bluelightninglinux-yocto-custom is covered under 2.4. Working With Your Own Sources22:45
seebskergoth, I sent you a pull request for that meta-sourcery stuff. It's probably still got bugs, but it's far enough along that I don't feel totally awful inflicting it on someone.22:46
brmso I have to use a different kernel? The BBB receipe has to use linux-mainline as all the BBB patches are on that kernel22:49
bluelightningbrm: no, you can point to the exact same source and use the same patches22:49
bluelightningbrm: you can use the same SRC_URI line22:50
brmok, got it thanks ....22:51
brmgoing for lunch now, thanks for your help ;-)22:52
kergothseebs: cool, thanks, will likely take a look at it tomorrow22:52
seebsI'm on vacation Friday through a week from Monday, and probably won't check work email.22:53
seebsMight be around this channel, though, because my freenode IRC is on the client I use for personal chats anyway.22:53
* kergoth nods, same22:55
*** seebs <seebs!> has quit IRC23:02
*** seebs <seebs!> has joined #yocto23:04
*** mulhern <mulhern!> has joined #yocto23:09
*** hollisb <hollisb!> has quit IRC23:11
-YoctoAutoBuilder- build #227 of nightly is complete: Exception [exception interrupted] Build details are at
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC23:18
*** bozojoe <bozojoe!4475c643@gateway/web/freenode/ip.> has joined #yocto23:35
bozojoeis mark hatle here?23:35
*** mulhern <mulhern!> has quit IRC23:57
*** smartin_ <smartin_!> has joined #yocto23:59

Generated by 2.11.0 by Marius Gedminas - find it at!