| *** tlwoerner_ <tlwoerner_!~tlwoerner@linaro/tlwoerner> has quit IRC | 00:02 | |
| *** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC | 00:04 | |
| *** _julian <_julian!~quassel@x2f10ab0.dyn.telefonica.de> has joined #yocto | 00:25 | |
| *** _julian_ <_julian_!~quassel@x2f03027.dyn.telefonica.de> has quit IRC | 00:26 | |
| *** nitink <nitink!~nitink@134.134.137.73> has joined #yocto | 00:43 | |
| *** davest <davest!Adium@nat/intel/x-kgltwapxlxccutav> has quit IRC | 00:45 | |
| *** scot__ <scot__!~scot@130.164.62.183> has quit IRC | 00:49 | |
| *** nitink <nitink!~nitink@134.134.137.73> has quit IRC | 00:56 | |
| *** nitink <nitink!nitink@nat/intel/x-umdtetjwfjcbnbxk> has joined #yocto | 01:07 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 01:10 | |
| *** nitink <nitink!nitink@nat/intel/x-umdtetjwfjcbnbxk> has quit IRC | 01:13 | |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has joined #yocto | 01:20 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:27 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC | 01:30 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 01:31 | |
| -YoctoAutoBuilder- build #236 of nightly-oecore is complete: Failure [failed Building Toolchain Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-oecore/builds/236 | 01:35 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 01:47 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 01:56 | |
| *** silviof1 <silviof1!~silviof@unaffiliated/silviof> has joined #yocto | 02:01 | |
| *** silviof <silviof!~silviof@unaffiliated/silviof> has quit IRC | 02:04 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 02:08 | |
| -YoctoAutoBuilder- build #256 of nightly-world is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/256 | 02:12 | |
| -YoctoAutoBuilder- build #261 of nightly-x86 is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86/builds/261 | 02:15 | |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 02:34 | |
| *** Jefro <Jefro!~jefro@50-0-152-82.dedicated.static.sonic.net> has quit IRC | 02:36 | |
| *** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC | 02:36 | |
| *** shoragan <shoragan!~jlu@2001:6f8:1178:2:219:99ff:fe56:8d7> has joined #yocto | 02:37 | |
| *** shoragan <shoragan!~jlu@debian/developer/shoragan> has joined #yocto | 02:37 | |
| *** nitink <nitink!~nitink@134.134.137.73> has joined #yocto | 02:47 | |
| *** darknighte is now known as darknighte_znc | 02:57 | |
| *** nitink <nitink!~nitink@134.134.137.73> has quit IRC | 03:02 | |
| *** nitink <nitink!~nitink@134.134.137.73> has joined #yocto | 03:13 | |
| *** tanamo <tanamo!cb7dac02@gateway/web/freenode/ip.203.125.172.2> has joined #yocto | 03:22 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:24 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 03:33 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 03:34 | |
| *** _alex_kag_ <_alex_kag_!~alex_kag@37.213.46.42> has quit IRC | 04:11 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 04:23 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 04:24 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 04:31 | |
| *** _alex_kag_ <_alex_kag_!~alex_kag@178.124.16.226> has joined #yocto | 04:50 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 05:39 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 05:40 | |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has quit IRC | 05:47 | |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-ldzbfwpwiutblirx> has joined #yocto | 05:48 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 05:48 | |
| *** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto | 05:55 | |
| *** nitink1 <nitink1!nitink@nat/intel/x-huzcqnzkmcxntctu> has joined #yocto | 05:59 | |
| *** nitink <nitink!~nitink@134.134.137.73> has quit IRC | 05:59 | |
| *** blitz00 <blitz00!~stefans@unaffiliated/blitz00> has joined #yocto | 06:03 | |
| *** zecke <zecke!~ich@p5099b351.dip0.t-ipconnect.de> has joined #yocto | 06:04 | |
| *** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has joined #yocto | 06:04 | |
| *** nitink <nitink!nitink@nat/intel/x-ihyzgftjnreksfss> has joined #yocto | 06:04 | |
| *** nitink1 <nitink1!nitink@nat/intel/x-huzcqnzkmcxntctu> has quit IRC | 06:04 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 06:17 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:34 | |
| *** silviof1 is now known as silviof | 06:43 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:47 | |
| -YoctoAutoBuilder- build #257 of nightly-world is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/257 | 06:47 | |
| -YoctoAutoBuilder- build #138 of nightly-qa-systemd is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-qa-systemd/builds/138 | 06:56 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 07:09 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 07:10 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 07:17 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 07:17 | |
| *** ka6sox <ka6sox!~ka6sox@nasadmin/ka6sox> has quit IRC | 07:19 | |
| *** ka6sox <ka6sox!ka6sox@nasadmin/ka6sox> has joined #yocto | 07:22 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 07:29 | |
| *** mike <mike!c2881242@gateway/web/freenode/ip.194.136.18.66> has joined #yocto | 07:39 | |
| *** mike is now known as Guest37012 | 07:39 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 07:40 | |
| lpapp | http://paste.kde.org/~lpapp/p123e0cc2/ -> why am I getting this gtk doc fetching issue, especially when I have this in the downloads folder, already? git2_git.gnome.org.gtk-doc-stub.tar.gz | 07:41 |
|---|---|---|
| lpapp | hi | 07:41 |
| erbo | lpapp: do you also have git2_git.gnome.org.gtk-doc-stub.tar.gz.done? | 07:45 |
| lpapp | erbo: yeah | 07:45 |
| lpapp | 25135 git2_git.gnome.org.gtk-doc-stub.tar.gz | 07:45 |
| erbo | and no error about the checksum being wrong? | 07:45 |
| lpapp | 0 git2_git.gnome.org.gtk-doc-stub.tar.gz.done | 07:46 |
| ndec | this .tar.gz is the 'tree' archive, not the package archive required to build the recipe, i believe. | 07:46 |
| ndec | the fetcher first clone the tree and create a local archive, then it creates the package tarball from that. | 07:46 |
| lpapp | erbo: I do not see any checksum errors. | 07:46 |
| ndec | next build, it fetches git updates (if any), recreate the tree tarball. | 07:46 |
| ndec | do you have the tarball for that specific commit ID? | 07:47 |
| lpapp | what is a tree archive | 07:47 |
| erbo | ndec: ok, so you need the git2/git.gnome.org.gtk-doc-stub/ and git2/git://git.gnome.org/gtk-doc-stub.done as well? | 07:47 |
| erbo | minus the "git://" | 07:47 |
| lpapp | package tarball + the .git stuff ? | 07:47 |
| ndec | lpapp: see my first comments above. | 07:47 |
| lpapp | ndec: I have not understood that. | 07:48 |
| ndec | ok. | 07:48 |
| ndec | bitbake keeps a local copy of the entire git tree. | 07:48 |
| ndec | it then create the recipe tarball from that copy. | 07:48 |
| lpapp | is there an option for local.conf to override this behavior ? | 07:48 |
| lpapp | otherwise there is not much point in checking stuff out, especially which comes from git ... | 07:49 |
| lpapp | I would like it not to do any update at all. | 07:49 |
| lpapp | otherwise we would need to rely on upstream stuff. | 07:49 |
| lpapp | which can fail anytime blocking us. | 07:49 |
| ndec | hmm. let me check. now i am a little confused. | 07:50 |
| lpapp | so what downloads we check in, should be the "final" until further notification. | 07:50 |
| lpapp | and and and ... poky releases should not use git anyway? | 07:50 |
| lpapp | or a fixed tag ? | 07:50 |
| *** Saur <Saur!pkj@nat/axis/x-wusqdwgeexlufqgj> has quit IRC | 07:50 | |
| *** RP <RP!~richard@dan.rpsys.net> has quit IRC | 07:51 | |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 07:51 | |
| erbo | lpapp: 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 feature | 07:51 |
| erbo | s/should/shouldn't | 07:51 |
| lpapp | erbo: I am just using upstream poky ... | 07:51 |
| lpapp | it should be reliable. | 07:51 |
| *** florian_kc is now known as florian | 07:51 | |
| lpapp | and users should be able to avoid the dependency on upstream repositories ... | 07:51 |
| *** rikroled <rikroled!~tbn@mad27-1-88-172-46-29.fbx.proxad.net> has joined #yocto | 07:52 | |
| lpapp | and AFAIK poky does not like AUTOREV for stuff. | 07:52 |
| erbo | lpapp: I agree, when it's fetched it shouldn't need access to the git until someone touches the build recipe to update SRCREV | 07:52 |
| ndec | lpapp: 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 |
| lpapp | well, how can I solve this? | 07:52 |
| lpapp | it has been blocking our CI for a while. | 07:53 |
| erbo | can you clone the gtk-doc-stub manually on that machine? | 07:54 |
| erbo | I could clone it ok from here | 07:54 |
| lpapp | it does not matter. | 07:54 |
| lpapp | I mean: 1) I do not have access 2) We should not fetch it | 07:54 |
| erbo | no you shouldn't, but now something has gone wrong.. | 07:55 |
| erbo | lpapp: is the error repeatable if you remove the gtk-doc-stub stuff from download? | 07:55 |
| lpapp | yeah, so I need to find a way to disable the fetch. | 07:55 |
| lpapp | erbo: no idea... that would require a commit | 07:56 |
| lpapp | I rather avoid any commit unless if necessary. | 07:56 |
| lpapp | would* | 07:56 |
| erbo | bitbake -c cleansstate gtk-doc-stub ? | 07:56 |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:56 | |
| lpapp | erbo: it is only failing on the CI | 07:56 |
| lpapp | erbo: it had not failed locally before I committed. | 07:57 |
| lpapp | and I have no access to the CI, etc. | 07:58 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 07:58 | |
| erbo | lpapp: for the future, maybe something like this might help you. https://wiki.yoctoproject.org/wiki/How_do_I (the Q: How do I create my own source download mirror part) | 07:59 |
| lpapp | and for now? | 07:59 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 07:59 | |
| erbo | lpapp: I don't know, just trying to help out with what I can | 08:00 |
| *** belen <belen!~Adium@134.134.139.72> has joined #yocto | 08:00 | |
| *** tonghuix <tonghuix!~tonghuix@61.149.210.24> has joined #yocto | 08:00 | |
| lpapp | thanks.. I am just trying to find a workaround now not to block other people... | 08:01 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 08:02 | |
| erbo | lpapp: An ugly workaround to get going might be to create you own tarball + a bbappend that points to that instead of the upstream git | 08:02 |
| erbo | but it's not nice, so I guess it depends on how bad you need it working right now | 08:03 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 08:06 | |
| lpapp | erbo: very bad. :D | 08:08 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 08:09 | |
| lpapp | erbo: 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!~richard@dan.rpsys.net> has joined #yocto | 08:10 | |
| *** tomz2 <tomz2!~trz@c-68-53-177-94.hsd1.in.comcast.net> has quit IRC | 08:11 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC | 08:11 | |
| *** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has quit IRC | 08:11 | |
| *** levi <levi!~user@c-174-52-89-43.hsd1.ut.comcast.net> has quit IRC | 08:11 | |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has quit IRC | 08:11 | |
| *** tlwoerner <tlwoerner!~trevor@dsl-67-55-9-50.acanac.net> has joined #yocto | 08:12 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 08:12 | |
| *** tlwoerner <tlwoerner!~trevor@dsl-67-55-9-50.acanac.net> has quit IRC | 08:12 | |
| *** tlwoerner <tlwoerner!~trevor@linaro/tlwoerner> has joined #yocto | 08:12 | |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto | 08:13 | |
| erbo | lpapp: 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_URL | 08:13 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 08:14 | |
| lpapp | erbo: uh, oh. | 08:14 |
| *** tomz <tomz!~trz@c-68-53-177-94.hsd1.in.comcast.net> has joined #yocto | 08:14 | |
| lpapp | local will not make it work on the CI and the dev machines. | 08:15 |
| lpapp | webserver looks more reasonable to me. | 08:15 |
| *** tomz is now known as Guest49189 | 08:15 | |
| *** smartin_ is now known as smartin | 08:15 | |
| lpapp | oh, actually I am wrong. | 08:15 |
| lpapp | you can put it somewhere in the repository, too, and then everyone has that set. | 08:15 |
| lpapp | but 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 |
| erbo | no, probably better scp and serve over http | 08:16 |
| lpapp | the documentation could shed a bit more light. :) | 08:16 |
| lpapp | erbo: yeah, but that means devs need to have access to the server. | 08:16 |
| lpapp | pretty much all of them. | 08:16 |
| lpapp | hmm, actually nope if only one is responsible for updating poky. | 08:17 |
| *** tonghuix <tonghuix!~tonghuix@61.149.210.24> has left #yocto | 08:17 | |
| *** Daemon404 <Daemon404!~who_knows@S0106586d8f4832af.tb.shawcable.net> has joined #yocto | 08:18 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 08:19 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 08:24 | |
| ndec | lpapp: 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 |
| ndec | that still doesn't explain your problem. but wanted to clarify | 08:26 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 08:26 | |
| lpapp | ok, thanks. So what is causing the issue then? | 08:26 |
| ndec | it'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 |
| ndec | lpapp: not yet ;-) | 08:27 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 08:27 | |
| lpapp | not yet what | 08:27 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 08:28 | |
| *** sameo <sameo!~samuel@192.55.55.37> has joined #yocto | 08:28 | |
| ndec | lpapp: do you have access to downloads folder? | 08:28 |
| ndec | and can run cmd? | 08:28 |
| ndec | inside | 08:28 |
| ndec | looking 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 |
| lpapp | ndec: server or local? | 08:29 |
| ndec | where you get the failure | 08:29 |
| lpapp | wha cmd | 08:30 |
| lpapp | t | 08:30 |
| ndec | lpapp: so when using git in SRC_URI, the fetcher will clone the git tree in downloads/git2/<git url> | 08:30 |
| ndec | then to get the source in tmp/work/<package/... it would run a git checkout from downloads/git2/<xxx> | 08:31 |
| *** honschu_ <honschu_!~honschu@p549E83E6.dip0.t-ipconnect.de> has joined #yocto | 08:31 | |
| *** honschu_ <honschu_!~honschu@shackspace/j4fun> has joined #yocto | 08:31 | |
| *** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC | 08:31 | |
| ndec | can you check in downloads/git2/git.gnome.org.gtk-doc-stub if you have the required commit (SRCREV)? | 08:32 |
| ndec | lpapp: to check if a commit exist, bitbake will do " git log --pretty=oneline -n 1 <commit>" | 08:34 |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has quit IRC | 08:40 | |
| lpapp | ndec: I guess that is fine locally, too, then as the same is on the server due to the check in. | 08:42 |
| ndec | lpapp: i don't get that | 08:42 |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has joined #yocto | 08:44 | |
| jeremiah | I have some questions about cross-posting to the lists, typical procedural questions but I don't want to get flamed. :-) | 08:44 |
| jeremiah | I would like to cross-post to meta-ti and meta-ivi, is this considered an anti-pattern. TIA! | 08:45 |
| lpapp | ndec: downloads/git2/git.gnome.org.gtk-doc-stub is a folder. | 08:46 |
| -YoctoAutoBuilder- build #256 of nightly-x86-64 is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x86-64/builds/256 | 08:46 | |
| lpapp | ndec: so what did you mean by "if you have the required commit (SRCREV)"? | 08:47 |
| ndec | lpapp: 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 |
| ndec | the first time. | 08:48 |
| lpapp | ndec: I am not sure what you ask me to do. | 08:48 |
| ndec | then when you clean/rebuild, bitbake won't fetch again, if the SRCREV (e.g. commit ID) hasn't changed. | 08:48 |
| lpapp | as I said before, it is a folder, a git repository in fact. | 08:49 |
| lpapp | it is not a bitbake recipe, whatsoever. | 08:49 |
| lpapp | accordingly, it has no SRCREV in. | 08:49 |
| ndec | gtk-doc-stub? | 08:49 |
| lpapp | which makes me confused why you are talking about SRCREV inside a git repository. | 08:49 |
| ndec | gtk-doc-stub fetches its sources from a git tree, according to SRC_URI in the .bb file. | 08:50 |
| ndec | the .bb also specifies which version of the tree in the git it uses. that's SRCREV. | 08:50 |
| *** smartin_ is now known as smartin | 08:51 | |
| ndec | to get you the source, bitbake will clone (git clone) SRC_URI tree in downloads/git2 | 08:51 |
| ndec | then it will checkout the SRVREV commit from that 'local' clone into $WORKDIR. | 08:51 |
| lpapp | so what you are basically asking is to check the SRVREV in the gtk-doc-stub bitbake recipe | 08:51 |
| lpapp | and see if that presents in the gtk stub doc build folder. | 08:51 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 08:52 | |
| ndec | well, based on your error, you must not even have a build folder yet for gtk-doc-stub. | 08:52 |
| ndec | since it failed in the fetch. | 08:52 |
| lpapp | no, I mean download | 08:53 |
| ndec | lpapp: do you have downloads/git2/git.gnome.org.gtk-doc-stub | 08:53 |
| lpapp | yes, see above. | 08:53 |
| ndec | and do you have the commit mentioned in the .bb in that clone. | 08:53 |
| ndec | ah, | 08:53 |
| eren | morning all | 08:55 |
| lpapp | ndec: SRCREV = "3dfd0a09de696ec8c544762747f8a0f77153622e" | 08:55 |
| lpapp | git show 3dfd0a09de696ec8c544762747f8a0f77153622e | 08:55 |
| lpapp | fatal: bad object 3dfd0a09de696ec8c544762747f8a0f77153622e | 08:55 |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has quit IRC | 08:55 | |
| ndec | ok that explains why it tries to fetch from network at least. | 08:56 |
| lpapp | why does it ? | 08:56 |
| ndec | because the 'requested' commit id does not exist in the local clone, the local clone needs to be updated. | 08:56 |
| lpapp | why does it contain a non-existing SRCREV anyway? | 08:56 |
| *** another_andy <another_andy!~andy@50-197-51-41-static.hfc.comcastbusiness.net> has quit IRC | 08:56 | |
| lpapp | when it is cloning an existing that should be present locally, yeah? | 08:56 |
| *** ScriptRipper1 <ScriptRipper1!~ScriptRip@178-26-58-205-dynip.superkabel.de> has quit IRC | 08:57 | |
| ndec | it might be an old clone. | 08:57 |
| ndec | that was clone before the object was pushed. | 08:57 |
| *** rikroled <rikroled!~tbn@mad27-1-88-172-46-29.fbx.proxad.net> has quit IRC | 08:57 | |
| rburton | gtk-doc-stub hasn't been touched for ages, so i'd be curious to see what head is in that clone | 08:57 |
| *** another_andy <another_andy!~andy@50-197-51-41-static.hfc.comcastbusiness.net> has joined #yocto | 08:57 | |
| erbo | the gtk-doc-stub recipe hasn't been touched since 2012-07-28 :/ | 08:57 |
| lpapp | hmpf | 08:57 |
| ndec | lpapp: in my case, it exists: $ git log --oneline -1 3dfd0a09de696ec8c544762747f8a0f77153622 | 08:57 |
| ndec | 3dfd0a0 Import introspection stub machinery too | 08:57 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 08:58 | |
| lpapp | that folder is actually in our git tree | 08:58 |
| lpapp | so git show will get the wrong stuff | 08:58 |
| rburton | lpapp: aah | 08:58 |
| ndec | bummer. | 08:58 |
| lpapp | how can I get the local git stuff? | 08:58 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 08:58 | |
| lpapp | i.e. nested git repository. | 08:58 |
| ndec | i 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!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 08:58 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 08:58 | |
| JaMa | someone 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 scope | 08:58 |
| rburton | lpapp: its a bare clone, so maybe it can't auto-detect it | 08:59 |
| *** rikroled <rikroled!~tbn@84.55.160.118> has joined #yocto | 08:59 | |
| lpapp | ndec: it is not the download managed as a git tree, but the whole poky. | 08:59 |
| lpapp | ndec: with our custom layer, etc. | 08:59 |
| ndec | is download inside that tree? | 09:00 |
| lpapp | it is a perfectly valid use case to manage addition under git just like poky is managed under git. | 09:00 |
| lpapp | yes, of course. | 09:00 |
| lpapp | build/downloads is inside the poky root after all. | 09:00 |
| rburton | lpapp: you can try "git --git-dir=. show" inside downloads/git2/git.gnome.org.gtk-doc-stub | 09:01 |
| *** ScriptRipper <ScriptRipper!~ScriptRip@opensuse/member/MartinMohring> has joined #yocto | 09:01 | |
| lpapp | git --git-dir=. show 3dfd0a09de696ec8c544762747f8a0f77153622e | 09:01 |
| rburton | that should force it to consider the current directory as the git directory as the autodetect isn't working | 09:01 |
| lpapp | fatal: Not a git repository: '.' | 09:01 |
| lpapp | not even with full path. | 09:02 |
| rburton | this is what i get | 09:02 |
| rburton | ross@melchett ~/Yocto/downloads/git2 | 09:02 |
| rburton | $ git --git-dir=git.gnome.org.gtk-doc-stub show | 09:02 |
| rburton | commit 3dfd0a09de696ec8c544762747f8a0f77153622e | 09:02 |
| rburton | ... | 09:02 |
| lpapp | ok, that is not working for me. | 09:02 |
| rburton | so what you have there isn't actually a clone | 09:03 |
| lpapp | it --version | 09:03 |
| lpapp | git version 1.8.3.4 | 09:03 |
| ndec | rburton: i don't think you can clone a git, inside another git that easily. | 09:03 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 09:03 | |
| lpapp | rburton: yes, true. | 09:03 |
| rburton | ndec: i suspect git will auto-ignore some files that are important | 09:03 |
| lpapp | rburton: there is no .git/ whatsoever. | 09:04 |
| lpapp | git.gnome.org.gtk-doc-stub $ ls | 09:04 |
| lpapp | HEAD config description hooks info objects packed-refs | 09:04 |
| ndec | yes, it would auto ignore the entire .git ;-) | 09:04 |
| rburton | ndec: bare clones don't have .git/ | 09:04 |
| rburton | lpapp: $ la | 09:04 |
| rburton | branches config description FETCH_HEAD HEAD hooks info objects packed-refs refs | 09:04 |
| ndec | right. | 09:04 |
| lpapp | you mean ls -a? | 09:04 |
| rburton | no branches, no refs | 09:04 |
| lpapp | nothing more, I checked. | 09:04 |
| lpapp | only . and .. | 09:04 |
| lpapp | but how does --git-dir work for you then anyway? | 09:05 |
| lpapp | you have made a manual checkout or what? | 09:05 |
| rburton | lpapp: you're missing the branches and refs directories | 09:05 |
| rburton | so its only half a git clone you've got | 09:06 |
| lpapp | rburton: half a git clone ? | 09:06 |
| lpapp | but why would that work locally, and not remotely ? | 09:06 |
| ndec | rburton: just did a quick try, it should work in fact. i could add a bare tree in another top level tree. | 09:06 |
| rburton | lpapp: 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 one | 09:07 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 09:07 | |
| ndec | rburton: argh. but when cloning that test tree, it removed the branches and heads dirs... | 09:07 |
| ndec | refs and branches i meant. | 09:08 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 09:08 | |
| ndec | lpapp: i think the short answer, is that git can't have 'bare tree' embedded inside a top level tree. | 09:09 |
| ndec | by 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 |
| lpapp | ndec: looks like you guys would need to find a solution for this use case at some point ... | 09:10 |
| lpapp | ndec: also, are you sure git really does not support that? | 09:10 |
| lpapp | ndec: oh, and just for reference, the same way, denzil has just worked fine. | 09:11 |
| *** sgw_ <sgw_!~sgw@c-71-193-189-117.hsd1.wa.comcast.net> has joined #yocto | 09:11 | |
| ndec | i just tried, and was able to reproduce your issue. | 09:11 |
| lpapp | ndec: so what made poky break this | 09:11 |
| ndec | with git i mean | 09:11 |
| lpapp | denzil has not used git fetcher? | 09:11 |
| ndec | i think the fetcher has changed indeed. to allow the WORKDIR to be a 'git' tree. | 09:12 |
| lpapp | meh, bah, doh, gosh, uh, oh, huh, what, ok. :) | 09:12 |
| lpapp | so it is yet another regression. | 09:12 |
| lpapp | any quick workaround? | 09:12 |
| lpapp | or the people can only be unblocked by series investment for dylan? | 09:13 |
| lpapp | serious* | 09:13 |
| lpapp | it is very painful to update two releases ahead apparently. | 09:14 |
| lpapp | I think the migration path should be done smoother. | 09:14 |
| lpapp | I had a bunch of issues already, and then this again. | 09:14 |
| rburton | lpapp: i'll repeat my advice from a few weeks ago - putting downloads/ into git will really hurt you, even if it worked | 09:14 |
| rburton | in six months time you'll have a *giant* git repository | 09:14 |
| lpapp | rburton: 621 MB | 09:15 |
| lpapp | on a few TB server. | 09:15 |
| lpapp | >>> 621/10000000 | 09:15 |
| lpapp | 0 | 09:15 |
| lpapp | >>> | 09:15 |
| lpapp | just with 1 TB | 09:15 |
| rburton | lpapp: for every client who wants to clone that repo | 09:15 |
| rburton | and fwiw, my downloads/ is 22G | 09:16 |
| -YoctoAutoBuilder- build #258 of nightly-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-arm/builds/258 | 09:16 | |
| rburton | i really wouldn't want that directory to be in the same git repo as my layer | 09:16 |
| lpapp | right, so >>> 621/500000 | 09:16 |
| lpapp | 0 | 09:16 |
| lpapp | >>> | 09:16 |
| lpapp | 500 GB locally. | 09:16 |
| lpapp | (on one disk, does not count the other) | 09:16 |
| ndec | looking at diffs between dylan and denzil, i have some doubts it used to work with denzil... that code hasn't chnaged. | 09:17 |
| lpapp | rburton: even the whole build dir, not the downloads, is much less here than 22 GB. | 09:17 |
| lpapp | ndec: we have never had any issues with this on denzil. | 09:17 |
| lpapp | then, maybe the previous suggestion is not valid about this not supposed to work. | 09:18 |
| lpapp | and the root cause may be something else. | 09:18 |
| lpapp | but it has definitely worked on denzil off-hand. | 09:18 |
| ndec | lpapp: it might depends on how you manage your download 'git tree' too. | 09:18 |
| lpapp | ? | 09:18 |
| ndec | how do you add/commit stuff in your tree. | 09:19 |
| lpapp | denzil: du -sh downloads/ | 09:19 |
| lpapp | 261M downloads/ | 09:19 |
| lpapp | ndec: not sure what you mean. | 09:19 |
| lpapp | rburton: I am sure your download is not containing only image-core-minimal ... | 09:19 |
| lpapp | perhaps some very hefty stuff even perhaps the result of more builds. | 09:19 |
| ndec | when a build is done, there are new files in downloads. so i guess you have to commit these files for the next build | 09:20 |
| lpapp | ndec: ? | 09:20 |
| ndec | nevermind. | 09:20 |
| lpapp | ndec: downloads were checked as is after the successful local build. | 09:20 |
| lpapp | in* | 09:20 |
| lpapp | without any tinkering. | 09:21 |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has joined #yocto | 09:21 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 09:21 | |
| ndec | you 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 issue | 09:21 |
| lpapp | I am not sure what you mean. | 09:22 |
| ndec | your tree on your CI server is different from your local tree where you did your commit. | 09:22 |
| lpapp | it is not missing any files. | 09:22 |
| lpapp | it is the same as locally. | 09:22 |
| lpapp | and local works just fine. | 09:22 |
| ndec | no. | 09:22 |
| lpapp | yep | 09:22 |
| ndec | locally you must have these 'refs' an branches folder which are missing on the server. | 09:22 |
| lpapp | no | 09:22 |
| ndec | in downloads/git2/.. | 09:22 |
| lpapp | it is the local stuff not having it, and working fine. | 09:23 |
| ndec | because you don't start with a clean env, and the sources are from sstate? | 09:23 |
| ndec | or already unpacked | 09:23 |
| lpapp | I always start with clean state. | 09:23 |
| lpapp | especially before checking in. | 09:23 |
| lpapp | oh, btw, and the server seems to have branches and refs. | 09:24 |
| lpapp | SRCREV is present in that bare clone. | 09:25 |
| *** Daemon404 <Daemon404!~who_knows@S0106586d8f4832af.tb.shawcable.net> has quit IRC | 09:26 | |
| lpapp | perhaps I did some half-baked check in, I will double check again. | 09:26 |
| lpapp | it 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 up | 09:27 |
| lpapp | it would be a lot easier if stuff just worked out of the box on arch. ;) | 09:27 |
| lpapp | oh, hmm, I actually have an idea what went haywire! | 09:30 |
| lpapp | I got a push feedback from git about a few thousand files | 09:30 |
| lpapp | it was a warning... maybe git cannot handle 4-5.000 files? | 09:30 |
| lpapp | and several files were left out accordingly? | 09:30 |
| lpapp | ndec: git add that-gtk-doc-stuff-dir does not seem to add branches and refs. | 09:33 |
| lpapp | is that a correct behavior? We do not have anything like that in .gitignore, whatsoever. | 09:34 |
| ndec | lpapp: 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/git.py. | 09:36 |
| ndec | my feeling is that your issue is related to download being in a git tree already. | 09:37 |
| lpapp | actually the issue is this: | 09:37 |
| lpapp | scp -r A.B.C.D:/home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/downloads/git2/git.gnome.org.gtk-doc-stub/branches ./downloads/git2/git.gnome.org.gtk-doc-stub/ | 09:38 |
| lpapp | which gives no result. | 09:38 |
| lpapp | why is that? | 09:38 |
| lpapp | -> /home/lpapp/Projects/Yocto/poky-dylan-9.0.1/build/downloads/git2/git.gnome.org.gtk-doc-stub/branches presents on the server. Is it because it is an empty folder? | 09:38 |
| lpapp | then who cares about branches and refs if they are empty? | 09:38 |
| lpapp | at least, branches is empty. | 09:39 |
| lpapp | yeah, scp does not copy empty folders, which is really empty for gtk doc stub. | 09:40 |
| lpapp | oh, git needs those for operate even if they are empty. | 09:41 |
| lpapp | but git add actually does not add empty folders to the repository. | 09:42 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 09:48 | |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto | 09:49 | |
| -YoctoAutoBuilder- build #237 of nightly-oecore is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-oecore/builds/237 | 09:52 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 10:03 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto | 10:08 | |
| *** Saur <Saur!pkj@nat/axis/x-tgxbnipafcplcnzs> has joined #yocto | 10:09 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 10:09 | |
| lpapp | hmm, would the bare git clone be necessary also for local mirrors? | 10:10 |
| lpapp | or there, we would only have the tarballs? | 10:10 |
| Stygia | Hey, 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 |
| lpapp | Stygia: yes, a few people. | 10:14 |
| Stygia | lpapp, 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!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 10:15 | |
| rburton | Stygia: hm, what list was that sent to? | 10:17 |
| rburton | Stygia: openembedded-devel@lists.openembedded.org is the list for most non-oe-core patches | 10:17 |
| Stygia | rburton, yes, I'm pretty sure this is where I send it. | 10:17 |
| Stygia | rburton, Ah wait, shit, I send it to core. Fuck me, just a sec | 10:18 |
| Stygia | rburton, Now I send it to openembedded-devel@ | 10:18 |
| * rburton looks at oe-core again | 10:18 | |
| Stygia | .. sorry. I just execute things from my bash history too damn often. Usually it only bothers me and nobody else. | 10:19 |
| rburton | :) | 10:19 |
| Stygia | rburton, 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 |
| Stygia | rburton, Anyway... If this looks right/is formatted properly/etc I'll be sending up a ton of patches soon. | 10:21 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 10:22 | |
| rburton | Stygia: feel free to pastebin the patch first if you want to get a quick review | 10:23 |
| Stygia | rburton, 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!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 10:24 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 10:24 | |
| Stygia | rburton, 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. :P | 10:24 |
| Net147 | Stygia: are you subscribed to the mailing list? | 10:27 |
| rburton | Stygia: encoding warnings aren't generally a problem | 10:27 |
| rburton | but i suspect you're in the moderation queue | 10:27 |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto | 10:28 | |
| Stygia | rburton, I'm pretty sure I am. | 10:28 |
| Stygia | rburton, Quite possible. I have made a commit or two that was misformatted... | 10:28 |
| Stygia | rburton, But for reference this is the patch: http://pastebin.com/cRh6CpBB | 10:29 |
| Net147 | Stygia: is your git author email you used when sending the patch the same as the email you subscribed with? | 10:29 |
| rburton | Stygia: looks good to me :) | 10:29 |
| rburton | Stygia: PATCHBOMB | 10:29 |
| Stygia | I'm pretty sure, yes, erp@movis.dk | 10:30 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 10:33 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 10:41 | |
| *** daBONDi_work <daBONDi_work!~david@80.122.151.98> has joined #yocto | 10:59 | |
| daBONDi_work | hi 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_work | currently 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 /init | 11:03 |
| daBONDi_work | i use follow lines in syslinux.cfg | 11:04 |
| daBONDi_work | KERNEL /vmlinuz | 11:04 |
| daBONDi_work | APPEND initrd=/core-image-minimal-mrec-dev-iei-pv-d525-20130821103541.rootfs.cpio.gz rootfs=/dev/ram0 console=tty0 | 11:04 |
| daBONDi_work | sorry for asking prbly this dumb question, but iam quite a linux n00b =) | 11:05 |
| Stygia | daBONDi_work, I'm pretty sure cpio isn't a rootfs, I think you need the *.rootfs.tar.gz file | 11:06 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 11:06 | |
| daBONDi_work | prbly i need a initrd Image with rootfs Included, thats what iam reading, but don't know how to do that in an yocto bb | 11:07 |
| daBONDi_work | :/ | 11:07 |
| *** abelloni <abelloni!~piout@128-79-216-144.hfc.dyn.abo.bbox.fr> has quit IRC | 11:08 | |
| Stygia | daBONDi_work, Initrd is an init ram fs, not a root fs as such. | 11:09 |
| Stygia | daBONDi_work, to boot just from the init ram fs, you need the cpio and initramfs files. | 11:10 |
| *** abelloni <abelloni!~piout@128-79-216-144.hfc.dyn.abo.bbox.fr> has joined #yocto | 11:10 | |
| Stygia | daBONDi_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_work | so i need to make something like core-minimal-image-initramfs | 11:12 |
| daBONDi_work | and appanend in syslinux another initrd file | 11:12 |
| daBONDi_work | with the rootfs.cpio | 11:12 |
| Stygia | daBONDi_work, Hmm. I'm not expert, so don't rely on just my saying so, but that does sound about right. | 11:13 |
| ant_work | some bootloaders are supposed to be able to chain multiple initramfs | 11:13 |
| ant_work | http://gentoo-en.vfose.ru/wiki/Talk:Initramfs#multiple_initramfs | 11:13 |
| daBONDi_work | my intention is to make a system booting into ram | 11:13 |
| ant_work | what will surely work is embedding a cpio in a first kernel and while booting the kernel add another initrd= | 11:14 |
| ant_work | I've tested it, 2 cpio stacked | 11:15 |
| daBONDi_work | looks like grub can do it | 11:15 |
| daBONDi_work | but prbly iam to dumb i need more learning on the linux boot process :-) | 11:15 |
| Stygia | I'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 |
| Stygia | Not 100% if you can hotswap that, though, but still. | 11:16 |
| daBONDi_work | currently we using debirf for the system | 11:16 |
| daBONDi_work | it builds a debian system to run in ram | 11:16 |
| daBONDi_work | but customization is a pain in the ass :-) | 11:17 |
| daBONDi_work | so i was hoping yocto can built that to, but with the superb bitbake engine | 11:17 |
| ant_work | if it can give any idea, see how we do for a linux-as-bootloader (kexec) specific initramfs inmplementation | 11:19 |
| Stygia | daBONDi_work, I'm not 100% _exactly_ how, but I'm pretty damn sure you can do that, yea. | 11:19 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 11:19 | |
| ant_work | http://kexecboot.org/documentation/crosscompiling/oe-yocto | 11:19 |
| daBONDi_work | i found the kexec thing also, prbly should look again and try to understand it completly :-) | 11:20 |
| ant_work | in that case kexecboot is the init process | 11:21 |
| ant_work | you can customize as you want | 11:21 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 11:25 | |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC | 11:27 | |
| Stygia | rburton, 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 |
| Stygia | rburton, Probably a silly question, but I've never contributed anything to an open source project before, so. | 11:29 |
| rburton | Stygia: there's a changelog sent weekly, or just watch the repo | 11:29 |
| rburton | we don't do "thanks your patch has been merged" mails as that would be incredibly tiresome to send :( | 11:30 |
| Stygia | rburton, 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 |
| rburton | Stygia: 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 thread | 11:31 | |
| *** belen <belen!~Adium@134.134.139.72> has quit IRC | 11:31 | |
| *** belen <belen!Adium@nat/intel/x-krxslxacdtpmouom> has joined #yocto | 11:32 | |
| Stygia | rburton, Yes. | 11:33 |
| Stygia | rburton, I am trying to commit these patches to meta-perl in oe-devel | 11:33 |
| Stygia | rburton, I made two commits there, for libcarp-perl and libtaint-util-perl | 11:34 |
| Stygia | rburton, in... meta-perl/recipes-perl/ | 11:34 |
| Stygia | rburton, under meta-openembedded. | 11:34 |
| rburton | cool | 11:34 |
| otavio | :) | 11:40 |
| rburton | meta-perl lives! IT LIVES! MWHAHAHAHAHAHA. | 11:41 |
| Stygia | rburton, Hah. | 11:42 |
| Stygia | I'll make it live, whether it wants to or not. | 11:42 |
| Stygia | I 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 |
| zibri | :) | 11:43 |
| Stygia | Plus 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@178.124.16.226> has quit IRC | 11:43 | |
| *** _alex_kag_ <_alex_kag_!~alex_kag@178.124.16.226> has joined #yocto | 11:44 | |
| Stygia | Oh 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 |
| Stygia | zibri, 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@178.124.16.226> has quit IRC | 11:45 | |
| zibri | no, nothing right now. but thanks! i'll let you know :) | 11:45 |
| *** _alex_kag_ <_alex_kag_!~alex_kag@178.124.16.226> has joined #yocto | 11:45 | |
| zibri | at least i'll double check so that i'm not duplicating your efforts! | 11:46 |
| Stygia | zibri, Oh yea, don't go making any cpan recipes anytime soon. :P I'm almost bound to have it at this point. | 11:46 |
| Stygia | zibri, Although I was lazy with DEPENDS so I'll have to clean up before I commit. | 11:46 |
| *** _alex_kag_ <_alex_kag_!~alex_kag@178.124.16.226> has quit IRC | 11:50 | |
| jeremiah | perl -pe -i 's/.*/w00t!/' /etc/motd :D | 11:52 |
| erbo | jeremiah: don't tell me you have a notification when someone mentions perl in a channel? :) | 11:53 |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has left #yocto | 11:53 | |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has joined #yocto | 11:53 | |
| jeremiah | erbo: hits erbo with the camel book | 11:53 |
| Stygia | jeremiah, Heh. I actually have that right here. | 11:54 |
| Stygia | Fun story... the camel is actually scrapped off. | 11:54 |
| jeremiah | lol! | 11:54 |
| jeremiah | Now _that_ is heavy use | 11:54 |
| Stygia | Because I bunked with muslims and its "Shirk" (polytheism) to pray in the same room as a picture of an animal. | 11:54 |
| zibri | embrace the camel | 11:54 |
| erbo | I 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 |
| jeremiah | Stygia: Ah, wow. | 11:54 |
| Stygia | So... not the camel on my camel book has no face. | 11:54 |
| Stygia | *now | 11:55 |
| Stygia | Like an old painting of Muhammad, kinda hilarious. | 11:55 |
| B4gder | so, rather than moving the precious book you patched it? =) | 11:55 |
| jeremiah | erbo: I think you're thinking of the lama book | 11:55 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 11:56 | |
| lpapp | hi, do I need to define a do_compile function even though I would just do the regular make in a subfolder? | 11:56 |
| Stygia | B4gder, Yea it's just the cover, not like the picture of the camel matters at all. | 11:56 |
| Stygia | lpapp, You should probably have the do_compile function doing that, it's what it's for | 11:56 |
| lpapp | Stygia: why? running "make" is pretty common. | 11:57 |
| Stygia | lpapp, Well, the idea of using the recipes is to not have to do it manually. | 11:57 |
| Stygia | lpapp, If you're gonna manually cd there and make, why use a recipe? | 11:57 |
| zibri | base.bbclass defines a simple oe_runmake | 11:57 |
| lpapp | Stygia: you are not following. | 11:57 |
| Stygia | lpapp, Possible. | 11:57 |
| lpapp | Stygia: I do use a recipe, but why would everyone start adding the regular "make" for manual execution? | 11:58 |
| zibri | defines a simple do_compile calling oe_runmake* | 11:58 |
| *** elmi82_ <elmi82_!~timo@mail.bmw-carit.de> has joined #yocto | 11:58 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 11:58 | |
| lpapp | for execution* | 11:58 |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has joined #yocto | 11:58 | |
| ant_work | lpapp: simplest do_compile () { | 12:00 |
| ant_work | ${CC} ${CFLAGS} ${LDFLAGS} foo.c -o foo | 12:00 |
| ant_work | } | 12:00 |
| rburton | lpapp: have a look at the default do_compile in base.bbclass | 12:00 |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has quit IRC | 12:01 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 12:02 | |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has joined #yocto | 12:02 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 12:04 | |
| lpapp | ant_work: as I said, it is about make, not ${CC}, i.e. we use Makefiles. | 12:05 |
| lpapp | rburton: 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 |
| rburton | lpapp: yeah, do_compile() { oe_runmake -C src} | 12:07 |
| Stygia | lpapp, 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 |
| Stygia | rburton, Couldn't he just set WORKDIR and import the maker class? | 12:07 |
| Stygia | autotools/automake IIRC. | 12:08 |
| rburton | Stygia: presumably there's something in the top-level that's useful, even if its license files | 12:08 |
| Stygia | rburton, Ah, hmm, right. That would prelude that unless you love ../ | 12:09 |
| rburton | i'd find it clearer to use make -C | 12:10 |
| Stygia | lpapp, Well you'd probably need to do make -C src, then, unless you simply want a flat 'fake' | 12:10 |
| Stygia | rburton, Yea exactly. | 12:10 |
| Stygia | Having relative paths all over the place is confusing. | 12:10 |
| rburton | but this is a one-line do_compile function | 12:10 |
| lpapp | rburton: thanks. | 12:11 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 12:16 | |
| *** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has quit IRC | 12:20 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 12:20 | |
| *** sameo <sameo!~samuel@192.55.55.37> has quit IRC | 12:20 | |
| ndec | lpapp: 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 |
| Stygia | Hmm. 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!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC | 12:22 | |
| Stygia | I 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 |
| lpapp | ndec: I prefer the inline version. | 12:25 |
| Stygia | I would lean towards writing my own php.ini, adding it to the PHP recipe, and then writing that out? | 12:25 |
| *** scot__ <scot__!~scot@130.164.62.183> has joined #yocto | 12:26 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 12:29 | |
| zibri | i have build failures on syslinux: http://codepad.org/rh1sVIbU, "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 |
| lpapp | why am I getting unpack issues for such a line? SRC_URI = "file://foo.xz \ | 12:44 |
| lpapp | and foo.xz is in $packageroot/foo | 12:45 |
| erbo | lpapp: shouldn't it be do_fecth that failed it it couldn't find the file? | 12:47 |
| erbo | no more details in the error msg? | 12:47 |
| lpapp | ERROR: Function failed: Unpack failure for URL: 'file://foo.xz'. | 12:48 |
| lpapp | xz -dc /path/to/foo.xz | tar x --no-same-owner -f - failed with return value 2 | 12:48 |
| lpapp | xz: /path/to/foo.xz: File format not recognized | 12:49 |
| lpapp | | tar: This does not look like a tar archive | 12:49 |
| lpapp | | tar: Exiting with failure status due to previous errors | 12:49 |
| lpapp | oopsie, corrupted file as it seems, bizarro. | 12:49 |
| erbo | hmm, maybe it expects a tar.xz and not .xz | 12:50 |
| lpapp | erbo: mayhaps ... | 12:51 |
| erbo | it sure looked like it piped the output to tar atleast :) | 12:52 |
| lpapp | rburton: -C src will not work | 12:54 |
| lpapp | it apparently needs the version folder first something like 0.1-r0 | 12:54 |
| lpapp | or WORKDIR or something | 12:55 |
| rburton | lpapp: it starts in $S | 12:55 |
| lpapp | make: *** src: No such file or directory. Stop. | 12:55 |
| lpapp | I do have such a folder. | 12:56 |
| lpapp | so why is make asserting? | 12:56 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 12:57 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 12:59 | |
| rburton | maybe your default S is bad? | 12:59 |
| rburton | have a look in the work directory | 12:59 |
| lpapp | ? | 12:59 |
| rburton | S defaults to $WORKDIR/$PN-$PV | 13:00 |
| rburton | if that isn't where your sources appeared, set S to where they are | 13:00 |
| lpapp | I am not sure what you mean. | 13:00 |
| lpapp | ./tmp/work/armv5te-polatis-linux-gnueabi/oxcopenflowagent/0.1-r0/ | 13:00 |
| lpapp | oops, wrong content | 13:00 |
| lpapp | ./tmp/work/bar/foo/0.1-r0 -> that is the source folder where "src" should be found. | 13:01 |
| rburton | work, so your S isn't right | 13:01 |
| rburton | set S to where the sources ended up | 13:01 |
| rburton | the default assumes you've a tarball which expands to foo-0.1 | 13:01 |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 13:04 | |
| lpapp | why don't I have that folder name? | 13:04 |
| lpapp | I mean by default. | 13:04 |
| rburton | because your sources didn't extract like that | 13:04 |
| rburton | unpack simply extracts the tarballs it put into WORKDIR | 13:05 |
| rburton | and the default is to assume that one of them used PN-PV as a directory | 13:05 |
| rburton | if that isn't the case, then you need to set S | 13:05 |
| lpapp | not sure I follow. | 13:06 |
| lpapp | I have got the 0.1-r0 stuff instead of foo foo-0.1, why? | 13:06 |
| lpapp | that has not much to do with the compression. | 13:06 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 13:06 | |
| rburton | that's workdir, where your SRC_URI contents got dropped | 13:06 |
| lpapp | I mean... my uncompressed content should reside in that folder. | 13:06 |
| rburton | unpack happens and extracts everything | 13:06 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 13:07 | |
| rburton | if the tarball didn't unpack into a PN-PV directory, then you need to set S to point to where it did unpack | 13:07 |
| rburton | ie maybe the directory isn't versioned | 13:08 |
| lpapp | so basically I need to use prefix when archiving with git. | 13:08 |
| lpapp | IMO, Yocto could do this right by default. | 13:08 |
| rburton | define "right" | 13:09 |
| rburton | there is no "right" | 13:09 |
| lpapp | create ${PN}-{PV} | 13:09 |
| rburton | and then what? | 13:09 |
| rburton | you've an empty directory | 13:09 |
| lpapp | and then get it working off-hand? | 13:09 |
| rburton | as your sources when somewhere else | 13:09 |
| lpapp | ? | 13:09 |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has quit IRC | 13:09 | |
| rburton | yes, if you're using git-archive, it makes sense to use --prefix and use name-version/ | 13:09 |
| lpapp | no, the sources should be uncompressed into that by Yocto. | 13:09 |
| lpapp | if there is no prefix inside the archive. | 13:10 |
| rburton | define no prefix | 13:10 |
| rburton | what if there are files and directories? | 13:10 |
| lpapp | ? | 13:10 |
| rburton | the default of S=PN-PV works for 99% of software in yocto | 13:10 |
| lpapp | yeah, but apparently release guys have to do it manually. | 13:11 |
| lpapp | rather than not using prefix, and yocto adding them by default. | 13:11 |
| rburton | tell the people making tarballs to use --prefix | 13:11 |
| lpapp | this is already coded into the recipe name after all, so it would not be hard. | 13:11 |
| rburton | every tarball since the mid-70s starts with a directory | 13:11 |
| rburton | so yours should too | 13:11 |
| lpapp | erm, it is not about what it should. | 13:12 |
| lpapp | Yocto could have a fallback. | 13:12 |
| lpapp | when it is not, it is adding that. | 13:12 |
| lpapp | or at least warning, whatever. | 13:13 |
| lpapp | or both, actually. | 13:13 |
| rburton | we can add a warning that S doesn't exist | 13:13 |
| rburton | you probably had that in the logs already | 13:13 |
| lpapp | no, that is an error | 13:13 |
| lpapp | what I am saying there should be no error at all for simply missing prefices. | 13:14 |
| rburton | it used to be auto-created which did confuse people, because you didn't get errors | 13:14 |
| lpapp | warning | 13:14 |
| lpapp | not error. | 13:14 |
| lpapp | if you skip a warning, you are on your own ... | 13:14 |
| lpapp | so what is confusion in there? :) | 13:14 |
| *** cfo215 <cfo215!~christos@mail.abemblem.com> has joined #yocto | 13:14 | |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has joined #yocto | 13:14 | |
| lpapp | rburton: does that make sense? | 13:17 |
| *** jkridner <jkridner!~jkridner@nat/ti/x-csuqsmeypbmepruv> has joined #yocto | 13:25 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 13:25 | |
| *** scot__ <scot__!~scot@130.164.62.183> has quit IRC | 13:25 | |
| *** scot <scot!~scot@130.164.62.183> has joined #yocto | 13:25 | |
| lpapp | hmm, if a makefile for a software contains this line right at the beginning: CC = gcc | 13:35 |
| lpapp | will Yocto use the cross compiler supplied, i.e. can it override that somehow? | 13:36 |
| lpapp | or that is a bad practice from the software author? | 13:36 |
| rburton | thats bad practise | 13:36 |
| rburton | "However, an explicit assignment in the makefile, or with a command argument, overrides the environment." | 13:36 |
| rburton | says the make manual | 13:36 |
| RP | I think we use make -e don't we? | 13:37 |
| RP | so we force our environment to override the makefile | 13:37 |
| rburton | oh, do we? | 13:37 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 13:37 | |
| rburton | so we do! | 13:37 |
| zibri | oe_runmake does that yes. | 13:37 |
| ndec | yes, we do. | 13:37 |
| rburton | learn something new every day ;) | 13:38 |
| rburton | lpapp: it should get overridden by the cross compiler then | 13:38 |
| RP | bitbake.conf: EXTRA_OEMAKE = "-e MAKEFLAGS=" | 13:38 |
| rburton | another good reason to use oe_runmake instead of make directly | 13:39 |
| ndec | however -e is not recursively passed by make. so if you have a top level makefile that 'recurses' , -e is lost. | 13:39 |
| rburton | that pretty much ruins the point then doesn't it? | 13:40 |
| ndec | yes... | 13:41 |
| ndec | i was just debugging an issue about that last friday... | 13:41 |
| ndec | that's when i noticed. | 13:41 |
| lpapp | meh | 13:41 |
| lpapp | limitation for doing the right thing in there is? | 13:42 |
| rburton | lpapp: probably along the lines of "posix make says its isn't preserved" | 13:42 |
| rburton | hand-rolling a build system using raw makefiles is so much effort | 13:43 |
| lpapp | so what is the right practice? Not have CC line at all? Note, I have not written Makefiles by hand the last 5-6 years | 13:43 |
| lpapp | have been mostly using qmake, cmake, and a bit of autotools before. | 13:43 |
| lpapp | where I do not need to care so much about all this. | 13:43 |
| lpapp | rburton: yeah, that is where I agree. | 13:43 |
| lpapp | IMHO, we should use cmake, but that is not a discussion for today. | 13:44 |
| rburton | lpapp: shame, that's a perfectly reasonably solution | 13:44 |
| lpapp | so what is the right GNU Makefile practice? | 13:44 |
| *** melonipoika <melonipoika!~quassel@a88-115-25-114.elisa-laajakaista.fi> has joined #yocto | 13:46 | |
| ndec | rburton: well, i think the '-e' is lost because we also set MAKEFLAGS= | 13:46 |
| ndec | otherwise the -e would be recursively used. | 13:46 |
| rburton | lpapp: well, are you recursing? the defaults may just work. | 13:47 |
| lpapp | rburton: yes | 13:47 |
| lpapp | I am recursing. | 13:47 |
| ndec | you could change EXTRA_OEMAKE not -e only, to see. | 13:48 |
| ndec | i haven't tried that yet. | 13:48 |
| ndec | i am not sure why we do MAKEFLAGS= | 13:49 |
| lpapp | rburton: we can adjust the software easily though if needed... it was not written by me. | 13:49 |
| rburton | lpapp: try changing that assignment to CC?=gcc | 13:50 |
| rburton | then the environment variable might take priority | 13:50 |
| rburton | been a while since i've written a real makefile :( | 13:50 |
| rburton | but a quick test says that should work | 13:51 |
| rburton | note that CC already has a default in make, of "cc", which will also work so you don't even need to set CC | 13:51 |
| rburton | its a default variable, there's loads of those | 13:51 |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 13:53 | |
| *** cfo215 <cfo215!~christos@mail.abemblem.com> has left #yocto | 13:56 | |
| *** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto | 13:57 | |
| *** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has quit IRC | 13:57 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 13:57 | |
| *** sameo <sameo!~samuel@192.55.55.37> has joined #yocto | 13:59 | |
| lpapp | rburton: ok, so just remove. | 14:00 |
| Stygia | Hey, we're having a weird (if relatively minor) issue with our boxes, and I wondered if anyone here'd seen anything similar. | 14:00 |
| Stygia | When we update our box's system image, we (right now) SCP an image over and reboot the box via SSH. | 14:00 |
| Stygia | However, 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 |
| Stygia | Immediately, 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 |
| Stygia | Anyone here seen something like this before? | 14:01 |
| *** Zagor <Zagor!~bjst@rockbox/developer/Zagor> has quit IRC | 14:02 | |
| rburton | Stygia: stupid usb power management? | 14:02 |
| rburton | x86 kernels until a few days ago enabled usb power management, which was Bad | 14:02 |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has quit IRC | 14:02 | |
| Stygia | rburton, 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 |
| Stygia | rburton, Hmm. I've honestly no idea. | 14:03 |
| Stygia | rburton, Sometimes it works, this time it did it right away. Sometimes it hangs. | 14:03 |
| Stygia | rburton, But, your suggestion would be trying a 3.10-ish kernel? | 14:03 |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has joined #yocto | 14:04 | |
| Stygia | rburton, 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 |
| rburton | Stygia: is the keyboard usb? | 14:04 |
| rburton | i've just seen keyboards acting odd when autosuspend was enabled | 14:05 |
| rburton | but unless you're running linux-yocto on x86, it should be disabled | 14:05 |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has quit IRC | 14:07 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 14:07 | |
| *** cfo215 <cfo215!~christos@mail.abemblem.com> has joined #yocto | 14:08 | |
| *** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC | 14:08 | |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has joined #yocto | 14:09 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 14:09 | |
| *** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto | 14:09 | |
| *** kspr <kspr!~Kasper@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has quit IRC | 14:09 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 14:11 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has quit IRC | 14:12 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 14:12 | |
| cfo215 | I'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 qt4-embedded_4.8.3.bb). | 14:15 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 14:17 | |
| lpapp | cfo215: qt4? | 14:18 |
| lpapp | cfo215: any reason why not getting qt5 with meta-qt5? | 14:19 |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto | 14:19 | |
| cfo215 | lpapp: I'm more familiar with qt4. | 14:19 |
| lpapp | cfo215: yeah, but it is getting dead end. | 14:19 |
| lpapp | maybe there will be one more "last" bugfix release, but that is pretty much it. | 14:20 |
| *** LiangC <LiangC!~Leon@76.78.7.186> has joined #yocto | 14:20 | |
| lpapp | qt 5.2 feature freeze is less than a month ahead. | 14:20 |
| *** LiangC <LiangC!~Leon@76.78.7.186> has quit IRC | 14:20 | |
| *** LiangC <LiangC!~Leon@76.78.7.187> has joined #yocto | 14:20 | |
| cfo215 | lpapp: 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 |
| lpapp | cfo215: yes, of course. | 14:21 |
| cfo215 | lpapp: is meta-qt5 supported in "dev" builds; i.e. if I want to create a tool-chain build? | 14:22 |
| lpapp | cfo215: ? | 14:23 |
| cfo215 | when 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 |
| cfo215 | lpapp: I'll add meta-qt5 to my mix and see what happens ;) | 14:26 |
| lpapp | cfo215: sorry, but I am not sure what you mean. Apparently, this explanation is not clear for me. | 14:26 |
| lpapp | how is a toolchain build related to qt5? | 14:27 |
| lpapp | toolchain build is happening way before a software like qt5 as that is the first in the queue. | 14:27 |
| ndec | i think cfo215 means a 'SDK' that includes the toolchain and all the libs/headers | 14:28 |
| cfo215 | lpapp: no worries. I'm just learning this whole process. I'm more used to ./configure; make; make install... | 14:28 |
| ndec | i haven't tried for QT5, but several people have complained that SDK wasn't working, i believe. | 14:28 |
| cfo215 | ndec:lpapp: that is exactly what I mean. | 14:28 |
| lpapp | yeah, bluelightning claimed that SDK was not working. | 14:28 |
| lpapp | cfo215: so you might be out of luck with that... | 14:29 |
| lpapp | I have no idea what an SDK creation means though on the yocto level. | 14:29 |
| cfo215 | ndec:lpapp: which is why I was looking to use qt4.. :) | 14:29 |
| ndec | sure. | 14:29 |
| lpapp | cfo215: well, how about looking into the issue, and see if it is easy to fix? | 14:29 |
| cfo215 | ndec:lpapp: I don't need to be on the "bleading-edge" for my app. | 14:29 |
| lpapp | qt4 is really dead end, and no one should use it for new projects. | 14:29 |
| *** arky <arky!~arky@58.187.83.102> has joined #yocto | 14:30 | |
| lpapp | cfo215: it is more than just not bleeding edge. | 14:30 |
| lpapp | effectively, you are not getting any fixes anymore. | 14:30 |
| lpapp | except a very few still sneaking in. | 14:30 |
| cfo215 | lpapp: I don't think I really have the skills for that. | 14:30 |
| *** melonipoika <melonipoika!~quassel@a88-115-25-114.elisa-laajakaista.fi> has quit IRC | 14:31 | |
| *** Guest49189 <Guest49189!~trz@c-68-53-177-94.hsd1.in.comcast.net> has left #yocto | 14:31 | |
| lpapp | cfo215: well, if it is qt related, I can help. If it is yocto related, others can help in here. | 14:31 |
| lpapp | I would help fixing it, but I do not even know why an SDK is needed. | 14:31 |
| lpapp | or what it is supposed to provide. | 14:31 |
| lpapp | you can already build a library by adding a recipe. | 14:31 |
| cfo215 | lpapp: ic, i'll try qt5 and see what happens. May as well jump into the pool. | 14:31 |
| lpapp | what more does an sdk provide? | 14:32 |
| cfo215 | lpap: the build paths; libraries; etc. conveniently bundled into a 'source'able environment file. just makes development for a platform easier. | 14:33 |
| cfo215 | lpapp: that way when your developing you just source the environment and your compiles know where everything is. | 14:34 |
| cfo215 | lpapp:ndec: thanks for your input. I value it. | 14:35 |
| ndec | np. | 14:35 |
| *** levi <levi!~user@174.52.89.43> has joined #yocto | 14:38 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 14:39 | |
| lpapp | cfo215: I would say, let us fix the qt5 stuff unless it is a terrible pain. :) | 14:41 |
| lpapp | qt4 is sooo much dead that it is only worth considering if there are headaches not doing so. | 14:41 |
| lpapp | not doing the qt5 stuff, that is. | 14:41 |
| cfo215 | lpapp: I certainly couldn't fix it. ;) | 14:42 |
| lpapp | cfo215: never know if you do not try. | 14:43 |
| cfo215 | lpapp: 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 |
| lpapp | cfo215: iirc the 20th of september is the feature freeze for 5.2 | 14:44 |
| lpapp | cfo215: 5.1.1 is soon out. | 14:44 |
| cfo215 | lpapp: true that! | 14:44 |
| lpapp | 5.0 was out last December. | 14:44 |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 14:44 | |
| *** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC | 14:45 | |
| ndec | lpapp: 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!~marsman@90-145-17-249.wxdsl.nl> has joined #yocto | 14:45 | |
| lpapp | ndec: we will see. | 14:46 |
| ndec | note that if you do it, i will use it ;-) since i need it too! | 14:46 |
| cfo215 | ndec: 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 |
| cfo215 | Missing or unbuildable dependency chain was: ['console-image', 'qt4-embedded_4.8.3'] | 14:46 |
| lpapp | ndec: well, I do not care that much about something I do not even understand what it is for. | 14:46 |
| lpapp | but I am happy to help with qt5 in general. | 14:46 |
| cfo215 | lpapp: I may just be calling on you for that... | 14:47 |
| cfo215 | I tried IMAGE_INSTALL_append += "qt4" and IMAGE_INSTALL_append += "qt4-embedded_4.8.3" in my local.conf with similar results | 14:48 |
| *** sameo <sameo!~samuel@192.55.55.37> has quit IRC | 14:50 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has quit IRC | 14:52 | |
| cfo215 | lpap: another newb question: where do I clone meta-qt5? in the top-level source dir or in meta-openembedded or someplace else? | 14:57 |
| ndec | cfo215: where you want ;-) | 14:58 |
| lpapp | cfo215: up to you, I do it next to the other layers. | 14:58 |
| ndec | you just need to put the right path in bblayer.conf | 14:58 |
| lpapp | cfo215: but I know some people here do this right outside poky, so not next to the poky layers. | 14:58 |
| cfo215 | ndec:lpapp: thanks, that may have answered my other problem... forgot to update bblayer.conf for qt4. | 14:59 |
| ndec | that should help indeed. | 14:59 |
| *** AlexG <AlexG!86bfdd48@gateway/web/freenode/ip.134.191.221.72> has joined #yocto | 15:01 | |
| cfo215 | ndec: 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.conf | 15:01 |
| cfo215 | ndec: no change to bblayers.conf. Bitbake "just" found it... though I think it's supposed too... lol | 15:02 |
| lpapp | I wonder if anyone can provide me a link to this SDK stuff | 15:03 |
| lpapp | to read a more upon it. | 15:03 |
| kergoth | cfo215: 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-qt5 | 15:03 |
| *** zenlinux_ <zenlinux_!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 15:04 | |
| ndec | lpapp: from high level http://www.yoctoproject.org/docs/current/adt-manual/adt-manual.html | 15:04 |
| ndec | the 'SDK' is a 'standalone' installer that contains the cross compiler, qemu, and all 'dev' files for all packages. | 15:04 |
| cfo215 | kergoth: 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 |
| ndec | lpapp: you generally create the SDK with bitbake -c populate_sdk <image> | 15:05 |
| ndec | and you get it in tmp/deploy/sdk | 15:05 |
| cfo215 | ndec: thaks for that tip... writing it down... | 15:05 |
| lpapp | ndec: I have read that manual, but apparently it did not make it clear for me. | 15:05 |
| ndec | you can then redistribute to others that can build applications against your image without needing to use OE. | 15:05 |
| lpapp | ndec: isn't the cross compiler built by core-image-minimal anyways? | 15:06 |
| ndec | yes. but the 'SDK' is relocatable. e.g. you can install it on a nother PC. | 15:06 |
| lpapp | and why cannot a qt5 image just work without the need to use OE? | 15:06 |
| lpapp | how is the toolchain not relocatable? | 15:07 |
| ndec | in terms of hard coded path. | 15:07 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 15:07 | |
| lpapp | ? | 15:08 |
| *** sameo <sameo!samuel@nat/intel/x-dnkcbjaeqqzoocnr> has joined #yocto | 15:08 | |
| *** jkridner|work <jkridner|work!~jkridner@nat/ti/x-hzgsmswpdogrtrfn> has joined #yocto | 15:09 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 15:09 | |
| ndec | the toolchain as it's built in tmp/sysroot cannot be 'exported' onto another PC. | 15:10 |
| ndec | the 'SDK' with -c populate_sdk allows you to do that. | 15:10 |
| ndec | the 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 IRC | 15:10 | |
| ndec | i am not sure what you don't understand. | 15:10 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 15:10 | |
| *** mranostay <mranostay!~mranostay@pdpc/supporter/active/mranostay> has joined #yocto | 15:12 | |
| lpapp | ndec: actually, all that should work out of the box. | 15:13 |
| lpapp | without a dedicated sdk option imho. | 15:13 |
| lpapp | the 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 IRC | 15:14 | |
| lpapp | it is not something that sounds complex for end user in an ideal world. | 15:14 |
| *** sameo <sameo!samuel@nat/intel/x-steojqojsemntyam> has joined #yocto | 15:15 | |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has joined #yocto | 15:27 | |
| *** _Lucretia_ <_Lucretia_!~munkee@pdpc/supporter/active/lucretia> has joined #yocto | 15:30 | |
| *** jeremiah <jeremiah!~jeremiah@194-237-7-146.customer.telia.com> has quit IRC | 15:31 | |
| *** zenlinux <zenlinux!~sgarman@c-24-20-145-95.hsd1.or.comcast.net> has joined #yocto | 15:34 | |
| *** rikroled <rikroled!~tbn@84.55.160.118> has quit IRC | 15:53 | |
| *** smartin_ is now known as smartin | 15:53 | |
| *** belen <belen!Adium@nat/intel/x-krxslxacdtpmouom> has quit IRC | 15:55 | |
| *** nitink <nitink!nitink@nat/intel/x-ihyzgftjnreksfss> has quit IRC | 15:55 | |
| *** nitink <nitink!nitink@nat/intel/x-lfsguknexlurruys> has joined #yocto | 15:55 | |
| *** belen <belen!Adium@nat/intel/x-dfrjjotfzhuyzkqr> has joined #yocto | 15:57 | |
| *** arky <arky!~arky@58.187.83.102> has quit IRC | 15:59 | |
| *** belen2 <belen2!Adium@nat/intel/x-bbylakuhyeypomcp> has joined #yocto | 15:59 | |
| *** belen <belen!Adium@nat/intel/x-dfrjjotfzhuyzkqr> has quit IRC | 16:01 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 16:05 | |
| *** nitink <nitink!nitink@nat/intel/x-lfsguknexlurruys> has quit IRC | 16:06 | |
| *** nitink <nitink!nitink@nat/intel/x-ubdbuiibxxjhobqm> has joined #yocto | 16:07 | |
| *** davest <davest!Adium@nat/intel/x-avjfwtvgxlbpoavo> has joined #yocto | 16:09 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 16:09 | |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 16:10 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 16:11 | |
| *** nitink1 <nitink1!~nitink@134.134.137.73> has joined #yocto | 16:14 | |
| *** nitink <nitink!nitink@nat/intel/x-ubdbuiibxxjhobqm> has quit IRC | 16:14 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 16:20 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 16:22 | |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 16:24 | |
| *** zeeblex <zeeblex!apalalax@nat/intel/x-ldzbfwpwiutblirx> has left #yocto | 16:25 | |
| *** Stygia <Stygia!~gmpsaifi@x1-6-00-21-9b-e8-d0-5a.k663.webspeed.dk> has quit IRC | 16:29 | |
| *** nitink1 <nitink1!~nitink@134.134.137.73> has quit IRC | 16:29 | |
| *** nitink <nitink!nitink@nat/intel/x-giqjtdkrvcnytaxs> has joined #yocto | 16:29 | |
| RP | lpapp: 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 file | 16:31 |
| lpapp | that should just work out of the box with the right architecture. | 16:33 |
| lpapp | and all it would take, again with an ideal design, is to write a description. | 16:33 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 16:35 | |
| rburton | tw | 16:37 |
| lpapp | rburton: ? | 16:40 |
| rburton | wrong window! | 16:42 |
| *** nitink <nitink!nitink@nat/intel/x-giqjtdkrvcnytaxs> has quit IRC | 16:42 | |
| *** nitink <nitink!nitink@nat/intel/x-leyxmsfiprqdemez> has joined #yocto | 16:42 | |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has quit IRC | 16:42 | |
| *** cfo215 <cfo215!~christos@mail.abemblem.com> has left #yocto | 16:44 | |
| *** nitink <nitink!nitink@nat/intel/x-leyxmsfiprqdemez> has quit IRC | 16:47 | |
| *** nitink <nitink!~nitink@134.134.137.73> has joined #yocto | 16:48 | |
| *** shoragan <shoragan!~jlu@debian/developer/shoragan> has quit IRC | 16:52 | |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 16:52 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 16:55 | |
| kergoth | yow, weren't kidding about the parse slowdown with server mode :) | 16:59 |
| kergoth | brings back memories | 16:59 |
| *** zecke <zecke!~ich@p5099b351.dip0.t-ipconnect.de> has quit IRC | 16:59 | |
| rburton | haha | 17:03 |
| rburton | does it print "we recommend you install psyco"? | 17:03 |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 17:03 | |
| *** elmi82 <elmi82!~timo@mail.bmw-carit.de> has quit IRC | 17:05 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 17:06 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 17:09 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 17:10 | |
| *** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has quit IRC | 17:14 | |
| *** ftonello <ftonello!~felipe@wsip-70-183-20-162.oc.oc.cox.net> has joined #yocto | 17:14 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 17:16 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has left #yocto | 17:16 | |
| *** AlexG <AlexG!86bfdd48@gateway/web/freenode/ip.134.191.221.72> has quit IRC | 17:21 | |
| *** sameo <sameo!samuel@nat/intel/x-steojqojsemntyam> has quit IRC | 17:24 | |
| *** belen2 <belen2!Adium@nat/intel/x-bbylakuhyeypomcp> has quit IRC | 17:30 | |
| *** belen <belen!~Adium@134.134.139.72> has joined #yocto | 17:32 | |
| *** pidge <pidge!~pidge@134.134.139.72> has joined #yocto | 17:34 | |
| *** belen <belen!~Adium@134.134.139.72> has quit IRC | 17:35 | |
| *** mihai <mihai!~mihai@188.27.93.142> has joined #yocto | 17:35 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 17:44 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 17:45 | |
| *** cfo215 <cfo215!~christos@mail.abemblem.com> has joined #yocto | 17:48 | |
| cfo215 | does yocto support beaglebone out of the box or just beagleboard(-xm)? | 17:49 |
| kergoth | the bits provided by TI support both. see the meta-ti and meta-beagleboard layers | 17:51 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 17:57 | |
| *** mbroadst <mbroadst!~mbroadst@kde/developer/mbroadst> has joined #yocto | 18:08 | |
| *** zenlinux <zenlinux!~sgarman@c-24-20-145-95.hsd1.or.comcast.net> has quit IRC | 18:09 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 18:09 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 18:10 | |
| seebs | I 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 |
| cfo215 | kergoth: I added the meta-ti layer and updated my local.conf and bblayers.conf but get an error message when bitbaking. http://pastebin.com/cTAFT9xT | 18:17 |
| denix | cfo215: what branch are you using? | 18:18 |
| kergoth | cfo215: 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 |
| cfo215 | denix:kergoth: dylan | 18:19 |
| cfo215 | ? | 18:19 |
| kergoth | dylan is a yocto release, version 1.4, afaik | 18:19 |
| denix | cfo215: dylan has mesa-9.0.2 | 18:20 |
| *** reeve <reeve!81c0aafa@gateway/web/freenode/ip.129.192.170.250> has joined #yocto | 18:20 | |
| reeve | hi everyone | 18:20 |
| denix | cfo215: so, error about mesa-9.1.6 means you are not using matching branches | 18:21 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 18:21 | |
| lpapp | ndec: why is it difficult to fix the qt5 sdk stuff? | 18:21 |
| reeve | I'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/pm.py", 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 |
| cfo215 | denix: thanks I'm really a newbie here. | 18:22 |
| reeve | can anyone help me out? | 18:22 |
| cfo215 | and don't know how to match what to what. Is that documented somewhere? | 18:22 |
| denix | cfo215: 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 layers | 18:24 |
| cfo215 | denix: I followed the "Quick Start" from yocto-project. So gussing it's poky. | 18:25 |
| lpapp | cfo215: what is the issue? | 18:25 |
| cfo215 | lpapp: 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. http://pastebin.com/cTAFT9xT | 18:26 |
| denix | cfo215: if it says 1.4 in the name, then it's dylan. you need to clone corresponding branches of additional layers | 18:27 |
| denix | cfo215: specifically, switch your meta-ti clone to dylan, instead of master | 18:28 |
| cfo215 | denix: sorry a little vague on git: I use "git clone -b <branch name> <repository>" when doing that? | 18:28 |
| lpapp | cfo215: core-image-minimal should not have any relation to your meta-ti | 18:28 |
| cfo215 | lpapp: i added it to my bblayers.conf | 18:28 |
| lpapp | cfo215: cause of the toolchain or what do you use from there? | 18:29 |
| denix | cfo215: yes, or use git checkout later | 18:29 |
| cfo215 | denix: thanks... I was just consulting the man page for git... | 18:30 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 18:33 | |
| reeve | nobody knows my question? Where should I ask? | 18:34 |
| seebs | reeve: 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 |
| reeve | seebs: the other thing just look normal | 18:38 |
| reeve | seebs: let me try to paste more | 18:38 |
| seebs | I would recommend not pasting long output in IRC. | 18:38 |
| seebs | Mostly people overlook it, or have trouble reading it. | 18:38 |
| reeve | just a little bit more, you can tell what I said | 18:38 |
| seebs | But basically, that looked like a single line from an error message that would normally be 20+ lines. | 18:39 |
| reeve | or what's your suggestion? should I ask the question in mailing list? | 18:39 |
| *** Stygia <Stygia!~gmpsaifi@94.191.231.92.bredband.3.dk> has joined #yocto | 18:39 | |
| Stygia | Hey guys. | 18:39 |
| reeve | in fact on my screen that's 34 liens, let me paste line by line | 18:39 |
| seebs | My 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 |
| seebs | 34 lines is too much for IRC. | 18:39 |
| Stygia | I 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 |
| Stygia | Does that mean they got rejected? | 18:40 |
| reeve | sorry, 4 lines | 18: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/pm.py", 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/pm.py", line 297, in _process_rpmout | output = self.rpmout.read() | 18:40 |
| reeve | | File "/home2/reeve-ws/yocto-dylan-merge/build/tmp/sysroots/x86_64-linux/usr/lib/python2.7/codecs.py", 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 #yocto | 18:41 | |
| kergoth | Stygia: 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 shrugs | 18:41 | |
| reeve | seebs: it's a traceback from codec.py, complaining about ascii ... | 18:41 |
| seebs | Huh. That's a fascinating one. Some string, somewhere, which is expected to be all ASCII characters, has an 0xa1 in it. | 18:41 |
| seebs | Which is indeed out of range. | 18:41 |
| reeve | this is google's snappy package ... | 18:42 |
| Stygia | kergoth, Alright, fair enough. | 18:42 |
| Stygia | kergoth, And hah... like a day or two. | 18:42 |
| kergoth | ah, yeah, might just have to wait a bit longer :) | 18:43 |
| Stygia | kergoth, And, further, I probably got on some list that means I require moderation approval because I submitted 2-3 patches incorrectly. | 18:43 |
| Stygia | Alright, fair enough. Thanks, I just wondered if I could/should keep submitting my recipes. | 18:43 |
| cfo215 | kergoth: thanks for your help... cd meta-ti; git checkout dylan; cooking with gas now! | 18:45 |
| kergoth | cfo215: glad to hear it | 18:46 |
| seebs | I 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 |
| Stygia | seebs, Hmm alright. Well fair enough. | 18:50 |
| Stygia | These are new recipes, though, so I'm hoping it'll go in fairly soon. | 18:50 |
| Stygia | Because 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 have | 18:52 | |
| kergoth | Stygia: where are you submitting them? which layer? | 18:52 |
| kergoth | getting a recipe into oe-core is non-trivial, only highly prevalent, key, core stuff is supposed to be going in there | 18:52 |
| seebs | Due 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 |
| Stygia | meta-openembedded | 18:54 |
| Stygia | the new meta-perl layer. | 18:54 |
| Stygia | I have most of the stuff from metacpan as recipes here with me. | 18:54 |
| kergoth | ahh, cool | 18:56 |
| Crofton|work | ah | 18:56 |
| bluelightning | Stygia: unless you sent some I'm not seeing, all of the ones you sent to the oe-devel list the other day had problems | 18:57 |
| seebs | meta-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 |
| bluelightning | heh | 18:58 |
| bluelightning | there are still a huge (and growing) number of layers on github that aren't in the index :( | 18:58 |
| seebs | PATCH [0/aleph-0] ... | 18:59 |
| seebs | meta-paradox: Contains recipes unsuitable for inclusion in any layer intended for use with oe-core. | 18:59 |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 18:59 | |
| *** swex__ <swex__!~swex@178.17.206.110> has quit IRC | 19:00 | |
| *** swex__ <swex__!~swex@178.17.193.130> has joined #yocto | 19:01 | |
| Stygia | bluelightning, Yea, I know. But I send two more that were formatted/named properly and with the correct (I think) metadata? | 19:01 |
| bluelightning | Stygia: which ones were those? can you find them in http://lists.openembedded.org/pipermail/openembedded-devel/2013-August/thread.html ? | 19:03 |
| Stygia | bluelightning, libtaint-util-perl/libtaint-util-perl_0.08.bb: http://pastebin.com/NKNDeZef | 19:03 |
| Stygia | bluelightning, Hmm. Nope, I can't. Only the broken ones. | 19:04 |
| bluelightning | Stygia: looks like they never made it to the list in that case | 19:04 |
| Stygia | bluelightning, Hmm alright. I didn't get banned or something for pushing broken patches, did I? | 19:05 |
| bluelightning | no, we wouldn't have done that... too many of us would have gotten banned by now :D | 19:05 |
| seebs | I don't think yocto would be well served by a community consisting only of people who never submit patches. :) | 19:05 |
| Stygia | Heh. | 19:06 |
| Stygia | Well alright, weird, I was sure I'd pushed them. But alright, I will push them again, then. | 19:06 |
| seebs | At 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 |
| Stygia | Hmm I think it's fine, all the shitty/broken patches I did submit were shown on the list just fine. :P | 19:08 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 19:09 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 19:10 | |
| cfo215 | is there a meta-qt4 or meta-qt5 layer in yocto? I only found meta-qt3 | 19:11 |
| kergoth | http://layers.openembedded.org/layerindex/ | 19:12 |
| cfo215 | maybe looking in the wrong spot... | 19:12 |
| kergoth | click on layers | 19:12 |
| kergoth | click in text box, type qt, hit enter | 19:12 |
| kergoth | :) | 19:12 |
| cfo215 | kergoth: thanks | 19:12 |
| kergoth | not all yocto compatible layers are hosted at yoctoproject.org, so best to use the layer index there | 19:12 |
| cfo215 | kergoth: I really do appreciate all the help. Someday I won't be such a newb | 19:15 |
| Stygia | Hmm. I don't think that worked. | 19:16 |
| Stygia | At least my commit still doesn't appear on the list bluelightning linked. | 19:16 |
| seebs | Sometimes there is a delay. | 19:17 |
| Stygia | I 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 --to=openembedded-devel@lists.openembedded.org --confirm=always -M -1 | 19:17 |
| seebs | I've had messages that really did go through not show up for a couple-few hours. | 19:17 |
| Stygia | Weird. Email is usually pretty instant. | 19:18 |
| Stygia | But fair enough, then. | 19:18 |
| Stygia | I was just wondering if something was broken in my approach or setup of git. | 19:18 |
| *** daBONDi_work <daBONDi_work!~david@80.122.151.98> has quit IRC | 19:19 | |
| *** darknighte_znc is now known as darknighte | 19:19 | |
| zibri | stygia: you set up postfix? you can have a look with "postqueue -p" (as root) to view any queued up mails. | 19:26 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 19:26 | |
| zibri | or /var/log/mail.log | 19:26 |
| Stygia | zibri, I'm pretty sure I did, I did push the other broken commits. But I'll have a look. | 19:27 |
| Stygia | Ah, hmm. They say connection timed out. | 19:27 |
| Stygia | I'll have a look, thanks zibri | 19:28 |
| zibri | you could try "telnet mail.openembedded.org 25". in sweden a lot of isps filters port 25 | 19:28 |
| zibri | if you can connect, you can continue investigate any local configuration issues. otherwise that's the probable culprit | 19:29 |
| Stygia | zibri, I'm not Swedish? | 19:29 |
| zibri | no, but i am. | 19:29 |
| Stygia | zibri, Jævlå svænsa | 19:29 |
| zibri | just saying, it's like that here. probably elsewhere as well. | 19:30 |
| zibri | :) | 19:30 |
| Stygia | Heh. | 19:30 |
| Stygia | Hmm does give me 'no route to host' | 19:30 |
| zibri | i 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 |
| zibri | http://codepad.org/wa8WRB7R | 19:36 |
| *** Stygia <Stygia!~gmpsaifi@94.191.231.92.bredband.3.dk> has quit IRC | 19:36 | |
| zibri | on master, i got issues at roughly the same point, with errors about -malign-labels=0 not being a valid flag | 19:36 |
| zibri | http://codepad.org/rh1sVIbU <-- this one is from the master build | 19:37 |
| zibri | any ideas what i'm doing wrong? | 19:37 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 19:41 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 19:43 | |
| *** Stygia <Stygia!~gmpsaifi@146.185.28.212> has joined #yocto | 19:49 | |
| seebs | Hmm. | 20:00 |
| seebs | One 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 |
| seebs | If 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 |
| zibri | unfortunately, 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!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 20:06 | |
| *** cfo215 <cfo215!~christos@mail.abemblem.com> has left #yocto | 20:07 | |
| *** sameo <sameo!~samuel@192.55.55.39> has joined #yocto | 20:07 | |
| *** Stygia <Stygia!~gmpsaifi@146.185.28.212> has quit IRC | 20:12 | |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has joined #yocto | 20:24 | |
| *** amarsman <amarsman!~marsman@90-145-17-249.wxdsl.nl> has quit IRC | 20:28 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 20:28 | |
| *** ant_home <ant_home!~andrea@95.236.249.179> has joined #yocto | 20:31 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 20:41 | |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 20:47 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 20:49 | |
| *** amarsman <amarsman!~marsman@52489B71.cm-4-1c.dynamic.ziggo.nl> has joined #yocto | 20:53 | |
| *** brm <brm!da653619@gateway/web/freenode/ip.218.101.54.25> has joined #yocto | 21:05 | |
| brm | Hi guys! Anyone expert on yocto kernel configuration that can help me? | 21:06 |
| brm | added a kernel config fragment to my layer, re-did the image, but the change has not gone through to the deploy directory | 21:07 |
| *** cfo215 <cfo215!~christos@mail.abemblem.com> has joined #yocto | 21:08 | |
| brm | hey cfo215, know anything about kernel config development? | 21:10 |
| cfo215 | brm: 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 |
| cfo215 | you could try http://www.tldp.org/HOWTO/SCSI-2.4-HOWTO/kconfig.html for starters | 21:21 |
| bluelightning | brm: did the change make it into the .config file in the build dir under the workdir for the kernel recipe? | 21:32 |
| cfo215 | Got 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 |
| cfo215 | ERROR: Task 7 (/media/toshiba-usb3/work/poky/meta/recipes-core/images/core-image-minimal.bb, do_rootfs) failed with exit code '1'http://pastebin.com/qrRQEc46 | 21:33 |
| bluelightning | cfo215: that sounds like you added qtbase-native to IMAGE_INSTALL, which wouldn't be correct | 21:34 |
| cfo215 | bluelightning: IMAGE_INSTALL_append += " qtbase qtbase-native" .. was added to local.conf. What is the proper way? | 21:36 |
| reeve | seebs: stepped out for a while. Is there anything you could hint me to resolev the problem? | 21:37 |
| seebs | Nothing 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!~jefro@50-0-152-82.dedicated.static.sonic.net> has joined #yocto | 21:39 | |
| bluelightning | cfo215: qtbase-native isn't a package to be installed into the image; it's a recipe providing tools/libs to run on the build host | 21:41 |
| bluelightning | cfo215: I suspect you just want qtbase there | 21:41 |
| cfo215 | blueligtning: 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 |
| bluelightning | cfo215: if you took out qtbase as well, then I suspect it won't have | 21:43 |
| cfo215 | bluelightning: i did take it out. I'll put it back in... won't be long. | 21:44 |
| reeve | seebs: this is a package I'm trying to add into my own layer, but really nothing special | 21:45 |
| reeve | seebs: this is the link to the package https://code.google.com/p/snappy/, has anyone added it successfully? | 21:46 |
| seebs | I 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 |
| reeve | enh? 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 IRC | 21:52 | |
| cfo215 | bluelightning: 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 |
| bluelightning | cfo215: heh | 21:55 |
| JaMa | zenlinux: Hi, can you extend http://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html 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, thanks | 21:56 |
| zenlinux | JaMa, you're looking for other "other" Scott, scottrif | 21:57 |
| JaMa | zenlinux: ah sorry | 21:57 |
| zenlinux | no prob :) | 21:57 |
| zenlinux | man, I can't form a coherent sentence myself | 21:58 |
| JaMa | scot: are you right scott for this task? ^^^ :) | 21:58 |
| zenlinux | Scott Rifenbark's nick is scottrif. He's in Europe IIRC so it may be late for him. | 21:59 |
| JaMa | OK, I'll check bugzilla anyway | 22:00 |
| zenlinux | your best bet is to make the request on the yocto ML or bugzill | 22:00 |
| zenlinux | a | 22:00 |
| cfo215 | bluelightning: ./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-image | 22:02 |
| *** galak <galak!~galak@99-51-185-173.lightspeed.austtx.sbcglobal.net> has quit IRC | 22:03 | |
| bluelightning | cfo215: :) | 22:03 |
| bluelightning | cfo215: not sure whether anyone's implemented the SDK for qt5 yet, last I checked nobody had | 22:03 |
| cfo215 | bluelightning: I think I just verified that... :( ERROR: Nothing PROVIDES 'core-image' | 22:05 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 22:05 | |
| bluelightning | cfo215: I think that's a mistake in your command line, at least out of the box there is nothing called "core-image" | 22:05 |
| bluelightning | no recipe, at least | 22:06 |
| cfo215 | bluelightning: bitbake -c populate_sdk core-image-minimal is working... so far, so good... | 22:06 |
| brm | bluelightning: Sorry had to leave for a bit. I had a look in the work directory and can't even find a .cinfig!! | 22:23 |
| brm | oops .config | 22:23 |
| *** darknighte is now known as darknighte_znc | 22:25 | |
| brm | the config fragment made it into the work directory, but don't know if it made the .config, as I can't find it | 22:26 |
| kergoth | .config is in the source tree, not workdir | 22:26 |
| brm | oh, where abouts? in the git folder? | 22:27 |
| kergoth | yep | 22:28 |
| bluelightning | kergoth: depends, at least linux-yocto uses a separate directory to build in | 22:28 |
| kergoth | true | 22:28 |
| brm | thanks, will have a look | 22:28 |
| kergoth | bitbake -e | grep '^B=' might be the best bet :) | 22:28 |
| kergoth | bitbake -e virtual/kernel that is | 22:28 |
| brm | my kernel is linux-mainline | 22:30 |
| brm | ends up: "/home/bmentink/beagleboard_black/build/tmp/work/beaglebone-poky-linux-gnueabi/linux-mainline/3.8.13-r23a/git" | 22:31 |
| kergoth | yep, thats .config will be after do_configure runs | 22:32 |
| brm | my change did not get into the .config there | 22:33 |
| bluelightning | er, actually... if you're using linux-mainline, I'm not sure you'll have config fragment support | 22:34 |
| brm | I have no idea what i have done wrong with my fragment | 22:34 |
| brm | oh, so I have to make the change to what to get it to stick? | 22:35 |
| bluelightning | without config fragment support you will need to supply a full defconfig | 22:35 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 22:35 | |
| brm | do I put it into defconfig in that directory | 22:35 |
| brm | or can I put the defconfig file in my layer | 22:36 |
| bluelightning | it 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 |
| bluelightning | alternatively you can change your kernel recipe to be like meta-skeleton/recipes-kernel/linux/linux-yocto-custom.bb | 22:37 |
| bluelightning | that provides config fragment support | 22:37 |
| brm | so just pich the portions that do the fragment support? | 22:38 |
| bluelightning | I think you'll have to pretty much take the whole thing | 22:40 |
| bluelightning | but 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 requires | 22:40 |
| kergoth | I'd question that recipe naming. imo "linux-yocto" implies said source/meta branching | 22:41 |
| kergoth | heh | 22:41 |
| bluelightning | perhaps, but there was no config fragment functionality before linux-yocto either :) | 22:42 |
| bluelightning | at least not that I am aware of | 22:42 |
| brm | I am out of my depth here .. | 22:42 |
| bluelightning | brm: have you had a look at this manual? http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html | 22:43 |
| bluelightning | brm: that should cover the basics | 22:44 |
| brm | yep have, still struggling .. | 22:44 |
| brm | most of the examples there assume linux-yocto kernel not mainline | 22:44 |
| brm | so a lot of the commands don't work | 22:45 |
| bluelightning | brm: start with linux-yocto-custom; apart from the bits that talk about split meta branches, the rest is equally applicable to linux-yocto-custom | 22:45 |
| bluelightning | linux-yocto-custom is covered under 2.4. Working With Your Own Sources | 22:45 |
| seebs | kergoth, 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 |
| brm | so I have to use a different kernel? The BBB receipe has to use linux-mainline as all the BBB patches are on that kernel | 22:49 |
| bluelightning | brm: no, you can point to the exact same source and use the same patches | 22:49 |
| bluelightning | brm: you can use the same SRC_URI line | 22:50 |
| brm | ok, got it thanks .... | 22:51 |
| brm | going for lunch now, thanks for your help ;-) | 22:52 |
| kergoth | seebs: cool, thanks, will likely take a look at it tomorrow | 22:52 |
| seebs | 'k. | 22:52 |
| seebs | I'm on vacation Friday through a week from Monday, and probably won't check work email. | 22:53 |
| kergoth | k | 22:53 |
| seebs | Might be around this channel, though, because my freenode IRC is on the client I use for personal chats anyway. | 22:53 |
| * kergoth nods, same | 22:55 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 23:02 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 23:04 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 23:09 | |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC | 23:11 | |
| -YoctoAutoBuilder- build #227 of nightly is complete: Exception [exception interrupted] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly/builds/227 | 23:17 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 23:18 | |
| *** bozojoe <bozojoe!4475c643@gateway/web/freenode/ip.68.117.198.67> has joined #yocto | 23:35 | |
| bozojoe | is mark hatle here? | 23:35 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 23:57 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 23:59 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!