| *** sameo_ <sameo_!~samuel@192.55.55.39> has quit IRC | 00:07 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 00:13 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 00:14 | |
| *** agust <agust!~agust@p4FC464A8.dip0.t-ipconnect.de> has quit IRC | 00:19 | |
| *** _julian <_julian!~quassel@x2f05fdd.dyn.telefonica.de> has joined #yocto | 00:25 | |
| *** _julian_ <_julian_!~quassel@x2f05d9a.dyn.telefonica.de> has quit IRC | 00:28 | |
| *** forcev <forcev!~quassel@wafaa.eu> has quit IRC | 00:31 | |
| *** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto | 00:31 | |
| *** squix_ <squix_!~squix__@p091.net042127178.tokai.or.jp> has joined #yocto | 00:32 | |
| *** squix_ <squix_!~squix__@p091.net042127178.tokai.or.jp> has quit IRC | 00:33 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 00:41 | |
| *** zz_ka6sox-away is now known as ka6sox | 00:43 | |
| *** scot <scot!~scot@client-74-113.natinst.com> has quit IRC | 00:49 | |
| *** cetola <cetola!4a5ca5c1@gateway/web/freenode/ip.74.92.165.193> has quit IRC | 00:51 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC | 01:03 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 01:04 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 01:06 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 01:06 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 01:18 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 01:19 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has quit IRC | 01:25 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has joined #yocto | 01:26 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 01:40 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 01:42 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 01:54 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 01:56 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 02:00 | |
| *** silviof2 <silviof2!~silviof@ppp-188-174-119-187.dynamic.mnet-online.de> has joined #yocto | 02:11 | |
| -YoctoAutoBuilder- build #175 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at http://autobuilder.yoctoproject.org:8011/builders/nightly-fsl-arm-lsb/builds/175 | 02:13 | |
| *** silviof1 <silviof1!~silviof@ppp-188-174-6-217.dynamic.mnet-online.de> has quit IRC | 02:13 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC | 02:30 | |
| *** nitink <nitink!~nitink@134.134.139.76> has quit IRC | 02:31 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:14 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:18 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 03:23 | |
| *** klinger_ <klinger_!~klinger@f053229034.adsl.alicedsl.de> has joined #yocto | 03:33 | |
| *** klinger <klinger!~klinger@g229153041.adsl.alicedsl.de> has quit IRC | 03:36 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 03:57 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 03:58 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 04:05 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 04:08 | |
| *** cetola <cetola!~cetola@c-50-139-1-70.hsd1.or.comcast.net> has joined #yocto | 04:11 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 04:27 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 04:29 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 04:31 | |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has quit IRC | 04:32 | |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has joined #yocto | 04:32 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 04:38 | |
| *** crazy_imp <crazy_imp!~mj@a89-182-42-76.net-htp.de> has quit IRC | 04:40 | |
| *** crazy_imp <crazy_imp!~mj@a89-182-42-195.net-htp.de> has joined #yocto | 04:42 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 04:51 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 04:51 | |
| *** cetola <cetola!~cetola@c-50-139-1-70.hsd1.or.comcast.net> has quit IRC | 04:52 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 04:52 | |
| *** cetola <cetola!~cetola@c-50-139-1-70.hsd1.or.comcast.net> has joined #yocto | 04:52 | |
| *** cetola <cetola!~cetola@c-50-139-1-70.hsd1.or.comcast.net> has quit IRC | 04:54 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 05:03 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 05:05 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has quit IRC | 05:11 | |
| *** rburton <rburton!~rburton@35.106.2.81.in-addr.arpa> has joined #yocto | 05:11 | |
| *** britzp <britzp!~britzp@smtp.connexionz.co.nz> has quit IRC | 05:16 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 05:27 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 05:29 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 05:35 | |
| *** agust <agust!~agust@p4FDE7637.dip0.t-ipconnect.de> has joined #yocto | 05:41 | |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has quit IRC | 05:45 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has joined #yocto | 05:52 | |
| *** nitink <nitink!nitink@nat/intel/x-sfsqehbirnpdcywd> has joined #yocto | 05:54 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:04 | |
| *** lpapp_ <lpapp_!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has joined #yocto | 06:06 | |
| lpapp_ | hi, are there plans to support Yocto on Windows? | 06:07 |
|---|---|---|
| msm` | probably not | 06:13 |
| lpapp_ | it would be nice to have. | 06:15 |
| msm` | virtualbox? | 06:20 |
| msm` | they have a build appliance | 06:20 |
| *** myopiate <myopiate!~roderick@203-206-170-6.perm.iinet.net.au> has quit IRC | 06:21 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:21 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 06:37 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 06:43 | |
| lpapp_ | msm`: vbox != native build. | 06:44 |
| *** rburton is now known as Guest5976 | 06:45 | |
| lpapp_ | from the short bitbake manual: "Must support build and target operating systems (including cygwin, the BSDs, etc)." | 06:49 |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has joined #yocto | 06:56 | |
| *** ynezz_ is now known as ynezz | 07:07 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has joined #yocto | 07:08 | |
| *** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has joined #yocto | 07:08 | |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has joined #yocto | 07:12 | |
| lpapp_ | is there any plan to maintain the releases? | 07:13 |
| lpapp_ | i.e. to provide bugfix releases, like for instance, backporting build fixes to a "major" release? | 07:13 |
| lpapp_ | it is really hard now to trust any release as a company. | 07:13 |
| lpapp_ | companies cannot update Yocto all the time, and bugfix releases would solve that issue. | 07:13 |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has joined #yocto | 07:14 | |
| *** TuTizz <TuTizz!~TuTizz@46.18.96.158> has left #yocto | 07:14 | |
| fenrig | Hi I'm having trouble generating a sdk with "-c populate_sdk" | 07:14 |
| fenrig | It has to do with x11-common: https://gist.github.com/fenrig/5982513 | 07:14 |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has joined #yocto | 07:18 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has quit IRC | 07:18 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has joined #yocto | 07:19 | |
| fenrig | there isn't much information about it :/ | 07:22 |
| fenrig | so I'm pretty much stuck | 07:22 |
| *** lpapp_ <lpapp_!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has quit IRC | 07:23 | |
| *** florian_kc <florian_kc!~fuchs@port-217-146-132-69.static.qsc.de> has joined #yocto | 07:26 | |
| *** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto | 07:26 | |
| *** sameo_ <sameo_!samuel@nat/intel/x-fuicvuzezuitwyqk> has joined #yocto | 07:37 | |
| *** Jay7x <Jay7x!jay@176.15.24.66> has joined #yocto | 07:37 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has quit IRC | 07:38 | |
| *** Jay7 <Jay7!jay@176.15.24.66> has quit IRC | 07:38 | |
| *** jchonig <jchonig!~jch@firewall.honig.net> has quit IRC | 07:38 | |
| *** jwessel <jwessel!~jwessel@128.224.250.2> has quit IRC | 07:38 | |
| *** icanicant <icanicant!~klawson@195.88.236.129> has quit IRC | 07:38 | |
| *** zeddii_home <zeddii_home!~zeddii_ho@CPE002369bcfa62-CMbcc810032faf.cpe.net.cable.rogers.com> has quit IRC | 07:39 | |
| *** jwessel <jwessel!~jwessel@128.224.250.2> has joined #yocto | 07:39 | |
| *** abelloni <abelloni!~piout@128-79-216-144.hfc.dyn.abo.bbox.fr> has quit IRC | 07:39 | |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 07:39 | |
| fenrig | maybe to do with version mismatch? | 07:40 |
| *** florian_kc is now known as florian | 07:40 | |
| *** abelloni <abelloni!~piout@128-79-216-144.hfc.dyn.abo.bbox.fr> has joined #yocto | 07:40 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has joined #yocto | 07:40 | |
| *** icanicant <icanicant!~klawson@195.88.236.129> has joined #yocto | 07:44 | |
| *** jchonig <jchonig!~jch@firewall.honig.net> has joined #yocto | 07:44 | |
| *** silviof2 is now known as silviof | 07:52 | |
| fenrig | so I have problems building a sdk with "-c populate_sdk". It has to do with x11-common, though the error is not complete enough for me to be understandable (or even to fix it) | 07:54 |
| fenrig | it says it can't statisfy a dependency :/ | 07:54 |
| *** sameo_ <sameo_!samuel@nat/intel/x-fuicvuzezuitwyqk> has quit IRC | 07:55 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 07:57 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 07:58 | |
| *** gmacario1 <gmacario1!~gmacario@maxlab.polito.it> has joined #yocto | 07:59 | |
| *** gmacario <gmacario!~gmacario@maxlab.polito.it> has quit IRC | 08:01 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 08:03 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 08:05 | |
| *** snua12 <snua12!~snua12@gw.koukaam.se> has joined #yocto | 08:05 | |
| *** jbaxter <jbaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 08:07 | |
| *** zeeblex <zeeblex!~apalalax@134.134.139.76> has joined #yocto | 08:08 | |
| fenrig | nobody willing to help me out :/ as I'm really stuck at this last step of generating the sdk :) | 08:11 |
| *** synthnassizer <synthnassizer!~quassel@143.233.242.130> has quit IRC | 08:15 | |
| mihai | fenrig: maybe you missed a layer? check the build configuration header | 08:20 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 08:20 | |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto | 08:21 | |
| erbo | fenrig: is there a x11-common package built? try: find <builddir>/tmp/deploy/ -name 'x11-common*' | 08:21 |
| erbo | fenrig: if not, try "bitbake x11-common" and then try the populate_sdk again | 08:22 |
| fenrig | I think so /ipk/all/x11-common_0.1-r38_all.ipk | 08:23 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 08:23 | |
| *** slaine <slaine!~slaine@84.203.137.218> has joined #yocto | 08:23 | |
| erbo | fenrig: that's an older version that what it looks for | 08:23 |
| fenrig | erbo: x11-common is built :o | 08:23 |
| fenrig | erbo: yes but I tried changing version numbers, that's why the version is older | 08:23 |
| fenrig | erbo: I'll undo the changes, regenerate and check te version number again ;) | 08:24 |
| erbo | fenrig: do that and post the build log and I'll see if I can atleast help you narrow the issue down.. | 08:25 |
| fenrig | erbo: the error log you mean? or ...? | 08:25 |
| erbo | yes | 08:25 |
| fenrig | erbo: okay just a second ;) | 08:26 |
| fenrig | https://docs.google.com/file/d/0B5y2Yque9ykrMFBqS2h3SV93SVU/edit?usp=sharing | 08:29 |
| *** tbn <tbn!~tbn@84.55.160.118> has joined #yocto | 08:32 | |
| *** tbn is now known as Guest15299 | 08:32 | |
| bluelightning | morning all | 08:33 |
| fenrig | bluelightning: morning ;) | 08:33 |
| erbo | morning | 08:33 |
| erbo | fenrig: do you now have a /ipk/all/x11-common_0.1-r47_all.ipk ? | 08:34 |
| fenrig | ./ipk/all/x11-common_0.1-r47_all.ipk | 08:35 |
| fenrig | yes I have :) | 08:35 |
| bluelightning | hi fenrig | 08:35 |
| fenrig | bluelightning: hi | 08:35 |
| fenrig | erbo: I think it's strange it can't statisfy the dependency :/ | 08:36 |
| fenrig | erbo: and it's only an issue when populating the sdk, not when generating the image :) | 08:36 |
| fenrig | erbo: I do however use my own image recepi in my own layer, maybe I have to extend something in it ? | 08:37 |
| *** romain_ <romain_!d96c30f9@gateway/web/freenode/ip.217.108.48.249> has joined #yocto | 08:38 | |
| fenrig | an hour ago I looked at belgian Linux embedded training programs, so I have a more structured approach at linux embedded. I was kind of shocked when I read that for 5 days training i had to pay 3000 euro's | 08:39 |
| Guest5976 | fenrig: training often isn't cheap. i think there'll be a yocto developer day/training thingy at ELC-E in edinburgh this october. | 08:42 |
| fenrig | Guest5976: going to edinburgh from belgium won't be cheap either, i'm still a (3th year) student actually, so I'm almost always low on cash -.- | 08:44 |
| *** RagBal_ is now known as RagBal | 08:45 | |
| fenrig | Guest5976: And because of social regulations here in Belgium I'm not allowed to earn more then 3000 euro as a student, for example I wanted to participate in Google summer of code, I couldn't or I'd have to pay a lot of more taxes | 08:46 |
| *** dv_ <dv_!~quassel@chello080108009040.14.11.vie.surfer.at> has quit IRC | 08:46 | |
| Guest5976 | oh, that's silly | 08:47 |
| Guest5976 | oh hang on , why am i guest! | 08:47 |
| *** Guest5976 is now known as rburton | 08:47 | |
| rburton | better. | 08:47 |
| bluelightning | rburton: using the web client? | 08:48 |
| bluelightning | (morning btw) | 08:48 |
| fenrig | rburton: yes it is, here in belgium payed education (that's what it is) is extra money for the goverment | 08:48 |
| ynezz | fenrig: well, I've been throught whole europe by jyst using "autostop" :) | 08:48 |
| rburton | bluelightning: no, znc. been having small connectivity blips so it probably tried reconnecting before the server kicked the dead connection. | 08:49 |
| fenrig | ynezz: cool :) I can look into that | 08:49 |
| ynezz | fenrig: and those trainings... better buy few boards, load of books and beers for that 3000EUR | 08:50 |
| fenrig | erbo: did you find anything ? | 08:50 |
| fenrig | ynezz: got any GREAT books on the subject? | 08:50 |
| erbo | fenrig: I don't really have any good ideas. From the log is seems like it install x11-common-dbg ok, but can't install x11-common.. It also looks like it uses xserver-common as a replacement for x11-common, maybe that's where something goes wrong | 08:50 |
| *** Jay7x is now known as Jay7 | 08:51 | |
| fenrig | erbo: strange :/ | 08:51 |
| ynezz | fenrig: http://elinux.org/Category:Books | 08:52 |
| erbo | fenrig: xserver-common comes from meta-openembedded/meta-oe/recipes-graphics/xserver-common/ | 08:52 |
| fenrig | erbo: Multiple replacers for x11-common, using first one (xserver-common). | 08:52 |
| erbo | it has conflicts and replaces for x11-common | 08:52 |
| fenrig | erbo: maybe something to do with using angstrom? | 08:53 |
| erbo | could be | 08:53 |
| fenrig | can I force x11-common instead of xserver-common? | 08:54 |
| *** belen <belen!Adium@nat/intel/x-jcbaetbrbdlinaxm> has joined #yocto | 08:55 | |
| ant_work | fenrig: erbo: catch rburton ..he knows about that infamous X settings split | 08:57 |
| fenrig | rburton: Are you willing to help me out with some populate_sdk and x11-common problems? | 08:58 |
| fenrig | erbo: thx for helping me out ;) I appreciate it | 09:01 |
| ant_work | fenrig: this is maybe the last drift btw meta-oe and oe-core. Somehow impacting on -sdk | 09:01 |
| fenrig | ant_work: how do u mean? | 09:02 |
| rburton | uhoh | 09:02 |
| rburton | oh is it time for my jog? /me runs | 09:02 |
| ant_work | xserver-common vs. x11-common has been discussed several times on the ML | 09:02 |
| rburton | fenrig: what's the problem? | 09:02 |
| * rburton will go for his jog later | 09:03 | |
| * ant_work downloading the huge log | 09:03 | |
| fenrig | rburton: I'm trying to generate a sdk with "-c populate_sdk" and it fails because it can't statisfy a dependency namely x11-common :o | 09:03 |
| rburton | fenrig: got a build log uploaded? | 09:03 |
| ant_work | * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-x11-utils-dev: | 09:04 |
| ant_work | * x11-common (= 0.1-r47) * | 09:04 |
| ant_work | * opkg_install_cmd: Cannot install package packagegroup-core-x11-utils-dev. | 09:04 |
| fenrig | rburton: erbo pointed out that x11-common got replaced by xserver-common, so that's probably why it fails :o | 09:04 |
| fenrig | rburton: yes: https://docs.google.com/file/d/0B5y2Yque9ykrMFBqS2h3SV93SVU/edit?usp=sharing | 09:04 |
| ant_work | I see xinput-calibrator so it's obviously from meta-oe | 09:05 |
| fenrig | yeah I opted to upload the file, cause when I pasted it on gist in chrome the browser tab crashed :/ | 09:05 |
| rburton | heh | 09:05 |
| rburton | yocto should run a pastebin, and then we can make bb upload logs to it | 09:05 |
| romain_ | Hi everyone, I have a question with xorg-server too ! | 09:06 |
| romain_ | It seems that the 'xserver-xorg-extension-dri' package isn't present in poky 9.0.0. How the libdri.so can be installed? | 09:06 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 09:06 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 09:07 | |
| rburton | fenrig: hm, yeah, looks like its trying to install xserver-common but x11-common-dbg, which isn't going to work. why is there a x11-common-dbg i wonder. | 09:07 |
| rburton | fenrig: one option would be to blow away your deploy and mask out xserver-common | 09:07 |
| rburton | (meaning, hide xserver-common from bitbake) | 09:08 |
| fenrig | so delete deploy and how do I mask out xserver-common ? | 09:08 |
| ant_work | fenrig: http://sprunge.us for pasting form console | 09:08 |
| rburton | fenrig: one sec, digging a bit | 09:08 |
| fenrig | just rename the xserver-common.bb file to something with backup appended to it? | 09:08 |
| rburton | nah there's a better way | 09:08 |
| fenrig | rburton: take your time ;) | 09:08 |
| ant_work | rburton: iirc I did delete the xserver-nodm-init of meta-oe | 09:09 |
| ant_work | when doing such tests | 09:10 |
| rburton | i'm confused as to why there's a x11-common-dbg | 09:10 |
| fenrig | rburton: you need any additional files? | 09:10 |
| rburton | fenrig: no | 09:11 |
| fenrig | oh yeah I'm using my own image recipe edna-image-minimal, and i'm building with the angstrom distro, and I'm building for the BBB | 09:11 |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC | 09:11 | |
| *** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto | 09:12 | |
| fenrig | the angstrom distro also is one version behind yocto, I think they still use dylan | 09:13 |
| rburton | yeah, something like that | 09:13 |
| rburton | really need to sort the x init stuff out | 09:13 |
| fenrig | supposse I upgrade to the most recent (stable?) yocto layers, would that fix the issue (if it doesn't cause other issues) | 09:15 |
| *** eren <eren!~eren@unaffiliated/eren> has joined #yocto | 09:15 | |
| rburton | fenrig: try bitbake -cclean xserver-common (that will remove it from your deploy/ too); then add BBMASK="meta-oe/recipes-graphics/xserver-common" | 09:16 |
| rburton | and rebuild your image and sdk | 09:16 |
| rburton | hopefully nothing explicitly depends on xserver-common | 09:16 |
| rburton | the alternative is to find out why x11-common-dbg exists at all, considering its empty. | 09:17 |
| rburton | as that's not getting switched to xserver-common-dbg, which is where the problem is | 09:17 |
| erbo | rburton: do the xserver-common generate -dev and -dbg packages as well? If so, don't they have to be in RCONFLICTS / RREPLACES in xserver-common as well? | 09:18 |
| rburton | dunno, i don't have a working meta-oe build right now | 09:20 |
| fenrig | rburton: okay I'll try that ;) | 09:20 |
| fenrig | If you guys want I can supply my build dir, but it's quite large :/ so it can take a while to upload | 09:21 |
| rburton | no its fine, quite large is probably quite an understatement :) | 09:22 |
| rburton | and i can see how this can happen | 09:22 |
| rburton | bluelightning: under what situations will a package with no files exist, apart from using ALLOW_EMPTY? | 09:22 |
| rburton | bluelightning: x11-common just puts files into $PN, but -dev and -dbg are built (but empty). are those two always built? | 09:22 |
| ant_work | rburton: I have built Angstrom 2012.12 overnight. Note it's still branched on danny | 09:23 |
| rburton | danny? old school. | 09:23 |
| bluelightning | rburton: those two are marked ALLOW_EMPTY I believe | 09:23 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has joined #yocto | 09:23 | |
| rburton | ah, yes | 09:23 |
| rburton | in bitbake.conf | 09:23 |
| rburton | gotcha. | 09:24 |
| rburton | so, maybe we should set x11-common and xserver-common to have PACKAGES="$PN" | 09:24 |
| rburton | we *could* add more replaces/conflicts as erbo said, but removing the problem entirely would be another solution. | 09:24 |
| ant_work | we have to remove one xserver-nodm-init | 09:25 |
| ant_work | that's the Holy Grail | 09:25 |
| rburton | that too. | 09:25 |
| JaMa | florian: can you apply those patches to xserver-common before they remove it completely? :) | 09:26 |
| ant_work | pfhh | 09:26 |
| rburton | never noticed xserver-common was so heavily patched | 09:27 |
| ant_work | rburton: ofc coordinate with JaMa ;) | 09:27 |
| JaMa | rburton: it's in florian's queue since 12 Apr 2012 | 09:28 |
| JaMa | so the Upstream-Status should be "submitted" | 09:28 |
| fenrig | rburton: about the bbmask, do I add this one to my image recipe or ...? | 09:29 |
| rburton | fenrig: i've a better idea now. just add PACKAGES="${PN}" to both x11-common.bb and xserver-common.bb. | 09:30 |
| fenrig | rburton: okay, great :D7 | 09:30 |
| rburton | i suspect other bits of angstrom will want xserver-common, so masking it out may break something else | 09:30 |
| rburton | fenrig: that's untested but might work nicely | 09:30 |
| ant_work | afaik it's just xserver-nodm-init | 09:30 |
| rburton | JaMa: surely all the per-machine tweaking in xserver-common should be in the BSPs | 09:33 |
| ant_work | yes | 09:33 |
| fenrig | https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/conf/machine/beaglebone.conf | 09:34 |
| fenrig | this is the bsp I'm using so | 09:34 |
| fenrig | you could check that out ;) | 09:34 |
| fenrig | rburton: I just started the populate_sdk process, let's hope for success :D | 09:38 |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 09:38 | |
| rburton | fenrig: thanks for testing :) | 09:38 |
| fenrig | rburton: with pleasure, but you don't have to thank me. I should thank you guys ;) | 09:39 |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto | 09:39 | |
| JaMa | rburton: whole point of upstream xserver-common is to support as many machines as possible | 09:40 |
| ant_work | but this doesn't play well with the layer arch : supposedly the BSP customizes the xorg.conf and provides formfactor | 09:42 |
| JaMa | BSPs can upstream their customizations too | 09:46 |
| fenrig | rburton: I think it fixed the problem | 09:46 |
| *** swex_ <swex_!~swex@217.197.243.108> has joined #yocto | 09:46 | |
| *** swex <swex!~swex@178.17.194.141> has quit IRC | 09:49 | |
| ant_work | JaMa: as it is now, there are around many (deprecated ?) variables defining the same thing. MACHINE_GUI_, MACHINE_DISPLAY_ now even GUI_MACHINE_CLASS | 09:55 |
| ant_work | formfactor uses the DISPLAY_ set of vars for xserver | 09:56 |
| *** sameo <sameo!samuel@nat/intel/x-hhjvsdagjwtuvdlp> has joined #yocto | 09:56 | |
| *** sameo <sameo!samuel@nat/intel/x-hhjvsdagjwtuvdlp> has quit IRC | 09:57 | |
| *** sameo <sameo!samuel@nat/intel/x-xrtthcwcenfiosqx> has joined #yocto | 09:57 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 09:57 | |
| * ant_work notes this is a bit OT for #yocto, issues are mostly in meta-oe | 09:58 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has joined #yocto | 09:58 | |
| mshakeel | Hi JaMa, rburton, Can you please comment on Saul's reply here: http://patches.openembedded.org/patch/53489/ | 10:00 |
| mshakeel | are you guys working on anything related to this? Or should I try to handle this? | 10:00 |
| JaMa | mshakeel: check this thread http://lists.openembedded.org/pipermail/openembedded-devel/2013-July/091262.html | 10:02 |
| JaMa | mshakeel: I agree that systemd.bbclass should be improved (like meta-systemd version was), but I'm not working on it | 10:02 |
| rburton | i wasn't convinced at first, but the repetition is clearly showing it needs to happen centrally. | 10:04 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 10:05 | |
| rburton | i can't recall exactly what the meta-systemd systemd.bbclass did but its clearly a good starting point | 10:05 |
| rburton | mshakeel: would be much appreciated if you could handle it. maybe just a install_append that deletes files as appropriate, so recipes install everything and the classes removes what it doesn't need. | 10:06 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 10:06 | |
| rburton | (iirc, the meta-systemd class was more complicated than that, and would auto-install service files in SRC_URI, but i'm not convinced that's a good idea) | 10:07 |
| rburton | anyway after getting distracted by work for two hours, it's now time for my "pre-work" jog of doom. i may not return alive. | 10:07 |
| mshakeel | rburton: ok, I will spend some time on it. Just wanted to make sure that you are not on it. thanks. | 10:08 |
| JaMa | mshakeel: rburton: unlike meta-systemd class we can add variable which says which .service files should be autoinstalled | 10:08 |
| rburton | JaMa: as more upstreams integrate a service file, and they generally should be ran through sed to fix paths, i'm not sure that's worth it. | 10:09 |
| JaMa | that will resolve valid concerns about automagic issues we had with *-config | 10:09 |
| * rburton really off now | 10:09 | |
| rburton | back in 30, apparently. | 10:09 |
| fenrig | rburton: have fun jogging, and thx for helping ;) | 10:10 |
| *** ant__ <ant__!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has joined #yocto | 10:11 | |
| *** sameo_ <sameo_!~samuel@192.55.55.37> has joined #yocto | 10:13 | |
| *** swex__ <swex__!~swex@217.197.243.108> has joined #yocto | 10:14 | |
| *** jzhang1 <jzhang1!jzhang@nat/intel/x-vezbaqanyfyvskgs> has joined #yocto | 10:14 | |
| *** strassek <strassek!~strassek@flip3.engr.oregonstate.edu> has joined #yocto | 10:16 | |
| *** gmacario1 <gmacario1!~gmacario@maxlab.polito.it> has quit IRC | 10:17 | |
| *** rogerzhou_ <rogerzhou_!~rogerzhou@1.202.252.122> has joined #yocto | 10:17 | |
| *** jzhang <jzhang!~jzhang@134.134.139.70> has quit IRC | 10:18 | |
| *** agust <agust!~agust@p4FDE7637.dip0.t-ipconnect.de> has quit IRC | 10:18 | |
| *** sameo <sameo!samuel@nat/intel/x-xrtthcwcenfiosqx> has quit IRC | 10:18 | |
| *** swex_ <swex_!~swex@217.197.243.108> has quit IRC | 10:18 | |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 10:18 | |
| *** rogerzhou <rogerzhou!~rogerzhou@1.202.252.122> has quit IRC | 10:18 | |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has quit IRC | 10:18 | |
| *** strassek_ <strassek_!~strassek@flip3.engr.oregonstate.edu> has quit IRC | 10:18 | |
| *** agust <agust!~agust@p4FDE7637.dip0.t-ipconnect.de> has joined #yocto | 10:19 | |
| *** sakoman <sakoman!~steve@static-74-41-60-154.dsl1.pco.ca.frontiernet.net> has joined #yocto | 10:19 | |
| *** rogerzhou_ <rogerzhou_!~rogerzhou@1.202.252.122> has quit IRC | 10:51 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 10:51 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 10:55 | |
| *** swex__ <swex__!~swex@217.197.243.108> has quit IRC | 10:59 | |
| *** swex <swex!~swex@178.17.197.246> has joined #yocto | 10:59 | |
| *** belen <belen!Adium@nat/intel/x-jcbaetbrbdlinaxm> has quit IRC | 11:02 | |
| *** ant__ is now known as ant_work | 11:03 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 11:03 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 11:05 | |
| *** belen <belen!~Adium@134.134.139.72> has joined #yocto | 11:10 | |
| romain_ | It seems that the 'xserver-xorg-extension-dri' package isn't present in poky 9.0.0. How the libdri.so can be installed? | 11:10 |
| rburton | romain_: its built into the server | 11:15 |
| rburton | "noinst_LTLIBRARIES = libdri.la" | 11:15 |
| rburton | also, see the log for xserver-xorg.inc | 11:15 |
| rburton | " The following external modules are now built-in: | 11:16 |
| rburton | * DBE | 11:16 |
| rburton | * DRI2 | 11:16 |
| rburton | * DRI | 11:16 |
| rburton | * RECORD" | 11:16 |
| thaytan | rburton: all of sunray, to answer your question :) | 11:24 |
| thaytan | so I guess they won't be using Yocto after all :) | 11:25 |
| rburton | thaytan: i suspected as much. ah well, the tech was neat. | 11:25 |
| *** behanw <behanw!~behanw@216-58-123-51.cpe.distributel.net> has joined #yocto | 11:49 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has joined #yocto | 11:52 | |
| romain_ | Ok thanks, it clears my doubts | 11:53 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 11:54 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 11:59 | |
| lpapp | is there any plan for a cmake class? | 11:59 |
| *** jonatan__ <jonatan__!~quassel@c-2ec2e5db-74736162.cust.telenor.se> has joined #yocto | 11:59 | |
| *** jonatan_ <jonatan_!~quassel@194-237-7-146.customer.telia.com> has quit IRC | 11:59 | |
| rburton | lpapp: there is a cmake class | 12:02 |
| lpapp | ok, so it is a documentation problem only. | 12:03 |
| *** jonatan_ <jonatan_!~quassel@194-237-7-146.customer.telia.com> has joined #yocto | 12:03 | |
| *** jonatan__ <jonatan__!~quassel@c-2ec2e5db-74736162.cust.telenor.se> has quit IRC | 12:04 | |
| lpapp | there is also a qmake class, already? | 12:05 |
| rburton | lpapp: have a look in meta/classes, that's easier than asking here | 12:06 |
| lpapp | I do not have a clone right now. | 12:06 |
| lpapp | also, it is not entirely clear to me which meta-foo to check in general | 12:07 |
| rburton | http://git.openembedded.org/openembedded-core/tree/meta/classes | 12:07 |
| rburton | start with oe-core | 12:07 |
| rburton | that's where the common ones all end up | 12:07 |
| lpapp | ok, there is no qbs class yet. :) | 12:08 |
| rburton | is there actually anything releases that uses that yet? | 12:10 |
| *** sameo_ <sameo_!~samuel@192.55.55.37> has quit IRC | 12:10 | |
| lpapp | yes, of course. | 12:10 |
| fenrig | so I tried generating a sdk, with a lot of help op rburton it worked. But my SDK has to be able to compile Qt programs | 12:19 |
| fenrig | and I noticed I don't have a (native) qmake | 12:19 |
| fenrig | are there some special steps I have to follow? | 12:20 |
| rburton | i thought qt-dev would recommend that, somehow | 12:20 |
| fenrig | rburton: what do you mean? | 12:21 |
| rburton | i though it would get pulled in for you | 12:22 |
| rburton | not sure how to get extra bits into a sdk to be honest. bluelightning? | 12:22 |
| * rburton delegates because fenrig said "qt" | 12:22 | |
| fenrig | I do have to point out that I used the meta-qt5 layer :) | 12:23 |
| *** scot <scot!~scot@client-74-113.natinst.com> has joined #yocto | 12:26 | |
| fenrig | bluelightning: if you have time could you help me out with qt5 sdk generation? :) | 12:31 |
| rburton | (he might be eating lunch) | 12:32 |
| belen | (he is) | 12:33 |
| fenrig | rburton: yes I though so because he says "goodmorning" a hour or 2 later then when I start working, but I tried asking it politely | 12:33 |
| fenrig | so that when he returns he'll answer me ^^ | 12:33 |
| fenrig | too bad there isn't much information about qt5 and yocto on the internet | 12:35 |
| rburton | fenrig: for reference, me/bluelighting are in the UK, so it's lunchtime. which explains why i'm hungry. | 12:36 |
| fenrig | oh yeah I have a another question too, I promised myself that I would start working on an opensource project this summer, too contribute to the large ecosystem of gnu and linux that has helped me where I am now. Do you recommend the yocto project (bitbake & openembedded) | 12:36 |
| rburton | belen: (is friday a themed lunch in the office?) | 12:36 |
| rburton | fenrig: yes, of course we do :) | 12:37 |
| fenrig | and is there a way for a noob, like me, to start contributing in little stupid patches so that I could learn how the source works | 12:37 |
| fenrig | I have a fair bit of python experience :) | 12:37 |
| rburton | there's an open bug tracker | 12:38 |
| rburton | if you're brave, there's an in-progress python3 port. | 12:38 |
| belen | rburton: (no. Should it be?) | 12:38 |
| fenrig | and I'm the cream of the crop programmer of our school (isn't really a good reference) | 12:38 |
| rburton | if you actually want to work on bitbake then i'm certainly not the person to talk to. try kergoth/bluelighting. | 12:38 |
| fenrig | but I'm a bit worried of the lean entry level :/ | 12:38 |
| fenrig | or is it steep in english? | 12:39 |
| rburton | belen: well, burrito tuesday. fish and chips friday sounds like a good idea :) | 12:39 |
| rburton | fenrig: steep | 12:39 |
| belen | rburton: ah, if that's what you mean, it might be Falafel Friday | 12:39 |
| rburton | oh, now there's a reason to visit on a friday. | 12:40 |
| belen | rburton: you need a strong one to visit on fridays | 12:41 |
| fenrig | you know what I'll create a bugzilla account, and when I finish this job I'm in ;-) | 12:43 |
| lpapp | rburton: perhaps I can help with a qbs class file if it is not that hard to learn it... | 12:45 |
| rburton | lpapp: writing a build system class is fairly simple as it's just the bits from the recipe, in a separate file | 12:48 |
| *** tor <tor!~tor@c-ef66e655.125-1-64736c10.cust.bredbandsbolaget.se> has quit IRC | 12:49 | |
| *** jmpdelos <jmpdelos!~polk@174-24-109-134.clsp.qwest.net> has quit IRC | 12:57 | |
| ant_work | rburton: [PATCH v3 0/1] xinput-calibrator: move it from meta-oe to oe-cor | 13:04 |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-yzedatloardeilrd> has joined #yocto | 13:06 | |
| bluelightning | fenrig: I'm back, but to be honest I'm probably not the best person to ask about qt5 | 13:06 |
| fenrig | bluelightning: and about qt in general? | 13:07 |
| bluelightning | fenrig: I can certainly try to help... | 13:07 |
| fenrig | bluelightning: that would be great :) | 13:07 |
| fenrig | bluelightning: so uhm I'm trying to incorperate qt5 into my sdk :) | 13:09 |
| *** jmpdelos <jmpdelos!~polk@174-24-109-134.clsp.qwest.net> has joined #yocto | 13:09 | |
| fenrig | bluelightning: but as I understand I need qmake to support my version | 13:09 |
| fenrig | bluelightning: so this qmake needs to be able to cross compile or ...? | 13:09 |
| fenrig | I know qmake generates make and moc files for project, so it can support introspection :) | 13:10 |
| bluelightning | fenrig: the qmake we use for qt4 is built separately as part of qt4-native (which is a dependency when building qt4-x11-free / qt4-embedded) | 13:10 |
| bluelightning | I don't know what meta-qt5 does | 13:11 |
| bluelightning | fenrig: so did you manage to produce an SDK with bitbake -c populate_sysroot imagename ? | 13:11 |
| fenrig | but qt4 is already an old version I presume? | 13:11 |
| fenrig | bluelightning: yes rburton made that possibe ;) | 13:11 |
| eren | ok, I have ax25, kiss modules present in the kernel | 13:12 |
| fenrig | bluelightning: in fact I already executed the installer :) | 13:12 |
| bluelightning | fenrig: but it does not contain qmake and that's what you were asking about? | 13:12 |
| eren | the package name is 'kernel-module-{ax25,mkiss}' | 13:12 |
| fenrig | bluelightning: yes indeed :) | 13:12 |
| eren | should I add the package name as is, or is there another way to include a kernel module in the image? | 13:12 |
| bluelightning | fenrig: ok, I might be able to answer that, one sec | 13:12 |
| eren | bluelightning: you mentioned something like RDEPENDS? | 13:12 |
| fenrig | bluelightning: take your time ;) | 13:12 |
| bluelightning | eren: we always use RRECOMMENDS for kernel modules | 13:12 |
| eren | ah | 13:13 |
| eren | bluelightning: in which bb file? | 13:13 |
| bluelightning | eren: in case the user wants to build them into the kernel rather than being built as modules | 13:13 |
| eren | RRECOMMENDS = 'kernel-module-ax25 kernel-module-mkiss', then? | 13:13 |
| *** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has joined #yocto | 13:13 | |
| bluelightning | eren: RRECOMMENDS_${PN} += "..." | 13:13 |
| bluelightning | eren: RRECOMMENDS like all runtime package variables need to be qualified with the name of the package to add the relationship to | 13:13 |
| bluelightning | in this case the main package (${PN}) | 13:14 |
| eren | okkie | 13:14 |
| eren | then I will add it in libax25 package | 13:14 |
| *** melonipoika <melonipoika!~quassel@ip050-115.seclan.com> has quit IRC | 13:15 | |
| *** sameo <sameo!samuel@nat/intel/x-gbhhcwtjtzetlotv> has joined #yocto | 13:16 | |
| bluelightning | fenrig: so unfortunately it looks like nobody has added nativesdk support to meta-qt5 yet | 13:17 |
| fenrig | bluelightning: so I should revert back to qt4? | 13:17 |
| fenrig | bluelightning: or try to add nativesdk support? | 13:17 |
| bluelightning | fenrig: it depends how much work you want to do :) | 13:18 |
| bluelightning | it's possible someone else is planning on adding nativesdk to meta-qt5, I don't know what everyone's plans are | 13:18 |
| bluelightning | JaMa: any ideas? | 13:18 |
| fenrig | bluelightning: Well unfornately it's not mine to decide, so I have to ask my boss | 13:18 |
| fenrig | bluelightning: how long do you think it could take me? | 13:19 |
| fenrig | bluelightning: a day? a week? | 13:19 |
| ant_work | couple of nights ;) | 13:19 |
| *** AlexG <AlexG!c0c6972b@gateway/web/freenode/ip.192.198.151.43> has quit IRC | 13:20 | |
| bluelightning | fenrig: I would think at least a week to get it working fully unless you already have experience with qt / OE | 13:20 |
| fenrig | ant_work: okay :D thx for the help | 13:20 |
| ant_work | check qt3 layer and qt4 in oe-core | 13:20 |
| ant_work | you'll see the missing recipe | 13:20 |
| fenrig | bluelightning: I have experience with Qt but not as much as with cross compilation, and if I had to decide I'd probably try it, but my time here is limited so I don't get to decide :) | 13:21 |
| *** thaytan <thaytan!~thaytan@113.94.233.220.static.exetel.com.au> has quit IRC | 13:24 | |
| *** munch <munch!~mark@c-67-184-166-69.hsd1.il.comcast.net> has joined #yocto | 13:26 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has quit IRC | 13:26 | |
| *** thaytan <thaytan!~thaytan@113.94.233.220.static.exetel.com.au> has joined #yocto | 13:28 | |
| fenrig | and we've opted to go to qt4 | 13:30 |
| fenrig | bluelightning: thx for your help ;) | 13:31 |
| bluelightning | fenrig: np | 13:31 |
| fenrig | does anybody know by chance which packages I have to provide to image_install? | 13:31 |
| JaMa | fenrig: few people asked about sdk support but nobody sent patches yet | 13:31 |
| fenrig | JaMa: I think Qt is pretty popular framework | 13:32 |
| JaMa | fenrig: qt5 is sometimes quite tricky, so a week for SDK is a minimum | 13:32 |
| fenrig | I wonder how they do it with ubuntu-touch | 13:32 |
| fenrig | and tizen | 13:32 |
| JaMa | fenrig: yes it is, that's why I maintain meta-qt5 :) | 13:33 |
| fenrig | they probably have their own buid system | 13:33 |
| eren | JaMa: nice commits on llvm, btw. | 13:33 |
| *** tinti_ <tinti_!~tinti@maxtrack-F4-0-3-gacc04.bhe.embratel.net.br> has joined #yocto | 13:33 | |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto | 13:33 | |
| JaMa | but we're not using SDK internally so I cannot spend much time on it (and I would rather invest time in 5.1 recipes) | 13:33 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 13:33 | |
| JaMa | eren: except the last one with zlib.. that sliped into master branch accidentally :/ | 13:34 |
| fenrig | JaMa: I learned to work with Qt a few months ago, and I immediatly felt why people loved it so :) | 13:34 |
| eren | JaMa: ah, it can happen all the time :) | 13:34 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 13:36 | |
| bluelightning | fenrig: the only thing you need to do I think is TOOLCHAIN_HOST_TASK_append = " nativesdk-qt4-tools" and TOOLCHAIN_TARGET_TASK_append = " qt4-mkspecs" | 13:37 |
| fenrig | oh yeah to uninstall the installed sdk should I just remove the dir /usr/lib/oecore-i686 | 13:37 |
| bluelightning | fenrig: then if you do bitbake -c populate_sdk imagename for your image you'll get a complete Qt4 SDK | 13:37 |
| bluelightning | fenrig: yep you can just delete it, no special uninstall needed | 13:37 |
| fenrig | bluelightning: yeah but my image does has to support Qt4 | 13:38 |
| bluelightning | fenrig: right, for that you should just add your application to the image | 13:38 |
| fenrig | bluelightning: I'm so sorry for my english :o | 13:38 |
| bluelightning | fenrig: required Qt libraries will be pulled in automatically via dependencies | 13:38 |
| eren | btw, which package puts bzImage to $DEPLOY_DIR? | 13:38 |
| bluelightning | eren: the kernel | 13:39 |
| fenrig | bluelightning: ah yes, but for now I'd like to not make a recipe for it as I'm just playing with the system so to speak | 13:39 |
| bluelightning | eren: i.e. linux-yocto in the default configuration, might be different depending on the BSP | 13:39 |
| eren | bluelightning: okkie, thanks | 13:39 |
| bluelightning | eren: most of the magic is in kernel*.bbclass though | 13:40 |
| bluelightning | fenrig: ok, if you just want to try you could build any image and add "qt4-pkgs" to IMAGE_FEATURES | 13:41 |
| fenrig | bluelightning: okay cool ;) | 13:41 |
| fenrig | oh yeah I don't know if I have to ask it here but, I'd like to run myt | 13:42 |
| fenrig | Qt application dedicated in the Xorg | 13:42 |
| fenrig | got any pointers on that | 13:42 |
| fenrig | or do you guys have no experience with that (I know I'm asking a lot) | 13:42 |
| fenrig | you know what, I'll try to find that out myself, sorry for asking | 13:42 |
| bluelightning | well, if you're building qt4-x11-free (which qt4-pkgs will pull in) then that will be Qt for X11 | 13:42 |
| bluelightning | for your application recipe just ensure you add "inherit qt4x11" and it'll get the appropriate dependencies | 13:43 |
| fenrig | bluelightning: yes that I already understand, but I'll have to figure out how to run that application like a DE :) | 13:43 |
| bluelightning | fenrig: this might be useful: https://wiki.yoctoproject.org/wiki/Creating_a_recipe_for_a_Qt_application | 13:43 |
| bluelightning | fenrig: I think if you have x11-base in IMAGE_FEATURES you'll get mini-x-session installed which should start up a very basic X11 session | 13:44 |
| bluelightning | nothing like a full desktop environment but OK for single apps | 13:44 |
| fenrig | bluelightning: great :) | 13:46 |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 14:02 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 14:04 | |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has joined #yocto | 14:05 | |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 14:06 | |
| *** jackmitchell <jackmitchell!~Thunderbi@host217-34-104-101.in-addr.btopenworld.com> has quit IRC | 14:07 | |
| rtollert | I cannot precisely wrap my brain around the importance of gcc-*-initial. Is it there primarily to bootstrap the core libc-initial build? If so, where do we bootstrap native gcc, to ensure that the final gcc cross-compilers are built with the correct native compiler version? | 14:08 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto | 14:10 | |
| rtollert | (i.e., to ensure that gcc-cross 4.8 is built with gcc 4.8 native, regardless of system compiler version?) | 14:12 |
| *** tsjsieb is now known as tjsieb_away | 14:13 | |
| rtollert | (yes, it seems pretty obvious that both gcc-cross-initial and gcc-crosssdk-initial are both cross compilers, but I can't find any evidence of a gcc-native getting built as a dependency of meta-toolchain, and that seems unnecessarily stupid, so maybe I'm missing something) | 14:15 |
| fray | rtollert: there are actually three cross compilers.. "host" -> target (gcc-cross) | 14:17 |
| fray | gcc-crosssdk "host" to "nativesdk" | 14:17 |
| fray | gcc-cross-canadian "nativesdk" -> target | 14:17 |
| rtollert | fray: right, I got that far | 14:17 |
| JaMa | rtollert: there aren't gcc-native recipes, your host needs to provide sane gcc | 14:17 |
| fray | yup, thats what i was just abut to get to.. | 14:17 |
| fray | the host is expected to work "properly", well enought to be able to build functional software to run on that same host.. | 14:18 |
| bluelightning | WIP section in the manual covering this stuff, btw: http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#cross-development-toolchain-generation | 14:18 |
| bluelightning | (feedback to Scott if there are any changes needed) | 14:18 |
| rtollert | fray JaMa: But that's explicitly described as a bad idea in the gcc docs. And it's broken miserably before — IIRC, gcc 4.6 added a -fbuilding-gcc option, or something like that, and it's physically impossible to build a gcc 4.6 cross from gcc 4.4 because of it | 14:19 |
| fray | ew have impericle evidence that we can correctly rebuild the cross compilers... until someone shows up bugs otherwise, we believe its working.. | 14:20 |
| fray | empirical even | 14:21 |
| fray | basically use us a combination of 'buildhistory' (built into the build system) to compare build output.. and I've personally compared the binaries being generated by the compilers from different hosts.. | 14:21 |
| fray | other then path name and some embedded timestamps, the generated objects are the same | 14:21 |
| *** b46258 <b46258!~b46258@gate-tx3.freescale.com> has joined #yocto | 14:21 | |
| fray | (last time I ran that test was the 4.7 toolchain BTW) 4.8 is still too new | 14:21 |
| *** eballetbo <eballetbo!~eballetbo@43.Red-2-139-180.staticIP.rima-tde.net> has quit IRC | 14:23 | |
| fray | (you can do the comparison using hexdump on the text section of the ELF executables.. diff them and you'll see the differences are "reasonable") | 14:23 |
| bluelightning | we had some pain building 4.7 with 4.8, that got fixed... but 4.8 has had quite a number of problems anyway | 14:24 |
| rtollert | yeah I was about to mention the 4.7/4.8 pain; I run Arch, so that bit me | 14:24 |
| rtollert | ... but, that would have bit me anyway if we built a gcc-native of 4.7 | 14:25 |
| fray | we're regularly building on hosts as old as CentOS/RHEL 5.9.. and as new as Fedora 19... | 14:25 |
| rtollert | right. and actually, I thought I saw official gcc docs to the effect of "make sure to match native and cross versions", but I can only find that on the osdev wiki right now. The official gcc docs merely say "use 2.95.3 or newer". So I might have been in error there. | 14:26 |
| fray | ya, it was a definite problem in the past, but it's gotten so much better in the last few years.. | 14:27 |
| JaMa | I thing there are still issues when someone with external-tc with older gcc tries to build newer gcc-runtime (or gcc) from oe-core | 14:28 |
| rtollert | yeah, I remember the bad old days. (occasionally I still live them.) the gcc devs are doing a bangup job | 14:29 |
| rtollert | JaMa: that reminds me, does anybody use external-tc for crosstool-ng sourced toolchains? Or is external-tc still mostly csl's thing? | 14:30 |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 14:31 | |
| rtollert | bluelightning: also do you recall the issues encountered so far with 4.8? Or can link me to the mailing lists/channels I need to follow to catch them? :) | 14:32 |
| fray | the normal mechanism is the csl stuff.. | 14:32 |
| rtollert | thanks for the answers so far btw | 14:32 |
| fray | but you could use it to introduce the crosstool, but it has to be modified | 14:32 |
| JaMa | rtollert: we're using external-tf for crosstool-ng created tc | 14:33 |
| fray | (I'm not a fan of the existing csl tool integration, but frankly their are the one ones who did it and keep it working.. so until someone does their own.. thats the way it's going to be) | 14:33 |
| *** mihai <mihai!~mihai@80.97.15.150> has joined #yocto | 14:33 | |
| JaMa | rtollert: you can also use external-linaro-toolchain for linaro binary toolchains which are created with ctng | 14:34 |
| bluelightning | rtollert: we had the one I mentioned above, and we have had compile and boot-time issues on arm and ppc (the arm issue I think has required a kernel patch) | 14:34 |
| fray | ya, the arm issue was a kernel issue in the end.. | 14:34 |
| fray | I'm not familar with the PPC one.. is that the e500? or is there more then that? | 14:34 |
| fray | (older mips kernels required a patch as well to compile.. but once they do they appear to work) | 14:34 |
| rtollert | JaMa: s/external-tf/external-tc/? | 14:35 |
| *** agust <agust!~agust@p4FDE7637.dip0.t-ipconnect.de> has quit IRC | 14:35 | |
| bluelightning | fray: I think so, I've not been closely involved with it but we had build failures with meta-fsl-ppc | 14:35 |
| bluelightning | on the autobuilder, that is | 14:36 |
| fray | I think that's the e500... | 14:36 |
| rtollert | fray bluelightning: interesting. So y'all have somewhat less confidence of 4.8's stability wrt 4.7 | 14:36 |
| bluelightning | rtollert: well, it's been a little bit rocky so far for sure... hopefully the issues have been ironed out | 14:36 |
| * fray has been using 4.8 now for over a month.. and we're getting consistent results, and the number of ICE and related are dropping | 14:37 | |
| fray | performance for some targets is significantly better though.. (at least in my opinion, I don't have any numbers to back that up) | 14:37 |
| rtollert | fray: building gcc svn? | 14:37 |
| fray | the one in oe-core master | 14:37 |
| rtollert | k | 14:37 |
| fray | we're just starting to use the pre-release eglibc 2.18 as well.. | 14:38 |
| JaMa | rtollert: y | 14:39 |
| *** challinan_ <challinan_!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC | 14:39 | |
| fenrig | hhmm got a new problem | 14:42 |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 14:42 | |
| fenrig | apparently the gpu drivers of the BBB get compiled | 14:42 |
| fenrig | and it fails :/ due to compilation errors | 14:43 |
| rburton | fenrig: pastebin the error | 14:43 |
| fenrig | I found some pastebins of people trying it with yocto, but no solutions as of now. Does somebody have some information about it? | 14:43 |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 14:43 | |
| fenrig | rburton: will do, wait a sec ;) | 14:43 |
| fenrig | https://gist.github.com/fenrig/5984988 | 14:44 |
| *** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has joined #yocto | 14:44 | |
| rburton | fenrig: you'll be better trying #beagle or whatever the meta-ti/beagle support channel is | 14:45 |
| fenrig | rburton: yeah probably, but my working day is almost over so | 14:47 |
| *** hollisb <hollisb!~hollisb@c-67-169-221-181.hsd1.or.comcast.net> has joined #yocto | 14:47 | |
| fenrig | rburton: I'll probably start heading home and fix this problem another time, thx anyway. I think it has to do with the drivers itself and not yocto :) | 14:48 |
| rtollert | couple more (unrelated) questions. 1) poky's relationship with oe-core seems to be that of a downstream branch, so that patches get merged to/from; poky doesn't sync oe-core as a dependency. Is oe-core imported unmodified into poky? | 14:48 |
| rtollert | 2) I wrote up some instructions on how to use debootstrap+schroot to build poky on an unsupported distribution; does that sound like something that would be useful to add to the wiki? | 14:49 |
| rburton | rtollert: commits from bitbake, oe-core, meta-yocto, meta-yocto-bsp and yocto-docs are all applied to poky (with a few minor tweaks). | 14:49 |
| rburton | rtollert: 2) yes. there was discussion about that sort of thing here a few days ago. | 14:49 |
| rburton | rtollert: re (1), the tool used to make poky is combo-layer. in oe-core's scripts repo. | 14:49 |
| rtollert | rburton: 2) OK, I'll add my docs to the wiki | 14:49 |
| rtollert | rburton: is there any policy defined for applying tweaks to oe-core meta/ itself, as opposed to making them in meta-yocto? (and if so what?) | 14:51 |
| rburton | rtollert: the tweaks to oe-core are trivial, iirc there's just one (to change the a message from saying oe-core to poky) | 14:52 |
| rtollert | rburton: excellent, thanks | 14:52 |
| rburton | rtollert: that's why meta-yocto has some bbappends | 14:52 |
| *** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.85.234.195.229> has quit IRC | 14:54 | |
| rtollert | rburton: right.. when I couldn't find an obvious oe-core sync point, I started to worry that maybe the reason for that was that perhaps some changes to oe-core are more maintainable as changes made in a downstream branch, as opposed to confined to new layers. Sounds like that fear was unfounded. | 14:55 |
| rburton | rtollert: yeah, poky is a merged repo from its parents, as you'll see from the log its got bitbake/oe-core/etc commits interleaved | 14:56 |
| rtollert | heh... I'm registering for a new acct on wiki.yoctoproject.org, and the Terms of Service link is a 404. Who ought to know about that? | 14:57 |
| rburton | heh | 14:57 |
| rburton | halstead i guess | 14:57 |
| rtollert | halstead: consider yourself knowing about that | 14:58 |
| *** doerrpau <doerrpau!~ni@caen-vnc06.engin.umich.edu> has joined #yocto | 14:58 | |
| *** romain_ <romain_!d96c30f9@gateway/web/freenode/ip.217.108.48.249> has quit IRC | 14:59 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 15:01 | |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto | 15:02 | |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has quit IRC | 15:02 | |
| lpapp | is anyone working on a similar tool as hob, but with qt/qml? | 15:02 |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has joined #yocto | 15:03 | |
| rburton | lpapp: no | 15:03 |
| rburton | lpapp: there is a web-based hob in active development though | 15:03 |
| *** jmpdelos <jmpdelos!~polk@174-24-109-134.clsp.qwest.net> has quit IRC | 15:03 | |
| lpapp | rburton: ok, I would prefer qt/qml. | 15:03 |
| rburton | you can wait for webhob if gtk+ bothers you that much :) | 15:04 |
| lpapp | well, I do not like web stuff either. | 15:05 |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has joined #yocto | 15:06 | |
| lpapp | I guess there is nothing against someone contributing a qt frontend? :) | 15:07 |
| rburton | if you feel motivated enough to write a third UI to bitbake, go for it | 15:07 |
| *** zeeblex <zeeblex!~apalalax@134.134.139.76> has left #yocto | 15:07 | |
| halstead | rtollert, rburton I've added a link to our main terms of service for now. | 15:07 |
| *** jmpdelos <jmpdelos!~polk@174-24-109-134.clsp.qwest.net> has joined #yocto | 15:08 | |
| lpapp | rburton: sure, I guess the problem would be to find reviewers. | 15:10 |
| Stygia | Heya. Does anyone here know what, __exactly__, is meant by "Installed but not shipped"? I keep seeing this 'warning' message and then my files are not included - in spite of my running install on them with (seemingly) proper arguments. This, BTW, is the recipe giving me issues: http://pastebin.com/C1fVc61R . Currently it complains that /usr/, /usr/lib/, and /usr/lib/perl/ were installed but not shipped - How do I ship them, and why aren't my ot | 15:11 |
| Stygia | her folders such as /etc/movis/ affected by tihs, when they are created with the same syntax? Kind regards. | 15:11 |
| lpapp | "smart"? | 15:11 |
| lpapp | wasn't that actually a hard disk related analyzing software initially? | 15:11 |
| bluelightning | lpapp: http://labix.org/smart/ | 15:12 |
| kergoth | PACKAGES is a list of package names. FILES_packagename lists the files/dirs to go into that package. "installed but not shipped" means it got installed by do_install, but didn'mt end up in any binary pcakages. make sure its installing to correct paths, and the FILES_ variables match up with that | 15:12 |
| bluelightning | lpapp: Smart vs SMART I guess | 15:12 |
| rburton | wikipedia insists the disk one is S.M.A.R.T. | 15:12 |
| *** Crofton|work <Crofton|work!~balister@pool-108-44-80-43.ronkva.east.verizon.net> has quit IRC | 15:12 | |
| bluelightning | rburton: honestly I don't think I would ever bother with the dots :) | 15:13 |
| rburton | lpapp: nothing to stop it being out of tree i guess | 15:13 |
| *** Crofton <Crofton!~balister@pool-108-44-80-43.ronkva.east.verizon.net> has quit IRC | 15:13 | |
| rburton | bluelightning: me neither, but someone must have insisted for the dots to be there | 15:13 |
| lpapp | rburton: bluelightning extra/smartmontools 6.1-3 Control and monitor S.M.A.R.T. enabled ATA and SCSI Hard Drives | 15:13 |
| lpapp | extra/libatasmart 0.19-2 [installed] ATA S.M.A.R.T. Reading and Parsing Library | 15:13 |
| lpapp | -> /usr/bin/smartd, etc | 15:14 |
| lpapp | it is going to be a bit confusing. :) | 15:14 |
| bluelightning | sure | 15:14 |
| lpapp | -> /usr/bin/smartctl | 15:14 |
| bluelightning | we didn't pick the name, it's an external tool we re-used... | 15:14 |
| lpapp | yeah, I know. | 15:14 |
| Stygia | kergoth, So, simply installing the files won't do, I need to explicitly add them to FILES_${PN} to ensure they got staged? This a bit confusing, as most recipes have not required me to do this. | 15:14 |
| lpapp | usually when I started a project back then, I looked for existing names. | 15:14 |
| bluelightning | I do find myself having to explain what it is a lot when mentioning it since it's not well known | 15:15 |
| bluelightning | a more unique name might have helped there I guess | 15:15 |
| *** jkridner <jkridner!~jkridner@nat/ti/x-vmhsewnqzgsvterw> has joined #yocto | 15:16 | |
| *** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto | 15:16 | |
| ndec | Stygia: yes, indeed. i send a detailed email on the list yesterday that would help you understand, i guess. | 15:16 |
| Stygia | ndec, Ah, unfortunately I am not subscribed to the list. Thanks anyway. | 15:16 |
| ndec | ok, let me find the archive | 15:17 |
| lpapp | bluelightning: I still need to learn why it is better than existing package managers. | 15:17 |
| lpapp | I think the learning curve is pretty steep for Yocto. :) | 15:17 |
| ndec | Stygia: https://lists.yoctoproject.org/pipermail/yocto/2013-July/017184.html | 15:17 |
| rburton | Stygia: for correctness, use ${libdir} and ${sysconfdir} instead of /usr/lib and /etc | 15:18 |
| Stygia | rburton, Noted. | 15:19 |
| Stygia | ndec, Thanks, bookmarked. | 15:19 |
| rburton | Stygia: tl;dr: $libdir/ isn't in FILES by default, so you'll need to add it | 15:19 |
| Stygia | rburton, Hmm, without appending ${D} in FILES, yes? | 15:20 |
| rburton | Stygia: correct, files is target paths, not paths in the build system | 15:20 |
| Stygia | rburton, Alright, thanks. | 15:20 |
| rburton | so FILES_${PN} += "${libdir}/perl" will do | 15:20 |
| Stygia | rburton, Hmm, no need to specify subfolders and files? | 15:21 |
| lpapp | rburton: can you give me an url to the thread about the gerrit discussion? | 15:21 |
| rburton | lpapp: sorry, no | 15:21 |
| rburton | Stygia: it will recurse down for you | 15:22 |
| lpapp | rburton: it exists? | 15:22 |
| rburton | lpapp: no idea | 15:22 |
| rburton | lpapp: may have been on irc, or in person at one of many conferences. | 15:22 |
| Stygia | rburton, Thanks. | 15:23 |
| *** davest <davest!Adium@nat/intel/x-uzremjzumkclkjoo> has joined #yocto | 15:23 | |
| lpapp | rburton: then it does not exist, so time to bring it up on the mailing list again. :) | 15:23 |
| lpapp | otherwise, no one will bother to actually document the decision, etc. | 15:23 |
| rburton | lpapp: it's really not. OE/yocto is explicitly patch-review-by-mail. | 15:23 |
| rburton | you might as well mail lkml and propose gerrit | 15:23 |
| lpapp | why? | 15:24 |
| rburton | because that's the choice that's was made and re-agreed several times over many years | 15:24 |
| ndec | because it might help them too. who knows? | 15:24 |
| lpapp | ok, so bitbake is written in python just like portage. | 15:24 |
| rburton | lpapp: bitbake and portage share a common root | 15:25 |
| lpapp | rburton: well, new ideas are not to be rejected just by the sake of rejecting | 15:25 |
| lpapp | if gerrit had been rejected for valid reasons, it needs to be documented for others. | 15:25 |
| ndec | lpapp: i think rburton means that it's not a new idea, as it's been evaluated already. | 15:25 |
| lpapp | so it can be reviewed, others can work on missing features, et cetera. | 15:25 |
| lpapp | ndec: all I am saying, nothing like that fundamental for the workflow should be hidden. | 15:26 |
| lpapp | whatever happened. | 15:26 |
| lpapp | decisions should happen openly, not just the source code ... ;-) | 15:26 |
| bluelightning | lpapp: most of the rationale for using Smart is here FYI: https://lists.yoctoproject.org/pipermail/yocto/2012-October/012593.html | 15:26 |
| *** sameo <sameo!samuel@nat/intel/x-gbhhcwtjtzetlotv> has quit IRC | 15:27 | |
| rburton | lpapp: the biggest reason is that yocto/oe is review-by-mail, and gerrit doesn't let you do that | 15:27 |
| lpapp | rburton: well, it cannot be review-by-mail just for the sake of review-by-mail | 15:27 |
| lpapp | it is not a technical discussion. :) | 15:27 |
| lpapp | bluelightning: thanks. | 15:28 |
| rburton | it cannot be gerrit just for the sake of gerrit. it's a choice. | 15:28 |
| bluelightning | lpapp: it's really down to what the maintainers are comfortable with, since they have to interact with the process the most | 15:28 |
| bluelightning | (re patch reviewing) | 15:28 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 15:28 | |
| *** tomz <tomz!~trz@c-68-53-177-94.hsd1.in.comcast.net> has joined #yocto | 15:28 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 15:29 | |
| lpapp | rburton: sure, but gerrit has advantages over email. | 15:29 |
| lpapp | bluelightning: sure, but they probably have a /technical/ reasoning as well. | 15:30 |
| lpapp | not just the end result. | 15:30 |
| *** icanicant <icanicant!~klawson@195.88.236.129> has quit IRC | 15:30 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has joined #yocto | 15:30 | |
| *** Squix <Squix!~Squix___@p091.net042127178.tokai.or.jp> has quit IRC | 15:31 | |
| *** Guest15299 <Guest15299!~tbn@84.55.160.118> has quit IRC | 15:31 | |
| lpapp | iow, I am personally interested why they prefer email. | 15:32 |
| fray | because it's much easier for them to review and respond to using a program they use on an ongoing basis. They don't have to load a new window/program/environment to review and approve and merge patches.. | 15:32 |
| bluelightning | lpapp: I know Richard has said he finds email works for him because he can easily work on it offline | 15:33 |
| fray | git is designed to interact directly with email lists.. (using git send-email as well as git am for applying), etc.. | 15:33 |
| fray | offline reading (and responding/processing) is yet another reason (as bluelightning indicated) | 15:33 |
| lpapp | fray: how do you review something without opening an email client up? | 15:34 |
| Stygia | rburton, kergoth, thanks to both of you, finally made this thing install properly. | 15:34 |
| Stygia | bluelightning, FYI, first build with all 80-ish modules where nothing segfaulted or complained about missing stuff.... | 15:35 |
| *** icanicant <icanicant!~klawson@195.88.236.129> has joined #yocto | 15:35 | |
| rburton | Stygia: nice :) | 15:35 |
| Stygia | rburton, Quite. | 15:35 |
| lpapp | bluelightning: yeah, gerrit has not added such a feature because it is rare nowadays not be online, I guess. | 15:36 |
| Stygia | rburton, Also this week I learned a lot of CPAN modules are exactly the same - different names (although usually in the same Module::), but the actual archive you get is exactly identical. | 15:36 |
| rburton | Stygia: ha! | 15:36 |
| rburton | lpapp: unless you're the sort of person that travels to conferences and meetings frequently, and spend non-trivial time on planes and trains. | 15:36 |
| lpapp | bluelightning: although, it would be probably simple enough to send the diff in an email, not just the commit message. | 15:36 |
| lpapp | rburton: well, flights are usually 2-3 hours inside europe. | 15:37 |
| lpapp | if you travel between continents frequently, then ok. | 15:37 |
| lpapp | but even inside the country, buses and trains usually provide wifi nowadays | 15:37 |
| fray | lpapp, I assume they are like me.. I never close my email client.. it's always up and I'm always seeing and able to respond to new email | 15:37 |
| lpapp | and I can always use my mobile data plan. | 15:37 |
| bluelightning | Stygia: FYI, a new layer was published yesterday contianing a few additional perl recipes for supporting other recipes - http://layers.openembedded.org/layerindex/layer/meta-security/ | 15:38 |
| lpapp | fray: the point is that, it is not an advantage apart from offline reading. | 15:38 |
| fray | its a workflow advantage.. | 15:38 |
| lpapp | fray: because it is just yet another window/tab like the web interface. | 15:38 |
| fray | I know personally I don't want "yet another tool" to do effectively what can be done in email, where everything is already automatically processed and archived.. | 15:38 |
| lpapp | so you do not spare window/tab in that sense if you are online. :) | 15:38 |
| rburton | can we please stop discussing the personal workflow of people who are not here | 15:38 |
| fray | some people in oe use patchwork, but thats about the extent of the tooling | 15:39 |
| lpapp | but the email client *is* a tool. | 15:39 |
| bluelightning | Stygia: also I just got a recipe for libio-pty-perl up-to-date based on an old recipe from OE-Classic, haven't sent it out yet | 15:39 |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 15:39 | |
| bluelightning | Stygia: not sure if either of those overlap with the recipes you've been working on | 15:39 |
| * fray yields as this is a personal preference and not something worth arguing.. | 15:39 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 15:39 | |
| lpapp | fray: actually, I do not think certain feature lacks are personal preference. :) | 15:39 |
| lpapp | like, how you group patches? | 15:40 |
| lpapp | do* | 15:40 |
| lpapp | how can you add reviewers anyone registered easily? | 15:40 |
| fray | email threads... and reviwers are anyone who subscribes to the mailing list | 15:40 |
| fray | or you email your patch to | 15:40 |
| lpapp | how do you know who subscribed for? | 15:41 |
| * fray goes back to work.. I'm not going to argue this | 15:41 | |
| lpapp | on gerrit, you start typing a name and it is there. | 15:41 |
| bluelightning | lpapp: for groups of patches we use pull requests containing a pointer to a branch, we even have a couple of scripts to create and send those easily | 15:41 |
| lpapp | regardless whether you interacted with that person before. | 15:41 |
| lpapp | also, how do you group changes with email? | 15:41 |
| lpapp | stable, master, next, different repositories, based on reviewers, authors, etc. | 15:41 |
| lpapp | it is getting tricky with a dedicated interface. | 15:41 |
| lpapp | without* | 15:41 |
| * rburton too | 15:42 | |
| lpapp | bluelightning: grouping, but not in that sense as you seem to have understood. | 15:42 |
| lpapp | how can you check only file in a diff with email? | 15:43 |
| lpapp | email was not meant like for such nice code review specific features. | 15:43 |
| lpapp | meant for*\ | 15:43 |
| Stygia | bluelightning, At a glance, neither do. | 15:43 |
| lpapp | bluelightning: email is a generic interface, and certain review specific features cannot be present that way. | 15:44 |
| Stygia | bluelightning, Will have a look at what you published though. | 15:44 |
| Stygia | bluelightning, And thanks for your help so far, you've really been invaluable. | 15:45 |
| lpapp | bluelightning: I think email was okay until someone put some significant effort to have a dedicated tool specialized for codereview features. | 15:45 |
| *** Stygia <Stygia!~gmpsaifi@0904ds6-noe.0.fullrate.dk> has quit IRC | 15:45 | |
| lpapp | bluelightning: and repeating for the record, adding a diff sending is probably an easy feature to add. | 15:46 |
| lpapp | because the commit header is already sent via email. | 15:46 |
| lpapp | I just think it was not high priority due to the available internet connection almost everywhere nowadays. | 15:46 |
| * ant_work notices our similarity with http://lists.infradead.org/pipermail/linux-arm-kernel/ | 15:47 | |
| bluelightning | lpapp: email for patches is fundamental to the way our maintainers work; our process is derived from the kernel process which is pretty well established; git's email-based functionality follows on from that | 15:48 |
| bluelightning | lpapp: if we were to use an additional tool it would have to integrate with email and not impose the use of that tool on maintainers | 15:48 |
| bluelightning | hence, the patchwork tool is about the closest thing there is, although it needs some tweaking | 15:49 |
| *** blitz00 <blitz00!stefans@nat/intel/x-yrenqmsimkcebjwp> has joined #yocto | 15:49 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto | 15:49 | |
| *** zenlinux <zenlinux!~sgarman@173-8-218-204-Oregon.hfc.comcastbusiness.net> has joined #yocto | 15:49 | |
| lpapp | bluelightning: well, it would not be the first time people start using new tools. | 15:50 |
| lpapp | getting used to something is not equivalent automatically to the best tool available. :) | 15:50 |
| lpapp | if the only thing the maintainers say, they do not wanna change, that is ok, but that is not technical. | 15:50 |
| lpapp | technology always improves. :) | 15:51 |
| *** ant_work <ant_work!~ant@host54-128-static.10-188-b.business.telecomitalia.it> has quit IRC | 15:51 | |
| bluelightning | no, this is mostly not a technical decision I agree, it's how maintainers have established their workflow | 15:51 |
| lpapp | if you try to achieve the things I mentioned above, it might be realized, those are not so handy with emails. | 15:51 |
| bluelightning | and you have to have a pretty compelling technical solution that covers the existing use cases to address that | 15:52 |
| bluelightning | any tool that lacks easy offline usage is not going to be workable | 15:52 |
| lpapp | it is, for me at least, like when people got used to svn which was not meant for merging at large. | 15:53 |
| lpapp | yeah, it is not a merge tool as such, but then some svn people do not change to git to solve those issues. | 15:53 |
| *** Crofton|work <Crofton|work!~balister@pool-108-44-80-43.ronkva.east.verizon.net> has joined #yocto | 15:53 | |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has quit IRC | 15:53 | |
| bluelightning | there's also the issue that patches and discussions often overlap, if these are able to happen in the same place i.e. mailing lists then there is no danger of discussions being split | 15:53 |
| lpapp | bluelightning: I still think that, that is a minority of the maintainers most probably. :) | 15:53 |
| lpapp | but yes, that is an easy fix IMO. | 15:54 |
| lpapp | I will be travelling 3000 km tonight to a conference, and I will be covered by internet most of the time. | 15:54 |
| lpapp | bluelightning: I agree, and that is why I think a mixed solution would be worse than now. | 15:55 |
| bluelightning | the only big issue with the current system is that it's hard to get a view on the outstanding patches | 15:56 |
| bluelightning | having patchwork should solve that | 15:56 |
| lpapp | well, you would have a mixed interface | 15:57 |
| lpapp | instead of gerrit, where you can do everything in one place. | 15:57 |
| lpapp | including outstanding, but even abandoned ones. | 15:57 |
| bluelightning | except gerrit won't be the place for non-patch discussions | 15:57 |
| bluelightning | so, two places | 15:57 |
| bluelightning | (that's what I meant above) | 15:58 |
| *** darknighte_znc is now known as darknighte | 15:58 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 15:59 | |
| lpapp | bluelightning: actually it can be sometimes. | 15:59 |
| lpapp | but yeah, mailing list would be necessary, or irc, or something else. | 15:59 |
| lpapp | bluelightning: but you would probably have two places in your email client for those two as well, I gues. | 15:59 |
| lpapp | guess* | 15:59 |
| lpapp | patch and discussions folder. | 16:00 |
| bluelightning | actually I don't... I could, but I find it easy enough to navigate with one folder for each mailing list | 16:00 |
| lpapp | and there are devs who do not use the mailing list, just very rarely.. they use irc for online chat, and then the review tool to review. | 16:00 |
| lpapp | the problem is that, you would be spammed by a lot of changes. | 16:00 |
| lpapp | but patchwork would not be an email solution either, anyhow? | 16:01 |
| *** slaine <slaine!~slaine@84.203.137.218> has quit IRC | 16:03 | |
| *** tonghuix <tonghuix!~tonghuix@114.245.218.93> has joined #yocto | 16:04 | |
| bluelightning | patchwork pretty much revolves around email - it picks up patches from emails and attaches threaded discussions to them | 16:04 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 16:04 | |
| bluelightning | http://patchwork.openembedded.org/ | 16:04 |
| lpapp | so, it is a web, and not email client. | 16:05 |
| lpapp | just like gerrit is, so you would not introduce more separated parts altogether. | 16:05 |
| lpapp | ok, anyway, fair enough. | 16:05 |
| Crofton|work | lpapp, we have had these conversations many times over the years | 16:06 |
| Crofton|work | and what we have know works well for the project | 16:06 |
| lpapp | Crofton|work: so what? I am a newcomer, and I have not been to those discussions. | 16:07 |
| lpapp | and I am not sure if experts had been there either. | 16:08 |
| lpapp | so a newcomer rightfully asks these questions IMHO. | 16:08 |
| rburton | lpapp: OE is ~ten years old, so yes, this has been discussed before | 16:09 |
| lpapp | in fact, I suggested to document those for your future convenience, in the very first place. | 16:09 |
| bluelightning | lpapp: I think what Crofton|work is saying is, we have genuinely looked at the process and the alternatives over the years (and fairly recently) and the decision has been that email works for us | 16:09 |
| lpapp | rburton: I know 20 years old projects where it has not been discussed. | 16:09 |
| lpapp | bluelightning: how do you know you looked at the process right, and a newcomer cannot open up new things? | 16:09 |
| lpapp | it is not something "done" | 16:09 |
| lpapp | technology is continously improving and advancing, changing, et cetera. | 16:10 |
| lpapp | anyway, I strongly suggest to document it... I am fairly certain I would not be the first, nor the last one asking these questions. | 16:10 |
| lpapp | imho, it is a rude, and potential loss to say to newcomers, "we discussed it thoroughly, and you cannot come up with anything new, so please stop it here now". | 16:11 |
| lpapp | it is rude* | 16:11 |
| lpapp | especially when the whole stuff is well hidden completely as it seems ... | 16:12 |
| bluelightning | lpapp: I wouldn't view it like that | 16:13 |
| bluelightning | lpapp: we're just saying it has come up | 16:13 |
| lpapp | bluelightning: if you read back, it has been said that "we discussed it, so let us stop it". | 16:13 |
| bluelightning | lpapp: the trouble is the biggest impact is on the maintainers rather than other community members, and those are the people who have to be convinced | 16:14 |
| lpapp | bluelightning: yes, sure, but "let us stop it in the way of total hidden untrasparency" in an open project is well ... not helpful with that. :) | 16:15 |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has quit IRC | 16:16 | |
| *** levi <levi!~user@c-24-10-225-212.hsd1.ut.comcast.net> has joined #yocto | 16:16 | |
| lpapp | bluelightning: believe it or not, for my contribution, it is a serious concern. | 16:16 |
| *** zenlinux <zenlinux!~sgarman@173-8-218-204-Oregon.hfc.comcastbusiness.net> has quit IRC | 16:16 | |
| lpapp | so it is good to understand why I take sacrifice if I happen to do. | 16:16 |
| *** zenlinux <zenlinux!~sgarman@173-8-218-204-Oregon.hfc.comcastbusiness.net> has joined #yocto | 16:16 | |
| bluelightning | lpapp: except we are pretty transparent, all discussions and patch review happens in the open on the mailing list | 16:20 |
| lpapp | bluelightning: I am referring to the "gerrit decision". | 16:22 |
| bluelightning | lpapp: I'm not saying we shouldn't document that, we probably should | 16:22 |
| *** ericben <ericben!~ebenard@pac33-3-88-170-243-169.fbx.proxad.net> has quit IRC | 16:25 | |
| *** ka6sox is now known as zz_ka6sox | 16:25 | |
| *** zz_ka6sox is now known as ka6sox | 16:25 | |
| bluelightning | it might be a little bit over the top to say we have "total hidden untransparency" just because we haven't documented that | 16:25 |
| *** mr_science <mr_science!~sarnold@net-cf9a4e91.cst.impulse.net> has joined #yocto | 16:26 | |
| *** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto | 16:26 | |
| lpapp | well, nothing is documented so it is fully hidden as of now. :) | 16:27 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 16:30 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 16:34 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 16:35 | |
| *** ka6sox is now known as zz_ka6sox | 16:35 | |
| *** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC | 16:35 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 16:36 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 16:37 | |
| *** seebs_ <seebs_!~seebs@home.seebs.net> has joined #yocto | 16:41 | |
| lpapp | https://www.yoctoproject.org/documentation/build-appliance-manual -> so virtualbox is not tested? | 16:42 |
| *** eren` <eren`!~eren@unaffiliated/eren> has joined #yocto | 16:42 | |
| lpapp | what is the difference between core-image-base and core-image-basic? The documentation does not make it that clear for me. | 16:43 |
| *** francois99_ <francois99_!~francois9@78-33-60-6.static.enta.net> has quit IRC | 16:44 | |
| *** jonatan__ <jonatan__!~quassel@194-237-7-146.customer.telia.com> has joined #yocto | 16:44 | |
| lpapp | qt4e-demo-image -> do you plan to have a qt5 variant? | 16:44 |
| *** mihai <mihai!~mihai@80.97.15.150> has quit IRC | 16:45 | |
| *** eren` <eren`!~eren@unaffiliated/eren> has quit IRC | 16:45 | |
| sgw1 | lpapp: there is a qt5 layer available, just not in core yet: git://github.com/meta-qt5/meta-qt5.git | 16:48 |
| lpapp | would it be in core for the next release? | 16:50 |
| *** tomz <tomz!~trz@c-68-53-177-94.hsd1.in.comcast.net> has quit IRC | 16:50 | |
| *** jonatan_ <jonatan_!~quassel@194-237-7-146.customer.telia.com> has quit IRC | 16:50 | |
| *** eren <eren!~eren@unaffiliated/eren> has quit IRC | 16:50 | |
| *** silviof <silviof!~silviof@ppp-188-174-119-187.dynamic.mnet-online.de> has quit IRC | 16:51 | |
| *** seebs <seebs!~seebs@home.seebs.net> has quit IRC | 16:51 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has quit IRC | 16:51 | |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has quit IRC | 16:51 | |
| pev_ | Hi all. I've got a custom layer I've written - it includes recipes for both a server daemon and a dynamically loadable module that the server uses. However when building with the module I need to modify the daemons.conf line to add support for the module... What's the correct technique to do this from the recipe? | 16:51 |
| kergoth | postinst script, most likely | 16:52 |
| lpapp | is there ubifs support in Yocto? | 16:52 |
| sgw1 | lpapp: likely not for 1.5, which is the current planned release for Oct timeframe | 16:55 |
| sgw1 | lpapp: ^^^ was in reference to qt5 | 16:56 |
| lpapp | sgw1: :( | 16:57 |
| lpapp | qt5 was released in december. | 16:57 |
| *** silviof <silviof!~silviof@ppp-188-174-119-187.dynamic.mnet-online.de> has joined #yocto | 16:57 | |
| lpapp | it would be a pitty to wait more than a year for it to appear in Yocto | 16:57 |
| sgw1 | lpapp: that's what the layers are for, its trivial to add it | 16:57 |
| *** tomz <tomz!~trz@c-68-53-177-94.hsd1.in.comcast.net> has joined #yocto | 16:58 | |
| lpapp | sgw1: yeah, but it is not nice if many people add it, instead of one centralized place... | 16:58 |
| lpapp | what can I do to help with getting this into the release in October? | 16:59 |
| sgw1 | lpapp: we don't keep everything in oe-core, it will be something to look at for future releaes | 16:59 |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has quit IRC | 16:59 | |
| *** yzhao2 <yzhao2!~yzhao2@128.224.252.2> has joined #yocto | 17:00 | |
| sgw1 | lpapp: BTW, ubifs is supported in yocto via the mtd-utils package and you can create a ubifs image. | 17:00 |
| lpapp | sgw1: we have three months until that release. | 17:01 |
| *** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC | 17:01 | |
| lpapp | and this feature cannot get in, even if it gets help from an upstream developer? | 17:01 |
| *** zeddii_home_ <zeddii_home_!~zeddii_ho@CPE002369bcfa62-CMbcc810032faf.cpe.net.cable.rogers.com> has joined #yocto | 17:01 | |
| *** fray <fray!U2FsdGVkX1@gate.crashing.org> has joined #yocto | 17:02 | |
| sgw1 | lpapp: we have layers to help support upstream development when something is not yet in the core. Those layers are maintained also. | 17:03 |
| lpapp | sgw1: you claimed that it would not be released any soon | 17:04 |
| lpapp | end users need releases. | 17:04 |
| *** honschu <honschu!~honschu@p508F67C4.dip0.t-ipconnect.de> has joined #yocto | 17:06 | |
| *** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto | 17:06 | |
| *** Crofton <Crofton!~balister@96.sub-75-197-30.myvzw.com> has joined #yocto | 17:06 | |
| *** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC | 17:08 | |
| sgw1 | lpapp: please read back more carefully, I said that qt5 would not be in the 1.5 release, it is available as a layer and that layers are supported. The layer mechanism was created for exactly this reason to allow for other projects to work with the core. Not everything will be in the oe-core and we need a plan for transitioning from qt4 to qt5 | 17:10 |
| lpapp | qt 5.0 has been released for more than half a year go | 17:11 |
| lpapp | and now we got even a new feature release, 5.1 | 17:11 |
| lpapp | if it is not getting released this year, Yocto will cause additional pain to qt5 developers. | 17:11 |
| bluelightning | lpapp: we have the layer structure to allow additional items to be added easily | 17:12 |
| lpapp | but why would they add that "easily"? | 17:12 |
| bluelightning | lpapp: we haven't had the resources to work on qt5, but luckily Martin and co have been able to do so in meta-qt5 | 17:13 |
| lpapp | when it can be solved centrally? | 17:13 |
| lpapp | I think if it takes 4-5 months at least + another few to get a qt5 package up... that is worrying to say the least. | 17:13 |
| lpapp | I am wondering why 3 months are not enough for stabilizing those packages, especially if it is now in a good shape? | 17:15 |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 17:15 | |
| bluelightning | lpapp: some features are missing, such as SDK generation | 17:16 |
| *** tonghuix <tonghuix!~tonghuix@114.245.218.93> has quit IRC | 17:16 | |
| bluelightning | (because it hasn't been needed by the primary contributors to meta-qt5 so far) | 17:16 |
| seebs_ | You know, I one wondered why no one had done a thing I wanted done in Yocto. Eventually I concluded that it had not yet been important enough to someone who had the time. So I did it. | 17:16 |
| lpapp | sure, I would be happy to help qt5 going on. | 17:17 |
| lpapp | feel free to distribute tasks to me. :) | 17:18 |
| lpapp | that is what I offered before. | 17:19 |
| pev_ | bluelightning: Have you ever modified conf files from a do_install() function? | 17:19 |
| lpapp | so I am wondering why it would not be stable enough to get in, with my help by October? | 17:19 |
| bluelightning | lpapp: we can certainly evaluate it as time goes on, if it's ready well before october (last milestone is for stabilisation and we prefer to avoid taking new features during that time) then perhaps | 17:21 |
| bluelightning | pev_: sure, using sed I have yes | 17:21 |
| Crofton | lpapp, the planning for the next release has already been done | 17:21 |
| Crofton | qt5 would be fairly major update | 17:22 |
| Crofton | and by the next cycle we should have a fairly well tested qt5 in the meat-qt5 | 17:22 |
| pev_ | bluelightning: Is that the best way to do things then? Just do checks to see if you've already made the change and if not use sed to mod in? Was just wondering if theres a more elegant mechanism... | 17:22 |
| sgw1 | pev_: If your modifing another packages conf files you would need to do a postinst as kergoth suggested before | 17:23 |
| lpapp | Crofton: well, qt4 should not be killed. | 17:23 |
| lpapp | so I do not see the risk respectively. | 17:23 |
| lpapp | at any rate, are there tasks for that work on the issue tracker? | 17:23 |
| bluelightning | pev_: it depends on the nature of the change really; if it's fixing an issue or adding a substantial part I'd use a patch rather than sed'ing in do_install | 17:23 |
| Crofton | it is vary acceptable to use layers | 17:23 |
| Crofton | we want to keep the core layer very focused and not start moving more and more in over time | 17:24 |
| bluelightning | pev_: but the standard way to insert dynamic paths and values of variables is to use sed on the config file (after installing rather than before, so re-executing the task works) | 17:24 |
| lpapp | Crofton: as I said, qt5 was released relatively long ago | 17:24 |
| lpapp | and we have 5.1 as well now. | 17:25 |
| lpapp | it is a valid expectation not to make qt5 users' life hard. | 17:25 |
| lpapp | more difficult than it could be, that is. | 17:25 |
| Crofton | adding meta-qt5 should not make your life hard | 17:25 |
| bluelightning | lpapp: that is correct, it's just that the majority of users we have are still working with apps that build on top of qt4 | 17:25 |
| lpapp | and qt5 and qt4 should exist simultaneously. | 17:25 |
| lpapp | for a few years. | 17:25 |
| bluelightning | lpapp: but luckily, the community as a whole hasn't ignored qt5, we have a layer to support it already | 17:25 |
| lpapp | bluelightning: new developers will not pick up qt4 at all. | 17:26 |
| lpapp | and there are already several big projects built around qt5. | 17:26 |
| pev_ | sgwl: is that using "pkg_postinst_${PN} () {" - only refs I can see | 17:26 |
| bluelightning | lpapp: I'm not in any way suggesting qt5 isn't important | 17:26 |
| bluelightning | lpapp: with the resources we have we just have to pick the stuff we can to work on | 17:27 |
| sgw1 | pev_: yes that would be the construct | 17:27 |
| *** sgw1 is now known as sgw_ | 17:27 | |
| pev_ | bluelightning: its just adding a line to dynamically load a module and modifying another two to change two vars. I didn't think it was sensible to use patches at that point in the build process? | 17:27 |
| pev_ | sgwl: Thanks will try that | 17:27 |
| lpapp | bluelightning: well, I would be a resource for qt5. | 17:28 |
| lpapp | the reasoning accordingly can be void. :) | 17:28 |
| bluelightning | pev_: right, it depends on the nature of the changes being made | 17:28 |
| bluelightning | lpapp: great! | 17:28 |
| lpapp | may I ask for concrete tasks again? | 17:29 |
| bluelightning | lpapp: beyond adding support for building nativesdk (for SDKs) I'm not sure what needs doing | 17:30 |
| pev_ | sgw_: do you mean using the postinst so that it only runs on the target as I see in various examples? Is this really much different to modifying in the rootfs before packaging? | 17:30 |
| bluelightning | lpapp: but really this is a case where someone such as yourself with Qt5 experience can help identify anything that might be missing | 17:30 |
| lpapp | bluelightning: "building nativesdk (for SDKs)" -> not sure that is a show stopper. | 17:31 |
| lpapp | I imagine Yocto would be more useful for embedded at this stage. | 17:31 |
| *** doerrpau <doerrpau!~ni@caen-vnc06.engin.umich.edu> has quit IRC | 17:32 | |
| bluelightning | lpapp: it is for us, people expect to have externally usable SDKs containing the tools that they can run outside of the build process | 17:32 |
| bluelightning | lpapp: especially important for things like Qt which are used by app developers that aren't closely involved in the system development and thus won't be using the build system directly | 17:33 |
| *** belen <belen!~Adium@134.134.139.72> has quit IRC | 17:33 | |
| lpapp | bluelightning: not sure I follow. | 17:33 |
| lpapp | bluelightning: wouldn't the SDK mean qtcreator, documentation, assistant, designer, and all that? | 17:33 |
| lpapp | bluelightning: that is not used when shipping an embedded system. | 17:34 |
| lpapp | they might be used on the host PC with affected distributions. | 17:34 |
| bluelightning | lpapp: it's not for shipping, it's for when applications are being developed | 17:34 |
| bluelightning | lpapp: I'm more thinking of qmake/moc/etc. rather than QtCreator etc. | 17:35 |
| *** everlook <everlook!~everlook@74-92-165-193-Oregon.hfc.comcastbusiness.net> has joined #yocto | 17:35 | |
| bluelightning | lpapp: really the most important part of the SDK is the cross-compiler, which we naturally already handle; but users expect to have the other Qt-specific build tools available as well | 17:36 |
| lpapp | bluelightning: those tools should come with qt5-core | 17:36 |
| bluelightning | lpapp: yes, they do... but the recipes we have currently can only build those for native (host) and the target, not for SDKs | 17:37 |
| lpapp | qtchooser* | 17:37 |
| lpapp | bluelightning: that is enough. | 17:37 |
| lpapp | if you supply mkspecs files, those can cross-compile. | 17:37 |
| bluelightning | in our system, SDKMACHINE i.e. the machine the SDK is intended to run on is not necessarily the same as the host | 17:39 |
| bluelightning | yes, mkspecs are part of the target portion of the SDK, those aren't a problem | 17:39 |
| lpapp | sure, it is the matter of using the right mkspecs file. | 17:39 |
| lpapp | for applications | 17:39 |
| lpapp | for qt itself, -platform and -xplatform. | 17:39 |
| pev_ | OK, so if Ive added a pkg_postinst_${PN} function, when does it get run? It look like normally bit-baking the recipe doesnt execute it | 17:39 |
| bluelightning | pev_: it will be run every time the package is installed... in practice, that will be attempted at one of three times - 1) image construction time on the host when the package is included in the image; 2) if that fails, on first boot of the image; or 3) if the package wasn't included in the image but runtime package management is enabled and the package gets installed/upgraded at a later date on the target | 17:41 |
| pev_ | Ok, thanks. So for convenience prototype my changes under do_install then move to postinstall once working correctly? | 17:42 |
| lpapp | I guess I do not yet understand what goes into bsp. | 17:43 |
| bluelightning | pev_: I'm assuming so... I'm still not totally sure I understand what you're trying to do though | 17:43 |
| bluelightning | lpapp: everything that's specific to the machine supported by the BSP | 17:43 |
| lpapp | I see regular userspace linux utils in there alongside u-boot, grub, and so forth. | 17:43 |
| lpapp | bluelightning: which BSP? | 17:43 |
| bluelightning | lpapp: I'm speaking generally for any BSP | 17:44 |
| bluelightning | lpapp: which one are you looking at? | 17:44 |
| lpapp | we have a custom board. | 17:44 |
| pev_ | bluelightning: basically I have a layer within which are two recipes. 1) a daemon with a config, 2) a dynamically loadable module for the daemon. When I build the modules recipe it needs to modify the .conf file installed by the daemon to add the line to dynamically load the module. | 17:44 |
| bluelightning | pev_: ah right, now I get it | 17:45 |
| pev_ | bluelightning: Should be easy eh? :-D | 17:45 |
| lpapp | but how is keymaps for instance BSP related? | 17:45 |
| lpapp | instead of say... corE? | 17:45 |
| lpapp | core* | 17:45 |
| bluelightning | pev_: yes, that is a case where a postinstall script is needed; and I don't think prototyping it in do_install will work unless you mean do_install of the daemon recipe | 17:45 |
| bluelightning | lpapp: that's typically where there is a custom keymap for the specific machine | 17:46 |
| bluelightning | lpapp: usually it's done as a bbappend so it's modifying the existing keymaps recipe | 17:46 |
| pev_ | bluelightning: Gotcha. Just an idiot question, am I right in thinking that postinstall gets executed in both the dev host AND on the target? | 17:47 |
| pev_ | some of the comments indicate that | 17:47 |
| lpapp | bluelightning: but it is more like a core package for distributions.. | 17:48 |
| lpapp | cannot mention any distribution without it. | 17:48 |
| bluelightning | pev_: yes, basically as I described above | 17:49 |
| bluelightning | lpapp: it is, and that's why the core bit is not in the BSP | 17:49 |
| pev_ | I'll give that a go, thanks. | 17:50 |
| bluelightning | I gotta go, have a good weekend all | 17:50 |
| lpapp | but keymap is in BSP. | 17:50 |
| lpapp | not in core. | 17:50 |
| pev_ | You too. Enjoy the sun | 17:50 |
| fray | for keymaps, you have to have a board that supports 'keys'.. not all of them do | 17:50 |
| bluelightning | lpapp: not the whole recipe, it's a bbappend as I mentioned already | 17:50 |
| *** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC | 17:50 | |
| lpapp | glib is core?! | 17:51 |
| lpapp | really? | 17:51 |
| lpapp | why is a gnome library core? | 17:52 |
| *** Crofton <Crofton!~balister@96.sub-75-197-30.myvzw.com> has quit IRC | 17:54 | |
| lpapp | Crofton|work: btw, I would probably use qt5 for a qt frontend of bitbake. | 17:54 |
| walters | lpapp, because it's really good =) | 17:54 |
| fray | look at the dependency tree.. there are a large number of basic applications these days that require glib | 17:54 |
| lpapp | walters: let us agree to disagree. ;) | 17:56 |
| lpapp | fray: same can be said about qt-core | 17:56 |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 17:57 | |
| lpapp | what is the recommended place for adding an updated u-boot version and ignore what is in the release? | 17:57 |
| fray | uboot versions are usually tied to the BSP.. | 17:58 |
| lpapp | updated u-boot version with one custom patch for our board. | 17:58 |
| lpapp | should I create another layer? | 17:58 |
| lpapp | or should I make a new recipe in meta-bsp? | 17:58 |
| fray | So placing uboot within the BSP layer (and/or patches to the base version) is the usual approach | 17:58 |
| lpapp | or a new one in recipes-bsp? | 17:58 |
| fray | new recipe vs extending the existing is up to the requriements of the BSP creator | 17:59 |
| fray | but you should have your own BSP layer, and within that layer place the items in similar locations to the existing system.. | 17:59 |
| lpapp | extending does not help as in our release, the u-boot version is pretty old. | 17:59 |
| lpapp | own BSP layer means? | 17:59 |
| fray | standard practice is when you add functionality to the system you do so in a layer in which you create.. | 18:00 |
| fray | you should create a BSP layer for your custom board, and place firmware and boot items within that layer so that it's all together.. | 18:00 |
| fray | it makes long-term maintenance of the BSP easier | 18:00 |
| fray | applications generally should not be in the BSP layer, unless the application is specific to functionality of that board | 18:01 |
| lpapp | you mean this? | 18:01 |
| lpapp | meta-foo/recipes-bsp? | 18:01 |
| fray | you create a new layer.. meta-foo | 18:02 |
| fray | you place the contents within meta-foo.. recipes-* replacing * with the appropriate directory | 18:02 |
| lpapp | why are there a few layers by default? | 18:02 |
| lpapp | I am especially thinking of meta-yocto? | 18:03 |
| fray | they group the software and help delinate maintenance responsibilities.. | 18:03 |
| fray | meta -- oe-core, meta-hob and meta-skeleton come from oe-core.. | 18:04 |
| fray | meta-yocto-bsp and meta-yocto come from the Yocto Project | 18:04 |
| fray | for a basic system (oe-core) you only need to use the oe-core layer.. but you get a basic distribution configuration and access to only the QEMU bsps.. | 18:05 |
| lpapp | so there is someone sync'ing up with oe upstream? | 18:05 |
| fray | adding in the meta-yocto and meta-yocto-bsp layers add additional functionality | 18:05 |
| fray | yes | 18:05 |
| fray | BSP-layers usually consist of the machine configuration, and patches as part of the linux recipe | 18:06 |
| lpapp | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/?h=master-next -> so meta-qt5 is not planned to be an addition here for the next release so far... | 18:06 |
| lpapp | so by the easy way, it was meant like we can clone the meta-qt5 repository, and copy into the yocto project folder? | 18:06 |
| fray | http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/ | 18:06 |
| fray | that is the current state of Poky | 18:07 |
| fray | http://git.openembedded.org/openembedded-core/tree/ | 18:07 |
| fray | that is the current state of oe-core.. you will see they are very similar.. | 18:07 |
| fray | poky is made up of oe-core + meta-yocto | 18:07 |
| fray | (meta-yocto: http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/) | 18:07 |
| lpapp | git://github.com/meta-qt5/meta-qt5.git | 18:08 |
| lpapp | so we should clone that, and copy into the poky tree? | 18:08 |
| fray | poky is provided as a unit as a convienence to developers so they don't have to assembly it themselves.. | 18:08 |
| lpapp | that is what "easy" means, right? | 18:08 |
| fray | you should clone it, and add it to your projects bblayers.conf file | 18:08 |
| lpapp | k, ty... | 18:08 |
| lpapp | g2g, take care | 18:08 |
| *** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC | 18:09 | |
| trollixx | I have a problem with meta-qt5, my recipe does not set proper paths until I copy-paste OE_QMAKE_PATH_HEADERS and others from qt5.inc into my .inc. How to avoid this? | 18:11 |
| *** jbaxter <jbaxter!~jbaxter@jimbax.plus.com> has quit IRC | 18:14 | |
| *** Crofton <Crofton!~balister@wsip-98-191-7-58.rn.hr.cox.net> has joined #yocto | 18:16 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 18:18 | |
| ftonello | is avahi a DISTRO_FEATURE? | 18:20 |
| ftonello | it should be | 18:20 |
| JaMa | trollixx: that's OK, see wiki on meta-qt5 | 18:24 |
| JaMa | trollixx: only QT_HEADERS should be needed | 18:24 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 18:24 | |
| kergoth | who was it that was doing most of the read-only-rootfs work, again? | 18:27 |
| trollixx | JaMa: thanks, I missed it in wiki | 18:28 |
| * kergoth just had an idea to create <recipe>-volatile packages that include tmpfiles.d/volatile configurations to symlink paths the recipe needs to write to, then set up a dbg/dev-like install of complementary volatile packages in r/o rootfs constructions | 18:28 | |
| *** jbaxter <jbaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 18:29 | |
| sgw_ | kergoth: that was a guy in china, Qi Chen | 18:29 |
| *** dvhart <dvhart!~dvhart@static-50-53-108-147.bvtn.or.frontiernet.net> has joined #yocto | 18:29 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 18:30 | |
| kergoth | aside: we should really have a sseparate script which creates systemd tmpfiles.d-based stuff and migrate our old volatiles to it, or something, having two implementations of this is rather ugly | 18:30 |
| trollixx | JaMa: Isn't it possible to put this path in mkspecs? | 18:30 |
| JaMa | trollixx: I know it's not elegant, but other option would be to assume that every app using qmake to build itself wants to install headers and libs in qt5 prefix and that's IMHO worse | 18:30 |
| trollixx | yeah | 18:31 |
| JaMa | trollixx: the problem is that there isn't good separation between "search" paths and "install" paths | 18:31 |
| JaMa | or at least I haven't found it :) | 18:31 |
| trollixx | Hm, ubuntu use the same separation if qt4 and qt5 headers... | 18:32 |
| ftonello | My image is installing avahi, but I'm not adding this dependecy no where.. when I do a bitbake -g -u depexp I see that avahi depends on libnss-mdsn which no one is depending | 18:47 |
| rburton | kergoth: yes, having two solutions for /run is madness. | 18:48 |
| *** zenlinux <zenlinux!~sgarman@173-8-218-204-Oregon.hfc.comcastbusiness.net> has quit IRC | 18:48 | |
| ftonello | what I see in the recipes is that libnss-mdsn depends on avahi.. and avahi has this: RRECOMMENDS_avahi-daemon_append_libc-glibc = "libnss-mdns" and RRECOMMENDS_${PN}_append_libc-glibc = "libnss-mdns" | 18:48 |
| ftonello | what is this _append in RRECOMMENDS ? | 18:50 |
| seebs_ | _append is magic, it means that whatever happens to the value otherwise, after that's done the _append values will be added on to the end. | 18:57 |
| JaMa | not magic enough, I want bitbake to append whatever I'm thinking about to that variable before I even write it in the recipe | 18:59 |
| *** davest <davest!Adium@nat/intel/x-uzremjzumkclkjoo> has quit IRC | 18:59 | |
| *** dvhart <dvhart!~dvhart@static-50-53-108-147.bvtn.or.frontiernet.net> has quit IRC | 19:00 | |
| *** joeythesaint <joeythesaint!~jjm@128.224.252.2> has quit IRC | 19:00 | |
| ftonello | seebs_: ok | 19:03 |
| ftonello | but still doesn't make sense why libnss-mdns (and then avahi) is been installed in the image | 19:04 |
| seebs_ | Ohh. Looking more closely. _append_libc-glibc is an override-append. Meaning it's applied only if libc-glibc is in the OVERRIDES list. So presumably the intent is that if you don't have libc-glibc, that RRECOMMENDS won't get added. Not sure why. | 19:05 |
| seebs_ | It seems sort of odd that they're both getting brought in. It seems like adding avahi is intended to recommend (but not require) libnss-mdns, and that libnss-mdns is intended to require avahi, but I am not sure how it's getting around to looking at either. | 19:06 |
| *** acidfu <acidfu!~nib@unaffiliated/acidmen> has quit IRC | 19:08 | |
| *** dvhart <dvhart!~dvhart@134.134.139.70> has joined #yocto | 19:08 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 19:09 | |
| *** Crofton <Crofton!~balister@wsip-98-191-7-58.rn.hr.cox.net> has quit IRC | 19:11 | |
| *** jbaxter <jbaxter!~jbaxter@jimbax.plus.com> has quit IRC | 19:15 | |
| *** davest <davest!Adium@nat/intel/x-nhhvcrebszexdbis> has joined #yocto | 19:24 | |
| *** seebs_ is now known as seebs | 19:25 | |
| *** Umeaboy <Umeaboy!~Umeaboy@213-21-78-12.customer.t3.se> has joined #yocto | 19:26 | |
| rtollert | seebs ftonello: fwiw, libnss-mdns can optionally query avahi for cached mdns resolution, so that's where that dep is coming from | 19:27 |
| *** mitz <mitz!~mitz@KHP222227247006.ppp-bb.dion.ne.jp> has joined #yocto | 19:29 | |
| *** jbaxter <jbaxter!~jbaxter@jimbax.plus.com> has joined #yocto | 19:34 | |
| *** lpapp <lpapp!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has joined #yocto | 19:47 | |
| lpapp | fray: wn | 19:47 |
| lpapp | was tnere | 19:47 |
| lpapp | sorry, lemme try again. :) | 19:47 |
| lpapp | fray: was there anything else you wanted to share with me? | 19:47 |
| *** doerrpau <doerrpau!~ni@caen-vnc08.engin.umich.edu> has joined #yocto | 19:59 | |
| *** davest <davest!Adium@nat/intel/x-nhhvcrebszexdbis> has quit IRC | 20:02 | |
| *** b46258 <b46258!~b46258@gate-tx3.freescale.com> has quit IRC | 20:04 | |
| *** tomz is now known as Guest61203 | 20:07 | |
| *** vmeson <vmeson!~quassel@128.224.252.2> has quit IRC | 20:13 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 20:14 | |
| *** Guest61203 <Guest61203!~trz@c-68-53-177-94.hsd1.in.comcast.net> has left #yocto | 20:19 | |
| *** agust <agust!~agust@pD9E2FB2C.dip0.t-ipconnect.de> has joined #yocto | 20:21 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 20:36 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 20:40 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:40 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 20:43 | |
| *** jukkar <jukkar!~jukka@134.134.139.70> has quit IRC | 20:46 | |
| *** jukkar <jukkar!jukka@nat/intel/x-syjnedmkrvxxshrv> has joined #yocto | 20:47 | |
| *** smartin <smartin!~smartin@20-87-190-109.dsl.ovh.fr> has joined #yocto | 20:48 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:48 | |
| *** smartin_ <smartin_!~smartin@20-87-190-109.dsl.ovh.fr> has quit IRC | 20:49 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 20:50 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 20:50 | |
| *** vmeson <vmeson!~quassel@128.224.252.2> has joined #yocto | 20:51 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 20:52 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 20:55 | |
| *** zz_ka6sox is now known as ka6sox | 20:57 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 20:58 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 21:00 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 21:00 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 21:04 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 21:06 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 21:06 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 21:08 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 21:08 | |
| *** zenlinux <zenlinux!~sgarman@c-50-139-85-11.hsd1.or.comcast.net> has joined #yocto | 21:10 | |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has joined #yocto | 21:17 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has joined #yocto | 21:17 | |
| ftonello | rtollert: i didn't get it | 21:25 |
| rtollert | ftonello: sorry, I meant the mdns->avahi dep. I don't know about the more important question (where either of the two are being depended on). :F Maybe run bitbake -g and look at task-depends.dot for which task is bringing in one of those two? | 21:27 |
| *** walters <walters!~walters@c-66-31-18-51.hsd1.ma.comcast.net> has quit IRC | 21:32 | |
| ftonello | rtollert: ok.. as I said, mdns is the one who brings avahi dependency, but no other package depends on mdns, i shows alone in the reverse dependency list (using -u depexp) | 21:35 |
| *** zecke <zecke!~ich@91-65-247-193-dynip.superkabel.de> has quit IRC | 21:51 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 21:51 | |
| *** sameo <sameo!samuel@nat/intel/x-qmzdffcvaeqpthpx> has joined #yocto | 22:01 | |
| *** ant_home <ant_home!~andrea@host144-222-dynamic.7-79-r.retail.telecomitalia.it> has joined #yocto | 22:02 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-yzedatloardeilrd> has quit IRC | 22:04 | |
| *** lpapp <lpapp!~lpapp@cpc11-cmbg15-2-0-cust30.5-4.cable.virginmedia.com> has quit IRC | 22:04 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nkhezizjutzamkpd> has joined #yocto | 22:04 | |
| *** challinan <challinan!~challinan@173-10-226-189-BusName-WestFlorida.hfc.comcastbusiness.net> has quit IRC | 22:06 | |
| *** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nkhezizjutzamkpd> has quit IRC | 22:06 | |
| *** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC | 22:07 | |
| *** JYDawg_ <JYDawg_!~jydawg@jydawg.stoned-it.com> has quit IRC | 22:39 | |
| *** JYDawg <JYDawg!~jydawg@jydawg.stoned-it.com> has joined #yocto | 22:39 | |
| *** dvhart <dvhart!~dvhart@134.134.139.70> has quit IRC | 22:39 | |
| *** doerrpau <doerrpau!~ni@caen-vnc08.engin.umich.edu> has quit IRC | 22:48 | |
| *** andyross <andyross!~andy@c-67-171-188-207.hsd1.or.comcast.net> has quit IRC | 22:52 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has joined #yocto | 23:17 | |
| *** agust <agust!~agust@pD9E2FB2C.dip0.t-ipconnect.de> has quit IRC | 23:18 | |
| *** ant_home <ant_home!~andrea@host144-222-dynamic.7-79-r.retail.telecomitalia.it> has quit IRC | 23:21 | |
| *** dvhart <dvhart!~dvhart@static-50-53-108-147.bvtn.or.frontiernet.net> has joined #yocto | 23:30 | |
| *** cetola <cetola!~cetola@74-92-165-193-Oregon.hfc.comcastbusiness.net> has quit IRC | 23:35 | |
| *** jbaxter <jbaxter!~jbaxter@jimbax.plus.com> has quit IRC | 23:35 | |
| *** mulhern <mulhern!~mulhern@c-24-128-153-12.hsd1.ma.comcast.net> has quit IRC | 23:49 | |
Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!