Friday, 2013-07-12

*** sameo_ <sameo_!~samuel@> has quit IRC00:07
*** rburton <rburton!> has quit IRC00:13
*** rburton <rburton!> has joined #yocto00:14
*** agust <agust!> has quit IRC00:19
*** _julian <_julian!> has joined #yocto00:25
*** _julian_ <_julian_!> has quit IRC00:28
*** forcev <forcev!> has quit IRC00:31
*** FunkyPenguin <FunkyPenguin!~quassel@opensuse/member/FunkyPenguin> has joined #yocto00:31
*** squix_ <squix_!> has joined #yocto00:32
*** squix_ <squix_!> has quit IRC00:33
*** andyross <andyross!> has quit IRC00:41
*** zz_ka6sox-away is now known as ka6sox00:43
*** scot <scot!> has quit IRC00:49
*** cetola <cetola!4a5ca5c1@gateway/web/freenode/ip.> has quit IRC00:51
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has quit IRC01:03
*** ericben <ericben!> has quit IRC01:04
*** ericben <ericben!> has joined #yocto01:06
*** mulhern <mulhern!> has joined #yocto01:06
*** mitz <mitz!> has quit IRC01:18
*** mitz <mitz!> has joined #yocto01:19
*** levi <levi!> has quit IRC01:25
*** levi <levi!> has joined #yocto01:26
*** mitz <mitz!> has quit IRC01:40
*** mitz <mitz!> has joined #yocto01:42
*** mitz <mitz!> has quit IRC01:54
*** mitz <mitz!> has joined #yocto01:56
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto02:00
*** silviof2 <silviof2!> has joined #yocto02:11
-YoctoAutoBuilder- build #175 of nightly-fsl-arm-lsb is complete: Success [build successful] Build details are at
*** silviof1 <silviof1!> has quit IRC02:13
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has quit IRC02:30
*** nitink <nitink!~nitink@> has quit IRC02:31
*** andyross <andyross!> has joined #yocto03:14
*** andyross <andyross!> has joined #yocto03:18
*** andyross <andyross!> has joined #yocto03:23
*** klinger_ <klinger_!> has joined #yocto03:33
*** klinger <klinger!> has quit IRC03:36
*** smartin <smartin!> has joined #yocto03:57
*** smartin_ <smartin_!> has quit IRC03:58
*** smartin_ <smartin_!> has joined #yocto04:05
*** smartin <smartin!> has quit IRC04:08
*** cetola <cetola!> has joined #yocto04:11
*** mitz <mitz!> has quit IRC04:27
*** mitz <mitz!> has joined #yocto04:29
*** mitz <mitz!> has quit IRC04:31
*** Squix <Squix!> has quit IRC04:32
*** Squix <Squix!> has joined #yocto04:32
*** mitz <mitz!> has joined #yocto04:38
*** crazy_imp <crazy_imp!> has quit IRC04:40
*** crazy_imp <crazy_imp!> has joined #yocto04:42
*** mitz <mitz!> has quit IRC04:51
*** andyross <andyross!> has quit IRC04:51
*** cetola <cetola!> has quit IRC04:52
*** mitz <mitz!> has joined #yocto04:52
*** cetola <cetola!> has joined #yocto04:52
*** cetola <cetola!> has quit IRC04:54
*** ericben <ericben!> has quit IRC05:03
*** ericben <ericben!> has joined #yocto05:05
*** rburton <rburton!> has quit IRC05:11
*** rburton <rburton!> has joined #yocto05:11
*** britzp <britzp!> has quit IRC05:16
*** mitz <mitz!> has quit IRC05:27
*** mitz <mitz!> has joined #yocto05:29
*** zecke <zecke!> has joined #yocto05:35
*** agust <agust!> has joined #yocto05:41
*** behanw <behanw!> has quit IRC05:45
*** gmacario <gmacario!> has joined #yocto05:52
*** nitink <nitink!nitink@nat/intel/x-sfsqehbirnpdcywd> has joined #yocto05:54
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:04
*** lpapp_ <lpapp_!> has joined #yocto06:06
lpapp_hi, are there plans to support Yocto on Windows?06:07
msm`probably not06:13
lpapp_it would be nice to have.06:15
msm`they have a build appliance06:20
*** myopiate <myopiate!> has quit IRC06:21
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:21
*** mihai <mihai!~mihai@> has joined #yocto06:37
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC06:43
lpapp_msm`: vbox != native build.06:44
*** rburton is now known as Guest597606:45
lpapp_from the short bitbake manual: "Must support build and target operating systems (including cygwin, the BSDs, etc)."06:49
*** rogerzhou <rogerzhou!~rogerzhou@> has joined #yocto06:56
*** ynezz_ is now known as ynezz07:07
*** gmacario <gmacario!> has joined #yocto07:08
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has joined #yocto07:08
*** eballetbo <eballetbo!> has joined #yocto07: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@> has joined #yocto07:14
*** TuTizz <TuTizz!~TuTizz@> has left #yocto07:14
fenrigHi I'm having trouble generating a sdk with "-c populate_sdk"07:14
fenrigIt has to do with x11-common:
*** melonipoika <melonipoika!> has joined #yocto07:18
*** gmacario <gmacario!> has quit IRC07:18
*** gmacario <gmacario!> has joined #yocto07:19
fenrigthere isn't much information about it :/07:22
fenrigso I'm pretty much stuck07:22
*** lpapp_ <lpapp_!> has quit IRC07:23
*** florian_kc <florian_kc!> has joined #yocto07:26
*** florian_kc <florian_kc!~fuchs@Maemo/community/contributor/florian> has joined #yocto07:26
*** sameo_ <sameo_!samuel@nat/intel/x-fuicvuzezuitwyqk> has joined #yocto07:37
*** Jay7x <Jay7x!jay@> has joined #yocto07:37
*** gmacario <gmacario!> has quit IRC07:38
*** Jay7 <Jay7!jay@> has quit IRC07:38
*** jchonig <jchonig!> has quit IRC07:38
*** jwessel <jwessel!~jwessel@> has quit IRC07:38
*** icanicant <icanicant!~klawson@> has quit IRC07:38
*** zeddii_home <zeddii_home!> has quit IRC07:39
*** jwessel <jwessel!~jwessel@> has joined #yocto07:39
*** abelloni <abelloni!> has quit IRC07:39
*** ant_work <ant_work!> has joined #yocto07:39
fenrigmaybe to do with version mismatch?07:40
*** florian_kc is now known as florian07:40
*** abelloni <abelloni!> has joined #yocto07:40
*** gmacario <gmacario!> has joined #yocto07:40
*** icanicant <icanicant!~klawson@> has joined #yocto07:44
*** jchonig <jchonig!> has joined #yocto07:44
*** silviof2 is now known as silviof07:52
fenrigso 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
fenrigit says it can't statisfy a dependency :/07:54
*** sameo_ <sameo_!samuel@nat/intel/x-fuicvuzezuitwyqk> has quit IRC07:55
*** smartin <smartin!> has joined #yocto07:57
*** smartin_ <smartin_!> has quit IRC07:58
*** gmacario1 <gmacario1!> has joined #yocto07:59
*** gmacario <gmacario!> has quit IRC08:01
*** ericben <ericben!> has quit IRC08:03
*** ericben <ericben!> has joined #yocto08:05
*** snua12 <snua12!> has joined #yocto08:05
*** jbaxter <jbaxter!> has joined #yocto08:07
*** zeeblex <zeeblex!~apalalax@> has joined #yocto08:08
fenrignobody willing to help me out :/ as I'm really stuck at this last step of generating the sdk :)08:11
*** synthnassizer <synthnassizer!~quassel@> has quit IRC08:15
mihaifenrig: maybe you missed a layer? check the build configuration header08:20
*** mitz <mitz!> has quit IRC08:20
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto08:21
erbofenrig: is there a x11-common package built? try: find <builddir>/tmp/deploy/ -name 'x11-common*'08:21
erbofenrig: if not, try "bitbake x11-common" and then try the populate_sdk again08:22
fenrigI think so /ipk/all/x11-common_0.1-r38_all.ipk08:23
*** mitz <mitz!> has joined #yocto08:23
*** slaine <slaine!~slaine@> has joined #yocto08:23
erbofenrig: that's an older version that what it looks for08:23
fenrigerbo: x11-common is built :o08:23
fenrigerbo: yes but I tried changing version numbers, that's why the version is older08:23
fenrigerbo: I'll undo the changes, regenerate and check te version number again ;)08:24
erbofenrig: do that and post the build log and I'll see if I can atleast help you narrow the issue down..08:25
fenrigerbo: the error log you mean? or ...?08:25
fenrigerbo: okay just a second ;)08:26
*** tbn <tbn!~tbn@> has joined #yocto08:32
*** tbn is now known as Guest1529908:32
bluelightningmorning all08:33
fenrigbluelightning: morning ;)08:33
erbofenrig: do you now have a /ipk/all/x11-common_0.1-r47_all.ipk ?08:34
fenrigyes I have :)08:35
bluelightninghi fenrig08:35
fenrigbluelightning: hi08:35
fenrigerbo: I think it's strange it can't statisfy the dependency :/08:36
fenrigerbo: and it's only an issue when populating the sdk, not when generating the image :)08:36
fenrigerbo: 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.> has joined #yocto08:38
fenrigan 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's08:39
Guest5976fenrig: 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
fenrigGuest5976: 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 RagBal08:45
fenrigGuest5976: 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 taxes08:46
*** dv_ <dv_!> has quit IRC08:46
Guest5976oh, that's silly08:47
Guest5976oh hang on , why am i guest!08:47
*** Guest5976 is now known as rburton08:47
bluelightningrburton: using the web client?08:48
bluelightning(morning btw)08:48
fenrigrburton: yes it is, here in belgium payed education (that's what it is) is extra money for the goverment08:48
ynezzfenrig: well, I've been throught whole europe by jyst using "autostop" :)08:48
rburtonbluelightning: no, znc. been having small connectivity blips so it probably tried reconnecting before the server kicked the dead connection.08:49
fenrigynezz: cool :) I can look into that08:49
ynezzfenrig: and those trainings... better buy few boards, load of books and beers for that 3000EUR08:50
fenrigerbo: did you find anything ?08:50
fenrigynezz: got any GREAT books on the subject?08:50
erbofenrig: 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 wrong08:50
*** Jay7x is now known as Jay708:51
fenrigerbo: strange :/08:51
erbofenrig: xserver-common comes from meta-openembedded/meta-oe/recipes-graphics/xserver-common/08:52
fenrigerbo: Multiple replacers for x11-common, using first one (xserver-common).08:52
erboit has conflicts and replaces for x11-common08:52
fenrigerbo: maybe something to do with using angstrom?08:53
erbocould be08:53
fenrigcan I force x11-common instead of xserver-common?08:54
*** belen <belen!Adium@nat/intel/x-jcbaetbrbdlinaxm> has joined #yocto08:55
ant_workfenrig: erbo: catch rburton ..he knows about that infamous X settings split08:57
fenrigrburton: Are you willing to help me out with some populate_sdk and x11-common problems?08:58
fenrigerbo: thx for helping me out ;) I appreciate it09:01
ant_workfenrig: this is maybe the last drift btw meta-oe and oe-core. Somehow impacting on -sdk09:01
fenrigant_work: how do u mean?09:02
rburtonoh is it time for my jog? /me runs09:02
ant_workxserver-common vs. x11-common has been discussed several times on the ML09:02
rburtonfenrig: what's the problem?09:02
* rburton will go for his jog later09:03
* ant_work downloading the huge log09:03
fenrigrburton: I'm trying to generate a sdk with "-c populate_sdk" and it fails because it can't statisfy a dependency namely x11-common :o09:03
rburtonfenrig: 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
fenrigrburton: erbo pointed out that x11-common got replaced by xserver-common, so that's probably why it fails :o09:04
fenrigrburton: yes:
ant_workI see xinput-calibrator so it's obviously from meta-oe09:05
fenrigyeah I opted to upload the file, cause when I pasted it on gist in chrome the browser tab crashed :/09:05
rburtonyocto should run a pastebin, and then we can make bb upload logs to it09: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 can be installed?09:06
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC09:06
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto09:07
rburtonfenrig: 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
rburtonfenrig: one option would be to blow away your deploy and mask out xserver-common09:07
rburton(meaning, hide xserver-common from bitbake)09:08
fenrigso delete deploy and how do I mask out xserver-common ?09:08
ant_workfenrig:   for pasting form console09:08
rburtonfenrig: one sec, digging a bit09:08
fenrigjust rename the file to something with backup appended to it?09:08
rburtonnah there's a better way09:08
fenrigrburton: take your time ;)09:08
ant_workrburton: iirc I did delete the xserver-nodm-init of meta-oe09:09
ant_workwhen doing such tests09:10
rburtoni'm confused as to why there's a x11-common-dbg09:10
fenrigrburton: you need any additional files?09:10
rburtonfenrig: no09:11
fenrigoh 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 BBB09:11
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has quit IRC09:11
*** c00kiemon5ter <c00kiemon5ter!~c00kiemon@foss-aueb/coder/c00kiemon5ter> has joined #yocto09:12
fenrigthe angstrom distro also is one version behind yocto, I think they still use dylan09:13
rburtonyeah, something like that09:13
rburtonreally need to sort the x init stuff out09:13
fenrigsupposse 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 #yocto09:15
rburtonfenrig: try bitbake -cclean xserver-common (that will remove it from your deploy/ too); then add BBMASK="meta-oe/recipes-graphics/xserver-common"09:16
rburtonand rebuild your image and sdk09:16
rburtonhopefully nothing explicitly depends on xserver-common09:16
rburtonthe alternative is to find out why x11-common-dbg exists at all, considering its empty.09:17
rburtonas that's not getting switched to xserver-common-dbg, which is where the problem is09:17
erborburton: 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
rburtondunno, i don't have a working meta-oe build right now09:20
fenrigrburton: okay I'll try that ;)09:20
fenrigIf you guys want I can supply my build dir, but it's quite large :/ so it can take a while to upload09:21
rburtonno its fine, quite large is probably quite an understatement :)09:22
rburtonand i can see how this can happen09:22
rburtonbluelightning: under what situations will a package with no files exist, apart from using ALLOW_EMPTY?09:22
rburtonbluelightning: x11-common just puts files into $PN, but -dev and -dbg are built (but empty). are those two always built?09:22
ant_workrburton: I have built Angstrom 2012.12 overnight. Note it's still branched on danny09:23
rburtondanny? old school.09:23
bluelightningrburton: those two are marked ALLOW_EMPTY I believe09:23
*** tor <tor!> has joined #yocto09:23
rburtonah, yes09:23
rburtonin bitbake.conf09:23
rburtonso, maybe we should set x11-common and xserver-common to have PACKAGES="$PN"09:24
rburtonwe *could* add more replaces/conflicts as erbo said, but removing the problem entirely would be another solution.09:24
ant_workwe have to remove one xserver-nodm-init09:25
ant_workthat's the Holy Grail09:25
rburtonthat too.09:25
JaMaflorian: can you apply those patches to xserver-common before they remove it completely? :)09:26
rburtonnever noticed xserver-common was so heavily patched09:27
ant_workrburton: ofc coordinate with JaMa ;)09:27
JaMarburton: it's in florian's queue since 12 Apr 201209:28
JaMaso the Upstream-Status should be "submitted"09:28
fenrigrburton: about the bbmask, do I add this one to my image recipe or ...?09:29
rburtonfenrig: i've a better idea now.  just add PACKAGES="${PN}" to both and
fenrigrburton: okay, great :D709:30
rburtoni suspect other bits of angstrom will want xserver-common, so masking it out may break something else09:30
rburtonfenrig: that's untested but might work nicely09:30
ant_workafaik it's just xserver-nodm-init09:30
rburtonJaMa: surely all the per-machine tweaking in xserver-common should be in the BSPs09:33
fenrigthis is the bsp I'm using so09:34
fenrigyou could check that out ;)09:34
fenrigrburton: I just started the populate_sdk process, let's hope for  success :D09:38
*** jackmitchell <jackmitchell!> has quit IRC09:38
rburtonfenrig: thanks for testing :)09:38
fenrigrburton: with pleasure, but you don't have to thank me. I should thank you guys ;)09:39
*** jackmitchell <jackmitchell!> has joined #yocto09:39
JaMarburton: whole point of upstream xserver-common is to support as many machines as possible09:40
ant_workbut this doesn't play well with the layer arch : supposedly the BSP customizes the xorg.conf and provides formfactor09:42
JaMaBSPs can upstream their customizations too09:46
fenrigrburton: I think it fixed the problem09:46
*** swex_ <swex_!~swex@> has joined #yocto09:46
*** swex <swex!~swex@> has quit IRC09:49
ant_workJaMa: as it is now, there are around many (deprecated ?) variables defining the same thing. MACHINE_GUI_, MACHINE_DISPLAY_ now even GUI_MACHINE_CLASS09:55
ant_workformfactor uses the DISPLAY_ set of vars for xserver09:56
*** sameo <sameo!samuel@nat/intel/x-hhjvsdagjwtuvdlp> has joined #yocto09:56
*** sameo <sameo!samuel@nat/intel/x-hhjvsdagjwtuvdlp> has quit IRC09:57
*** sameo <sameo!samuel@nat/intel/x-xrtthcwcenfiosqx> has joined #yocto09:57
*** jackmitchell <jackmitchell!> has quit IRC09:57
* ant_work notes this is a bit OT for #yocto, issues are mostly in meta-oe09:58
*** jackmitchell <jackmitchell!> has joined #yocto09:58
mshakeelHi JaMa, rburton, Can you please comment on Saul's reply here:
mshakeelare you guys working on anything related to this? Or should I try to handle this?10:00
JaMamshakeel: check this thread
JaMamshakeel: I agree that systemd.bbclass should be improved (like meta-systemd version was), but I'm not working on it10:02
rburtoni wasn't convinced at first, but the repetition is clearly showing it needs to happen centrally.10:04
*** zecke <zecke!> has quit IRC10:05
rburtoni can't recall exactly what the meta-systemd systemd.bbclass did but its clearly a good starting point10:05
rburtonmshakeel: 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!> has joined #yocto10: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
rburtonanyway 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
mshakeelrburton: ok, I will spend some time on it. Just wanted to make sure that you are not on it. thanks.10:08
JaMamshakeel: rburton: unlike meta-systemd class we can add variable which says which .service files should be autoinstalled10:08
rburtonJaMa: 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
JaMathat will resolve valid concerns about automagic issues we had with *-config10:09
* rburton really off now10:09
rburtonback in 30, apparently.10:09
fenrigrburton: have fun jogging, and thx for helping ;)10:10
*** ant__ <ant__!> has joined #yocto10:11
*** sameo_ <sameo_!~samuel@> has joined #yocto10:13
*** swex__ <swex__!~swex@> has joined #yocto10:14
*** jzhang1 <jzhang1!jzhang@nat/intel/x-vezbaqanyfyvskgs> has joined #yocto10:14
*** strassek <strassek!> has joined #yocto10:16
*** gmacario1 <gmacario1!> has quit IRC10:17
*** rogerzhou_ <rogerzhou_!~rogerzhou@> has joined #yocto10:17
*** jzhang <jzhang!~jzhang@> has quit IRC10:18
*** agust <agust!> has quit IRC10:18
*** sameo <sameo!samuel@nat/intel/x-xrtthcwcenfiosqx> has quit IRC10:18
*** swex_ <swex_!~swex@> has quit IRC10:18
*** ant_work <ant_work!> has quit IRC10:18
*** rogerzhou <rogerzhou!~rogerzhou@> has quit IRC10:18
*** sakoman <sakoman!> has quit IRC10:18
*** strassek_ <strassek_!> has quit IRC10:18
*** agust <agust!> has joined #yocto10:19
*** sakoman <sakoman!> has joined #yocto10:19
*** rogerzhou_ <rogerzhou_!~rogerzhou@> has quit IRC10:51
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto10:51
*** mulhern <mulhern!> has joined #yocto10:55
*** swex__ <swex__!~swex@> has quit IRC10:59
*** swex <swex!~swex@> has joined #yocto10:59
*** belen <belen!Adium@nat/intel/x-jcbaetbrbdlinaxm> has quit IRC11:02
*** ant__ is now known as ant_work11:03
*** ericben <ericben!> has quit IRC11:03
*** ericben <ericben!> has joined #yocto11:05
*** belen <belen!~Adium@> has joined #yocto11:10
romain_ It seems that the 'xserver-xorg-extension-dri' package isn't present in poky 9.0.0. How the can be installed?11:10
rburtonromain_: its built into the server11:15
rburton"noinst_LTLIBRARIES ="11:15
rburtonalso, see the log for xserver-xorg.inc11:15
rburton"    The following external modules are now built-in:11:16
rburton     * DBE11:16
rburton     * DRI211:16
rburton     * DRI11:16
rburton     * RECORD"11:16
thaytanrburton: all of sunray, to answer your question :)11:24
thaytanso I guess they won't be using Yocto after all :)11:25
rburtonthaytan: i suspected as much. ah well, the tech was neat.11:25
*** behanw <behanw!> has joined #yocto11:49
*** joeythesaint <joeythesaint!~jjm@> has joined #yocto11:52
romain_Ok thanks, it clears my doubts11:53
*** lpapp <lpapp!~lpapp@kde/lpapp> has left #yocto11:54
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto11:59
lpappis there any plan for a cmake class?11:59
*** jonatan__ <jonatan__!> has joined #yocto11:59
*** jonatan_ <jonatan_!> has quit IRC11:59
rburtonlpapp: there is a cmake class12:02
lpappok, so it is a documentation problem only.12:03
*** jonatan_ <jonatan_!> has joined #yocto12:03
*** jonatan__ <jonatan__!> has quit IRC12:04
lpappthere is also a qmake class, already?12:05
rburtonlpapp: have a look in meta/classes, that's easier than asking here12:06
lpappI do not have a clone right now.12:06
lpappalso, it is not entirely clear to me which meta-foo to check in general12:07
rburtonstart with oe-core12:07
rburtonthat's where the common ones all end up12:07
lpappok, there is no qbs class yet. :)12:08
rburtonis there actually anything releases that uses that yet?12:10
*** sameo_ <sameo_!~samuel@> has quit IRC12:10
lpappyes, of course.12:10
fenrigso I tried generating a sdk, with a lot of help op rburton it worked. But my SDK has to be able to compile Qt programs12:19
fenrigand I noticed I don't have a (native) qmake12:19
fenrigare there some special steps I have to follow?12:20
rburtoni thought qt-dev would recommend that, somehow12:20
fenrigrburton: what do you mean?12:21
rburtoni though it would get pulled in for you12:22
rburtonnot sure how to get extra bits into a sdk to be honest.  bluelightning?12:22
* rburton delegates because fenrig said "qt"12:22
fenrigI do have to point out that I used the meta-qt5 layer :)12:23
*** scot <scot!> has joined #yocto12:26
fenrigbluelightning: 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
fenrigrburton: yes I though so because he says "goodmorning" a hour or 2 later then when I start working, but I tried asking it politely12:33
fenrigso that when he returns he'll answer me ^^12:33
fenrigtoo bad there isn't much information about qt5 and yocto on the internet12:35
rburtonfenrig: for reference, me/bluelighting are in the UK, so it's lunchtime.  which explains why i'm hungry.12:36
fenrigoh 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
rburtonbelen: (is friday a themed lunch in the office?)12:36
rburtonfenrig: yes, of course we do :)12:37
fenrigand is there a way for a noob, like me, to start contributing in little stupid patches so that I could learn how the source works12:37
fenrigI have a fair bit of python experience :)12:37
rburtonthere's an open bug tracker12:38
rburtonif you're brave, there's an in-progress python3 port.12:38
belenrburton: (no. Should it be?)12:38
fenrigand I'm the cream of the crop programmer of our school (isn't really a good reference)12:38
rburtonif you actually want to work on bitbake then i'm certainly not the person to talk to. try kergoth/bluelighting.12:38
fenrigbut I'm a bit worried of the lean entry level :/12:38
fenrigor is it steep in english?12:39
rburtonbelen: well, burrito tuesday. fish and chips friday sounds like a good idea :)12:39
rburtonfenrig: steep12:39
belenrburton: ah, if that's what you mean, it might be Falafel Friday12:39
rburtonoh, now there's a reason to visit on a friday.12:40
belenrburton: you need a strong one to visit on fridays12:41
fenrigyou know what I'll create a bugzilla account, and when I finish this job I'm in ;-)12:43
lpapprburton: perhaps I can help with a qbs class file if it is not that hard to learn it...12:45
rburtonlpapp: writing a build system class is fairly simple as it's just the bits from the recipe, in a separate file12:48
*** tor <tor!> has quit IRC12:49
*** jmpdelos <jmpdelos!> has quit IRC12:57
ant_workrburton: [PATCH v3 0/1] xinput-calibrator: move it from meta-oe to oe-cor13:04
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-yzedatloardeilrd> has joined #yocto13:06
bluelightningfenrig: I'm back, but to be honest I'm probably not the best person to ask about qt513:06
fenrigbluelightning: and about qt in general?13:07
bluelightningfenrig: I can certainly try to help...13:07
fenrigbluelightning: that would be great :)13:07
fenrigbluelightning: so uhm I'm trying to incorperate qt5 into my sdk :)13:09
*** jmpdelos <jmpdelos!> has joined #yocto13:09
fenrigbluelightning: but as I understand I need qmake to support my version13:09
fenrigbluelightning: so this qmake needs to be able to cross compile or ...?13:09
fenrigI know qmake generates make and moc files for project, so it can support introspection :)13:10
bluelightningfenrig: 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
bluelightningI don't know what meta-qt5 does13:11
bluelightningfenrig: so did you manage to produce an SDK with bitbake -c populate_sysroot imagename ?13:11
fenrigbut qt4 is already an old version I presume?13:11
fenrigbluelightning: yes rburton made that possibe ;)13:11
erenok, I have ax25, kiss modules present in the kernel13:12
fenrigbluelightning: in fact I already executed the installer :)13:12
bluelightningfenrig: but it does not contain qmake and that's what you were asking about?13:12
erenthe package name is 'kernel-module-{ax25,mkiss}'13:12
fenrigbluelightning: yes indeed :)13:12
erenshould I add the package name as is, or is there another way to include a kernel module in the image?13:12
bluelightningfenrig: ok, I might be able to answer that, one sec13:12
erenbluelightning: you mentioned something like RDEPENDS?13:12
fenrigbluelightning: take your time ;)13:12
bluelightningeren: we always use RRECOMMENDS for kernel modules13:12
erenbluelightning: in which bb file?13:13
bluelightningeren: in case the user wants to build them into the kernel rather than being built as modules13:13
erenRRECOMMENDS = 'kernel-module-ax25 kernel-module-mkiss', then?13:13
*** walters <walters!> has joined #yocto13:13
bluelightningeren: RRECOMMENDS_${PN} += "..."13:13
bluelightningeren: RRECOMMENDS like all runtime package variables need to be qualified with the name of the package to add the relationship to13:13
bluelightningin this case the main package (${PN})13:14
erenthen I will add it in libax25 package13:14
*** melonipoika <melonipoika!> has quit IRC13:15
*** sameo <sameo!samuel@nat/intel/x-gbhhcwtjtzetlotv> has joined #yocto13:16
bluelightningfenrig: so unfortunately it looks like nobody has added nativesdk support to meta-qt5 yet13:17
fenrigbluelightning: so I should revert back to qt4?13:17
fenrigbluelightning: or try to add nativesdk support?13:17
bluelightningfenrig: it depends how much work you want to do :)13:18
bluelightningit's possible someone else is planning on adding nativesdk to meta-qt5, I don't know what everyone's plans are13:18
bluelightningJaMa: any ideas?13:18
fenrigbluelightning: Well unfornately it's not mine to decide, so I have to ask my boss13:18
fenrigbluelightning: how long do you think it could take me?13:19
fenrigbluelightning: a day? a week?13:19
ant_workcouple of nights ;)13:19
*** AlexG <AlexG!c0c6972b@gateway/web/freenode/ip.> has quit IRC13:20
bluelightningfenrig: I would think at least a week to get it working fully unless you already have experience with qt / OE13:20
fenrigant_work: okay :D thx for the help13:20
ant_workcheck qt3 layer and qt4 in oe-core13:20
ant_workyou'll see the missing recipe13:20
fenrigbluelightning: 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!> has quit IRC13:24
*** munch <munch!> has joined #yocto13:26
*** levi <levi!> has quit IRC13:26
*** thaytan <thaytan!> has joined #yocto13:28
fenrigand we've opted to go to qt413:30
fenrigbluelightning: thx for your help ;)13:31
bluelightningfenrig: np13:31
fenrigdoes anybody know by chance which packages I have to provide to image_install?13:31
JaMafenrig: few people asked about sdk support but nobody sent patches yet13:31
fenrigJaMa: I think Qt is pretty popular framework13:32
JaMafenrig: qt5 is sometimes quite tricky, so a week for SDK is a minimum13:32
fenrigI wonder how they do it with ubuntu-touch13:32
fenrigand tizen13:32
JaMafenrig: yes it is, that's why I maintain meta-qt5 :)13:33
fenrigthey probably have their own buid system13:33
erenJaMa: nice commits on llvm, btw.13:33
*** tinti_ <tinti_!> has joined #yocto13:33
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has joined #yocto13:33
JaMabut 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!> has quit IRC13:33
JaMaeren: except the last one with zlib.. that sliped into master branch accidentally :/13:34
fenrigJaMa: I learned to work with Qt a few months ago, and I immediatly felt why people loved it so :)13:34
erenJaMa: ah, it can happen all the time :)13:34
*** mulhern <mulhern!> has joined #yocto13:36
bluelightningfenrig: 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
fenrigoh yeah to uninstall the installed sdk should I just remove the dir /usr/lib/oecore-i68613:37
bluelightningfenrig: then if you do bitbake -c populate_sdk imagename for your image you'll get a complete Qt4 SDK13:37
bluelightningfenrig: yep you can just delete it, no special uninstall needed13:37
fenrigbluelightning: yeah but my image does has to support Qt413:38
bluelightningfenrig: right, for that you should just add your application to the image13:38
fenrigbluelightning: I'm so sorry for my english :o13:38
bluelightningfenrig: required Qt libraries will be pulled in automatically via dependencies13:38
erenbtw, which package puts bzImage to $DEPLOY_DIR?13:38
bluelightningeren: the kernel13:39
fenrigbluelightning: 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 speak13:39
bluelightningeren: i.e. linux-yocto in the default configuration, might be different depending on the BSP13:39
erenbluelightning: okkie, thanks13:39
bluelightningeren: most of the magic is in kernel*.bbclass though13:40
bluelightningfenrig: ok, if you just want to try you could build any image and add "qt4-pkgs" to IMAGE_FEATURES13:41
fenrigbluelightning: okay cool ;)13:41
fenrigoh yeah I don't know if I have to ask it here but, I'd like to run myt13:42
fenrigQt application dedicated in the Xorg13:42
fenriggot any pointers on that13:42
fenrigor do you guys have no experience with that (I know I'm asking a lot)13:42
fenrigyou know what, I'll try to find that out myself, sorry for asking13:42
bluelightningwell, if you're building qt4-x11-free (which qt4-pkgs will pull in) then that will be Qt for X1113:42
bluelightningfor your application recipe just ensure you add "inherit qt4x11" and it'll get the appropriate dependencies13:43
fenrigbluelightning: yes that I already understand, but I'll have to figure out how to run that application like a DE :)13:43
bluelightningfenrig: this might be useful:
bluelightningfenrig: 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 session13:44
bluelightningnothing like a full desktop environment but OK for single apps13:44
fenrigbluelightning: great :)13:46
*** mihai <mihai!~mihai@> has quit IRC14:02
*** ericben <ericben!> has quit IRC14:04
*** ericben <ericben!> has joined #yocto14:05
*** mihai <mihai!~mihai@> has joined #yocto14:06
*** jackmitchell <jackmitchell!> has quit IRC14:07
rtollertI 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 #yocto14: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_away14: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
frayrtollert: there are actually three cross compilers..  "host" -> target  (gcc-cross)14:17
fraygcc-crosssdk  "host" to "nativesdk"14:17
fraygcc-cross-canadian "nativesdk" -> target14:17
rtollertfray: right, I got that far14:17
JaMartollert: there aren't gcc-native recipes, your host needs to provide sane gcc14:17
frayyup, thats what i was just abut to get to..14:17
fraythe host is expected to work "properly", well enought to be able to build functional software to run on that same host..14:18
bluelightningWIP section in the manual covering this stuff, btw:
bluelightning(feedback to Scott if there are any changes needed)14:18
rtollertfray 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 it14:19
frayew have impericle evidence that we can correctly rebuild the cross compilers... until someone shows up bugs otherwise, we believe its working..14:20
frayempirical even14:21
fraybasically 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
frayother then path name and some embedded timestamps, the generated objects are the same14:21
*** b46258 <b46258!> has joined #yocto14:21
fray(last time I ran that test was the 4.7 toolchain BTW)  4.8 is still too new14:21
*** eballetbo <eballetbo!> has quit IRC14: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
bluelightningwe had some pain building 4.7 with 4.8, that got fixed... but 4.8 has had quite a number of problems anyway14:24
rtollertyeah I was about to mention the 4.7/4.8 pain; I run Arch, so that bit me14:24
rtollert... but, that would have bit me anyway if we built a gcc-native of 4.714:25
fraywe're regularly building on hosts as old as CentOS/RHEL 5.9.. and as new as Fedora 19...14:25
rtollertright. 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
frayya, it was a definite problem in the past, but it's gotten so much better in the last few years..14:27
JaMaI thing there are still issues when someone with external-tc with older gcc tries to build newer gcc-runtime (or gcc) from oe-core14:28
rtollertyeah, I remember the bad old days. (occasionally I still live them.) the gcc devs are doing a bangup job14:29
rtollertJaMa: 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@> has quit IRC14:31
rtollertbluelightning: 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
fraythe normal mechanism is the csl stuff..14:32
rtollertthanks for the answers so far btw14:32
fraybut you could use it to introduce the crosstool, but it has to be modified14:32
JaMartollert: we're using external-tf for crosstool-ng created tc14: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@> has joined #yocto14:33
JaMartollert: you can also use external-linaro-toolchain for linaro binary toolchains which are created with ctng14:34
bluelightningrtollert: 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
frayya, the arm issue was a kernel issue in the end..14:34
frayI'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
rtollertJaMa: s/external-tf/external-tc/?14:35
*** agust <agust!> has quit IRC14:35
bluelightningfray: I think so, I've not been closely involved with it but we had build failures with meta-fsl-ppc14:35
bluelightningon the autobuilder, that is14:36
frayI think that's the e500...14:36
rtollertfray bluelightning: interesting. So y'all have somewhat less confidence of 4.8's stability wrt 4.714:36
bluelightningrtollert: well, it's been a little bit rocky so far for sure... hopefully the issues have been ironed out14: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 dropping14:37
frayperformance for some targets is significantly better though.. (at least in my opinion, I don't have any numbers to back that up)14:37
rtollertfray: building gcc svn?14:37
fraythe one in oe-core master14:37
fraywe're just starting to use the pre-release eglibc 2.18 as well..14:38
JaMartollert: y14:39
*** challinan_ <challinan_!> has quit IRC14:39
fenrighhmm got a new problem14:42
*** smartin_ <smartin_!> has joined #yocto14:42
fenrigapparently the gpu drivers of the BBB get compiled14:42
fenrigand it fails :/ due to compilation errors14:43
rburtonfenrig: pastebin the error14:43
fenrigI 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!> has quit IRC14:43
fenrigrburton: will do, wait a sec ;)14:43
*** challinan <challinan!> has joined #yocto14:44
rburtonfenrig: you'll be better trying #beagle or whatever the meta-ti/beagle support channel is14:45
fenrigrburton: yeah probably, but my working day is almost over so14:47
*** hollisb <hollisb!> has joined #yocto14:47
fenrigrburton: 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
rtollertcouple 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
rtollert2) 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
rburtonrtollert: 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
rburtonrtollert: 2) yes. there was discussion about that sort of thing here a few days ago.14:49
rburtonrtollert: re (1), the tool used to make poky is combo-layer. in oe-core's scripts repo.14:49
rtollertrburton: 2) OK, I'll add my docs to the wiki14:49
rtollertrburton: 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
rburtonrtollert: 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
rtollertrburton: excellent, thanks14:52
rburtonrtollert: that's why meta-yocto has some bbappends14:52
*** fenrig <fenrig!55eac3e5@gateway/web/freenode/ip.> has quit IRC14:54
rtollertrburton: 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
rburtonrtollert: yeah, poky is a merged repo from its parents, as you'll see from the log its got bitbake/oe-core/etc commits interleaved14:56
rtollertheh... I'm registering for a new acct on, and the Terms of Service link is a 404. Who ought to know about that?14:57
rburtonhalstead i guess14:57
rtollerthalstead: consider yourself knowing about that14:58
*** doerrpau <doerrpau!> has joined #yocto14:58
*** romain_ <romain_!d96c30f9@gateway/web/freenode/ip.> has quit IRC14:59
*** andyross <andyross!> has joined #yocto15:01
*** lpapp <lpapp!~lpapp@kde/lpapp> has joined #yocto15:02
*** Squix <Squix!> has quit IRC15:02
lpappis anyone working on a similar tool as hob, but with qt/qml?15:02
*** Squix <Squix!> has joined #yocto15:03
rburtonlpapp: no15:03
rburtonlpapp: there is a web-based hob in active development though15:03
*** jmpdelos <jmpdelos!> has quit IRC15:03
lpapprburton: ok, I would prefer qt/qml.15:03
rburtonyou can wait for webhob if gtk+ bothers you that much :)15:04
lpappwell, I do not like web stuff either.15:05
*** Stygia <Stygia!> has joined #yocto15:06
lpappI guess there is nothing against someone contributing a qt frontend? :)15:07
rburtonif you feel motivated enough to write a third UI to bitbake, go for it15:07
*** zeeblex <zeeblex!~apalalax@> has left #yocto15:07
halsteadrtollert, rburton I've added a link to our main terms of service for now.15:07
*** jmpdelos <jmpdelos!> has joined #yocto15:08
lpapprburton: sure, I guess the problem would be to find reviewers.15:10
StygiaHeya. 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: . 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 ot15:11
Stygiaher folders such as /etc/movis/ affected by tihs, when they are created with the same syntax? Kind regards.15:11
lpappwasn't that actually a hard disk related analyzing software initially?15:11
kergothPACKAGES 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 that15:12
bluelightninglpapp: Smart vs SMART I guess15:12
rburtonwikipedia insists the disk one is S.M.A.R.T.15:12
*** Crofton|work <Crofton|work!> has quit IRC15:12
bluelightningrburton: honestly I don't think I would ever bother with the dots :)15:13
rburtonlpapp: nothing to stop it being out of tree i guess15:13
*** Crofton <Crofton!> has quit IRC15:13
rburtonbluelightning: me neither, but someone must have insisted for the dots to be there15:13
lpapprburton: bluelightning extra/smartmontools 6.1-3 Control and monitor S.M.A.R.T. enabled ATA and SCSI Hard Drives15:13
lpappextra/libatasmart 0.19-2 [installed] ATA S.M.A.R.T. Reading and Parsing Library15:13
lpapp-> /usr/bin/smartd, etc15:14
lpappit is going to be a bit confusing. :)15:14
lpapp-> /usr/bin/smartctl15:14
bluelightningwe didn't pick the name, it's an external tool we re-used...15:14
lpappyeah, I know.15:14
Stygiakergoth, 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
lpappusually when I started a project back then, I looked for existing names.15:14
bluelightningI do find myself having to explain what it is a lot when mentioning it since it's not well known15:15
bluelightninga more unique name might have helped there I guess15:15
*** jkridner <jkridner!~jkridner@nat/ti/x-vmhsewnqzgsvterw> has joined #yocto15:16
*** jkridner <jkridner!~jkridner@pdpc/supporter/active/jkridner> has joined #yocto15:16
ndecStygia: yes, indeed. i send a detailed email on the list yesterday that would help you understand, i guess.15:16
Stygiandec, Ah, unfortunately I am not subscribed to the list. Thanks anyway.15:16
ndecok, let me find the archive15:17
lpappbluelightning: I still need to learn why it is better than existing package managers.15:17
lpappI think the learning curve is pretty steep for Yocto. :)15:17
rburtonStygia: for correctness, use ${libdir} and ${sysconfdir} instead of /usr/lib and /etc15:18
Stygiarburton, Noted.15:19
Stygiandec, Thanks, bookmarked.15:19
rburtonStygia: tl;dr: $libdir/ isn't in FILES by default, so you'll need to add it15:19
Stygiarburton, Hmm, without appending ${D} in FILES, yes?15:20
rburtonStygia: correct, files is target paths, not paths in the build system15:20
Stygiarburton, Alright, thanks.15:20
rburtonso FILES_${PN} += "${libdir}/perl" will do15:20
Stygiarburton, Hmm, no need to specify subfolders and files?15:21
lpapprburton: can you give me an url to the thread about the gerrit discussion?15:21
rburtonlpapp: sorry, no15:21
rburtonStygia: it will recurse down for you15:22
lpapprburton: it exists?15:22
rburtonlpapp: no idea15:22
rburtonlpapp: may have been on irc, or in person at one of many conferences.15:22
Stygiarburton, Thanks.15:23
*** davest <davest!Adium@nat/intel/x-uzremjzumkclkjoo> has joined #yocto15:23
lpapprburton: then it does not exist, so time to bring it up on the mailing list again. :)15:23
lpappotherwise, no one will bother to actually document the decision, etc.15:23
rburtonlpapp: it's really not.  OE/yocto is explicitly patch-review-by-mail.15:23
rburtonyou might as well mail lkml and propose gerrit15:23
rburtonbecause that's the choice that's was made and re-agreed several times over many years15:24
ndecbecause it might help them too. who knows?15:24
lpappok, so bitbake is written in python just like portage.15:24
rburtonlpapp: bitbake and portage share a common root15:25
lpapprburton: well, new ideas are not to be rejected just by the sake of rejecting15:25
lpappif gerrit had been rejected for valid reasons, it needs to be documented for others.15:25
ndeclpapp: i think rburton means that it's not a new idea, as it's been evaluated already.15:25
lpappso it can be reviewed, others can work on missing features, et cetera.15:25
lpappndec: all I am saying, nothing like that fundamental for the workflow should be hidden.15:26
lpappwhatever happened.15:26
lpappdecisions should happen openly, not just the source code ... ;-)15:26
bluelightninglpapp: most of the rationale for using Smart is here FYI:
*** sameo <sameo!samuel@nat/intel/x-gbhhcwtjtzetlotv> has quit IRC15:27
rburtonlpapp: the biggest reason is that yocto/oe is review-by-mail, and gerrit doesn't let you do that15:27
lpapprburton: well, it cannot be review-by-mail just for the sake of review-by-mail15:27
lpappit is not a technical discussion. :)15:27
lpappbluelightning: thanks.15:28
rburtonit cannot be gerrit just for the sake of gerrit.  it's a choice.15:28
bluelightninglpapp: it's really down to what the maintainers are comfortable with, since they have to interact with the process the most15:28
bluelightning(re patch reviewing)15:28
*** mulhern <mulhern!> has quit IRC15:28
*** tomz <tomz!> has joined #yocto15:28
*** mulhern <mulhern!> has joined #yocto15:29
lpapprburton: sure, but gerrit has advantages over email.15:29
lpappbluelightning: sure, but they probably have a /technical/ reasoning as well.15:30
lpappnot just the end result.15:30
*** icanicant <icanicant!~klawson@> has quit IRC15:30
*** levi <levi!> has joined #yocto15:30
*** Squix <Squix!> has quit IRC15:31
*** Guest15299 <Guest15299!~tbn@> has quit IRC15:31
lpappiow, I am personally interested why they prefer email.15:32
fraybecause 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
bluelightninglpapp: I know Richard has said he finds email works for him because he can easily work on it offline15:33
fraygit is designed to interact directly with email lists.. (using git send-email as well as git am for applying), etc..15:33
frayoffline reading (and responding/processing) is yet another reason (as bluelightning indicated)15:33
lpappfray: how do you review something without opening an email client up?15:34
Stygiarburton, kergoth, thanks to both of you, finally made this thing install properly.15:34
Stygiabluelightning, FYI, first build with all 80-ish modules where nothing segfaulted or complained about missing stuff....15:35
*** icanicant <icanicant!~klawson@> has joined #yocto15:35
rburtonStygia: nice :)15:35
Stygiarburton, Quite.15:35
lpappbluelightning: yeah, gerrit has not added such a feature because it is rare nowadays not be online, I guess.15:36
Stygiarburton, 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
rburtonStygia: ha!15:36
rburtonlpapp: 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
lpappbluelightning: although, it would be probably simple enough to send the diff in an email, not just the commit message.15:36
lpapprburton: well, flights are usually 2-3 hours inside europe.15:37
lpappif you travel between continents frequently, then ok.15:37
lpappbut even inside the country, buses and trains usually provide wifi nowadays15:37
fraylpapp, 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 email15:37
lpappand I can always use my mobile data plan.15:37
bluelightningStygia: FYI, a new layer was published yesterday contianing a few additional perl recipes for supporting other recipes -
lpappfray: the point is that, it is not an advantage apart from offline reading.15:38
frayits a workflow advantage..15:38
lpappfray: because it is just yet another window/tab like the web interface.15:38
frayI 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
lpappso you do not spare window/tab in that sense if you are online. :)15:38
rburtoncan we please stop discussing the personal workflow of people who are not here15:38
fraysome people in oe use patchwork, but thats about the extent of the tooling15:39
lpappbut the email client *is* a tool.15:39
bluelightningStygia: 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 yet15:39
*** andyross <andyross!> has quit IRC15:39
bluelightningStygia: not sure if either of those overlap with the recipes you've been working on15:39
* fray yields as this is a personal preference and not something worth arguing..15:39
*** andyross <andyross!> has joined #yocto15:39
lpappfray: actually, I do not think certain feature lacks are personal preference. :)15:39
lpapplike, how you group patches?15:40
lpapphow can you add reviewers anyone registered easily?15:40
frayemail threads... and reviwers are anyone who subscribes to the mailing list15:40
frayor you email your patch to15:40
lpapphow do you know who subscribed for?15:41
* fray goes back to work.. I'm not going to argue this15:41
lpappon gerrit, you start typing a name and it is there.15:41
bluelightninglpapp: 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 easily15:41
lpappregardless whether you interacted with that person before.15:41
lpappalso, how do you group changes with email?15:41
lpappstable, master, next, different repositories, based on reviewers, authors, etc.15:41
lpappit is getting tricky with a dedicated interface.15:41
* rburton too15:42
lpappbluelightning: grouping, but not in that sense as you seem to have understood.15:42
lpapphow can you check only file in a diff with email?15:43
lpappemail was not meant like for such nice code review specific features.15:43
lpappmeant for*\15:43
Stygiabluelightning, At a glance, neither do.15:43
lpappbluelightning: email is a generic interface, and certain review specific features cannot be present that way.15:44
Stygiabluelightning, Will have a look at what you published though.15:44
Stygiabluelightning, And thanks for your help so far, you've really been invaluable.15:45
lpappbluelightning: I think email was okay until someone put some significant effort to have a dedicated tool specialized for codereview features.15:45
*** Stygia <Stygia!> has quit IRC15:45
lpappbluelightning: and repeating for the record, adding a diff sending is probably an easy feature to add.15:46
lpappbecause the commit header is already sent via email.15:46
lpappI just think it was not high priority due to the available internet connection almost everywhere nowadays.15:46
* ant_work notices our similarity with
bluelightninglpapp: 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 that15:48
bluelightninglpapp: if we were to use an additional tool it would have to integrate with email and not impose the use of that tool on maintainers15:48
bluelightninghence, the patchwork tool is about the closest thing there is, although it needs some tweaking15:49
*** blitz00 <blitz00!stefans@nat/intel/x-yrenqmsimkcebjwp> has joined #yocto15:49
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has joined #yocto15:49
*** zenlinux <zenlinux!> has joined #yocto15:49
lpappbluelightning: well, it would not be the first time people start using new tools.15:50
lpappgetting used to something is not equivalent automatically to the best tool available. :)15:50
lpappif the only thing the maintainers say, they do not wanna change, that is ok, but that is not technical.15:50
lpapptechnology always improves. :)15:51
*** ant_work <ant_work!> has quit IRC15:51
bluelightningno, this is mostly not a technical decision I agree, it's how maintainers have established their workflow15:51
lpappif you try to achieve the things I mentioned above, it might be realized, those are not so handy with emails.15:51
bluelightningand you have to have a pretty compelling technical solution that covers the existing use cases to address that15:52
bluelightningany tool that lacks easy offline usage is not going to be workable15:52
lpappit is, for me at least, like when people got used to svn which was not meant for merging at large.15:53
lpappyeah, 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!> has joined #yocto15:53
*** mitz <mitz!> has quit IRC15:53
bluelightningthere'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 split15:53
lpappbluelightning: I still think that, that is a minority of the maintainers most probably. :)15:53
lpappbut yes, that is an easy fix IMO.15:54
lpappI will be travelling 3000 km tonight to a conference, and I will be covered by internet most of the time.15:54
lpappbluelightning: I agree, and that is why I think a mixed solution would be worse than now.15:55
bluelightningthe only big issue with the current system is that it's hard to get a view on the outstanding patches15:56
bluelightninghaving patchwork should solve that15:56
lpappwell, you would have a mixed interface15:57
lpappinstead of gerrit, where you can do everything in one place.15:57
lpappincluding outstanding, but even abandoned ones.15:57
bluelightningexcept gerrit won't be the place for non-patch discussions15:57
bluelightningso, two places15:57
bluelightning(that's what I meant above)15:58
*** darknighte_znc is now known as darknighte15:58
*** mulhern <mulhern!> has quit IRC15:59
lpappbluelightning: actually it can be sometimes.15:59
lpappbut yeah, mailing list would be necessary, or irc, or something else.15:59
lpappbluelightning: but you would probably have two places in your email client for those two as well, I gues.15:59
lpapppatch and discussions folder.16:00
bluelightningactually I don't... I could, but I find it easy enough to navigate with one folder for each mailing list16:00
lpappand 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
lpappthe problem is that, you would be spammed by a lot of changes.16:00
lpappbut patchwork would not be an email solution either, anyhow?16:01
*** slaine <slaine!~slaine@> has quit IRC16:03
*** tonghuix <tonghuix!~tonghuix@> has joined #yocto16:04
bluelightningpatchwork pretty much revolves around email - it picks up patches from emails and attaches threaded discussions to them16:04
*** mulhern <mulhern!> has joined #yocto16:04
lpappso, it is a web, and not email client.16:05
lpappjust like gerrit is, so you would not introduce more separated parts altogether.16:05
lpappok, anyway, fair enough.16:05
Crofton|worklpapp, we have had these conversations many times over the years16:06
Crofton|workand what we have know works well for the project16:06
lpappCrofton|work: so what? I am a newcomer, and I have not been to those discussions.16:07
lpappand I am not sure if experts had been there either.16:08
lpappso a newcomer rightfully asks these questions IMHO.16:08
rburtonlpapp: OE is ~ten years old, so yes, this has been discussed before16:09
lpappin fact, I suggested to document those for your future convenience, in the very first place.16:09
bluelightninglpapp: 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 us16:09
lpapprburton: I know 20 years old projects where it has not been discussed.16:09
lpappbluelightning: how do you know you looked at the process right, and a newcomer cannot open up new things?16:09
lpappit is not something "done"16:09
lpapptechnology is continously improving and advancing, changing, et cetera.16:10
lpappanyway, 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
lpappimho, 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
lpappit is rude*16:11
lpappespecially when the whole stuff is well hidden completely as it seems ...16:12
bluelightninglpapp: I wouldn't view it like that16:13
bluelightninglpapp: we're just saying it has come up16:13
lpappbluelightning: if you read back, it has been said that "we discussed it, so let us stop it".16:13
bluelightninglpapp: the trouble is the biggest impact is on the maintainers rather than other community members, and those are the people who have to be convinced16:14
lpappbluelightning: 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!> has quit IRC16:16
*** levi <levi!> has joined #yocto16:16
lpappbluelightning: believe it or not, for my contribution, it is a serious concern.16:16
*** zenlinux <zenlinux!> has quit IRC16:16
lpappso it is good to understand why I take sacrifice if I happen to do.16:16
*** zenlinux <zenlinux!> has joined #yocto16:16
bluelightninglpapp: except we are pretty transparent, all discussions and patch review happens in the open on the mailing list16:20
lpappbluelightning: I am referring to the "gerrit decision".16:22
bluelightninglpapp: I'm not saying we shouldn't document that, we probably should16:22
*** ericben <ericben!> has quit IRC16:25
*** ka6sox is now known as zz_ka6sox16:25
*** zz_ka6sox is now known as ka6sox16:25
bluelightningit might be a little bit over the top to say we have "total hidden untransparency" just because we haven't documented that16:25
*** mr_science <mr_science!> has joined #yocto16:26
*** mr_science <mr_science!~sarnold@gentoo/developer/nerdboy> has joined #yocto16:26
lpappwell, nothing is documented so it is fully hidden as of now. :)16:27
*** mulhern <mulhern!> has quit IRC16:30
*** andyross <andyross!> has quit IRC16:34
*** andyross <andyross!> has joined #yocto16:35
*** ka6sox is now known as zz_ka6sox16:35
*** blitz00 <blitz00!stefans@unaffiliated/blitz00> has quit IRC16:35
*** andyross <andyross!> has quit IRC16:36
*** andyross <andyross!> has joined #yocto16:37
*** seebs_ <seebs_!> has joined #yocto16:41
lpapp -> so virtualbox is not tested?16:42
*** eren` <eren`!~eren@unaffiliated/eren> has joined #yocto16:42
lpappwhat 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_!> has quit IRC16:44
*** jonatan__ <jonatan__!> has joined #yocto16:44
lpappqt4e-demo-image -> do you plan to have a qt5 variant?16:44
*** mihai <mihai!~mihai@> has quit IRC16:45
*** eren` <eren`!~eren@unaffiliated/eren> has quit IRC16:45
sgw1lpapp: there is a qt5 layer available, just not in core yet: git://
lpappwould it be in core for the next release?16:50
*** tomz <tomz!> has quit IRC16:50
*** jonatan_ <jonatan_!> has quit IRC16:50
*** eren <eren!~eren@unaffiliated/eren> has quit IRC16:50
*** silviof <silviof!> has quit IRC16:51
*** seebs <seebs!> has quit IRC16:51
*** fray <fray!> has quit IRC16:51
*** yzhao2 <yzhao2!~yzhao2@> has quit IRC16: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
kergothpostinst script, most likely16:52
lpappis there ubifs support in Yocto?16:52
sgw1lpapp: likely not for 1.5, which is the current planned release for Oct timeframe16:55
sgw1lpapp: ^^^ was in reference to qt516:56
lpappsgw1: :(16:57
lpappqt5 was released in december.16:57
*** silviof <silviof!> has joined #yocto16:57
lpappit would be a pitty to wait more than a year for it to appear in Yocto16:57
sgw1lpapp: that's what the layers are for, its trivial to add it16:57
*** tomz <tomz!> has joined #yocto16:58
lpappsgw1: yeah, but it is not nice if many people add it, instead of one centralized place...16:58
lpappwhat can I do to help with getting this into the release in October?16:59
sgw1lpapp: we don't keep everything in oe-core, it will be something to look at for future releaes16:59
*** Umeaboy <Umeaboy!> has quit IRC16:59
*** yzhao2 <yzhao2!~yzhao2@> has joined #yocto17:00
sgw1lpapp: BTW, ubifs is supported in yocto via the mtd-utils package and you can create a ubifs image.17:00
lpappsgw1: we have three months until that release.17:01
*** florian <florian!~fuchs@Maemo/community/contributor/florian> has quit IRC17:01
lpappand this feature cannot get in, even if it gets help from an upstream developer?17:01
*** zeddii_home_ <zeddii_home_!> has joined #yocto17:01
*** fray <fray!> has joined #yocto17:02
sgw1lpapp: we have layers to help support upstream development when something is not yet in the core. Those layers are maintained also.17:03
lpappsgw1: you claimed that it would not be released any soon17:04
lpappend users need releases.17:04
*** honschu <honschu!> has joined #yocto17:06
*** honschu <honschu!~honschu@shackspace/j4fun> has joined #yocto17:06
*** Crofton <Crofton!> has joined #yocto17:06
*** honschu_ <honschu_!~honschu@shackspace/j4fun> has quit IRC17:08
sgw1lpapp: 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 qt517:10
lpappqt 5.0 has been released for more than half a year go17:11
lpappand now we got even a new feature release, 5.117:11
lpappif it is not getting released this year, Yocto will cause additional pain to qt5 developers.17:11
bluelightninglpapp: we have the layer structure to allow additional items to be added easily17:12
lpappbut why would they add that "easily"?17:12
bluelightninglpapp: we haven't had the resources to work on qt5, but luckily Martin and co have been able to do so in meta-qt517:13
lpappwhen it can be solved centrally?17:13
lpappI 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
lpappI 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!> has joined #yocto17:15
bluelightninglpapp: some features are missing, such as SDK generation17:16
*** tonghuix <tonghuix!~tonghuix@> has quit IRC17: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
lpappsure, I would be happy to help qt5 going on.17:17
lpappfeel free to distribute tasks to me. :)17:18
lpappthat is what I offered before.17:19
pev_bluelightning: Have you ever modified conf files from a do_install() function?17:19
lpappso I am wondering why it would not be stable enough to get in, with my help by October?17:19
bluelightninglpapp: 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 perhaps17:21
bluelightningpev_: sure, using sed I have yes17:21
Croftonlpapp, the planning for the next release has already been done17:21
Croftonqt5 would be fairly major update17:22
Croftonand by the next cycle we should have a fairly well tested qt5 in the meat-qt517: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
sgw1pev_: If your modifing another packages conf files you would need to do a postinst as kergoth suggested before17:23
lpappCrofton: well, qt4 should not be killed.17:23
lpappso I do not see the risk respectively.17:23
lpappat any rate, are there tasks for that work on the issue tracker?17:23
bluelightningpev_: 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_install17:23
Croftonit is vary acceptable to use layers17:23
Croftonwe want to keep the core layer very focused and not start moving more and more in over time17:24
bluelightningpev_: 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
lpappCrofton: as I said, qt5 was released relatively long ago17:24
lpappand we have 5.1 as well now.17:25
lpappit is a valid expectation not to make qt5 users' life hard.17:25
lpappmore difficult than it could be, that is.17:25
Croftonadding meta-qt5 should not make your life hard17:25
bluelightninglpapp: that is correct, it's just that the majority of users we have are still working with apps that build on top of qt417:25
lpappand qt5 and qt4 should exist simultaneously.17:25
lpappfor a few years.17:25
bluelightninglpapp: but luckily, the community as a whole hasn't ignored qt5, we have a layer to support it already17:25
lpappbluelightning: new developers will not pick up qt4 at all.17:26
lpappand there are already several big projects built around qt5.17:26
pev_sgwl: is that using "pkg_postinst_${PN} () {"  - only refs I can see17:26
bluelightninglpapp: I'm not in any way suggesting qt5 isn't important17:26
bluelightninglpapp: with the resources we have we just have to pick the stuff we can to work on17:27
sgw1pev_: yes that would be the construct17: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 that17:27
lpappbluelightning: well, I would be a resource for qt5.17:28
lpappthe reasoning accordingly can be void. :)17:28
bluelightningpev_: right, it depends on the nature of the changes being made17:28
bluelightninglpapp: great!17:28
lpappmay I ask for concrete tasks again?17:29
bluelightninglpapp: beyond adding support for building nativesdk (for SDKs) I'm not sure what needs doing17: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
bluelightninglpapp: but really this is a case where someone such as yourself with Qt5 experience can help identify anything that might be missing17:30
lpappbluelightning: "building nativesdk (for SDKs)" -> not sure that is a show stopper.17:31
lpappI imagine Yocto would be more useful for embedded at this stage.17:31
*** doerrpau <doerrpau!> has quit IRC17:32
bluelightninglpapp: it is for us, people expect to have externally usable SDKs containing the tools that they can run outside of the build process17:32
bluelightninglpapp: 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 directly17:33
*** belen <belen!~Adium@> has quit IRC17:33
lpappbluelightning: not sure I follow.17:33
lpappbluelightning: wouldn't the SDK mean qtcreator, documentation, assistant, designer, and all that?17:33
lpappbluelightning: that is not used when shipping an embedded system.17:34
lpappthey might be used on the host PC with affected distributions.17:34
bluelightninglpapp: it's not for shipping, it's for when applications are being developed17:34
bluelightninglpapp: I'm more thinking of qmake/moc/etc. rather than QtCreator etc.17:35
*** everlook <everlook!> has joined #yocto17:35
bluelightninglpapp: 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 well17:36
lpappbluelightning: those tools should come with qt5-core17:36
bluelightninglpapp: yes, they do... but the recipes we have currently can only build those for native (host) and the target, not for SDKs17:37
lpappbluelightning: that is enough.17:37
lpappif you supply mkspecs files, those can cross-compile.17:37
bluelightningin our system, SDKMACHINE i.e. the machine the SDK is intended to run on is not necessarily the same as the host17:39
bluelightningyes, mkspecs are part of the target portion of the SDK, those aren't a problem17:39
lpappsure, it is the matter of using the right mkspecs file.17:39
lpappfor applications17:39
lpappfor 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 it17:39
bluelightningpev_: 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 target17:41
pev_Ok, thanks. So for convenience prototype my changes under do_install then move to postinstall once working correctly?17:42
lpappI guess I do not yet understand what goes into bsp.17:43
bluelightningpev_: I'm assuming so... I'm still not totally sure I understand what you're trying to do though17:43
bluelightninglpapp: everything that's specific to the machine supported by the BSP17:43
lpappI see regular userspace linux utils in there alongside u-boot, grub, and so forth.17:43
lpappbluelightning: which BSP?17:43
bluelightninglpapp: I'm speaking generally for any BSP17:44
bluelightninglpapp: which one are you looking at?17:44
lpappwe 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
bluelightningpev_: ah right, now I get it17:45
pev_bluelightning: Should be easy eh? :-D17:45
lpappbut how is keymaps for instance BSP related?17:45
lpappinstead of say... corE?17:45
bluelightningpev_: 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 recipe17:45
bluelightninglpapp: that's typically where there is a custom keymap for the specific machine17:46
bluelightninglpapp: usually it's done as a bbappend so it's modifying the existing keymaps recipe17: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 that17:47
lpappbluelightning: but it is more like a core package for distributions..17:48
lpappcannot mention any distribution without it.17:48
bluelightningpev_: yes, basically as I described above17:49
bluelightninglpapp: it is, and that's why the core bit is not in the BSP17:49
pev_I'll give that a go, thanks.17:50
bluelightningI gotta go, have a good weekend all17:50
lpappbut keymap is in BSP.17:50
lpappnot in core.17:50
pev_You too. Enjoy the sun17:50
frayfor keymaps, you have to have a board that supports 'keys'..  not all of them do17:50
bluelightninglpapp: not the whole recipe, it's a bbappend as I mentioned already17:50
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC17:50
lpappglib is core?!17:51
lpappwhy is a gnome library core?17:52
*** Crofton <Crofton!> has quit IRC17:54
lpappCrofton|work: btw, I would probably use qt5 for a qt frontend of bitbake.17:54
walterslpapp, because it's really good =)17:54
fraylook at the dependency tree.. there are a large number of basic applications these days that require glib17:54
lpappwalters: let us agree to disagree. ;)17:56
lpappfray: same can be said about qt-core17:56
*** mulhern <mulhern!> has joined #yocto17:57
lpappwhat is the recommended place for adding an updated u-boot version and ignore what is in the release?17:57
frayuboot versions are usually tied to the BSP..17:58
lpappupdated u-boot version with one custom patch for our board.17:58
lpappshould I create another layer?17:58
lpappor should I make a new recipe in meta-bsp?17:58
fraySo placing uboot within the BSP layer (and/or patches to the base version) is the usual approach17:58
lpappor a new one in recipes-bsp?17:58
fraynew recipe vs extending the existing is up to the requriements of the BSP creator17:59
fraybut you should have your own BSP layer, and within that layer place the items in similar locations to the existing system..17:59
lpappextending does not help as in our release, the u-boot version is pretty old.17:59
lpappown BSP layer means?17:59
fraystandard practice is when you add functionality to the system you do so in a layer in which you create..18:00
frayyou 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
frayit makes long-term maintenance of the BSP easier18:00
frayapplications generally should not be in the BSP layer, unless the application is specific to functionality of that board18:01
lpappyou mean this?18:01
frayyou create a new layer.. meta-foo18:02
frayyou place the contents within meta-foo.. recipes-*   replacing * with the appropriate directory18:02
lpappwhy are there a few layers by default?18:02
lpappI am especially thinking of meta-yocto?18:03
fraythey group the software and help delinate maintenance responsibilities..18:03
fraymeta -- oe-core, meta-hob and meta-skeleton come from oe-core..18:04
fraymeta-yocto-bsp and meta-yocto come from the Yocto Project18:04
frayfor 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
lpappso there is someone sync'ing up with oe upstream?18:05
frayadding in the meta-yocto and meta-yocto-bsp layers add additional functionality18:05
frayBSP-layers usually consist of the machine configuration, and patches as part of the linux recipe18:06
lpapp -> so meta-qt5 is not planned to be an addition here for the next release so far...18:06
lpappso by the easy way, it was meant like we can clone the meta-qt5 repository, and copy into the yocto project folder?18:06
fraythat is the current state of Poky18:07
fraythat is the current state of oe-core.. you will see they are very similar..18:07
fraypoky is made up of oe-core + meta-yocto18:07
lpappso we should clone that, and copy into the poky tree?18:08
fraypoky is provided as a unit as a convienence to developers so they don't have to assembly it themselves..18:08
lpappthat is what "easy" means, right?18:08
frayyou should clone it, and add it to your projects bblayers.conf file18:08
lpappk, ty...18:08
lpappg2g, take care18:08
*** lpapp <lpapp!~lpapp@kde/lpapp> has quit IRC18:09
trollixxI have a problem with meta-qt5, my recipe does not set proper paths until I copy-paste OE_QMAKE_PATH_HEADERS and others from into my .inc. How to avoid this?18:11
*** jbaxter <jbaxter!> has quit IRC18:14
*** Crofton <Crofton!> has joined #yocto18:16
*** mulhern <mulhern!> has quit IRC18:18
ftonellois avahi a DISTRO_FEATURE?18:20
ftonelloit should be18:20
JaMatrollixx: that's OK, see wiki on meta-qt518:24
JaMatrollixx: only QT_HEADERS should be needed18:24
*** zecke <zecke!> has quit IRC18:24
kergothwho was it that was doing most of the read-only-rootfs work, again?18:27
trollixxJaMa: thanks, I missed it in wiki18: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 constructions18:28
*** jbaxter <jbaxter!> has joined #yocto18:29
sgw_kergoth: that was a guy in china, Qi Chen18:29
*** dvhart <dvhart!> has joined #yocto18:29
*** mulhern <mulhern!> has joined #yocto18:30
kergothaside: 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 ugly18:30
trollixxJaMa: Isn't it possible to put this path in mkspecs?18:30
JaMatrollixx: 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 worse18:30
JaMatrollixx: the problem is that there isn't good separation between "search" paths and "install" paths18:31
JaMaor at least I haven't found it :)18:31
trollixxHm, ubuntu use the same separation if qt4 and qt5 headers...18:32
ftonelloMy 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 depending18:47
rburtonkergoth: yes, having two solutions for /run is madness.18:48
*** zenlinux <zenlinux!> has quit IRC18:48
ftonellowhat 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
ftonellowhat 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
JaManot magic enough, I want bitbake to append whatever I'm thinking about to that variable before I even write it in the recipe18:59
*** davest <davest!Adium@nat/intel/x-uzremjzumkclkjoo> has quit IRC18:59
*** dvhart <dvhart!> has quit IRC19:00
*** joeythesaint <joeythesaint!~jjm@> has quit IRC19:00
ftonelloseebs_: ok19:03
ftonellobut still doesn't make sense why libnss-mdns (and then avahi) is been installed in the image19: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 IRC19:08
*** dvhart <dvhart!~dvhart@> has joined #yocto19:08
*** mulhern <mulhern!> has quit IRC19:09
*** Crofton <Crofton!> has quit IRC19:11
*** jbaxter <jbaxter!> has quit IRC19:15
*** davest <davest!Adium@nat/intel/x-nhhvcrebszexdbis> has joined #yocto19:24
*** seebs_ is now known as seebs19:25
*** Umeaboy <Umeaboy!> has joined #yocto19:26
rtollertseebs ftonello: fwiw, libnss-mdns can optionally query avahi for cached mdns resolution, so that's where that dep is coming from19:27
*** mitz <mitz!> has joined #yocto19:29
*** jbaxter <jbaxter!> has joined #yocto19:34
*** lpapp <lpapp!> has joined #yocto19:47
lpappfray: wn19:47
lpappwas tnere19:47
lpappsorry, lemme try again. :)19:47
lpappfray: was there anything else you wanted to share with me?19:47
*** doerrpau <doerrpau!> has joined #yocto19:59
*** davest <davest!Adium@nat/intel/x-nhhvcrebszexdbis> has quit IRC20:02
*** b46258 <b46258!> has quit IRC20:04
*** tomz is now known as Guest6120320:07
*** vmeson <vmeson!~quassel@> has quit IRC20:13
*** zecke <zecke!> has joined #yocto20:14
*** Guest61203 <Guest61203!> has left #yocto20:19
*** agust <agust!> has joined #yocto20:21
*** mulhern <mulhern!> has joined #yocto20:36
*** andyross <andyross!> has quit IRC20:40
*** andyross <andyross!> has joined #yocto20:40
*** andyross <andyross!> has quit IRC20:43
*** jukkar <jukkar!~jukka@> has quit IRC20:46
*** jukkar <jukkar!jukka@nat/intel/x-syjnedmkrvxxshrv> has joined #yocto20:47
*** smartin <smartin!> has joined #yocto20:48
*** andyross <andyross!> has joined #yocto20:48
*** smartin_ <smartin_!> has quit IRC20:49
*** andyross <andyross!> has quit IRC20:50
*** zecke <zecke!> has quit IRC20:50
*** vmeson <vmeson!~quassel@> has joined #yocto20:51
*** andyross <andyross!> has joined #yocto20:52
*** mulhern <mulhern!> has quit IRC20:55
*** zz_ka6sox is now known as ka6sox20:57
*** andyross <andyross!> has quit IRC20:58
*** andyross <andyross!> has joined #yocto21:00
*** andyross <andyross!> has joined #yocto21:00
*** andyross <andyross!> has quit IRC21:04
*** mulhern <mulhern!> has joined #yocto21:06
*** andyross <andyross!> has joined #yocto21:06
*** andyross <andyross!> has quit IRC21:08
*** andyross <andyross!> has joined #yocto21:08
*** zenlinux <zenlinux!> has joined #yocto21:10
*** zecke <zecke!> has joined #yocto21:17
*** andyross <andyross!> has joined #yocto21:17
ftonellortollert: i didn't get it21:25
rtollertftonello: 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 for which task is bringing in one of those two?21:27
*** walters <walters!> has quit IRC21:32
ftonellortollert: 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!> has quit IRC21:51
*** mulhern <mulhern!> has quit IRC21:51
*** sameo <sameo!samuel@nat/intel/x-qmzdffcvaeqpthpx> has joined #yocto22:01
*** ant_home <ant_home!> has joined #yocto22:02
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-yzedatloardeilrd> has quit IRC22:04
*** lpapp <lpapp!> has quit IRC22:04
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nkhezizjutzamkpd> has joined #yocto22:04
*** challinan <challinan!> has quit IRC22:06
*** Garibaldi|work <Garibaldi|work!~andydalt@nat/cisco/x-nkhezizjutzamkpd> has quit IRC22:06
*** tinti_ <tinti_!~tinti@pdpc/supporter/student/tinti> has quit IRC22:07
*** JYDawg_ <JYDawg_!> has quit IRC22:39
*** JYDawg <JYDawg!> has joined #yocto22:39
*** dvhart <dvhart!~dvhart@> has quit IRC22:39
*** doerrpau <doerrpau!> has quit IRC22:48
*** andyross <andyross!> has quit IRC22:52
*** mulhern <mulhern!> has joined #yocto23:17
*** agust <agust!> has quit IRC23:18
*** ant_home <ant_home!> has quit IRC23:21
*** dvhart <dvhart!> has joined #yocto23:30
*** cetola <cetola!> has quit IRC23:35
*** jbaxter <jbaxter!> has quit IRC23:35
*** mulhern <mulhern!> has quit IRC23:49

Generated by 2.11.0 by Marius Gedminas - find it at!