| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 00:01 | |
| *** zeddii <zeddii!~bruce@64.88.227.134> has quit IRC | 00:01 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 00:02 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 00:02 | |
| *** abelloni <abelloni!~piout@128-79-216-144.hfc.dyn.abo.bbox.fr> has quit IRC | 00:03 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 00:03 | |
| *** abelloni <abelloni!~piout@128-79-216-144.hfc.dyn.abo.bbox.fr> has joined #yocto | 00:05 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 00:06 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 00:13 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 00:27 | |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has quit IRC | 00:31 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 00:47 | |
| *** ash_charles <ash_charles!~ash_charl@adsl-172-15-162-30.dsl.pltn13.sbcglobal.net> has joined #yocto | 00:54 | |
| ash_charles | hello. Anyone know how I might add a repository/channel to the smart package manager when I'm building an image. | 00:56 |
|---|---|---|
| ash_charles | ? | 00:56 |
| *** _julian_ <_julian_!~quassel@x2f14f06.dyn.telefonica.de> has joined #yocto | 00:58 | |
| *** _julian <_julian!~quassel@x2f0c2e5.dyn.telefonica.de> has quit IRC | 01:01 | |
| *** frank <frank!~frank@1.202.252.122> has quit IRC | 01:12 | |
| *** frank <frank!~frank@1.202.252.122> has joined #yocto | 01:13 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 01:13 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 01:14 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 01:17 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has joined #yocto | 01:18 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 02:01 | |
| *** silviof1 <silviof1!~silviof@ppp-88-217-75-129.dynamic.mnet-online.de> has joined #yocto | 02:13 | |
| *** silviof <silviof!~silviof@188.174.193.40> has quit IRC | 02:16 | |
| khem | sgw1: yes. now I have few mins here | 02:32 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 02:37 | |
| *** darknighte is now known as darknighte_znc | 02:40 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 03:01 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:01 | |
| lpapp | sgw1: any news? | 03:13 |
| *** ash_charles <ash_charles!~ash_charl@adsl-172-15-162-30.dsl.pltn13.sbcglobal.net> has left #yocto | 03:32 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 03:51 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 04:12 | |
| sgw1 | lpapp: other than I could confirm and reproduce it, but no fix, I have assigned it to kergoth to look into since he is most familiar with the external toolchain code. | 04:30 |
| lpapp | sgw1: :( | 04:43 |
| lpapp | the problem is that there is no workaround | 04:43 |
| lpapp | so I am fully blocked with my company work | 04:44 |
| sgw1 | lpapp: your either up very late or very early! I understand your frustration, I can't fix every bug, but I can confirm it's there and assigned to the most knowledge person. | 04:46 |
| lpapp | sgw1: it is not about to fix. | 04:47 |
| lpapp | as written, I do not even have a workaround. | 04:47 |
| lpapp | anyway, I will probably switch away from Yocto for now. | 04:47 |
| sgw1 | lpapp: it's about a fix or workaround, and I have neither right now, this is not my strong area | 04:48 |
| lpapp | it is too unstable for embedded developer as of now. | 04:48 |
| lpapp | I appreciate your help though, so do not take it personally. | 04:48 |
| lpapp | it is just not the right technology at the moment. | 04:49 |
| sgw1 | lpapp: If that's what you believe then you need to do what's right for your company, I know of many other people using, it may not be in the way you are currently. | 04:49 |
| sgw1 | lpapp: good night | 04:50 |
| lpapp | sgw1: it is not about what I believe. | 04:50 |
| lpapp | it is not subjective | 04:50 |
| lpapp | it just does not work, it is objective. | 04:50 |
| lpapp | it is a fact. | 04:50 |
| lpapp | sgw1: good night | 04:51 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 04:53 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 04:54 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 05:04 | |
| *** agust <agust!~agust@pD9E2F216.dip0.t-ipconnect.de> has joined #yocto | 05:04 | |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 05:06 | |
| *** frank <frank!~frank@1.202.252.122> has quit IRC | 05:26 | |
| *** g0hl1n <g0hl1n!5be602f4@gateway/web/freenode/ip.91.230.2.244> has quit IRC | 05:27 | |
| lpapp | http://lpapp.blogspot.ie/2013/07/yocto-mature-or-not.html | 05:39 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 05:51 | |
| melonipoika | denix, i want to install xserver-xorg and that is the only layer i found that provides it :-) but yeah, i noticed that arago-oe-dev is not really maintained | 05:53 |
| sgw1 | khem: you around now, I know it's late! | 06:13 |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 06:14 | |
| -YoctoAutoBuilder- build #225 of build-appliance is complete: Failure [failed Building Images_1 Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/build-appliance/builds/225 | 06:31 | |
| *** ka6sox is now known as ka6sox-away | 06:32 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 06:34 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 06:36 | |
| *** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has joined #yocto | 06:41 | |
| lpapp | rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4902 | 06:49 |
| yocti | Bug 4902: normal, Undecided, ---, richard.purdie, NEW , Add an option or util for automatically updating the file checksum | 06:49 |
| lpapp | rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4903 | 06:58 |
| yocti | Bug 4903: normal, Undecided, ---, richard.purdie, NEW , No proper error message for layer version mismatch | 06:58 |
| *** ka6sox-away is now known as ka6sox | 06:59 | |
| -YoctoAutoBuilder- build #202 of nightly-oecore is complete: Failure [failed Running Sanity Tests Building Toolchain Images Building Toolchain Images_1] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-oecore/builds/202 | 06:59 | |
| *** laur <laur!~lau@192.198.151.43> has left #yocto | 07:03 | |
| lpapp | rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4905 | 07:03 |
| yocti | Bug 4905: normal, Undecided, ---, richard.purdie, NEW , No proper location diagnostic for tab/space issues | 07:03 |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 07:04 | |
| lpapp | rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4906 | 07:06 |
| yocti | Bug 4906: normal, Undecided, ---, scott.m.rifenbark, NEW , No opengl mentioned | 07:06 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 07:09 | |
| lpapp | rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4907 | 07:11 |
| yocti | Bug 4907: normal, Undecided, ---, scott.m.rifenbark, NEW , Add an external sourcery chain example with documentation | 07:11 |
| lpapp | I need to stop it for now, but I will submit more bugreports. | 07:11 |
| -YoctoAutoBuilder- build #224 of nightly-non-gpl3 is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-non-gpl3/builds/224 | 07:11 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 07:17 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 07:17 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 07:19 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 07:20 | |
| *** tbn <tbn!~tbn@84.55.160.118> has joined #yocto | 07:25 | |
| *** tbn is now known as Guest89262 | 07:26 | |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 07:28 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 07:29 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 07:31 | |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 07:32 | |
| *** francois99 <francois99!~francois9@78-33-60-6.static.enta.net> has quit IRC | 07:41 | |
| *** francois99 <francois99!~francois9@78-33-60-6.static.enta.net> has joined #yocto | 07:41 | |
| lpapp | wmat: do you know how to use the meta-sourcery layer? | 07:43 |
| -YoctoAutoBuilder- build #234 of nightly-x32 is complete: Failure [failed Running Sanity Tests] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-x32/builds/234 | 07:44 | |
| *** zeeblex <zeeblex!~apalalax@134.134.139.76> has joined #yocto | 07:45 | |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 07:48 | |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:48 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 07:49 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 07:49 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has joined #yocto | 07:51 | |
| bluelightning | morning all | 07:54 |
| rburton | morning bluelightning | 07:54 |
| melonipoika | morning | 07:54 |
| Crofton | gm | 07:58 |
| *** ivali <ivali!ivali@unaffiliated/ivali> has joined #yocto | 08:04 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 08:04 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 08:06 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 08:11 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 08:18 | |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 08:21 | |
| *** ivali <ivali!ivali@unaffiliated/ivali> has quit IRC | 08:22 | |
| dzoe | Hi, I'm back with another (probably really stupid) question. How do I get ttf-dejavu-anything built? In meta-openembedded layer, there are a few tasks that depend on it (fonts-*), but I cannot find where to get the recipes. There's only some .inc in meta-oe/recipes-graphics/ttf-fonts. Perhaps I'm overlooking something ... | 08:22 |
| bluelightning | dzoe: which branch are you on? | 08:24 |
| dzoe | Danny. | 08:24 |
| *** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto | 08:27 | |
| bluelightning | dzoe: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-graphics/ttf-fonts?h=danny | 08:27 |
| *** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has joined #yocto | 08:28 | |
| bluelightning | dzoe: bitbake ttf-dejavu should build all of the ttf-dejavu-* packages | 08:28 |
| bluelightning | dzoe: (or indeed bitbake anything-depending-on-ttf-dejavu-*) | 08:28 |
| eren | o/ morning | 08:29 |
| *** frank <frank!~frank@1.202.252.122> has joined #yocto | 08:30 | |
| dzoe | Mea culpa ... I was searching outdated tree from some older experiment where we had those recipes deleted... Sorry for asking stupid questions... | 08:30 |
| *** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC | 08:30 | |
| bluelightning | dzoe: no worries | 08:31 |
| melonipoika | I have a most probably stupid question too, but here it goes :-) | 08:32 |
| melonipoika | i am trying to build a headless machine and i would like it to run a vnc server | 08:32 |
| melonipoika | i have x11vnc instaleld in my image | 08:32 |
| melonipoika | but i am missing x | 08:32 |
| *** lpapp <lpapp!~lpapp@212.44.19.228> has joined #yocto | 08:32 | |
| melonipoika | i think i should install xvfb, but can't find it in any layer | 08:33 |
| eren | what's the default behavior of PACKAGECONFIG? (regarding to the latest commit from JaMa) | 08:33 |
| lpapp | so is it just me, or I cannot really edit comments on bugzilla? | 08:33 |
| eren | +PACKAGECONFIG ??= "" | 08:33 |
| eren | PACKAGECONFIG[cap] = "--with-libcap,--without-libcap,libcap" | 08:33 |
| rburton | lpapp: correct, bugzilla comments are immutable | 08:33 |
| eren | by default, then, no PACKAGECONFIG is given for the package | 08:33 |
| eren | so, "cap" is disabled by default? | 08:33 |
| rburton | eren: correct | 08:33 |
| eren | then, --without-cap is given | 08:33 |
| melonipoika | is xvfb the way to go, or is there any other better approach? | 08:33 |
| eren | if it were "PACKAGECONFIG ??= "cap" assignment, it means that it's enabled by default | 08:34 |
| rburton | eren: yep | 08:34 |
| eren | oh, okkie. thanks! | 08:34 |
| rburton | melonipoika: xvfb sounds like a good idea | 08:35 |
| lpapp | that is a very unfortunate limitation... | 08:35 |
| lpapp | is that a feature or bug? | 08:35 |
| eren | JaMa: how did you manage to detect these options from sysroot? I mean, the autodetection of libraries and enabling automatically while the package is being built | 08:36 |
| melonipoika | rburton, thanks. Do you know what layer provides xvfb? | 08:36 |
| rburton | melonipoika: i suspect it might be in meta-oe | 08:36 |
| melonipoika | (i ma using arago and my target hw is a TI TCI6638 EVM) | 08:36 |
| lpapp | I am getting an error from the denzil branch when running bitbake ... http://paste.kde.org/~lpapp/p40944183/ | 08:36 |
| lpapp | with a brand fresh checkout for the branch. | 08:37 |
| melonipoika | ok | 08:37 |
| lpapp | ERROR: Unable to parse /home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf: [Errno 2] No such file or directory: '/home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf' | 08:37 |
| rburton | lpapp: you need a new bblayers | 08:38 |
| rburton | lpapp: as meta-yocto-bsp didn't exist in denzil | 08:38 |
| rburton | (iirc) | 08:38 |
| rburton | (still need a second coffee) | 08:38 |
| lpapp | I love error messages, have I ever mentioned? :) | 08:38 |
| rburton | its a perfectly good error message | 08:38 |
| rburton | you told it to load a layer, that layer doesn't exist | 08:38 |
| rburton | DEBUG: Adding layer /home/lpapp/Projects/poky/meta-yocto-bsp | 08:39 |
| rburton | DEBUG: LOAD /home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf | 08:39 |
| rburton | ERROR: Unable to parse /home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf: [Errno 2] No such file or directory: '/home/lpapp/Projects/poky/meta-yocto-bsp/conf/layer.conf' | 08:39 |
| rburton | not sure how much more concrete that could be to be honest | 08:39 |
| lpapp | it is perfectly good for you. | 08:39 |
| lpapp | but I doubt it is perfectly good for a user, like me. | 08:39 |
| rburton | lpapp: how could it be improved? | 08:39 |
| lpapp | well, it could be a lot more concrete. | 08:39 |
| rburton | its incredibly concrete | 08:39 |
| lpapp | I was about to open a bugreport. | 08:39 |
| lpapp | it is not? | 08:39 |
| rburton | I'm adding a layer / i'm opening this specific file / that specific file doesn't exist | 08:39 |
| rburton | it told you what layer its trying to add, and what file it can't find | 08:40 |
| lpapp | which is wrong, yes. | 08:40 |
| bluelightning | lpapp: ? | 08:40 |
| lpapp | please be patient | 08:41 |
| lpapp | as I said, I was already opening a bugreport for it. | 08:41 |
| ant_work | lpapp: to sum up 2-3 days of logs, I think the things you are asking for a better "user" experience (automatic bblayers editing, adding layers, some customization) are done fundamentally HOB. It is still WIP. | 08:43 |
| ant_work | lpapp: normally *developers* are building the images and users are just expected to update packages on target | 08:44 |
| lpapp | bluelightning: rburton https://bugzilla.yoctoproject.org/show_bug.cgi?id=4909 | 08:45 |
| yocti | Bug 4909: normal, Undecided, ---, richard.purdie, NEW , Improve the error message for tray bblayers.conf files | 08:45 |
| lpapp | ant_work: user experience is *not* tied to a frontend. | 08:45 |
| lpapp | ant_work: any frontend should be usable. | 08:45 |
| eren | I'm a little bit confused about what SRCPV actually does. I've realized that all git recipes use SRCREV, and assign PV = "<version_of_pkg>+git${SRCPV}". Why don't they use +git${SRCREV} ? | 08:45 |
| lpapp | ant_work: and no, I do not like HOB. I actually very much dislike gtk. | 08:45 |
| eren | I believe the current documentation is not clear on the variable either. | 08:46 |
| eren | "Returns the version string of the current package. This string is used to help define the value of PV." | 08:46 |
| ant_work | lpapp: neverthless, it has many of the automatisms you're asking for | 08:46 |
| ant_work | (I only gave a glimpse, I'm not HOB user fwiw) | 08:47 |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 08:48 | |
| lpapp | ant_work: well, thanks for the information, but I am not going to use HOB. | 08:48 |
| lpapp | I also think that HOB is the wrong layer to address it at. | 08:49 |
| lpapp | some of the things should be addressed on the bitbake layer. | 08:49 |
| lpapp | rburton: bluelightning http://paste.kde.org/~lpapp/p23e563aa/ | 08:51 |
| lpapp | this is with the denzil branch, poky, and beagleboard | 08:51 |
| lpapp | I cannot get any branch working with an external toolchain. :( | 08:51 |
| rburton | | automake.texi:13043: @itemx must follow @item | 08:52 |
| rburton | looks a lot like the problems caused by new texinfo | 08:52 |
| lpapp | also this: ERROR: Execution of event handler 'csl_version_handler' failed | 08:52 |
| lpapp | texinfo 5.1 in her. | 08:52 |
| lpapp | here* | 08:52 |
| rburton | yeah, that caused errors all over the place | 08:53 |
| lpapp | but I would be interested in the other error, too. | 08:53 |
| rburton | try changing that CmdError to bb.process.CmdError | 08:53 |
| lpapp | ah, yeah, that was fixed by us. | 08:53 |
| lpapp | should probably be fixed in upstream, too. | 08:56 |
| lpapp | it would be nice to give a last go to meta-sourcery before leaving Yocto. | 08:56 |
| rburton | commit caee06405f90d44b3476af645e2b3918578ba6b9 | 08:56 |
| lpapp | but to be honest, I am not even sure what I am supposed to do with it. | 08:56 |
| rburton | Author: Christopher Larson <chris_larson@mentor.com> | 08:56 |
| rburton | Date: Tue May 15 20:28:24 2012 -0500 | 08:56 |
| rburton | csl-versions: fix bb.process.CmdError reference | 08:57 |
| rburton | you can cherry-pick that into your denzil branch | 08:57 |
| lpapp | rburton: I meant the denzil branch. | 08:57 |
| lpapp | I fixed that on my own before. | 08:57 |
| lpapp | anyone having any idea how one is supposed to use the meta-sourcery layer? | 08:57 |
| rburton | lpapp: if you backport it you can send it to oe-core tagged for denzil | 08:58 |
| lpapp | rburton: too much effort that I do not have time for. | 08:58 |
| ant_work | lpapp: maybe I missed it, why don't you consider using the native toolchain? You have patches to coreutils? Add patches in your layer. | 08:58 |
| lpapp | ant_work: I do not have any patches to core utils ... | 08:59 |
| lpapp | coreutils* | 08:59 |
| lpapp | ant_work: huh? | 08:59 |
| lpapp | arm native toolchain on non-arm? | 08:59 |
| lpapp | that is kinda joke? | 08:59 |
| *** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has joined #yocto | 08:59 | |
| ant_work | lpapp: built by OE/Yocto | 08:59 |
| lpapp | it does not matter who builds it | 08:59 |
| lpapp | you cannot run ARM binary on the host | 09:00 |
| lpapp | without qemu, and other slow stuff | 09:00 |
| ant_work | lpapp: try to understand, I mean NO EXTERNAL TC | 09:00 |
| lpapp | that is not a native toolchain | 09:00 |
| *** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has left #yocto | 09:00 | |
| lpapp | that is non-external non-native. | 09:00 |
| lpapp | i.e. internal cross-toolchain. | 09:00 |
| *** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has joined #yocto | 09:01 | |
| lpapp | because we do not wanna build it. | 09:01 |
| lpapp | it takes time, and we do not have time for things that exist in binary forms off-hand. | 09:01 |
| ant_work | those are the reasons? | 09:01 |
| lpapp | yes, plus the lot of effort for refactoring. | 09:02 |
| lpapp | those are all blocker reasons | 09:02 |
| ant_work | lpapp: I think you're missing the Yocto goals | 09:03 |
| lpapp | ant_work: our project is not Yocto | 09:03 |
| lpapp | we have different goals. | 09:03 |
| lpapp | so yes, of course we miss the Yocto goals. | 09:04 |
| lpapp | so if I integrate this meta-sourcery, what am I supposed to set in my conf/layer.conf? | 09:06 |
| lpapp | or in bblayers.conf if any? | 09:06 |
| *** sameo <sameo!~samuel@192.55.55.37> has joined #yocto | 09:06 | |
| lpapp | is it just me being silly? | 09:09 |
| lpapp | and it is trivial? | 09:09 |
| lpapp | or is it something to ask from the MG guys? | 09:09 |
| bluelightning | lpapp: you complain about time, but the fact of the matter is if you had just gone with the internal toolchain you'd likely have your working build by now... | 09:09 |
| lpapp | bluelightning: stop this please. | 09:09 |
| lpapp | it is not productive. | 09:09 |
| lpapp | how did you know for *sure* it was going to cause issues? | 09:09 |
| lpapp | also, are you aware of the cost a full stack refactoring in a company? | 09:09 |
| lpapp | are you also aware of the fact developers *do* dislike the slow builds? | 09:10 |
| lpapp | also, I am *not* complaining. | 09:10 |
| lpapp | I am stating facts. | 09:10 |
| bluelightning | lpapp: but you immediately ignore the default option which is tested and works | 09:10 |
| lpapp | well, if you call that complaining, that is fine. | 09:10 |
| lpapp | bluelightning: you do not wanna realize what I wrote | 09:10 |
| lpapp | developers dislike the slow builds, it costs a lot of time to refactor, test, validate, develop, fix bugs and so forth | 09:11 |
| bluelightning | why would a "full stack refactoring" even be needed? | 09:11 |
| lpapp | even if the latter took zero effort, which it does not. | 09:11 |
| lpapp | then former argument would stay around. | 09:11 |
| lpapp | bluelightning: because it is the damn toolchain | 09:11 |
| lpapp | the very low-part of the stack. | 09:11 |
| lpapp | and every part above depending on it. | 09:11 |
| bluelightning | yes, and luckily we have quite a lot of experience building and testing that part | 09:12 |
| lpapp | how is that relevant? | 09:12 |
| lpapp | We need to test our software with it | 09:12 |
| lpapp | and we have a huuuuuuge software | 09:12 |
| lpapp | it is a different project to change the toolchain if it is every worth it | 09:13 |
| lpapp | and not a small project. | 09:13 |
| lpapp | we do not have budget for that now. | 09:13 |
| lpapp | makes sense? | 09:13 |
| lpapp | ever* | 09:14 |
| rburton | lpapp: if you are having problems with m-s, then yes, continue talking to kergoth. | 09:15 |
| lpapp | rburton: he is ignoring me here even though I unignored him | 09:15 |
| lpapp | rburton: and he has not replied for the email queries on the list | 09:15 |
| lpapp | I am now filing a bug against meta-sourcery on github | 09:15 |
| lpapp | not sure I can do more. | 09:15 |
| lpapp | rburton: https://github.com/MentorEmbedded/meta-sourcery/issues/9 | 09:16 |
| *** Ramana_ is now known as CK | 09:18 | |
| *** CK is now known as ckris | 09:18 | |
| frank | When adding IMAGE_INSTALL += "libnfsidmap", it will be renamed to libnfsidmap0 as param passing to translate_oe_to_smart(). | 09:22 |
| frank | Where is the code made this change? | 09:23 |
| *** ckris is now known as Ramana_ | 09:23 | |
| frank | I mean where did the changes to IMAGE_INSTALL or PACKAGE_INSTALL ? | 09:25 |
| lpapp | rburton: is that github report clear? | 09:26 |
| lpapp | would you report the same if you were interested in using it, but they do not provide documentation? | 09:26 |
| bluelightning | frank: I guess you switched from ipk to rpm ? | 09:26 |
| lpapp | should I add any additional information? | 09:26 |
| lpapp | bluelightning: I will spend half an hour with the internal toolchain | 09:27 |
| lpapp | bluelightning: do you have documentation at hand? | 09:27 |
| bluelightning | lpapp: it's the default option, you shouldn't need to do anything special | 09:27 |
| lpapp | bluelightning: ? | 09:27 |
| lpapp | bluelightning: I would like to be able to specify the compiler | 09:28 |
| bluelightning | lpapp: just comment out the lines you added to enable the external toolchain and you'll be configured to use it | 09:28 |
| *** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has joined #yocto | 09:28 | |
| lpapp | what architecture, what gcc version, etc. | 09:28 |
| lpapp | because I would like to use C++11 as much as possible, and C++14 soon. | 09:28 |
| lpapp | I would like to build for a particular arm. | 09:28 |
| bluelightning | lpapp: all of that is determined from the MACHINE you have set | 09:28 |
| lpapp | bluelightning: that did not fly last time. | 09:28 |
| lpapp | bluelightning: it built native x86 binaries | 09:28 |
| ant_work | lpapp: you did not specify a MACHINE | 09:28 |
| frank | bluelightning: not exactly, I just find sometimes, "libnfsidmap" is not renamed with the lib version | 09:29 |
| lpapp | ant_work: I di. | 09:29 |
| lpapp | d | 09:29 |
| frank | So, I want to browse the code doing this rename. | 09:29 |
| ant_work | lpapp: # This sets the default machine to be qemux86 if no other machine is selected: | 09:30 |
| ant_work | MACHINE ??= "qemux86" | 09:30 |
| ant_work | lpapp: pls explicitly add MACHINE = "foo" (from your BSP layer) | 09:31 |
| bluelightning | frank: ok, translate_oe_to_smart() is only used for rpm | 09:31 |
| bluelightning | frank: I'll find some pointers for you, one sec | 09:31 |
| lpapp | ant_work: I am not sure what you mean | 09:31 |
| lpapp | and where you get that from. | 09:31 |
| *** sameo <sameo!~samuel@192.55.55.37> has quit IRC | 09:31 | |
| lpapp | I definitely have a different local.conf | 09:31 |
| ant_work | http://cgit.openembedded.org/openembedded-core/tree/meta/conf/local.conf.sample | 09:31 |
| lpapp | no no | 09:31 |
| frank | bluelightning: yes. Thanks a lot ! | 09:31 |
| lpapp | I have local.conf setup for my environment. | 09:31 |
| lpapp | I did not get something blindly which I have never modified. | 09:31 |
| ant_work | lpapp: it looks like smthg went wrong then ;) | 09:32 |
| ant_work | lpapp: if I say 'spitz' I get code for that armv5te | 09:32 |
| lpapp | yes, but elsewhere. | 09:32 |
| lpapp | ./meta/conf/machine/include/tune-arm926ejs.inc -> so if I include it, it should build for that. | 09:32 |
| lpapp | dylan has gcc 4.7? | 09:33 |
| lpapp | I mean arm gcc gnueabi | 09:33 |
| bluelightning | frank: the actual code that does that is runtime_mapping_rename() in meta/classes/package.bbclass | 09:33 |
| bluelightning | frank: it's called from meta/classes/image.bbclass | 09:33 |
| frank | bluelightning: Thanks! | 09:35 |
| bluelightning | frank: it relies on the data in tmp/pkgdata (which is written during do_packagedata or do_package depending on what version of the build system you are using) | 09:36 |
| lpapp | bluelightning: I will make a test build | 09:37 |
| frank | bluelightning: Got it ! | 09:37 |
| lpapp | bluelightning: slow building is definitely better than no building for now. | 09:37 |
| lpapp | but we need to get the MG stuff working in the end of the day. | 09:37 |
| lpapp | I consider the internal an interim workaround | 09:37 |
| lpapp | provided it works. | 09:37 |
| rburton | lpapp: remember you build the compiler once, after that it's in the cache | 09:38 |
| ant_work | lpapp: don't play with the tune files, those are included by the machine.conf | 09:38 |
| lpapp | ant_work: ? | 09:38 |
| lpapp | ant_work: we have our own machine | 09:38 |
| lpapp | that is why we have a different layer in the first place. ;) | 09:38 |
| lpapp | and our machine includes that. | 09:38 |
| ant_work | lpapp: we maintain machines in an external BSP as well and the machine.conf just includes the tune files of oe-core | 09:39 |
| lpapp | I do need to deal with it | 09:39 |
| lpapp | i.e. I need to include it in my machine/foo.conf | 09:39 |
| lpapp | that is where the information should come from I believe. | 09:40 |
| lpapp | whether it is building with a cross-toolchain. | 09:40 |
| lpapp | bluelightning: it is using cross-toolchain rather than emulated native, right? | 09:40 |
| bluelightning | lpapp: absolutely | 09:40 |
| lpapp | k | 09:40 |
| lpapp | rburton: I do not like cache | 09:42 |
| lpapp | it is causing hard to debug issues | 09:42 |
| lpapp | bluelightning: internal toolchain does not work either. :/ | 09:43 |
| lpapp | bluelightning: http://paste.kde.org/pccafd75c/ | 09:44 |
| lpapp | the busybox error is back from yesterday... | 09:44 |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC | 09:44 | |
| lpapp | I guess I should open a bugreport about it now? | 09:45 |
| lpapp | I guess I am blocked then with the internal toolchain way as well. :/ | 09:45 |
| rburton | lpapp: remove your layers from bblayer.conf and try a build with qemuarm. | 09:45 |
| rburton | lpapp: then you can rule out any interaction with your layers | 09:45 |
| rburton | because busybox builds for everyone else | 09:45 |
| lpapp | rburton: well, the error is not coming from my layer. | 09:46 |
| lpapp | does everyone else test with bleeding arch? | 09:47 |
| lpapp | perhaps not. | 09:47 |
| rburton | lpapp: i didn't say it did, but lets reduce the test case | 09:47 |
| rburton | try a build with no custom layers, and see if that works | 09:47 |
| lpapp | yeah, I am doing that. | 09:48 |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has joined #yocto | 09:49 | |
| lpapp | rburton: seems to work with my distro | 09:49 |
| lpapp | when I add my machine, then it does not. | 09:49 |
| rburton | see, useful data point :) | 09:49 |
| rburton | can you pastebin your machine? | 09:49 |
| lpapp | no | 09:49 |
| lpapp | I am still investigating, and I need to be careful what to paste. :) | 09:50 |
| lpapp | it takes me some time. | 09:50 |
| lpapp | it is weird | 09:50 |
| lpapp | qemuarm -> mymachine | 09:50 |
| lpapp | I added it back, and then it works. | 09:50 |
| lpapp | again cache issue? | 09:50 |
| * lpapp dislikes cache | 09:50 | |
| rburton | doubt it, the cache is keyed on almost everything that can change, and you get a fresh sysroot for every machine. | 09:51 |
| JaMa | eren: see the script in first patch in that patchset | 09:52 |
| bluelightning | lpapp: what are your layers doing with BBPATH ? | 09:52 |
| lpapp | bluelightning: ./meta-polatis/conf/layer.conf:2:BBPATH := "${BBPATH}:${LAYERDIR}" | 09:54 |
| lpapp | bluelightning: ./meta-foo/conf/layer.conf:2:BBPATH := "${BBPATH}:${LAYERDIR}"* | 09:54 |
| lpapp | so just something that everyone else does. | 09:54 |
| bluelightning | lpapp: ok... was just trying to rule out that maybe the layer was picking up the wrong busybox.inc file with something odd in BBPATH | 09:55 |
| lpapp | bluelightning: it is working noqw | 09:56 |
| lpapp | now | 09:56 |
| lpapp | I did not do anything else than switching to qemuarm and then back | 09:56 |
| lpapp | and I deleted the cache in the meantime. | 09:56 |
| rburton | bitbake.cache? | 09:56 |
| lpapp | lock file tmp sstate cache etc | 09:56 |
| lpapp | bitbake.lock | 09:56 |
| lpapp | everything really. | 09:56 |
| lpapp | except conf | 09:56 |
| lpapp | I still think it is nasty to have conf files in build/ | 09:57 |
| lpapp | otherwise I could do rm -rf build/* | 09:57 |
| lpapp | of course a non-existing tool could help. | 09:57 |
| lpapp | if it was getting existent. | 09:57 |
| lpapp | bitbake --clean | 09:57 |
| *** sameo <sameo!samuel@nat/intel/x-izavkbaxeavrydqi> has joined #yocto | 09:58 | |
| rburton | lpapp: personally my "build" directory just contains conf/ and the bitbake parse cache, the local.conf then sets TMPDIR and SSTATE_DIR to subdirs in /data/poky-master. | 10:00 |
| rburton | mainly for disk allocation reasons but also useful for wiping stuff if i really destroy something. | 10:01 |
| *** dnil <dnil!~daniel@81-235-235-25-no92.tbcn.telia.com> has quit IRC | 10:06 | |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has joined #yocto | 10:09 | |
| lpapp | ahh, internal toolchain crashes | 10:16 |
| lpapp | due to 4.8 vs. 4.7 with gcc. | 10:16 |
| lpapp | anyway, we cannot use a new toolchain. | 10:16 |
| lpapp | an internal* | 10:16 |
| lpapp | I will go for denzil and a support debian in chroot for now. | 10:16 |
| lpapp | until the guys fix the sourcery issues. | 10:17 |
| frank | Is there a simple method to check what packages are included by a package group ? | 10:20 |
| lpapp | oh, debian is not supported. :( | 10:20 |
| lpapp | well, that sucks huge balls. | 10:20 |
| lpapp | so basically, I cannot install anything into chroot to get it work | 10:21 |
| lpapp | but I have to use virtualization. | 10:21 |
| lpapp | I dislike the vmware/vbox/etc stuff | 10:21 |
| lpapp | chroot would be so much more logical for a cli build. | 10:21 |
| bluelightning | lpapp: we do test against debian regularly | 10:21 |
| eren | JaMa: okkie, I will, thanks | 10:21 |
| lpapp | bluelightning: the website writes it is not supported. | 10:22 |
| lpapp | Ubuntu | 10:22 |
| lpapp | Fedora | 10:22 |
| lpapp | openSUSE | 10:22 |
| lpapp | CentOS | 10:22 |
| lpapp | https://wiki.yoctoproject.org/wiki/Distribution_Support -> Debian Wheezy failing. | 10:23 |
| bluelightning | lpapp: the linked report is from 2011... | 10:24 |
| -YoctoAutoBuilder- build #222 of nightly-world is complete: Failure [failed Building Images] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-world/builds/222 | 10:26 | |
| lpapp | bluelightning: yeah, so update it please. | 10:27 |
| bluelightning | lpapp: to be honest if nobody from QA is keeping that page up-to-date I'd rather see it deleted | 10:30 |
| Net147 | bluelightning: the links to it from the documentation should be removed as well then | 10:31 |
| bluelightning | Net147: yes, good point :/ | 10:31 |
| Net147 | I usually refer to the list of supported distributions in the reference manual - e.g. http://www.yoctoproject.org/docs/1.4/ref-manual/ref-manual.html#detailed-supported-distros | 10:32 |
| lpapp | bluelightning: I will submit a bugreport. | 10:33 |
| lpapp | I dislike wikis | 10:33 |
| lpapp | I agree about it being deleted. | 10:33 |
| bluelightning | Net147: right, that should be the canonical reference, since it's derived in a semi-automated manner from the SANITY_TESTED_DISTROS list in meta-yocto/conf/poky.conf | 10:33 |
| bluelightning | and SANITY_TESTED_DISTROS gets updated as a matter of course for every release | 10:34 |
| lpapp | bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4911 | 10:44 |
| yocti | Bug 4911: normal, Undecided, ---, scott.m.rifenbark, NEW , Wiki: Distribution Support outdated | 10:44 |
| bluelightning | lpapp: I think you may have pasted the wrong link | 10:45 |
| bluelightning | into the bug report | 10:45 |
| lpapp | bluelightning: whoops | 10:46 |
| lpapp | ;) | 10:46 |
| lpapp | indeed, konsole copy is buggy. | 10:46 |
| lpapp | thanks. | 10:46 |
| lpapp | lovely that I cannot edit a comment on bugzilla. :( | 10:47 |
| lpapp | updated. | 10:47 |
| bluelightning | standard for bugzilla out of the box I guess | 10:48 |
| lpapp | yeah, luckily enough Jira allows it. | 10:48 |
| *** Krz <Krz!c0c6972c@gateway/web/freenode/ip.192.198.151.44> has joined #yocto | 10:48 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 10:49 | |
| *** synthnassizer <synthnassizer!~quassel@143.233.242.130> has quit IRC | 10:49 | |
| *** synthnassizer <synthnassizer!~quassel@143.233.242.130> has joined #yocto | 10:49 | |
| lpapp | so does mantis | 10:49 |
| * lpapp is installing wheezy (7.0). | 10:52 | |
| bluelightning | lpapp: you already interact with kde that uses bugzilla, can you edit your comments there? | 10:53 |
| lpapp | bluelightning: I am interacting with Qt more. | 10:54 |
| lpapp | where Jira is in use. | 10:54 |
| lpapp | at my company, where mantis. | 10:54 |
| lpapp | bluelightning: no, bugs.kde.org does not allow that either. | 10:55 |
| lpapp | nor the meego bugtracker. | 10:55 |
| lpapp | nor gcc. | 10:55 |
| Net147 | I use Trac which allows editing comments | 10:55 |
| bluelightning | FWIW, I'm a fan of Mantis, I use it on one of the projects I maintain | 10:57 |
| lpapp | I have not used Mantis much. | 10:58 |
| lpapp | and I do not see it used that much in open source projects. | 10:58 |
| lpapp | can you mention any big open source project using it? | 10:58 |
| Krz | Hi guys, I'm using poky dylan-9.0.1 tag, found a problem in poky/scripts/rpm2cpio.sh. Basically when 'file' utility is not installed script falls back to lzma compression instead gently drop an error 'file not installed'. Eventually it causes very cryptic error. | 10:59 |
| bluelightning | Krz: hmm, I thought we were building file-native that would avoid that being an issue within the build process - or are you using it externally? | 11:01 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 11:01 | |
| bluelightning | lpapp: I don't know of any major one no, but then I haven't checked what they all use | 11:02 |
| *** swex <swex!~swex@178.17.201.225> has joined #yocto | 11:03 | |
| Krz | bluelightning: I spotted this error on clean debian-wheezy build without file utility installed. After installing file problem was gone. So I would say in this case Yocto used system file instead of Yocto file. Does that make any sense? | 11:03 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 11:05 | |
| *** swex__ <swex__!~swex@217.197.246.33> has quit IRC | 11:06 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 11:07 | |
| *** frank <frank!~frank@1.202.252.122> has quit IRC | 11:08 | |
| bluelightning | Krz: I guess so, I'd have to look at where rpm2cpio would be called and see if we need a dependency added there | 11:08 |
| bluelightning | Krz: Ideally it would have its own check and error if file is not available since it's a script that can be run externally | 11:08 |
| lpapp | sgw1: is there anyone still investigating about the CS external toolchain issue? | 11:10 |
| *** frank <frank!~frank@1.202.252.122> has joined #yocto | 11:10 | |
| Krz | bluelightning: either own check + error or some replacement for file. I think the same can be done without file, using only awk which is Yocto known dependency | 11:10 |
| bluelightning | Krz: right... would you mind filing a bug for that issue so it is tracked? | 11:11 |
| Krz | bluelightning: yes, I can do that. I requested access to Yocto bugzilla, but didn't receive activation email :(. Probably some email filters. | 11:11 |
| bluelightning | Krz: ah ok... if you continue to have problems with getting the activation email you might want to talk to halstead | 11:12 |
| * dzoe sighs ... | 11:13 | |
| dzoe | Compiling ttf-dejavu works, but building image that includes it results in: | Unable to resolve package ttf-dejavu | 11:13 |
| dzoe | Should I try something more than bitbake -f -c compile ? | 11:14 |
| Krz | bluelightning: ok, have access to bugzilla.yoctoproject.org. Is the Build System & Metadata -> BitBake the right place for scripts/rpm2cpio.sh related problem? | 11:18 |
| lpapp | when is the next dylan bugfix release expected to come? | 11:20 |
| *** lpapp <lpapp!~lpapp@212.44.19.228> has quit IRC | 11:33 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has quit IRC | 11:34 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 11:36 | |
| bluelightning | Krz: it's not bitbake, it's OE-Core | 11:37 |
| bluelightning | lpapp: I don't think a date has been set, but I think it's likely to be over a month away | 11:39 |
| bluelightning | dzoe: maybe it's a case that the ttf-dejavu package itself is empty and only ttf-dejavu-xyz packages get produced? | 11:40 |
| lpapp | bluelightning: phew... | 11:40 |
| bluelightning | ? | 11:40 |
| lpapp | that is a lot of time .... | 11:42 |
| lpapp | https://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html | 11:42 |
| lpapp | 1.3.2. Required Packages for the Host Development System | 11:42 |
| lpapp | debian is not there and supported, really? | 11:42 |
| lpapp | another bugreport to file against bugzilla? | 11:42 |
| rburton | bluelightning: hm, i think i just realised that the long pauses i see after bitbake finishes with "0 tasks remaining" is buildhistory writing (huge amounts of git activity in ps). can that easily write something to the console so there's the perception of progress? | 11:43 |
| rburton | lpapp: yes. it would just be a copy of the ubuntu section, anyway. | 11:44 |
| dzoe | bluelightning: I'm not sure, tmp/pkgdata/all-poky-linux/runtime/ttf-dejavu-sans-mono looks reasonable after bitbake ttf-dejavu, but bitbake ttf-dejavu-sans-mono yields "ERROR: Nothing PROVIDES 'ttf-dejavu-sans-mono'" | 11:44 |
| rburton | lpapp: the section above does say debian 6 and debian 7, fwiw | 11:45 |
| lpapp | rburton: not necessarily, no | 11:45 |
| lpapp | debian is not ubuntu after all. | 11:45 |
| lpapp | anyway, even if it should be the same which I dislike, but let us say it is | 11:45 |
| lpapp | 1.3.2.1 should be Ubuntu _and_ Debian | 11:46 |
| lpapp | so bugreport is being created. | 11:46 |
| rburton | for the base development stuff if the package names are not identical i'd be massively surprised | 11:46 |
| lpapp | rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4912 | 11:47 |
| yocti | Bug 4912: normal, Undecided, ---, scott.m.rifenbark, NEW , No "Required Packages" mentioned for Debian | 11:47 |
| bluelightning | dzoe: when you do "bitbake xyz", the xyz is a built-time target, i.e. a recipe or a recipe variant | 11:48 |
| volker | what's the best way to add an environment variable to a new RootFS image, so that it is available after starting up the embedded system | 11:48 |
| bluelightning | dzoe: ttf-dejavu is a build-time target, ttf-dejavu-sans-mono is a runtime package so "bitbake ttf-dejavu-sans-mono" would be invalid | 11:48 |
| *** Net147 <Net147!~Net147@60-242-179-244.static.tpgi.com.au> has quit IRC | 11:49 | |
| bluelightning | dzoe: however, IMAGE_INSTALL takes runtime packages so adding ttf-dejavu-sans-mono to IMAGE_INSTALL is valid | 11:49 |
| dzoe | Which means I should build ttf-dejavu and include ttf-dejavu-sans-mono? | 11:49 |
| bluelightning | dzoe: if you have to build it explicitly at all - just adding it to IMAGE_INSTALL (or RRECOMMENDS of another package if appropriate) will ensure it is built automatically | 11:49 |
| bluelightning | dzoe: (adding ttf-dejavu-sans-mono that is) | 11:50 |
| dzoe | I'd expect that, but that's what (I think) failed, gonna try again ... maybe I'm just overlooking something again. | 11:50 |
| bluelightning | rburton: yeah I do have a patch around here somewhere to do just that | 11:50 |
| bluelightning | volker: I think you should just be able to install a script setting the vars (with export) in ${sysconfdir}/profile.d/ and that should be all that's needed | 11:53 |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 11:54 | |
| volker | bluelightning: thanks, will try that | 11:55 |
| *** arky <arky!~arky@113.22.88.137> has joined #yocto | 11:57 | |
| *** Daemon404 <Daemon404!~who_knows@pdpc/supporter/student/Daemon404> has joined #yocto | 12:26 | |
| *** davest <davest!Adium@nat/intel/x-wfogpkawhxinguhi> has joined #yocto | 12:28 | |
| lpapp | http://paste.kde.org/~lpapp/p15489db4/ -> why am I getting error for bitbake on wheezy? | 12:29 |
| bluelightning | lpapp: your chroot is missing /dev/shm | 12:38 |
| bluelightning | lpapp: current versions check for the existence of that file and give you a proper error | 12:39 |
| lpapp | bluelightning: weird | 12:39 |
| lpapp | because /dev is mounted from fstab. | 12:39 |
| lpapp | -> /dev/shm is there. | 12:39 |
| lpapp | but it is empty. | 12:39 |
| lpapp | just like on the host | 12:39 |
| bluelightning | ok, not sure then, but errors usually only happen in that part of the code because /dev/shm can't be used | 12:40 |
| lpapp | so wheezy will not work either? :( | 12:40 |
| lpapp | what will work for Yocto then, seriously? | 12:40 |
| bluelightning | seriously, the list of distros/versions we test for every release | 12:41 |
| lpapp | the listed distribution does not work for me? | 12:42 |
| lpapp | I am reporting a bug again, sigh, but I do not think I can wait for any bug fixed. | 12:43 |
| lpapp | can anyone actually mention a setup where it should work? | 12:44 |
| lpapp | I am disappointed at large that even a reference platform is broken. :( | 12:44 |
| ant_work | Gentoo is not listed but working | 12:44 |
| lpapp | ok, so that is a complete no go. | 12:44 |
| ant_work | lpapp: you should really start a basic build for qemuarm | 12:44 |
| ant_work | then add the layers one by one | 12:45 |
| lpapp | actually, this issue, just like the other upstream, has nothing to do with layers. | 12:46 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 12:48 | |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 12:49 | |
| bluelightning | lpapp: I know of several people who are using debian in a chroot to do builds on a regular basis, so it is possible | 12:49 |
| *** davest <davest!Adium@nat/intel/x-wfogpkawhxinguhi> has quit IRC | 12:50 | |
| bluelightning | lpapp: but it's not a configuration we ever regularly test | 12:50 |
| bluelightning | nor did we ever claim anywhere that it was | 12:50 |
| lpapp | debian wheezy is mentioned as a supported distribution. | 12:50 |
| lpapp | anyway, let us start off with a bugreport. | 12:51 |
| ndec | lpapp: http://bec-systems.com/site/1029/os-containers-for-build-systems | 12:51 |
| *** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has quit IRC | 12:51 | |
| ndec | how to build OE, on Arch, using LXC and Debian. | 12:51 |
| bluelightning | lpapp: yep, but when you run a chroot of debian that is *not* the same thing as running debian | 12:51 |
| ndec | i casually build dylan on ubuntu (12.04, 12.10, 13.04), and Debian/sid. and some of my team members use OpenSuse. | 12:52 |
| lpapp | ndec: ? | 12:52 |
| lpapp | bluelightning: how do you *really* know it is a chroot issue? | 12:53 |
| ndec | lpapp: also, i assume what you don't run as root, in your chroot. i have never tried, but i expect it might not work fine. | 12:53 |
| lpapp | ndec: I have always used stuff as on the host | 12:53 |
| lpapp | have never had any issues | 12:54 |
| lpapp | this is not the first I am using debian in chroot | 12:54 |
| lpapp | we had to use that back then for meego, too. | 12:54 |
| lpapp | also, please note that sudo bitbake will not fly. | 12:54 |
| ndec | ok. | 12:55 |
| lpapp | bluelightning: it *might* just well be a generic debian issue | 12:55 |
| lpapp | unless you prove it *is* a chroot isuse. | 12:55 |
| lpapp | issue* | 12:55 |
| wmat | lpapp: re. meta-sourcery layer, you add it to bblayers.conf to use it | 12:57 |
| lpapp | wmat: that is all? | 12:57 |
| wmat | lpapp: here's an example of how the xilinx folks use it -> https://github.com/Xilinx/meta-xilinx | 12:58 |
| wmat | lpapp: see the README | 12:58 |
| lpapp | wmat: README of? | 12:58 |
| wmat | of that Github link, just scroll down | 12:58 |
| lpapp | ok, so the README of meta-xiling | 12:59 |
| lpapp | x | 12:59 |
| lpapp | and not meta-sourcery, or something else. | 12:59 |
| wmat | yes | 12:59 |
| rburton | lpapp: i can tell you for sure that debian is a working host, as i've been using it non-stop for over a year now | 12:59 |
| lpapp | rburton: any idea then? | 12:59 |
| rburton | lpapp: presumably the permissions on your /dev/shm are wrong? | 12:59 |
| ant_work | wmat: please be more precise | 12:59 |
| rburton | lpapp: the error says permission denied, to check the permissions. | 12:59 |
| lpapp | wmat: ok, better to make sure | 12:59 |
| wmat | ant_work: more precise? | 13:00 |
| lpapp | rburton: 755 | 13:00 |
| lpapp | rburton: 777 on the host | 13:00 |
| lpapp | and I cannot assign +w to it. | 13:00 |
| rburton | lpapp: well that's the problem | 13:01 |
| rburton | nothing to do with bitbake, but a bad chroot | 13:01 |
| lpapp | rburton: ? | 13:01 |
| lpapp | sudo LANG=C.UTF-8 chroot /mnt/wheezy /bin/bash -l -> this is the right way to chroot. | 13:01 |
| lpapp | and this is how it is mounted: /dev /mnt/wheezy/dev auto bind 0 0 | 13:02 |
| lpapp | full of regular stuff | 13:02 |
| rburton | sure. i meant the contents of the chroot when you are in it, is wrong. your /dev/shm isn't world-writable. | 13:02 |
| lpapp | could you please clarify why it is a *chroot* issue? | 13:02 |
| lpapp | right, so it is not a chroot issue | 13:02 |
| rburton | because its different inside and outside the chroot? | 13:02 |
| rburton | ffs, this is just semantic bullshit | 13:02 |
| rburton | your /dev/shm has the wrong permissions. | 13:03 |
| rburton | that's the problem | 13:03 |
| rburton | lets not play games at identifying exactly who is to blame so we can glare at them | 13:03 |
| *** arky <arky!~arky@113.22.88.137> has quit IRC | 13:03 | |
| rburton | lets just fix the permissions | 13:03 |
| lpapp | I do not like people when they think it is a chroot issue | 13:03 |
| lpapp | and they can free up their hand | 13:03 |
| lpapp | I think it is very important to get it straight. | 13:04 |
| lpapp | also, I am about to submit another bugreport | 13:04 |
| lpapp | it should suggest /dev/shm in some way. | 13:04 |
| lpapp | this is again something totally mysterious to me. | 13:04 |
| lpapp | I would have never guessed it. | 13:04 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-czxmiquuhmncwnvt> has joined #yocto | 13:06 | |
| bluelightning | lpapp: that's not our code, that's python multiprocessing | 13:07 |
| bluelightning | lpapp: and we already have a check in master for that, so no bug report needed | 13:07 |
| lpapp | huh? | 13:07 |
| lpapp | the error is coming from bitbake. | 13:07 |
| lpapp | bitbake should know what it is doing. | 13:07 |
| bluelightning | lpapp: check the code path | 13:07 |
| lpapp | you can hardly blame upstream. | 13:07 |
| bluelightning | lpapp: http://patchwork.openembedded.org/patch/49621/ | 13:08 |
| bluelightning | which has been merged as http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=fd8dcd7b88925dbb8203b0d2ec6ac62fe667676c | 13:09 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tqufjvqiiiryfgqg> has joined #yocto | 13:09 | |
| lpapp | bluelightning: I do not like that change. | 13:09 |
| lpapp | so I will submit a bugreport/change | 13:09 |
| * rburton lols | 13:09 | |
| bluelightning | lpapp: ? | 13:09 |
| lpapp | I think the exact issue could be specified without the option. | 13:09 |
| bluelightning | what option? | 13:09 |
| lpapp | you do not need to give a list of issue that can go wrong. | 13:09 |
| lpapp | you can directly give the *offending* issue. | 13:10 |
| lpapp | list of issues* | 13:10 |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 13:11 | |
| lpapp | bluelightning: agree? | 13:12 |
| bluelightning | lpapp: I honestly don't think it's a big deal, but if you feel motivated to write a patch to split it out into separate checks and corresponding errors, please feel free to send a patch that does that | 13:14 |
| lpapp | bluelightning: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4914 | 13:14 |
| yocti | Bug 4914: normal, Undecided, ---, richard.purdie, NEW , Not talkative enough error message for /dev/shm issues | 13:14 |
| lpapp | rburton: lols ? | 13:15 |
| lpapp | bluelightning: I have never said it is a big dela. | 13:15 |
| lpapp | deal* | 13:15 |
| lpapp | but small deals are not welcome, or what? | 13:15 |
| *** frank_fighting71 <frank_fighting71!~frank@118.186.200.116> has quit IRC | 13:16 | |
| *** Krz <Krz!c0c6972c@gateway/web/freenode/ip.192.198.151.44> has quit IRC | 13:18 | |
| lpapp | hmm, none /dev/shm tmpfs defaults,size=1G 0 0 did not help | 13:18 |
| lpapp | it is still not writable... :( | 13:18 |
| rburton | did you verify that your /dev/shm in the chroot is actually a tmpfs? | 13:20 |
| rburton | when i mount a tmpfs, the mode on the mountpoint change to 1777 | 13:20 |
| lpapp | oh, debian uses /run/shm | 13:20 |
| lpapp | not /dev/shm | 13:20 |
| lpapp | so bitbake is wrong then. | 13:20 |
| rburton | no, /dev/shm is a symlink | 13:20 |
| lpapp | but then I actually wonder how it is a supported platform?! | 13:21 |
| rburton | lrwxrwxrwx 1 root root 8 Jul 15 09:29 /dev/shm -> /run/shm | 13:21 |
| lpapp | no no, it is not. | 13:21 |
| rburton | that was a ls from my *debian system* | 13:21 |
| lpapp | ls -ld /dev/shm/ | 13:21 |
| lpapp | drwxr-xr-x 2 root root 40 Jul 25 11:33 /dev/shm/ | 13:21 |
| lpapp | rburton: what is the permission on your /run/shm? | 13:23 |
| mulhern | If a Perl module is under license Artistic-1.0 and GPLv2 why does the corresponding recipe file use Artistic-1.0 | GPLv2? My question is about changing and to or. | 13:23 |
| rburton | lpapp: same as all tmpfs, 1777 | 13:24 |
| lpapp | rburton: 755 in here. | 13:24 |
| rburton | mulhern: my standard reply to anything related to license fields is to say "ask beth" :) | 13:24 |
| rburton | lpapp: sounds like the tmpfs isn't actually mounted to me | 13:24 |
| mulhern | OK. :) | 13:24 |
| lpapp | rburton: you mean from the host. | 13:24 |
| lpapp | rburton: you mean, I also need to bind it? | 13:26 |
| lpapp | from the host to chroot? | 13:26 |
| lpapp | http://superuser.com/questions/460815/mounts-not-present-in-fstab-where-are-they | 13:27 |
| rburton | The bind mount call attaches only (part of) a single filesystem, | 13:27 |
| rburton | not possible submounts. The entire file hierarchy including sub‐ | 13:27 |
| rburton | mounts is attached a second place using | 13:27 |
| rburton | says the mount documentation | 13:27 |
| lpapp | tmpfs is of course attached to the host system if that is only what you mean | 13:28 |
| lpapp | but it might well be that it needs to be bound to the chroot. | 13:28 |
| rburton | yes, see the documentation quote i pasted | 13:29 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 13:29 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tqufjvqiiiryfgqg> has quit IRC | 13:39 | |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 13:39 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 13:41 | |
| lpapp | rburton: can you show the relevant lines from your fstab? | 13:41 |
| lpapp | I am not getting it. | 13:41 |
| lpapp | why is bitbake relying on it anyway? | 13:41 |
| lpapp | instead of getting the tmp variable content? | 13:42 |
| lpapp | it looks silly to me. | 13:42 |
| rburton | lpapp: i don't run debian in a chroot | 13:42 |
| lpapp | but you need to get it mounted on the host as well anyway? | 13:44 |
| rburton | sure, the init system does that | 13:44 |
| lpapp | not from fstab? | 13:44 |
| rburton | correct | 13:45 |
| lpapp | bizarro | 13:46 |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 13:46 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tcycxkqhgdrimiwp> has joined #yocto | 13:47 | |
| lpapp | wmat: lolz @ INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags" | 13:47 |
| lpapp | wmat: have you tried PREFERRED_PROVIDER_virtual/* | 13:48 |
| lpapp | wmat: why is meta-xilinx using TCMODE = "external-csl"? | 13:57 |
| lpapp | instead of TCMODE = "external-sourcery"? | 13:58 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 14:03 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 14:03 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 14:05 | |
| lpapp | rburton: bluelightning wmat got a clue ? http://paste.kde.org/~lpapp/pb3f03555/ | 14:08 |
| rburton | NOTE: preferred version 141 of udev not available (for item udev-utils) says your distro config still thinks its (probably) denzil | 14:08 |
| rburton | the pseudo problem is just incredibly frustrating. the cp says external-sourcery, i thought you were using our own compilers? | 14:09 |
| lpapp | rburton: no, we have used external. | 14:11 |
| lpapp | what is the libpseudo thingie? | 14:11 |
| rburton | its like fakeroot on steriods | 14:11 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 14:12 | |
| lpapp | -> /home/lpapp/Projects/polatis/Yocto/poky-dylan-9.0.0/foo-builds/tmp/work/armv5te-polatis-linux-gnueabi/external-sourcery-toolchain/2009q1-203-r22/image/ | 14:12 |
| lpapp | oh noooes... | 14:12 |
| lpapp | that folder is empty btw | 14:12 |
| rburton | the real problem is the cp i suspect, you'll have to debug what its trying to do and what should be there | 14:12 |
| lpapp | I removed the udev preference. | 14:13 |
| lpapp | well, I have no clue where to start the debugging. | 14:13 |
| lpapp | "A generic library providing simple thread-safe messaging between threads" | 14:15 |
| lpapp | rburton: what is this specifying? INSANE_SKIP_external-sourcery-toolchain-dev += "ldflags" | 14:21 |
| rburton | lpapp: its disabling a sanity check | 14:22 |
| rburton | without it you'd get a warning, which is presumably a false-positive for that package | 14:23 |
| rburton | http://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#var-INSANE_SKIP | 14:23 |
| *** mihai <mihai!~mihai@188.27.93.142> has joined #yocto | 14:25 | |
| *** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has quit IRC | 14:25 | |
| *** tinti <tinti!~tinti@pdpc/supporter/student/tinti> has quit IRC | 14:32 | |
| lpapp | sgw1: ping | 14:32 |
| sgw1 | lpapp: good morning | 14:33 |
| *** sgw1 is now known as sgw_ | 14:33 | |
| lpapp | sgw_: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4908 | 14:33 |
| yocti | Bug 4908: normal, Undecided, ---, laurentiu.palcu, ACCEPTED , External toolchain does not work with poky dylan | 14:33 |
| lpapp | can you reproduce the bug at the bottom? | 14:34 |
| sgw_ | lpapp: in a bug triage meeting reviewing the bugs now! | 14:34 |
| lpapp | I know meta-sourcery is not a yocto project material though, but still, any help appreciated. | 14:34 |
| *** TuTizz_ <TuTizz_!~TuTizz@46.18.96.158> has joined #yocto | 14:35 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 14:35 | |
| lpapp | also, no one has reviewed the tiny change yet: https://lists.yoctoproject.org/pipermail/poky/2013-July/009056.html | 14:35 |
| *** TuTizz_ is now known as TuTizz | 14:36 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 14:36 | |
| wmat | lpapp: it's using external-csl because it's an older set of instructions | 14:36 |
| wmat | lpapp: I have not tried any of this and unfortunately do not have time to | 14:36 |
| *** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has joined #yocto | 14:38 | |
| lpapp | wmat: got a clue about the error though? | 14:38 |
| denix | melonipoika: that is not even a yocto layer! that is a mirror of a Classic OpenEmbedded oe-dev repository! | 14:44 |
| wmat | lpapp: sort of, in so far as I've seen that pseudo error before on the mailing list | 14:49 |
| wmat | lpapp: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/15695 | 14:49 |
| *** zeddii <zeddii!~bruce@50-196-24-201-static.hfc.comcastbusiness.net> has joined #yocto | 14:49 | |
| wmat | lpapp: see if that post rings any bells regarding your system | 14:50 |
| lpapp | I saw that thread. | 14:51 |
| rburton | if thats the right thread it has a fix in | 14:51 |
| lpapp | rburton: what fix? | 14:52 |
| rburton | if you find the right pseudo thread, there's a fix in it | 14:52 |
| lpapp | file /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc | 14:52 |
| lpapp | /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped | 14:52 |
| rburton | by fix i mean possibly hack | 14:52 |
| lpapp | hmm, that might be inline with the last suggestion from mark. | 14:52 |
| lpapp | I am using x86_64 | 14:52 |
| lpapp | but the external toolchain seems to be 32 bit. | 14:52 |
| lpapp | wmat: did you find a 64 bit toolchain? | 14:53 |
| lpapp | provided by Code Sourcery? | 14:53 |
| *** frank_fighting71 <frank_fighting71!~frank@118.186.200.116> has joined #yocto | 14:53 | |
| *** swex <swex!~swex@178.17.201.225> has quit IRC | 14:53 | |
| lpapp | hmm, that probably does not matter since we need to generate 32 bit target. | 14:53 |
| lpapp | although a 64 bit compiler should be able to do that, but still. | 14:54 |
| lpapp | Finally, you can get this message if you are on a mixed-mode (multilib) host. | 14:54 |
| lpapp | I.e. you have executables that are both ELF 32 and ELF64. If so, you need to | 14:54 |
| lpapp | configure the system to build pseudo with both target environments, otherwise | 14:54 |
| lpapp | only one version is generated and you'll get an error when the "other" type is | 14:54 |
| lpapp | being executed. | 14:54 |
| lpapp | how to configure the system so? | 14:54 |
| rburton | lpapp: target arch is unrelated to host arch | 14:56 |
| lpapp | rburton: so? | 14:57 |
| rburton | i was answering your "hmm, that probably does not matter since we need to generate 32 bit target. / although a 64 bit compiler should be able to do that, but still." line | 14:58 |
| rburton | just trying to be helpful | 14:58 |
| lpapp | ok, I think either way is fine. | 14:58 |
| lpapp | CS probably pushes 32 bit binaries | 14:59 |
| lpapp | I guess I do not need to install libpseudo on my host? | 14:59 |
| rburton | bitbake builds pseudo | 15:00 |
| lpapp | yeah | 15:00 |
| lpapp | well, I have no clue to be honest. | 15:00 |
| lpapp | "If so, you need to configure the system to build pseudo with both target environments" -> what is that supposed to mean? | 15:00 |
| rburton | lpapp: seebs is your best person to speak to about pseudo | 15:01 |
| lpapp | ok | 15:03 |
| lpapp | it is pretty hard to get Yocto work with an external toolchain. | 15:04 |
| lpapp | I would not be envy for pastime people who cannot even spend 8 hours a day with getting it right. | 15:04 |
| rburton | this pseudo problem isn't related to external toolchains, and i've made it appear and disappear here by changing unrelated variables | 15:05 |
| lpapp | shouldn't the layer providers put example config files and README into their layer? | 15:05 |
| lpapp | well, the critical issue is the toolchain in here. | 15:05 |
| rburton | lpapp: yes, that's a requirement for the yocto compatible badge | 15:06 |
| lpapp | rburton: ok, so meta-sourcery is not like that just yet. | 15:07 |
| rburton | correct | 15:07 |
| rburton | its a mentor project | 15:07 |
| lpapp | rburton: should I file a bugreport about the libpseudo thingie? | 15:08 |
| *** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has quit IRC | 15:08 | |
| rburton | lpapp: pretty sure there's already one | 15:09 |
| rburton | https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 | 15:09 |
| yocti | Bug 4843: normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host | 15:09 |
| lpapp | https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=pseudo&list_id=60922 | 15:10 |
| lpapp | heh, this would be fun, too: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4063 | 15:10 |
| yocti | Bug 4063: enhancement, Medium, 1.5, peter.seebach, NEW , pseudo's logging and diagnostics are not very clear | 15:10 |
| *** swex <swex!~swex@178.17.201.225> has joined #yocto | 15:12 | |
| lpapp | https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 -> added a comment, and changed to accepted. | 15:14 |
| yocti | Bug 4843: normal, Medium, 1.5, paul.eggleton, ACCEPTED , Issue with pseudo on 64-bit build host | 15:14 |
| lpapp | bravely... /me runs | 15:14 |
| *** arky <arky!~arky@113.22.88.137> has joined #yocto | 15:15 | |
| rburton | lpapp: i hope by "set you accepted" you meant "i took the bug" | 15:15 |
| lpapp | I wonder why seebs is not added to that report though? | 15:15 |
| lpapp | now, he is. | 15:16 |
| lpapp | no escape... :-) | 15:16 |
| lpapp | sorry seebs | 15:16 |
| rburton | lpapp: btw my comment on that bug was in polite mode. please don't mess with bugzilla state. | 15:16 |
| lpapp | bluelightning: do you work on 4843? | 15:17 |
| lpapp | rburton: well, it is accepted | 15:17 |
| lpapp | as I plan to work on it if no one does already. | 15:17 |
| lpapp | but if someone already does, then it is accepted again. | 15:18 |
| rburton | lpapp: take the assignee then | 15:18 |
| lpapp | see the question above to bluelightning | 15:18 |
| rburton | as i said, accepted means "i am literally working on it right now, and expect to send a well-tested patch" | 15:18 |
| rburton | if that isn't your intention then don't take the accepted state | 15:18 |
| rburton | (and if it is, then take the assignee too) | 15:18 |
| panda84kde | Hi guys. I've googled but didn't found useful links. How do I change keyboard layout in yocto? | 15:18 |
| lpapp | what is the point of having an assignee without being accepted? | 15:18 |
| rburton | lpapp: i've got 30 bugs. am i working on them all right now? no. | 15:20 |
| lpapp | rburton: sounds bad then | 15:21 |
| *** JaMa <JaMa!~martin@ip-62-24-80-145.net.upcbroadband.cz> has joined #yocto | 15:21 | |
| lpapp | because others need to poke you if you work them or not. | 15:21 |
| lpapp | on* | 15:21 |
| lpapp | or just forgot to take it. | 15:21 |
| lpapp | anyway, I do not see the point of assignee without actual working. | 15:21 |
| *** frank_fighting71 <frank_fighting71!~frank@118.186.200.116> has quit IRC | 15:26 | |
| lpapp | is there an example how to set up an own local mirror, sstate, etc? | 15:28 |
| wmat | lpapp: I believe that's in the YP documentation | 15:29 |
| rburton | lpapp: the short version is "share it, somehow". NFS/CIFS/HTTPD will all do. | 15:30 |
| lpapp | rburton: I mean what do I need to do in the yocto repository to recognize the mirror | 15:30 |
| rburton | lpapp: that's in the docs | 15:30 |
| lpapp | ah, SSTATE_MIRRORS | 15:31 |
| lpapp | maybe ... | 15:31 |
| rburton | you can have a local download mirror too | 15:31 |
| lpapp | does it work on localhost | 15:31 |
| lpapp | k | 15:31 |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto | 15:33 | |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC | 15:36 | |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto | 15:36 | |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 15:38 | |
| *** davest <davest!~Adium@134.134.137.71> has joined #yocto | 15:44 | |
| *** zeddii <zeddii!~bruce@50-196-24-201-static.hfc.comcastbusiness.net> has quit IRC | 15:49 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 15:52 | |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC | 15:53 | |
| *** zeeblex <zeeblex!~apalalax@134.134.139.76> has left #yocto | 15:53 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 15:54 | |
| -YoctoAutoBuilder- build #223 of nightly-arm is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-arm/builds/223 | 15:55 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 15:55 | |
| *** davest <davest!~Adium@134.134.137.71> has quit IRC | 15:56 | |
| *** belen <belen!Adium@nat/intel/x-pntzefjzityjsnij> has quit IRC | 15:58 | |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto | 15:59 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 15:59 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 15:59 | |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has joined #yocto | 16:00 | |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 16:01 | |
| *** belen <belen!Adium@nat/intel/x-hyonfkukqfwuuapa> has joined #yocto | 16:01 | |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 16:02 | |
| *** Corneliu <Corneliu!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has quit IRC | 16:02 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 16:02 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 16:03 | |
| lpapp | seebs: ping | 16:04 |
| lpapp | can someone repaste the container log again? | 16:17 |
| lpapp | instead of chroot, there was some arch systemd thingie | 16:17 |
| *** sameo <sameo!samuel@nat/intel/x-izavkbaxeavrydqi> has quit IRC | 16:17 | |
| rburton | http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html | 16:18 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 16:18 | |
| lpapp | no no, there was an arch and debian specific link | 16:19 |
| lpapp | with oe particularly. :) | 16:19 |
| lpapp | the guy on the link just forgot to explain why it is needed. | 16:19 |
| lpapp | but apparently, you cannot create symlinks inside chroot. | 16:19 |
| lpapp | only hard link. | 16:19 |
| rburton | you can't symlink from inside to outside | 16:19 |
| rburton | but you can symlink inside a chroot | 16:20 |
| kergoth | huh, that's interesting, hadn't seen that systemd command | 16:20 |
| kergoth | too bad it's part of systemd :) | 16:20 |
| * lpapp needs the oe/arch/debian link again | 16:21 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-tcycxkqhgdrimiwp> has quit IRC | 16:23 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nrqmtzpofsaxriqj> has joined #yocto | 16:23 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nrqmtzpofsaxriqj> has quit IRC | 16:23 | |
| *** davest <davest!~Adium@134.134.137.71> has joined #yocto | 16:26 | |
| lpapp | I found the root cause of the issue! | 16:28 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 16:30 | |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC | 16:31 | |
| lpapp | NOTE: Your conf/bblayers.conf has been automatically updated. | 16:31 |
| lpapp | NOTE: Your conf/bblayers.conf has been automatically updated. | 16:31 |
| lpapp | huh ? | 16:32 |
| rburton | magic! | 16:32 |
| *** lgammo <lgammo!a12ce17f@gateway/web/cgi-irc/kiwiirc.com/ip.161.44.225.127> has joined #yocto | 16:32 | |
| lpapp | 1) I hate magics. | 16:32 |
| lpapp | 2) Nothing changed in that file. | 16:32 |
| rburton | 1) distro build systems are 90% magic | 16:32 |
| rburton | 2) presumably a false-positive | 16:33 |
| lpapp | majority does not make it right ... ;) | 16:33 |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 16:33 | |
| *** davest <davest!~Adium@134.134.137.71> has quit IRC | 16:33 | |
| *** arky <arky!~arky@113.22.88.137> has quit IRC | 16:33 | |
| rburton | you can't complain that a tool is doing something trivial and automated for you if you're using a build system | 16:34 |
| lpapp | trivial and automated != magics | 16:35 |
| lpapp | it should tell me what is doing and why. | 16:35 |
| lpapp | but at least the what. | 16:35 |
| lpapp | Updating xz ... | 16:35 |
| lpapp | even "magic tools" do that. | 16:35 |
| lpapp | looks like another bugreport to me. | 16:35 |
| lpapp | is it possible that poky/master has not changed since yesterday? | 16:36 |
| rburton | yes | 16:36 |
| lpapp | last commit 30 hours ago | 16:36 |
| lpapp | that is fine. | 16:36 |
| lpapp | I wonder if anyone has time to reproduce my issue? | 16:37 |
| rburton | lpapp: it re-formatted a statement, grep for that message and you'll see | 16:37 |
| lpapp | with cloning poky, meta-sourcery, and then I can give two config files? | 16:37 |
| lpapp | the issue should show up very early after running bitbake. | 16:37 |
| lpapp | I can reproduce it easily without my layer ... | 16:37 |
| lpapp | yet, kergoth claims he cannot. | 16:37 |
| lpapp | I suspect he has something different locally. | 16:37 |
| rburton | wasn't there a comment in the bug you filed where sgw_ said he can replicate? | 16:37 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 16:37 | |
| rburton | if its the bug i'm thinking of, there is someone looking at it | 16:38 |
| lpapp | rburton: that was with oe-core sourcery | 16:38 |
| lpapp | rburton: not with the supported meta-sourcery from MG. | 16:38 |
| rburton | lpapp: for that, speak to MG | 16:38 |
| lpapp | rburton: no no, I mean someone here | 16:38 |
| lpapp | who can spend a few minutes with it | 16:38 |
| lpapp | because it is currently 1:! | 16:38 |
| lpapp | 1:1 | 16:38 |
| lpapp | I can reproduce, kergoth cannot | 16:38 |
| lpapp | he would love to help according to the comment | 16:39 |
| lpapp | he just cannot reproduce the issue. | 16:39 |
| lpapp | and I can, even with a brand new clone | 16:39 |
| lpapp | meh, I cannot attach the config files to github | 16:40 |
| lpapp | they only support images | 16:40 |
| lpapp | lame | 16:40 |
| *** mihai <mihai!~mihai@188.27.93.142> has quit IRC | 16:40 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:41 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 16:41 | |
| *** Guest89262 <Guest89262!~tbn@84.55.160.118> has quit IRC | 16:46 | |
| * lpapp desperately needs bitbake --clean | 16:46 | |
| sgw_ | lpapp: I was about to reproduce the pure oe-core issue that you filed yesterday and someone was looking into it overnight in EU, unfortunately no progress was made and I will not be able to spend too much time on it today due to my other responsibilities. I understand it's currently blocking you. | 16:46 |
| lpapp | rm -rf bitbake.lock cache/ downloads/ sstate-cache/ tmp/ | 16:46 |
| lpapp | it is very annoying to do this all the time manually. | 16:47 |
| sgw_ | lpapp: I have not attempted to reproduce the meta-sorcery issue as that is MG's responsibility as rburton pointed out. | 16:47 |
| *** belen <belen!Adium@nat/intel/x-hyonfkukqfwuuapa> has quit IRC | 16:47 | |
| lpapp | yeah, but any volunteer is more than welcome for a few minutes testing. :) | 16:48 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-arbcqniygiuoexsh> has joined #yocto | 16:48 | |
| mr_science | moin | 16:50 |
| lpapp | sgw_: well, I guess the oe-core sourcery support is not the official way anyhow. | 16:51 |
| lpapp | at least, I guess no one is seriously maintaining that. | 16:51 |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 16:51 | |
| mr_science | we use the codesourcery toolchain with oe-classic/bitbake-1.10.2-arago but i haven't tried external with yocto yet | 16:53 |
| mr_science | lpapp: if you can point me to your issue, i can probably try it tonight | 16:54 |
| lpapp | mr_science: 4908 | 16:54 |
| lpapp | hopefully solved by that time though. ;) | 16:54 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-arbcqniygiuoexsh> has quit IRC | 16:56 | |
| kergoth | regarding the clean thing, you should never need to wipe sstate-cache manually, any metadata changes that affect the output will invalidate the cache and result in tasks being rerun as necessary. neither should you need to wipe bitbake.lock or cache, those are refreshed as necessary also. the only thing i ever wipe, personally, is tmp :) | 16:56 |
| kergoth | (you're unignored now, so we can speed up the test cycle on getting this issue resolved) | 16:56 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-rpeagkxppdvkwjzv> has joined #yocto | 16:57 | |
| sgw_ | kergoth: lpapp just as a data point I was able to reproduce the meta-sourcery failure (if all I needed to do was add meta-sourcery to my bblayers.conf) same as the oe-core failure | 16:58 |
| * lpapp cries for --clear | 16:58 | |
| *** belen <belen!Adium@nat/intel/x-umcxaurgfcnivshl> has joined #yocto | 16:58 | |
| lpapp | sgw_: yeah, before meta | 16:59 |
| lpapp | sgw_: and change external-csl to external-sourcery | 16:59 |
| lpapp | if you have not done that yet. | 16:59 |
| *** swex <swex!~swex@178.17.201.225> has quit IRC | 16:59 | |
| kergoth | sgw_: https://github.com/MentorEmbedded/meta-sourcery/issues/9 has the info on my attempts to reproduce, fyi | 16:59 |
| kergoth | FYI, I just added NO32LIBS="0" to the meta-sourcery tcmode, to hopefully avoid that being an issue going forward | 16:59 |
| *** swex <swex!~swex@178.17.201.225> has joined #yocto | 17:00 | |
| * kergoth fires up a centos 5.4 VM to test there also | 17:00 | |
| kergoth | (oldest test env i have) | 17:00 |
| sgw_ | kergoth: lpapp: I did not get the errors now that I moved the layer in bblayers, i tried MACHINE = beagleboard and qemuarm, I only got some preferred version notes about 4.3 for the compiler. | 17:03 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 17:03 | |
| lpapp | sgw_: what host? | 17:04 |
| lpapp | what BB_VERSION? | 17:04 |
| lpapp | what CSL_VER_MAIN? | 17:04 |
| lpapp | can you paste the build configuration as a whole please? | 17:04 |
| sgw_ | lpapp: Master on Ubuntu 12.10 | 17:05 |
| lpapp | also, have you tried poky master head? | 17:05 |
| lpapp | 64 bit or 32? | 17:05 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 17:05 | |
| sgw_ | posted to github issue | 17:06 |
| lpapp | sgw_: it would have been nice to have the same machine (qemuarm), but ok. | 17:07 |
| lpapp | sgw_: your meta-yocto-bsp is different | 17:08 |
| lpapp | perhaps due to the machine difference. | 17:08 |
| lpapp | sgw_: were you using my config files, third set? | 17:09 |
| sgw_ | lpapp: honestly I have lost track, I don't know which set of your local.conf file I have | 17:09 |
| *** lgammo <lgammo!a12ce17f@gateway/web/cgi-irc/kiwiirc.com/ip.161.44.225.127> has quit IRC | 17:10 | |
| lpapp | it is hard to make comparison that way, unfortunately. | 17:10 |
| lpapp | ls /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc | 17:11 |
| lpapp | /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc | 17:11 |
| lpapp | /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc -v | 17:11 |
| lpapp | bash: /usr/local/arm-2009q1/bin/arm-none-linux-gnueabi-gcc: No such file or directory | 17:11 |
| lpapp | huh? | 17:11 |
| kergoth | sgw_: if he's seeing a 'No such file or directory' error when trying to run an executable that exists, it usually means the dynamic linker is missing, which means he's likely missing the 32 bit libc bits for his distro (I think he still has me ignored) | 17:18 |
| sgw_ | kergoth: lpapp: yeah, it might be something like that, because with his third set of local.conf files it is building, we had pointed that we have not tested with arch linux in the past on IRC, so that's where some issue might come in. | 17:20 |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC | 17:21 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 17:21 | |
| lpapp | kergoth: I have not ignored you for a few days now | 17:24 |
| lpapp | hi | 17:24 |
| lpapp | well, I have /usr/lib32/ld-2.17.so | 17:24 |
| lpapp | perhaps it is not looking into /usr/lib32, only /usr/lib? | 17:24 |
| sgw_ | lpapp: can you do a find for libgcc_s on /usr/lib* and /lib | 17:24 |
| lpapp | libgcc_s? | 17:25 |
| sgw_ | or libpthread* | 17:25 |
| lpapp | find /usr/lib -name \*libgcc_s\* | 17:25 |
| lpapp | /usr/lib/libgcc_s.so.1 | 17:25 |
| lpapp | /usr/lib/libgcc_s.so | 17:25 |
| lpapp | nothing in /lib | 17:25 |
| sgw_ | lpapp: it's one of the files that pseudo seems to be failing to link against | 17:25 |
| lpapp | find /usr/lib -name \*libpthread\* | 17:26 |
| lpapp | /usr/lib/libpthread.so.0 | 17:26 |
| lpapp | /usr/lib/libpthread_nonshared.a | 17:26 |
| lpapp | /usr/lib/libpthread-2.17.so | 17:26 |
| lpapp | /usr/lib/libpthread.so | 17:26 |
| lpapp | /usr/lib/libpthread.a | 17:26 |
| lpapp | nothing in /lib | 17:26 |
| lpapp | right, but it is looking for 32 bit | 17:26 |
| lpapp | note, arch has /usr/lib32 | 17:26 |
| lpapp | but those pthread and gcc_s stuff is in /usr/lib32, too | 17:26 |
| lpapp | perhaps the stuff is not looking into /usr/lib32? | 17:26 |
| *** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:27 | |
| sgw_ | please do a file on both the /usr/lib and /usr/lib32 libpthread-2.17.so (should be the actual file I think) | 17:27 |
| lpapp | and /usr/bin/ld is definitely 64 bit | 17:27 |
| sgw_ | just curious | 17:27 |
| lpapp | file /usr/lib/libpthread-2.17.so | 17:28 |
| lpapp | /usr/lib/libpthread-2.17.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=34f9c4c656a433d97f1e95495bc400f1dace7637, for GNU/Linux 2.6.32, not stripped | 17:28 |
| lpapp | file /usr/lib32/libpthread-2.17.so | 17:28 |
| lpapp | /usr/lib32/libpthread-2.17.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), BuildID[sha1]=8f2c31fd48bd9964607c32037e5cb51a5525e06e, for GNU/Linux 2.6.32, not stripped | 17:28 |
| lpapp | file /usr/lib/libgcc_s.so.1 | 17:28 |
| lpapp | /usr/lib/libgcc_s.so.1: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=2a56ef2d37d3f5f43f3ab657b4e25235cff7b145, stripped | 17:28 |
| lpapp | file /usr/lib32/libgcc_s.so.1 | 17:28 |
| lpapp | /usr/lib32/libgcc_s.so.1: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BuildID[sha1]=4c82372fdcb4f7058073bc6d06fbdc08bdd01da5, stripped | 17:28 |
| sgw_ | Well I am at a loss then, we got past one issue and stumbled on another | 17:28 |
| kergoth | [Requesting program interpreter: /lib/ld-linux.so.2] | 17:29 |
| sgw_ | seebs: any ideas why pseudo would fail to link on lpapp's machine? | 17:29 |
| kergoth | according to a readelf -a on the toolchain gcc | 17:29 |
| kergoth | so it expects that to be a 32 bit linker | 17:29 |
| kergoth | make sure that's the case to | 17:29 |
| kergoth | o | 17:29 |
| * sgw_ biab | 17:30 | |
| seebs | Nothing obvious, although multilib hosts are a known source of trouble sometimes. | 17:30 |
| kergoth | the latest attached configs on the bug look solid, indeed | 17:30 |
| * kergoth hasn't tried doing builds on arch in a while, remembers having to deal with /usr/bin/python being python3 | 17:31 | |
| lpapp | what can I do to fix the issue? | 17:31 |
| *** pidge <pidge!~pidge@c-24-21-207-18.hsd1.or.comcast.net> has quit IRC | 17:31 | |
| lpapp | kergoth: that is a one liner fix | 17:31 |
| lpapp | added to your profile and done | 17:31 |
| kergoth | nod | 17:32 |
| lpapp | anyway, the README extension is unclear to me. | 17:32 |
| lpapp | at least, it does not help me understanding how to get over this issue | 17:32 |
| kergoth | I've never seen that pseudo build failure before, but it's unrelated to the external toolchain stuff, as its a native recipe | 17:32 |
| kergoth | it explains how to use meta-sourcery, I don't know how to make it any clearer than that. you've already followed those instructions, and are now hitting particular issues which are unrelated to configuration | 17:33 |
| lpapp | seebs: can you help circumventing the libpseudo issue? | 17:33 |
| lpapp | apparently, a define is not enough on the bugreport. | 17:33 |
| lpapp | https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 | 17:33 |
| yocti | Bug 4843: normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host | 17:33 |
| lpapp | kergoth: it might be not yet related | 17:34 |
| lpapp | but once the libpseudo issue is fixed, it will come back | 17:34 |
| lpapp | note how it was coming after the libpseudo issue before, too. | 17:34 |
| kergoth | regardless, issue #9 was about documentation being missing. it's no longer missing. if you get faiulres after getting past the pseudo failure, by all means open a new meta-sourcery bug, or we can continue to wrk against yocto bug 4908. | 17:35 |
| yocti | Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4908 normal, Medium+, 1.5 M3, laurentiu.palcu, ACCEPTED , External toolchain does not work with poky dylan | 17:35 |
| lpapp | well, documenting the local.conf usage more would be useful. | 17:36 |
| kergoth | I don't understand what you're referring to | 17:36 |
| lpapp | external-sourcery is yet mentioned for instance. | 17:37 |
| kergoth | the readme tells you what needs to be done, completely | 17:37 |
| kergoth | it's not mentioend because it's not needed | 17:37 |
| kergoth | meta-sourcery's layer.conf sets it for you | 17:37 |
| lpapp | or TARGET_PREFIX | 17:37 |
| kergoth | that's not needed either | 17:37 |
| lpapp | perhaps a note would be helpful. | 17:37 |
| kergoth | it searches a built in list of commonly used prefixes for sorucery toolchains | 17:37 |
| lpapp | because it is confusing after coming from the other end | 17:37 |
| lpapp | where it is needed. | 17:37 |
| lpapp | This is all you need | 17:37 |
| lpapp | if you do not wanna be explicit | 17:37 |
| kergoth | I'm not going to document everything people might have done following flawed instructions | 17:37 |
| lpapp | that could be a valuable addition to the README. | 17:38 |
| lpapp | it is not flawed instruction | 17:38 |
| lpapp | it is the official way it was before. | 17:38 |
| kergoth | nor does it hurt anything to set those things, as long as they're set correctly | 17:38 |
| lpapp | they are totally irrelevant | 17:38 |
| *** belen <belen!Adium@nat/intel/x-umcxaurgfcnivshl> has quit IRC | 17:38 | |
| lpapp | so should not bloat the config if they are not needed. | 17:38 |
| lpapp | it should be made clear. | 17:38 |
| kergoth | I'm not documenting how to minimize your local.conf. I really don't care how cluttered your local.conf is. that's your doing, not mine | 17:39 |
| kergoth | I document what needs to be done, period. | 17:39 |
| lpapp | you are not helping the migration at all. | 17:39 |
| lpapp | I really do not understand helping people migrating is not welcome | 17:39 |
| kergoth | from what, crappy meta-xilinx docs? | 17:40 |
| lpapp | it would be a one liner after all. | 17:40 |
| lpapp | no | 17:40 |
| lpapp | from damn oe-core | 17:40 |
| lpapp | you developer for users, not yourself, right? | 17:40 |
| lpapp | develop* | 17:40 |
| kergoth | TARGET_PREFIX hasn't been necessary in oe-core for years. | 17:40 |
| kergoth | even danny handled it automatically | 17:40 |
| lpapp | actually danny is less than a year old only. | 17:41 |
| lpapp | but anyway, documentating a migration path from a certain version ... I do not understand why it is so "bad". | 17:41 |
| kergoth | but as i've already explained, setting those things is *not* a problem | 17:41 |
| lpapp | it is for your users come on ... | 17:41 |
| lpapp | SIGH | 17:41 |
| kergoth | it's not a migration, its an optimization of your local.conf | 17:41 |
| lpapp | let us ignore each other, and continue over email | 17:41 |
| lpapp | if you do not wanna help your users. | 17:42 |
| kergoth | good plan, i'm sick of the whining | 17:42 |
| lpapp | I will blog about it, and I will help *your* users | 17:42 |
| lpapp | what whining? | 17:42 |
| lpapp | suggestion from A F U C K I N G U S E R | 17:42 |
| lpapp | to help others | 17:42 |
| *** ka6sox is now known as ka6sox-away | 17:43 | |
| * lpapp has never really understood the stubborn developers | 17:43 | |
| *** davest <davest!Adium@nat/intel/x-ulxqaizjltwdzhlh> has joined #yocto | 17:43 | |
| lpapp | who argue against doing the work when the main goal should be helping the users as much as possible. | 17:43 |
| lpapp | I was not trying to do any favour for myself as I already know the lesson by learning it the "hard way". | 17:45 |
| lpapp | sorry guys for the capital stuff | 17:46 |
| lpapp | I lost my mind | 17:46 |
| lpapp | I apologize. | 17:46 |
| * mr_science recalls the men-in-white-coats (with the extra long sleeve jackets) | 17:47 | |
| lpapp | ? | 17:50 |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 17:51 | |
| *** panda84kde <panda84kde!~diego@static-217-133-170-65.clienti.tiscali.it> has quit IRC | 17:51 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 17:54 | |
| kergoth | Okay, there, I think that should address lpapp's concerns about migration without needing to cover what the user may or may not have done, by explaining exactly what's being done for you. I'm not going any further than that. I think this has value for multiple reasons | 17:58 |
| *** davest <davest!Adium@nat/intel/x-ulxqaizjltwdzhlh> has quit IRC | 17:59 | |
| *** davest <davest!~Adium@134.134.137.71> has joined #yocto | 17:59 | |
| *** davest <davest!~Adium@134.134.137.71> has quit IRC | 18:03 | |
| *** Bagder <Bagder!~daniel@178.174.211.166> has joined #yocto | 18:07 | |
| *** Bagder <Bagder!~daniel@rockbox/developer/bagder> has joined #yocto | 18:07 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 18:11 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-rpeagkxppdvkwjzv> has quit IRC | 18:14 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 18:17 | |
| sgw_ | kergoth: seebs: did that pseudo issue get resolved by any chance? | 18:19 |
| seebs | Not yet. I'm still a little unsure on why it only seems to affect a few people. I am pretty sure I am missing some key piece of information. | 18:20 |
| seebs | Looking at it, PSEUDO_LIBDIR should work even if it's set to ../lib, not .../lib64, even on a 64-bit host where libpseudo.so is in the lib64 dir, because pseudo knows to add a 64 when setting up LD_LIBRARY_PATH. So I think… I guess what I probably need to do is get a smallish reproducer, if I can, and figure out what the difference is between hosts where it works and hosts where it doesn't. | 18:22 |
| seebs | I'm expecting this to be one of those obvious single-line fixes once I have a working and non-working host to compare. | 18:22 |
| JaMa | seebs: have you ever seen pseudo sqlite db getting broken somehow? When running many builds and comparing files-in-image.txt in buildhistory we have found that some files sometimes get different permissions or owners | 18:22 |
| JaMa | seebs: trying to debug it, I have found that the only difference between those builds was in pseudo.db | 18:23 |
| JaMa | seebs: and that the permissions got modified during do_package task | 18:23 |
| seebs | I have seen some occasionally. In theory, the ways that this is likely to happen should all produce diagnostics in pseudo.log about files being found in the database that mismatch the filesystem in some way. | 18:23 |
| JaMa | seebs: very unfortunate when it happens on /lib/ld-* and it looses executable bit | 18:24 |
| seebs | Yeah, that would be pretty bad. | 18:24 |
| JaMa | that's where we have discovered first :/ | 18:24 |
| *** davest <davest!Adium@nat/intel/x-dlajeimdvpzccybx> has joined #yocto | 18:25 | |
| seebs | In theory, pseudo is checking whether both the path and device/inode match between incoming queries and the state of the database. If they don't, the most common cause is that an inode got reused, and something which had been in the database got deleted without the database entry being deleted. | 18:25 |
| seebs | One cause of that can be, on 64-bit hosts, running a 32-bit binary which relinks stuff, and not having NO32LIBS = "0" | 18:25 |
| *** davest <davest!Adium@nat/intel/x-dlajeimdvpzccybx> has quit IRC | 18:25 | |
| JaMa | that's very likely because we're using 32bit external toolchain | 18:26 |
| JaMa | on 64-bit host | 18:26 |
| seebs | Ahh. Yes. | 18:28 |
| seebs | That would indeed cause that to happen a lot, especially with the prelinker. | 18:28 |
| seebs | Solution is NO32LIBS = "0" | 18:28 |
| seebs | Not that I ever spent two months (1) ignoring some "harmless" messages about failing to load libpseudo.so, and (2) trying to figure out why very sporadically builds would be corrupt. | 18:29 |
| seebs | That would be SILLY. | 18:29 |
| JaMa | :) | 18:30 |
| JaMa | thanks a lot I never noticed NO32LIBS before | 18:30 |
| sgw_ | seebs: should you really be ownong Bug 4843? | 18:30 |
| yocti | Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4843 normal, Medium, 1.5, paul.eggleton, NEW , Issue with pseudo on 64-bit build host | 18:30 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 18:30 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 18:31 | |
| seebs | Good question! I am probably the right person in that I know pseudo pretty well, but since I've never been able to get it to happen on any of my systems, I am not well situated to track it down. | 18:31 |
| mr_science | i still can't see why pathologically coupling makefiles between different source repos is a good idea... | 18:37 |
| * mr_science thought developers actually understood issues related to coupling | 18:37 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xcccthdknydaomip> has joined #yocto | 18:41 | |
| lpapp | unignore kergoth | 18:41 |
| lpapp | oopsie | 18:41 |
| lpapp | sorry. :) | 18:41 |
| lpapp | not my day, apparently. | 18:42 |
| mr_science | at least you're still here... | 18:47 |
| * kergoth chuckles | 18:49 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 18:49 | |
| kergoth | JaMa: I just added it to my tcmode now, should probably add it to the example in oe-core too (NO32LIBS) | 18:50 |
| kergoth | heh | 18:50 |
| * kergoth should have done that a while ago, but had it in his distro config instead :) | 18:50 | |
| lpapp | mr_science: here, but from home, and not in hacking mood. | 18:50 |
| lpapp | mr_science: just relaxing and enjoying the sunny evening. :) | 18:51 |
| *** evanp <evanp!~evan@192.55.54.36> has quit IRC | 18:51 | |
| mr_science | kergoth: where did you move it to? | 18:51 |
| *** evanp <evanp!~evan@134.134.139.74> has joined #yocto | 18:51 | |
| mr_science | lpapp: not even lunch yet here... | 18:51 |
| kergoth | really belongs in the external toolchain config, since its the execution of external 32 bit binaries that requires it | 18:51 |
| * kergoth is currently procrastinating doing real work | 18:51 | |
| mr_science | i think i just found a parallel make bug... | 18:52 |
| lpapp | seebs: let me know if you need any information from here. | 18:53 |
| lpapp | I am more than happy to collaborate on solving issues. | 18:53 |
| lpapp | seebs: err.. one thing | 18:54 |
| lpapp | seebs: you think that 64 bit hosts use lib64, but that is not true for Arch | 18:55 |
| lpapp | seebs: since 64 bit is the common on 64 bit, they prefer to set /usr/lib to 64 bit by default | 18:55 |
| lpapp | and the dedicated minority is /usr/lib32 | 18:55 |
| lpapp | seebs: setting up arch in chroot is 10 minutes, and I can help with it if that is the only way to move forward. | 18:56 |
| mr_science | hmm.. i had a pseudo multilib issue on gentoo amd64 when i tried yocto there | 18:59 |
| mr_science | but i was much more interested in building something than debugging pseudo so i just moved everything to an ubuntu box | 19:00 |
| mr_science | lpapp: gentoo is the same way, ie, lib -> lib64 and lib32 sits by itself | 19:01 |
| lpapp | I think it makes sense | 19:01 |
| lpapp | because obviously 64 is the majority on 64 bit | 19:01 |
| lpapp | otherwise you would use the 32 bit system | 19:01 |
| mr_science | i (almost) always 64-bit native/multilib gentoo installs | 19:02 |
| mr_science | *do | 19:02 |
| kergoth | there's really an argument to be made in favor of either approach. multilib configurations vary. which is why yocto lets you configure such paths for multilib on the target, just not for your host, sadly | 19:03 |
| kergoth | heh | 19:03 |
| mr_science | and usually multilib is only for extraneous crap like firefox plugins | 19:03 |
| kergoth | of course some distros are moving to the new multilib setup, where they can even add arm, etc binaries to an x86 system since everything is truly isolated. i personally think they're crazy, but whatever :) | 19:03 |
| *** sameo <sameo!~samuel@192.55.54.41> has joined #yocto | 19:04 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 19:04 | |
| lpapp | mr_science: yeah, or skype. | 19:04 |
| seebs | pseudo does assume that its libraries are in lib/lib64, but then, it also enforces that assumption because it places them in its own directories which are distinct from the directories used by the host. | 19:04 |
| seebs | Thus, it's <whatever_path>/pseudo/{lib,lib64} | 19:05 |
| seebs | And that is not contingent on what the host uses for /usr/lib* names. | 19:05 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 19:05 | |
| seebs | Going and doing a thing, might be back later, and I do sort of plan to poke at this, I just keep having other activities also. | 19:06 |
| lpapp | well, it is blocking me right now. | 19:06 |
| lpapp | so at least give pointers please if you cannot do the job. | 19:06 |
| lpapp | also, lib32 really is very important to handle. | 19:06 |
| lpapp | otherwise several distros will be totally screwed. | 19:06 |
| lpapp | perhaps I could even give ssh access to my arch host at home. | 19:09 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 19:10 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 19:14 | |
| JaMa | kergoth: it's well documented in local.conf example but I wasn't expecting that issues we're seeing have so simple well known cause | 19:16 |
| *** frank <frank!~frank@1.202.252.122> has quit IRC | 19:17 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 19:17 | |
| *** agust <agust!~agust@pD9E2F216.dip0.t-ipconnect.de> has quit IRC | 19:17 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has quit IRC | 19:17 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has quit IRC | 19:17 | |
| *** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has quit IRC | 19:17 | |
| *** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has quit IRC | 19:17 | |
| *** fabo <fabo!~fabo@linaro/fabo> has quit IRC | 19:17 | |
| *** rtollert_ <rtollert_!~rtollert@client-74-216.natinst.com> has quit IRC | 19:17 | |
| *** awafaa <awafaa!uid716@gateway/web/irccloud.com/x-gpbbhwqpzuhawasb> has quit IRC | 19:17 | |
| *** grifter1881 <grifter1881!~grifter@static-50-53-13-32.bvtn.or.frontiernet.net> has quit IRC | 19:17 | |
| *** halstead <halstead!~halstead@drupal.org/user/301087/view> has quit IRC | 19:17 | |
| *** khohm <khohm!~quassel@share.basyskom.com> has quit IRC | 19:17 | |
| *** denix <denix!~denix@pool-108-45-150-102.washdc.fios.verizon.net> has quit IRC | 19:17 | |
| *** gonzzor <gonzzor!~gonzzor@leela.campus.luth.se> has quit IRC | 19:17 | |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has joined #yocto | 19:18 | |
| *** frank <frank!~frank@1.202.252.122> has joined #yocto | 19:18 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 19:18 | |
| *** agust <agust!~agust@pD9E2F216.dip0.t-ipconnect.de> has joined #yocto | 19:18 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-96-211.hsd1.or.comcast.net> has joined #yocto | 19:18 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has joined #yocto | 19:18 | |
| *** jonatan <jonatan!~quassel@194-237-7-146.customer.telia.com> has joined #yocto | 19:18 | |
| *** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has joined #yocto | 19:18 | |
| *** fabo <fabo!~fabo@linaro/fabo> has joined #yocto | 19:18 | |
| *** rtollert_ <rtollert_!~rtollert@client-74-216.natinst.com> has joined #yocto | 19:18 | |
| *** awafaa <awafaa!uid716@gateway/web/irccloud.com/x-gpbbhwqpzuhawasb> has joined #yocto | 19:18 | |
| *** grifter1881 <grifter1881!~grifter@static-50-53-13-32.bvtn.or.frontiernet.net> has joined #yocto | 19:18 | |
| *** halstead <halstead!~halstead@drupal.org/user/301087/view> has joined #yocto | 19:18 | |
| *** khohm <khohm!~quassel@share.basyskom.com> has joined #yocto | 19:18 | |
| *** denix <denix!~denix@pool-108-45-150-102.washdc.fios.verizon.net> has joined #yocto | 19:18 | |
| *** gonzzor <gonzzor!~gonzzor@leela.campus.luth.se> has joined #yocto | 19:18 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 19:18 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto | 19:18 | |
| *** swex <swex!~swex@178.17.201.225> has quit IRC | 19:20 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 19:20 | |
| *** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has quit IRC | 19:20 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 19:20 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 19:20 | |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC | 19:20 | |
| *** honschu <honschu!~honschu@shackspace/j4fun> has quit IRC | 19:20 | |
| *** silviof1 <silviof1!~silviof@ppp-88-217-75-129.dynamic.mnet-online.de> has quit IRC | 19:20 | |
| *** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has quit IRC | 19:20 | |
| *** cristianiorga <cristianiorga!~cristiani@134.134.137.75> has quit IRC | 19:20 | |
| lpapp | JaMa: IMO it is a bug to specify that explicitly. | 19:20 |
| lpapp | it should autodetect what it needs to do. | 19:21 |
| *** swex <swex!~swex@178.17.201.225> has joined #yocto | 19:21 | |
| *** seebs <seebs!~seebs@home.seebs.net> has joined #yocto | 19:21 | |
| *** volker <volker!~volker@host-80-81-19-29.customer.m-online.net> has joined #yocto | 19:21 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 19:21 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 19:21 | |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has joined #yocto | 19:21 | |
| *** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto | 19:21 | |
| *** silviof1 <silviof1!~silviof@ppp-88-217-75-129.dynamic.mnet-online.de> has joined #yocto | 19:21 | |
| *** RagBal <RagBal!~RagBal@54694E34.cm-12-2b.dynamic.ziggo.nl> has joined #yocto | 19:21 | |
| *** cristianiorga <cristianiorga!~cristiani@134.134.137.75> has joined #yocto | 19:21 | |
| lpapp | I mean it is workaround for the bug, sorry, but not a solution. | 19:21 |
| JaMa | yes that's what documentation for that value says | 19:21 |
| *** Ramana_ <Ramana_!7aa6729b@gateway/web/freenode/ip.122.166.114.155> has quit IRC | 19:22 | |
| *** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.128.219.49.13> has quit IRC | 19:22 | |
| *** Ramana_ <Ramana_!7aa6729b@gateway/web/freenode/ip.122.166.114.155> has joined #yocto | 19:22 | |
| *** flynn378 <flynn378!80db310d@gateway/web/freenode/ip.128.219.49.13> has joined #yocto | 19:22 | |
| *** ka6sox-away is now known as ka6sox-farfarawa | 19:23 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 19:23 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has quit IRC | 19:23 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has quit IRC | 19:23 | |
| *** _Lucretia__ <_Lucretia__!~munkee@90.218.162.144> has quit IRC | 19:23 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has quit IRC | 19:23 | |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 19:23 | |
| *** Jay7 <Jay7!jay@176.15.255.149> has quit IRC | 19:23 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC | 19:23 | |
| *** chris__ <chris__!~chris@cpe-74-71-215-22.twcny.res.rr.com> has quit IRC | 19:23 | |
| *** Crofton|work <Crofton|work!~balister@pool-108-44-87-78.ronkva.east.verizon.net> has quit IRC | 19:23 | |
| *** jukkar <jukkar!jukka@nat/intel/x-yatttauwtthqpehh> has quit IRC | 19:23 | |
| *** thaytan <thaytan!~thaytan@113.94.233.220.static.exetel.com.au> has quit IRC | 19:23 | |
| *** ka6sox-farfarawa <ka6sox-farfarawa!ka6sox@nasadmin/ka6sox> has quit IRC | 19:23 | |
| lpapp | JaMa: once 4843 is fixed, that variable should be history. | 19:27 |
| lpapp | JaMa: also, I am unlucky because even that variable does not help on Arch. | 19:31 |
| *** acidfu <acidfu!~nib@24.37.17.210> has joined #yocto | 19:34 | |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has joined #yocto | 19:34 | |
| *** Crofton|work <Crofton|work!~balister@pool-108-44-87-78.ronkva.east.verizon.net> has joined #yocto | 19:34 | |
| *** thaytan <thaytan!~thaytan@113.94.233.220.static.exetel.com.au> has joined #yocto | 19:35 | |
| *** _Lucretia__ <_Lucretia__!~munkee@90.218.162.144> has joined #yocto | 19:35 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 19:35 | |
| *** YoctoAutoBuilder <YoctoAutoBuilder!~YoctoAuto@autobuilder.yoctoproject.org> has joined #yocto | 19:35 | |
| *** TuTizz <TuTizz!~TuTizz@unaffiliated/tutizz> has joined #yocto | 19:35 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has joined #yocto | 19:35 | |
| *** Jay7 <Jay7!jay@176.15.255.149> has joined #yocto | 19:35 | |
| *** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto | 19:35 | |
| *** chris__ <chris__!~chris@cpe-74-71-215-22.twcny.res.rr.com> has joined #yocto | 19:35 | |
| *** jukkar <jukkar!jukka@nat/intel/x-yatttauwtthqpehh> has joined #yocto | 19:35 | |
| *** ka6sox-farfarawa <ka6sox-farfarawa!ka6sox@nasadmin/ka6sox> has joined #yocto | 19:35 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 19:35 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto | 19:35 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 19:40 | |
| mr_science | so we have our first in-house package that fails randomly with make -jN (N > 1) | 19:40 |
| lpapp | mr_science: bugreport? | 19:40 |
| mr_science | the response i got was "parallel make is bad idea" | 19:41 |
| lpapp | LOLZ | 19:41 |
| mr_science | lpapp: internal = not public | 19:41 |
| lpapp | yeah, right. | 19:41 |
| * lpapp looks for bitbake --clear reports | 19:45 | |
| sgw_ | lpapp: based on your last email and a couple of other fixes, I can get pasted the multiple provides issue, but I have a different problem now with the install of external toolchain! | 19:51 |
| lpapp | sgw_: ? | 19:52 |
| lpapp | as for me, it is weird, I cannot even reproduce the issue now. | 19:52 |
| lpapp | not even the pseudo one. | 19:52 |
| lpapp | the only thing happend that I cleaned up the stuff | 19:52 |
| lpapp | happened* | 19:53 |
| sgw_ | hmm, well, I will have some patches soon I hope | 19:53 |
| lpapp | EXTERNAL_TOOLCHAIN = "/usr" | 19:53 |
| lpapp | I only have this left. | 19:53 |
| lpapp | I removed the PREFIX_PATH | 19:53 |
| lpapp | or how it was called. | 19:53 |
| lpapp | and the TCSMODE | 19:53 |
| lpapp | I could likely even remove EXTERNAL_TOOLCHAIN | 19:53 |
| sgw_ | EXTERNAL_TOOLCHAIN_SYSROOT I think is the correct setting | 19:53 |
| lpapp | as /usr is in the path | 19:53 |
| lpapp | ? | 19:53 |
| lpapp | no? | 19:53 |
| lpapp | "Set `EXTERNAL_TOOLCHAIN = "/path/to/your/sourcery-g++-install"` in `conf/local.conf`." | 19:54 |
| lpapp | probably you do not need to bother, if you install it in the path. | 19:54 |
| lpapp | if it is intelligent enough to pick up the one with the proper prefix. | 19:55 |
| lpapp | sorry, I was wrong, I can reproduce the libpseudo issue | 19:55 |
| lpapp | even without the hackery variable. | 19:55 |
| lpapp | I believe it is the matter of lib32/lib/lib64 support | 19:55 |
| lpapp | IMHO, guessing the library folder is wrong | 19:56 |
| lpapp | and the information should be obtained in a different way. | 19:56 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 19:57 | |
| mr_science | well, on gentoo bitbake could actually inherit an eclass and do ${get_libdir} | 20:03 |
| mr_science | would be easy enough to add... | 20:03 |
| lpapp | I am opening a new libpseudo bugreport | 20:04 |
| lpapp | there you go: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4919 | 20:07 |
| yocti | Bug 4919: normal, Undecided, ---, saul.wold, NEW , Failure when trying to build on Archlinux 64 bit host with 32 external toolchain | 20:07 |
| lpapp | seebs: sgw_ ^ | 20:07 |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 20:11 | |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has quit IRC | 20:14 | |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 20:16 | |
| mr_science | okay, i'll go back and try it on gentoo amd64 again and see if i can add anything useful... | 20:23 |
| mr_science | or maybe you'll just fix it for me ;) | 20:23 |
| lpapp | heh, k, thanks in advance. | 20:23 |
| *** ant_home <ant_home!~andrea@host88-64-dynamic.8-87-r.retail.telecomitalia.it> has joined #yocto | 20:24 | |
| sgw_ | seebs: so now I am seeing something different with the external toolchain and pseudo during do_install(), ERROR: ld.so: object ''\''libpseudo.so'\''' from LD_PRELOAD cannot be preloaded: ignored. | 20:25 |
| sgw_ | seebs: pseudo builds correctly, but then this occurs during the toolchain install | 20:25 |
| mr_science | sgw_: that was also in a previous error posted by lpapp i believe | 20:29 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 20:31 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:32 | |
| lpapp | sgw_: 4843 for that | 20:33 |
| lpapp | sgw_: are you using NO32LIBS = "0" now? | 20:34 |
| lpapp | seebs: how can I tell libpseudo to look into lib32 rather than lib? | 20:36 |
| lpapp | is this libpseudo a blocker for building a system anyway? | 20:37 |
| lpapp | desktop distributions have built without it just fine ... | 20:37 |
| lpapp | can we have it optional? | 20:37 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 20:38 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 20:40 | |
| sgw_ | lpapp: libpseudo provides a fakeroot equivlant with a persistent db , so it's very required | 20:48 |
| lpapp | sgw_: arch does not use fakeroot, nor libpseudo | 20:50 |
| lpapp | and arch is a fairly complex distribution. | 20:50 |
| sgw_ | lpapp, I am not going there, different build systems for different purposes | 20:50 |
| mr_science | lpapp: i think fakeroot has more potential issues | 20:51 |
| mr_science | libseudo just needs to understand multilib environments | 20:51 |
| mr_science | fakeroot in the bitbake context anyway... | 20:52 |
| *** ka6sox-farfarawa is now known as ka6sox-away | 20:53 | |
| seebs | sgw: That's interesting. Can we snoop the environment it's running in, and the executable? | 20:54 |
| mr_science | somehow i have a mental image of ka6sox-away caught in a tornado on his way to Oz... | 20:54 |
| seebs | In the current design, if pseudo is being used to set up the environment, it should work consistently because it's both setting up the environment and defining where things get installed. | 20:55 |
| sgw_ | seebs: sure, strace or what tool, I can do reproduce it in a devshell | 20:55 |
| mr_science | "auntie M~ auntie M!" | 20:55 |
| lpapp | mr_science: I dislike both. :) | 20:55 |
| lpapp | sgw_: well, it is not looking into lib32 | 20:55 |
| lpapp | that is the issue so clearly. | 20:55 |
| lpapp | it looks into lib, and that is fine for Ubuntu | 20:56 |
| lpapp | but Ubuntu is not Arch. | 20:56 |
| seebs | Well, the main thing I'd want to see would be what LD_LIBRARY_PATH is. | 20:56 |
| seebs | And where you have libpseudo.so files. | 20:56 |
| lpapp | so we need to get libpseudo look into the right folder. How to do that? | 20:56 |
| seebs | They aren't installed in the standard system library directories, nor should they be, so pseudo's naming convention is pretty much arbitrary; we could have it be .../lib/pseudo/a and .../lib/pseudo/b, it wouldn't matter. In principle. | 20:56 |
| sgw_ | let me fire up devshell | 20:57 |
| lpapp | -> ./build/tmp/work/x86_64-linux/pseudo-native | 20:57 |
| lpapp | well, | 20:57 |
| seebs | Hmm. I wonder. qemu.bbclass has its own setup for this. | 20:57 |
| lpapp | 1) It should look into the right place | 20:57 |
| mr_science | in the days of old we might set an env var and let libpseudo pick it up... | 20:57 |
| lpapp | 2) If it cannot, it should respect the manual override | 20:57 |
| seebs | Oh, heyyy. | 20:57 |
| sgw_ | seebs: another note, this is a "cp" command, and the cp works in devshell, but not when fired from the run.do_install scro[t | 20:57 |
| lpapp | there is no other way around. | 20:57 |
| seebs | Is that under qemu_run_binary? | 20:58 |
| sgw_ | script even | 20:58 |
| sgw_ | seebs: no | 20:58 |
| lpapp | well, I can beagleboard if you are concerned about qemuarm | 20:58 |
| sgw_ | this is the do_install for external-sourcery-toolchain | 20:58 |
| lpapp | use* | 20:58 |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 20:58 | |
| seebs | Okay, nevermind. The setup there looks a bit odd. And I'm a little unsure why qemu_run_binary is setting PSEUDO_UNLOAD=1, which was relevant to the case I was looking at previously. | 20:58 |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has quit IRC | 21:00 | |
| sgw_ | seebs, I think my issue is different that 4843 maybe | 21:00 |
| seebs | I think so. | 21:00 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 21:01 | |
| sgw_ | seebs: Ok, so how do you want to proceed with this one? | 21:02 |
| seebs | I am mostly curious about the existing setting of LD_LIBRARY_PATH, because that seems like it's relevant, and I am finding myself a little unsure on how it gets set. | 21:02 |
| lpapp | sgw_: your issue is more like 4919 | 21:02 |
| *** zerus <zerus!~epetmab@90-224-44-236-no67.tbcn.telia.com> has quit IRC | 21:02 | |
| lpapp | seebs: how should I print that variable out? | 21:03 |
| seebs | So, thinking about it, the entire build is being run with pseudo present but "disabled", as I recall. | 21:03 |
| seebs | Which is why things like FAKEROOTENV, etcetera, don't have to set LD_PRELOAD or LD_LIBRARY_PATH. | 21:03 |
| sgw_ | lpapp: no it's really a different issue | 21:03 |
| lpapp | sgw_: what issue? | 21:04 |
| seebs | hey wait a second. | 21:04 |
| seebs | I think I may have found a loose end. | 21:04 |
| seebs | … Possibly irrelevant, but I did just find an invocation of localedef which looks to me like it may be wrong, since it's still using PSEUDO_RELOADED, which I think should be obsolete by now. | 21:04 |
| sgw_ | lpapp: my do_install() of external-sourcery-toolchain | 21:05 |
| lpapp | sgw_: that does not tell much to me. | 21:05 |
| seebs | Interestingly, I note that prelink_image() has commented-out pieces for displaying LD_LIBRARY_PATH, LD_PRELOAD, and anything in env which matches PSEUDO. | 21:05 |
| lpapp | sgw_: why don't you create a bug report with a bit more details? | 21:05 |
| seebs | It seems a little odd that external-sourcery-toolchain would be failing in this way when other things aren't. | 21:07 |
| seebs | *thinks* sgw_, what host are you using, and what's your configuration look like? I have meta-sourcery around and can try things also. | 21:09 |
| seebs | I am not quite sure what I am looking for right now; I am currently dealing with this vague sense of "wasn't there this thing that I wanted to look at because I didn't trust it that mightbe relevant", which is unfortunately preventing me from thinking more coherently about the data I actually *do* have. | 21:09 |
| sgw_ | seebs: not using meta-sourcery trying to get the oe-core external-tool-chain working directly, have a patch for some bits | 21:10 |
| sgw_ | F18 and U 12.10 (happens on both) x86-64, building qemuarm or beagleboard | 21:10 |
| sgw_ | TCMODE = "external-csl" | 21:10 |
| sgw_ | EXTERNAL_TOOLCHAIN = "/usr/local/arm-2009q1" | 21:10 |
| sgw_ | TARGET_PREFIX = "arm-none-linux-gnueabi-" | 21:10 |
| sgw_ | NO32LIBS = "0" | 21:10 |
| seebs | Interesting. I haven't tried the external toolchain stuff in a while, but I think I have it lying around to test. | 21:11 |
| sgw_ | seebs that should be enough and fails quickly | 21:11 |
| seebs | Tragically, my fast machine isn't either of those. But it's fast enough that I think I'll try it anyway. | 21:11 |
| seebs | Huh. Except I don't have toolchain binaries there yet. This is what happens when I get shiny new hardware; I keep forgetting stuff I'll need access to at some point for it to work well. | 21:12 |
| sgw_ | seebs to you need a pointer to the 2009q1 toolchain? | 21:13 |
| kergoth | sgw_: you shouldn't be using external-csl | 21:13 |
| kergoth | even in oe-core its just a sstub that pulls in external-sourcery, if it still exists at all | 21:13 |
| sgw_ | Ok, but I am not sure it will change the failure I am seeing in core | 21:13 |
| seebs | I have a variety of CS toolchains, they're just not that specific one. But I think they work. … Or used to,anyway. | 21:13 |
| * kergoth gets food | 21:13 | |
| seebs | sgw_, if you could add an echo of LD_LIBRARY_PATH and LD_PRELOAD to the failing do_install, and give me the output of those, plus the run.do_install, I could probably productively study those and ask smarter questions. | 21:14 |
| kergoth | it may not, but using it propogates problematic configurations, since people tend to copy and paste :) | 21:14 |
| sgw_ | kergoth: got it, sorry | 21:14 |
| kergoth | no worries | 21:15 |
| *** bluelightning <bluelightning!~paul@cpc13-lewi17-2-0-cust74.2-4.cable.virginmedia.com> has joined #yocto | 21:17 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 21:17 | |
| sgw_ | kergoth: just sent you a patch for pre-review, let me know if that's OK with you. | 21:17 |
| sgw_ | seebs: working on a paste bin! | 21:17 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 21:17 | |
| *** fitzsim <fitzsim!~user@nat/cisco/x-gatiaonknqjnejaw> has quit IRC | 21:18 | |
| kergoth | sgw_: ah, looks fine to me, nicely done identifying the particular changes needed | 21:18 |
| * kergoth never had time to look into it | 21:18 | |
| sgw_ | kergoth: between your meta-sourcery and lpapp email helped point it all out | 21:19 |
| sgw_ | seebs: ignore me I think I just found a different problem with I looked at the script more closely | 21:19 |
| sgw_ | seebs: # Use optimized files if available | 21:20 |
| sgw_ | sysroot="ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be preloaded: ignored. | 21:20 |
| sgw_ | /usr/local/arm-2009q1/bin/../arm-none-linux-gnueabi/libc" | 21:20 |
| sgw_ | seems there is more issue with generating the sysroot! | 21:20 |
| seebs | Oh-hoh! | 21:20 |
| seebs | I believe I know where that comes from. | 21:20 |
| seebs | Because earlier, it was set by invoking gcc --print-sysroot | 21:20 |
| sgw_ | seebs: yup, that's where I am going next! | 21:20 |
| seebs | I'm a little surprised to find the stderr message showing up there. | 21:21 |
| kergoth | heh, it should probably not be grabbing stderr.. | 21:26 |
| mr_science | hey, no grabbing... | 21:26 |
| seebs | And come to think of it, we might have missed this internally at WR because we had fancy stuff to compare --print-sysroot values to values we expected. | 21:26 |
| sgw_ | yeah think! | 21:26 |
| * mr_science is conditioned to respond that way | 21:28 | |
| mr_science | especially on long car trips... | 21:28 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-xcccthdknydaomip> has quit IRC | 21:50 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 22:04 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 22:05 | |
| *** e8johan <e8johan!~quassel@c-d463e455.16-3-64736c10.cust.bredbandsbolaget.se> has quit IRC | 22:08 | |
| *** agust <agust!~agust@pD9E2F216.dip0.t-ipconnect.de> has quit IRC | 22:14 | |
| *** ka6sox-away is now known as ka6sox | 22:20 | |
| -YoctoAutoBuilder- build #194 of nightly-fsl-ppc-lsb is complete: Failure [failed Building Images Publishing Artifacts] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-ppc-lsb/builds/194 | 22:22 | |
| sgw_ | seebs: here is a pastebin with the gcc and libpsuedo search http://pastebin.com/8wKaDu2r | 22:23 |
| seebs | Thanks! | 22:23 |
| sgw_ | sorry took a while had to do some other setup, that was without NO32LIBS set | 22:23 |
| seebs | Oh, that's REALLY interesting. | 22:24 |
| seebs | Consider: /srv/hdd/releases/dylan/build/tmp/sysroots/x86_64-linux/usr/bin/../lib/pseudo/lib/tls/sse2/libpseudo.so | 22:24 |
| seebs | That looks very much like LD_LIBRARY_PATH has lib/pseudo/lib, and something else, and I'm not sure what, is then searching for subdirectories it thinks are likely. | 22:25 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 22:26 | |
| seebs | So the next question is, where did LD_LIBRARY_PATH get set originally? | 22:26 |
| sgw_ | I am guessing it's bitbake's env since this is anon python code | 22:26 |
| seebs | Hmm. | 22:27 |
| seebs | bitbake -e doesn't show that being set yet. | 22:27 |
| sgw_ | It finds the libpseudo.so once not the second time | 22:27 |
| seebs | Yeah. That is also strange. Hmm. | 22:27 |
| sgw_ | Like it looses the LD_LIBRARY_PATH on that second look up | 22:28 |
| seebs | Okay, I appear to be unclear on something fairly fundamental about how bitbake is working, which is that I can't actually figure out how LD_LIBRARY_PATH got set initially. | 22:28 |
| seebs | Like, from the point where I type "bitbake foo" to the point at which something executes in the pseudo environment. I don't know where that happens, and casual grepping isn't finding anything likely. | 22:28 |
| sgw_ | Ok, I will add an echo of LD_LIBRARY_PATH in the command, what even more interesting is that with the -e option is works correctly but when it generates the run.do_install it's wrong | 22:29 |
| seebs | Hmm. That sounds very much like something is helpfully cleaning up or fixing the environment in some way... | 22:29 |
| sgw_ | Yup | 22:29 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 22:31 | |
| sgw_ | I am not sure if it's the usage of PSEUDO_UNLOAD or PSEUDO_DISABLED | 22:31 |
| seebs | It shouldn't be… Hmm. | 22:31 |
| seebs | Okay, I think I have found a thing of which I am now suspicious. | 22:31 |
| *** mario-go` <mario-go`!~user@email.parenteses.org> has joined #yocto | 22:31 | |
| sgw_ | seebs: I know RP was real careful to only enable pseudo when really needed | 22:31 |
| seebs | But I am still not clear on where LD_LIBRARY_PATH is coming from. But I do notice... | 22:32 |
| seebs | There's a point where pseudo detects that there's no LD_LIBRARY_PATH, and you've specified PSEUDO_LIBDIR, and does the right thing. | 22:32 |
| seebs | And if you DO have an LD_LIBRARY_PATH at that point, it checks that for PSEUDO_LIBDIR, and if it's missing, it adds both versions. | 22:32 |
| seebs | But if you had LD_LIBRARY_PATH == PSEUDO_LIBDIR, it wouldn't realize that it wants to set LD_LIBRARY_PATH to PSEUDO_LIBDIR:PSEUDO_LIBDIR64. | 22:33 |
| seebs | I still don't know how LD_LIBRARY_PATH is getting set, or what to, but this would be a thing that could cause problems. | 22:33 |
| *** dzoe_ <dzoe_!joe@joe.cz> has joined #yocto | 22:33 | |
| *** reaperofsouls <reaperofsouls!~reaperofs@64.2.3.195.ptr.us.xo.net> has quit IRC | 22:34 | |
| *** wgao__ <wgao__!~wgao@1.202.252.122> has quit IRC | 22:34 | |
| *** mario-goulart <mario-goulart!~user@email.parenteses.org> has quit IRC | 22:34 | |
| *** dzoe <dzoe!joe@pdpc/supporter/active/dzoe> has quit IRC | 22:34 | |
| seebs | Which means that changing that might well "fix" this, and I think that's the right fix, but… I also really want to know why we *just sometimes* end up with an LD_LIBRARY_PATH which is apparently missing a component. | 22:34 |
| *** reaperofsouls <reaperofsouls!~reaperofs@64.2.3.195.ptr.us.xo.net> has joined #yocto | 22:35 | |
| sgw_ | seebs: in conf/distro/include/tcmode-external-sourcery.inc, there is a extc_run() which runs that gcc command, I see the PATH is set for the bb.process.run, do we need to set a PSEUDO_something there? | 22:35 |
| *** wgao__ <wgao__!~wgao@1.202.252.122> has joined #yocto | 22:35 | |
| seebs | Well, that's an interesting question. | 22:36 |
| seebs | I don't know what bb.process.run does. | 22:36 |
| seebs | In particular, I don't know what it does with env = {foo} | 22:36 |
| seebs | and whether that might cause it to, say, wipe out other environment variables. | 22:37 |
| seebs | oh. hoh. | 22:38 |
| seebs | So, the options just get passed on to Popen() | 22:38 |
| seebs | and Popen() says that env, if not None, is a mapping that defines the environment for the new process. | 22:39 |
| seebs | Rather than, say, a mapping that overrides the current process's environment. | 22:39 |
| seebs | So Python is going to be trying to run us with an environment that has nothing but $PATH set. And pseudo should, in principle, try to recover that. | 22:39 |
| sgw_ | but does not seem to? | 22:40 |
| seebs | Dunno. | 22:40 |
| *** mario-go` is now known as mario-goulart | 22:40 | |
| seebs | It's at least plausible that it would be failing to recover it sufficiently. | 22:40 |
| seebs | Hmm. It *should* correctly recover it. Unless it's set wrong when we get there. | 22:41 |
| seebs | But if I understood the Popen() docs correctly, it should have been unset, and then pseudo should have recovered it correctly. | 22:42 |
| seebs | Hmm. And it should also try to regenerate LD_PRELOAD. And that looks like it should work. Hmmm. | 22:45 |
| *** dlern <dlern!~dlerner@128.224.250.2> has left #yocto | 22:45 | |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has quit IRC | 22:47 | |
| seebs | Okay, I have a thought for this, perhaps. | 22:50 |
| mr_science | ata1: link online but 1 devices misclassified, retrying <= this is not good... | 22:51 |
| seebs | My thought is basically: I can give you a patch that, if you had it in pseudo, would cause it to emit a useful diagnostic and abort(). | 22:51 |
| seebs | In the case which I think might be what's biting us. And that would at least cause this to generate quick and obvious failures. | 22:51 |
| sgw_ | seebs: see pm for full env of gcc execve call | 22:51 |
| sgw_ | lpapp: you still around | 23:08 |
| *** JimBaxter <JimBaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 23:25 | |
| seebs | I do note in passing: We don't have any known problems with pseudo's behavior on Ubuntu 12.04 and 12.10 64-bit, both of which use lib/lib32 rather than lib64/lib. | 23:35 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 23:41 | |
| *** Jay7 <Jay7!jay@176.15.255.149> has quit IRC | 23:42 | |
| *** Jay7 <Jay7!jay@176.15.255.149> has joined #yocto | 23:43 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 23:48 | |
| *** sameo <sameo!~samuel@192.55.54.41> has quit IRC | 23:55 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!